Oracle RAC 10g＋HP Serviceguardの勘どころ・前編

まずはHAクラスタとRACによるクラスタの違いについて再確認しておきたい。

以前の特集「HAクラスタの疑問を解く」でも説明したとおり、HAクラスタでは1台の共有ディスクを複数のノードに接続する。たとえばHAクラスタ上でOracleデータベースを運用するケースを考えてみよう。プライマリ・ノードの障害時には、スタンバイ・ノード側で共有ディスクのボリュームをマウントし直したあと、Oracleインスタンスを起動する。その後、スタンバイ・ノードによってサービスが再開される。共有ディスク上のデータベースをオープンできるのは、つねに1つのノードに限定されている。

一方RACによるクラスタでも、1台の共有ディスクを複数のノードに接続するという構成は変わらない。異なるのは、すべてのノード上でOracleインスタンスが常時起動しており、それぞれが共有ディスク上のデータベースを同時にオープンしている点だ(図1)。もちろん、普通のデータベースでこのようなことをすれば、共有ディスクにI/O負荷が極端に集中するし、データの整合性も維持できない。

こうしたアーキテクチャの違いから、RACによるクラスタは、通常のHAクラスタでは得られない以下のようなメリットを提供する。

• インスタンス起動が不要なため短時間でフェイルオーバできる
• 負荷分散によりスケーラビリティが大幅に向上する

HAクラスタでのフェイルオーバでは、Oracleインスタンスの起動のために数10秒〜数分の時間を要する。これに対し、RACではOracleインスタンスの起動はすべてのノードで動作しているため、あらためて起動する時間がかからない。さらにRACではCache Fusionによる負荷分散のおかげで、すべてのノードのプロセッサーとメモリを活用でき、格段に高いスケーラビリティを実現できる。この2点がRACのアドバンテージである。

HAクラスタと同様に、RACにおいてもノードやネットワーク、Oracleインスタンスなどの障害をきっかけとしてフェイルオーバが開始される。HAクラスタとは異なり、RACではOracleインスタンスの起動や共有ディスクのボリュームのマウントは不要だ。ただしその他のフェイルオーバ処理、たとえば障害の検知をはじめ、スプリット・ブレイン（障害によりクラスタが分裂する現象）の解決、クラスタの再構成、IPアドレスの引き継ぎといった処理は、HAクラスタと同じく必要になる。またダウンしたOracleインスタンスの代わりを務めるOracleインスタンスでは、共有ディスク上に残されたREDOログをもとにトランザクションのロール・フォワードやキャッシュのリカバリなどを実施する。

Oracle RAC 10gからは、RACのフェイルオーバを実現する手段として、オラクル製のクラスタウェアCluster Ready Service(CRS)が標準コンポーネントとして提供されるようになった。

そこで以下ではCRSがどのように構成されているかを概観し、システム、OSレベルのイベント、RAC以外のアプリケーションの監視に必要となるSGeRACと共存させる際に考慮すべきポイントを説明したい。