サービスレベルに応じてデータベースの可用性を確保する「Oracle Maximum Availability Architecture」とは何か？：データベースクラウドに求められる3つの要件（1）（3/4 ページ）

Oracle Database 12cによるプライベートクラウド環境の構築に際して課題となることの1つが、必要な「可用性」をいかにして確保するかということだ。オラクルは、サービスレベル要件に応じてデータベースシステムの可用性を確保するためのブループリントとして「Oracle Maximum Availability Architecture」を提唱している。[プライベートクラウド/データベース統合][高可用性/災害対策][Oracle Database 12c]

[PR／＠IT]

Oracle RACに組み込まれた高可用性を実現するテクノロジー

　Oracle RACでは、可用性を維持するために複数の方法で監視を行う。具体的には、Oracle Clusterwareによるクラスタノードメンバーシップの監視やOracle Database／Oracle ASMの各インスタンス間でのメンバーシップ監視など、大きく5つの方法で監視が行われ、異常を検知すると即座に異常ノードまたはインスタンスが排除される。その後、ノード異常の場合にはクラスタノードを再構成し、リソースの再配置を行って復旧する。この一連の処理が自動的に行われるわけだ。

　アクティブ／アクティブなHA構成のデータベースシステムにおいて、管理者が不安を感じるのは、「処理を行っている最中に障害が発生してサーバがダウンした場合、処理中のデータはどうなるのか」ということだろう。データベース処理の結果をコミットしたタイミングでディスクに書き込まれるのはREDO情報だけであり、実際のデータはメモリ上にしかなく、障害によってデータが失われる可能性がある。

　だが、Oracle RACに関して、その心配は無用だ。Oracle RACでは、障害が発生したノードで処理していたREDOログを即座に正常稼働しているノードに読み込み、自動的にリカバリ処理を実施する。ダウンしたノードが直前に行っていた処理の内容を正常なノードで復元するため、コミットしたデータが失われることはない。これは共有ディスク型のOracle RACならではの強みであり、ミッションクリティカルなシステムでも安心して使うことができる。

　Oracle RACでは、アプリケーション側でノード障害などを検知し、接続先データベースを切り替えるといった処理も不要だ。個々のデータベースではなく、複数ノードを抽象化した“サービス”に対して接続するため、アプリケーションが個別のノードを意識せずに済むのである。もちろん、接続先は自動的に正常ノードに振り分けられる他、障害が発生したノードとの接続に使われていたコネクションを即座に破棄し、正常なノードに切り替える仕組みも備わっている。

　ちなみに、クライアントがノードに接続する際のIPアドレスとしては、ホスト名にひも付く実際のIPアドレスではなく、Oracle RACが割り当てる仮想的なIPアドレス「SCAN VIP/VIP」が使われる。ノード障害によりサーバが停止した際、通常のIPアドレスを使っている場合はタイムアウトするまで再接続を待たされることになる。しかし、Oracle RACでは、異常が発生したノードに割り当てられたVIPを即座に正常なノードに割り当て直すため、クライアントはタイムアウトを待つ必要がない。ノード障害を意識せず、常に正常稼働しているノードに接続できるのだ。

ストレージの柔軟かつ効率的な運用を実現するテクノロジー

　Oracle ASMも、多くの企業がOracle RACとともに活用している、データベースシステムの可用性向上に有効なテクノロジーである。これはストレージ仮想化を実現するボリュームマネジャ兼ファイルシステムであり、Oracle Databaseのエディションに関係なく利用することができる。つまり、Standard Editionでも使えるわけだ。

　データベースを運用する中では、最初のサイジング時に想定していた以上にデータ量が増大してしまうといった事態がしばしば発生する。これにはディスク増設で対応することになるが、その際に問題となるのが「ホットスポット」である。容量不足を補うためにディスクを追加すると、新たなデータは増設したディスクにばかり書き込まれることになり、参照系の処理は大量の過去データが蓄積された旧ディスクに集中する。このようにI/Oが偏ることをホットスポットと呼ぶが、これが発生するとディスクの性能を十分に生かせなくなってしまう。それを防ぐには、データを別の場所でアンロードし、RAIDを切り直してロードし直すといった作業が必要になるが、それには相応の手間と時間を要する。

　このようなストレージ管理の問題を解決するのがOracle ASMである。このテクノロジーは「S.A.M.E（Stripe And Mirror Everything）」という設計思想に基づいており、ストライピングによって全てのディスクにデータを分散配置し、さらにミラーリングまで行う。データの分散配置によって各ディスクのI/O帯域をフルに活用しつつ、データのミラーリングによって可用性も確保しているわけだ。

ミラーリング機能により、ディスク障害時もアプリが継続動作

　Oracle ASMでは、ミラーリングに関する動作方式として「External（ミラーなし）」「Normal（1組のミラー）」「High（2組のミラー）」のいずれかを選択することができる。NormalまたはHighを選ぶと、読み取り処理時にI/Oエラーを検知し、不良ブロックがあると判断した際にミラーとして保存したデータを使って自動修復する機能が有効になる。

　書き込み処理時にI/Oエラーを検知すると、ディスクに障害が発生したと判断してオフライン化が行われる。読み取り、書き込みエラーともに透過的に処理が行われるので、クライアント側にはエラーを返さない（アラートは通知される）。そのため、アプリケーション側ではディスク障害を意識することなく、データベースに対する処理を継続できる。

　このミラーリング機能では、ユーザーが設定した障害グループを使ってディスクを選択することで、耐障害性を高めているのも大きなポイントだ。具体的には、単に異なるディスクにミラーを書き込むのではなく、オリジナルを書き込んだディスクと同時に障害が発生する可能性のあるディスクにはミラーを書き込まないようにディスクを選択する。こうして適切に障害グループを設定すれば、オリジナルとミラーを書き込んでいる両ディスクで同時に障害が発生し、どちらのデータも読み取れなくなるといったリスクを回避できる。

動的リバランス機能でホットスポットの問題にも対処

　Oracle ASMには、リバランスの機能も備わる。これはディスクを追加あるいは削除した際、自動的にデータを再配置する機能だ。これによって特定のディスクにデータが偏るホットスポットの発生を防ぎ、ディスクのI/O性能を余さず生かすことができる。オンラインで処理が行われるため、データベースを止める必要がないことも、手動でのデータ再配置に対する大きなアドバンテージである。