データベースを運用するにあたって、可用性を担保する方法についての検討は避けられないものです。
Oracle Databaseでは、Oracle SEHAとRACがHA構成を構築するための方法として挙がりますが、この二つの詳細な違いまでは把握していない担当者様も多いでしょう。
そこで今回は、Oracle SEHAの機能を紹介したうえで、RACとの違いを徹底解説いたします。
「HA化するための最適な手段を知りたい」とお考えの担当者様は、ぜひ本記事の内容を参考としてください。
目次
Oracle SEHAとは
シングルインスタンスのOracle Database にて、クラスターベースのフェイルオーバーを可能とするための機能が、Oracle SEHAです。
2台以上のサーバーをクラスター化し、一つのサーバーに障害が発生した場合でも、残りでデータベースとしての機能を提供しつづけるHA構成を実現します。
このような高可用性を実現するための手段として、Oracle DatabaseにはRAC（Real Application Clusters）という機能も存在します。
以前はStandard Edition 2とEnterprise Editionの両方で利用可能でしたが、Oracle Database 19cのリリース以降、前者でRACが使えなくなってしまったのです。
その代わりに、Standard Edition 2で可用性を担保するための手段として、今回解説するOracle SEHAが登場したという経緯があります。
Oracle SEHAが提供する機能
Oracle SEHAを理解するうえで特に重要となるのが、以下の３つの機能です。
フェイルオーバー
Oracle SEHAのクラスターを構成するのが、稼働中のアクティブノードと待機中のパッシブノードです。
通常時はアクティブノードでデータベースを稼働させますが、障害が発生した際は、パッシブノードへの切り替えが自動的に行われます。
この一連のプロセスがフェイルオーバーであり、Oracle SEHAの提供するもっとも重要な機能です。
フェイルオーバーは、大まかには以下の流れで実行されます。
フェイルオーバーの基本的な流れ
- アクティブノードで障害が発生する
- アクティブノードからのハートビートがなくなり、障害が検知される
- パッシブノードへの切り替えが自動で行われる
- 障害が発生したノードの再起動が行われ、以降パッシブノードとなる
接続先フェイルオーバーを事前に設定しておけば、切り替えの際、アプリケーション側でデータベースの接続先を明示的に変える必要はありません。
また、データは各ノードからアクセス可能な共有ディスクに保管されています。
フェイルオーバーのたびにリマウントしなくてもよいため、比較的迅速にデータベースの利用を再開できます。
10日間ルールについて
クラスター環境下でのフェイルオーバーには、Oracleの“10日間ルール”が適用されます。
これは、年間で合計10日間以内であれば、待機系のサーバーを本番系のサーバーのライセンスで稼働させてもよい、というものです。
つまり、Oracle SEHA構成でパッシブノードの稼働が年間10日間を超えないなら、アクティブノードのライセンスだけでデータベースを運用できるわけです。
詳細な条件はOracleのドキュメントに記載がありますので、実際に運用される際は、まずそちらをご参照ください。
参照元：Oracle「データ・リカバリ環境におけるライセンス」
正常性の監視
フェイルオーバーを可能とするためには、アクティブノードの正常性監視も欠かせません。
Oracle SEHAにおける正常性監視では、以下の要素についてCSSとCRSによる監視が行われます。
Oracle SEHAでの正常性監視の対象
- アクティブノードとパッシブノードのネットワーク
- 各ノードから共有ディスクへのアクセス
- 各ノードの状態
正常性監視の結果、アクティブノードに問題があればフェイルオーバーが発生する、という流れです。
リソースの管理
Oracle SEHAは、Oracle Grid Infrastructureと完全に統合されています。
そのため、クラスター内のネットワークやノード、ディスクなどの各種リソースを管理する機能も備わっています。
Oracle SEHAとRACの違い
Oracle SEHAとRACは、「データベースの可用性を担保する」という点で共通していますが、以下の通り、その実現方法や仕組みはまったく異なります。
【Oracle SEHAとRACの比較表】
| 項目 | Oracle SEHA | RAC |
| 利用可能なエディション | Standard Edition 2
（Oracle Database 19.7以降） |
Enterprise Edition |
| 構成 | Active-Passive | Active-Active |
| フェイルオーバー | 〇 | ─ |
| リロケート | 〇 | ─ |
| 障害時の処理継続性 | × | 〇 |
| ローリングアップデート | × | 〇 |
大きな違いがあるのは、利用可能なエディションとクラスターの構成の2点です。
まずエディションの違いについてですが、これは費用面に大きく影響を与えます。
エディションごとの料金表（Named User Plusに関しては除く）
| Processor License | Software Update
License & Support |
|
| Standard Edition 2 | 2,712,500円 | 596,750円 |
| Enterprise Edition | 7,362,500円 | 1,619,750円 |
このように、Standard Edition 2とEnterprise Editionの費用には大きな差があります。
そのうえで、Oracle SEHAの利用に際しても追加費用が発生することはありません。
コストを抑えつつもデータベースの可用性を担保できるというのは、Enterprise Edition が必要なRAC にはない利点といえるでしょう。
ただし、Active-Passive構成のOracle SEHAでは、フェイルオーバー時に数十秒～数分の空白時間が生じます。
そのため、少しの停止も許されないシステムには採用できません。
一方で、RACは常時すべてのノードが稼働しているActive-Active構成であり、障害発生時もデータベースは稼働しつづけます。
くわえて、ローリングアップデートもサポートしており、システムを稼働させたままパッチを適用できます。
ノードの増減も柔軟に行えるため、リソースの拡張も難しくありません。
参照元：Oracle「Oracle Technology Global Price List」
データベースの可用性を考える際に重要なポイント
Oracle Databaseに限らず、データベースを構築する際には高い可用性を目指すのが一般的です。
ただし、ダウンタイムゼロの構成を常に目指せばよい、というわけではないことも理解しておく必要があります。
高可用性を実現する構成にすれば、当然その分構築コストや運用コストはかさむためです。
システム要件を考慮せずに可用性ばかりを気にしては、思うような費用対効果は得られないでしょう。
たとえば、社内の一部部門だけが利用する、基幹業務に大きく関わらないシステムであれば、万が一停止したとしても直ちに甚大な被害が出ることはありません。
この場合に、コストをかけてダウンタイムゼロのシステムを作る必要性は薄いといえます。
反対に、社会的な重要度が高いミッションクリティカルなシステムでは、SLA100％を目指して構築を進めなくてはなりません。
Active-Active構成による可用性の確保のみならず、拠点間バックアップによるDRなども求められる可能性があります。
このように、「どこまでの可用性を目指すべきなのか？」「どれだけコストを抑えるべきなのか」などをクリアにするうえでは、まずシステム要件をきちんと定めることが大切です。
Oracle SEHAとRACでどちらを使うべきか迷った場合の判断基準
Oracle SEHAとRACの利用可能なエディションが異なることは、前項で説明した通りです。
しかしOracle Databaseでは、エディションのアップグレード・ダウングレードが可能なので、この点だけを選択の際の判断基準とするのは適当ではありません。
自社での利用においてどちらを使うべきか検討する際は、以下の２点を考慮するのが賢明です。
パッシブノードへの再接続に時間がかかることは問題ないか？
繰り返しになりますが、Oracle SEHAはActive-Passive構成のため、障害の際にアプリケーションがパッシブノードへ接続するまでに数十秒～数分ほど要します。
システム要件でこの点が許容できるなら、コスト面に優れるOracle SEHAを検討しても問題ありません。
対して、常時稼働が求められるシステムでは、フェイルオーバーの際のダウンタイムが大きな損害をもたらす可能性があります。
この場合は、障害時もデータベースの稼働が止まらない、Active-Active構成のRACを選ぶべきでしょう。
CPUスレッド数が制限されても問題ないか？
Standard Edition 2では、1つのデータベースで使用可能なCPUスレッド数が16に制限されています。
CPUスレッド数はデータベースの性能に関わる部分であるため、この点の妥協が許容できないのであれば、Enterprise EditionおよびRACの利用をおすすめします。
このほかにも、Standard Edition 2ではEnterprise Editionの有償オプション製品が利用できないなどの制限事項があるので、データベース構築の際は確認しておきましょう。
Oracle SEHAの動作条件
Standard Edition 2でHA構成を実現できるOracle SEHAですが、利用に際しては以下の動作条件を満たす必要があります。
【Oracle SEHAを利用するための動作条件】
| Oracle Databaseのエディション | Standard Edition 2 |
| 対応OS | Linux・Windows・Solaris |
| 対応環境 | オンプレミス環境
仮想環境 |
| ソフトウェア・ハードウェア要件 | Oracle Database 19.7およびOracle Grid Infrastructure 19.7以降のバージョン |
| ディスク構成 | Oracle ASMあるいはOracle ACFS |
上記からもわかる通り、Oracle Database 19.7およびOracle Grid Infrastructure 19.7以降でなければ使えません。
また、既存のOracle Databaseの環境を、Oracle SEHAを用いたHA構成に直接アップグレードすることも不可能です。
新しいバージョンでインストールしなおして、環境を再度構築しなくてはなりません。
Oracle SEHAを利用する際の注意点
最後に、Oracle SEHAを利用する際の6つの注意点を解説します。
利用を開始してから「想定していた運用ができない……」と困ることがないように、以下の内容を把握しておきましょう。
注意点①Oracle Database 19cの初期バージョンでは利用できない
Oracle SEHAが利用できるのは19.7以降のバージョンのみで、 19cの初期バージョン（19.3～19.6）では利用できません。
くわえて、Oracleにて配布されているインストールメディアは バージョン19.3相当であることにも注意しましょう。
Oracle SEHAを用いてHA構成を構築するためには、19.7以降のバッチを別途適用することが求められます。
注意点②パブリッククラウドやOCIにはまだ対応していない
2025年1月時点で、Oracle SEHAはAmazon Web ServicesやMicrosoft Azureといったパブリッククラウドに対応していません。
また、OCI（Oracle Cloud Infrastructure）にも未対応となっています。
オンプレミス環境や自前の仮想環境でOracle Databaseを運用しつづけるなら、この点は問題になりません。
しかしパブリッククラウドへの移行を計画しているなら、Oracle SEHAに変わる構成を検討する必要があります。
代替案の一つとして挙げられるのは、コーソルでも取り扱っているLifeKeeperなどのサードパーティー製のクラスタリングソフトウェアです。
追加費用こそかかってしまうものの、利用のエディションに関係なくHA構成を構築できるうえに、Oracle SEHAではカバーできなかった機能も備えている場合があります。
また、パブリッククラウドが提供するマネージドサービスを利用するのも一案です。
OCIとは
上記で言及したOCIとは、Oracleが提供するパブリッククラウドサービスである、Oracle CloudにおけるIaaSとPaaSに該当するサービス群です。
データベースに関するサービスのみならず、ストレージやネットワーク、セキュリティといった、その他の分野も網羅しています。
注意点③データレプリケーション構成では実現できない
動作条件の項で述べた通り、Oracle SEHAではOracle ASMまたはOracle ACFSにデータを格納します。
これらの機能を使ううえでは、必然的に共有ディスクが必須となります。
システム要件などでデータレプリケーション構成が求められるのであれば、Oracle SEHA以外の手段でHA構成を構築するべきでしょう。
注意点④アプリケーションやミドルウェアのHA化までは叶わない
当然ですが、Oracle SEHAでHA化できるのはOracle Databaseまでです。
アプリケーションやミドルウェアは、ユーザー側が別の手段でHA化しなくてはなりません。
上記に対応するうえでは、監視やフェイルオーバー用のスクリプト作成や、それを設計・実装・試験するための工数など、リソースと時間の両方が必要になります。
データベース構築やシステム開発の知見がない場合には、非常に困難な対応となるのは間違いありません。
また不具合が生じた場合に、ベンダーからのサポートが受けられないなどのリスクも伴います。
注意点⑤GUIベースでの作業ができない
Oracle SEHAに関する操作は現状CUIからのみ可能であり、GUIは対応していません。
またCUIで操作する際にも、データベースの知識とは別に、Oracle Grid Infrastructureの知見が求められます。
Oracle Grid Infrastructureの使用経験に乏しいと、この点も大きなハードルとなるかもしれません。
注意点⑥ユーザー側でカスタマイズできる部分がない
Oracle SEHAで行われる障害の検知やフェイルオーバーなどはすべて自動のため、その回数や回復までの時間をユーザー側でカスタマイズすることができません。
これがすぐに問題となるわけではありませんが、たとえばシステム要件として「ダウンタイムは○○秒以下に抑える」などがある場合には、対応が困難となります。
システム要件にフレキシブルに対応したいのであれば、ほかのHA化手段を検討するのも一つの手です。
Oracle SEHAとRACは利用可能なエディションとクラスターの構成が異なる
今回は、Oracle SEHAとRACの違いを解説しました。
両者は利用可能なエディションとクラスターの構成に違いがあり、この点が運用にも大きな影響を与えています。
コストを抑えたい場合や、フェイルオーバーの際のダウンタイムが許容できるケースでは、Standard Edition 2およびOracle SEHAを使うのがおすすめです。
ただし、Standard Edition 2ではCPUスレッド数が制限されていたり、Oracle SEHAはパブリッククラウド非対応であったりと、注意点があることも把握しておきましょう。
Oracle Databaseのプロフェッショナルであるコーソルでは、Oracle SEHAを用いたHA構成構築の支援サービスを提供しております。
「自社でHA構成を構築するのは難しそうだ……」とお悩みであれば、ぜひ弊社にお問い合わせください。
