検証！RACの耐障害性と拡張性

SPOFのないシステム

今回は、「Oracle Real Application Clusters」（以下RAC）の特徴である耐障害性と拡張性にスポットをあてて紹介します。RACを構成するにあたって、データベースサーバーとしてSPOF（Single Point Of Failure：単一障害点、障害を起こすとシステム全体が停止してしまうようなコンポーネント）があるとその機能を最大限に生かすことができません。極端な例ですが、共有ディスクストレージへのパスが1本の場合、そのパスが障害を起こすとRACといえどもシステム全体が停止してしまいます。

つまり、RACだけではデータベースサーバーの耐障害性を確保できません。RACを構成する場合には、システムコンポーネントにSPOFがないように冗長化を図る必要があります。具体的なコンポーネント名と、想定される障害は以下のようになります。

「インスタンス」には、プロセス障害やソフトウェアバグなどによる停止が想定されます。「ノード」には、ハードウエア故障、OS上の問題などによる停止が、「インターコネクトネットワーク」および「サービスネットワーク」には、パスの切断、スイッチ故障などによる不通が想定されます。「ストレージ」には、パスの切断、スイッチ故障などによるストレージへのアクセス遮断、ディスク障害、コントローラ障害といったストレージの障害が想定されます。

インスタンスとノードに関しては、もちろんRACによって冗長化されます。それ以外のコンポーネントに関しては、RAC以外の機能や製品を利用します。

インターコネクトとサービスネットワークについては、OSのネットワーク冗長化機能を利用します（SolarisのIPMP、Linux/Windowsのチーミングなど）。これらは、パスが切断するなどの障害に対し、別の正常なパスを利用することで、RACに影響を与えることなく継続動作させることが可能です。

ストレージについては、ストレージベンダが用意しているマルチパスドライバーを利用したり、NAS接続の場合は、上述のOSのネットワーク冗長化機能を利用してパスを冗長化します。ストレージ自身については、RAIDによってディスクの障害に備えたり、ストレージコントローラなど、ストレージ自体が内部コンポーネントを2重化したものを利用すると安心です。SPOFがないシステムを図1に示します。

RACだけでなくこうした機能を使用することで、システム停止を防ぐことができますし、障害によってはRACのフェールオーバー処理をさせるまでもなく、継続的に運用を続けることができ、ダウンタイムを減らすことができます。

検証で確かめる

システム構築時に、疑似的に障害を発生させSPOFがないことを実機で確かめることをお勧めします。その際、アプリケーションを用意して実際にRACに処理をさせながら実施すれば、障害時の対応方法の確認やダウンタイムがどの程度発生するかを確認することができ、自信を持って本番運用に望めます。検証実施の際には次の観点で問題がないかをチェックします。

1つ目が「疑似障害発生後の運用継続性確認」です。単一障害を発生させたときに、障害個所に応じて当該機能が作動し、フェールオーバー処理を行い、継続して処理を行えることを確認します。アプリケーションを用いる場合は、アプリケーションがどのような影響を受けるのか（接続は切れないのか、接続先が切り替わるのか、処理が一時的に停止するのか）確認します。

2つ目が「障害時に発生するダウンタイム計測」です。障害が発生するとRACといえども切り替えやフェールオーバーに時間を要します。その間アプリケーションの処理が停滞しますが、その時間がシステム上問題ないものなのかを確認します。

3つ目が「障害復旧時の通常運用構成（正常運用状態）への移行手順の確認」です。復旧作業手順を確認します。ポイントは、システムを止めないまま復旧可能かどうかです。たまにシステムを通常状態に戻すためにシステムをリブートさせるケースがありますが、それでは本末転倒ですので、注意する必要があります。