スプリットブレイン時の動作

スプリットブレイン時の動作

   さてこれまでの説明で、LifeKeeperが実装するクラスタ技術の大まかな仕組みと特長はご理解いただけたと思う。次に、OracleをLifeKeeperでクラスタ化した場合のスプリットブレイン時のLifeKeeperの動作について説明する。

   図6はOracleリソースの階層構造である。構成要素はIPリソース、ファイルシステムリソース、Oracleリソースである。

図6：Oracleリソース階層

   この構成は、「IPリソース（親） → Oracleリソース（子） → ファイルシステムリソース」というように従属しており、親リソースであるIPリソースがActiveとなるためには、子リソースであるOracleリソー スがActiveでなければならない。さらに、OracleリソースがActiveとなるためには、ファイルシステムリソースがActiveにならなけれ ばならないという順序関係を持っている。

   サーバhp1でリソース階層全体がActiveとなっており、サーバhp2がStandbyである状態で、すべてのハートビートが障害となると、サーバhp1とサーバhp2の両方でリソースの引き継ぎ処理が実行される。

   しかし、すでにすべてのリソースがActiveとなっているサーバhp1はサーバhp2から引き継ぐべきリソースがないため、数秒で処理は終了し運 転を継続する。一方、サーバhp2ではOracleリソースがStandby状態となっているので、LifeKeeperはこれらのリソースの引き継ぎ処 理を実行する。引き継ぐ順番は一番下の階層にあるリソースつまりDiskリソースの引き継ぎから開始される。

   先に述べたようにLifeKeeperはアクセス制御をSCSI Reservationによって行っているので、リソースをActiveにするにはこのDiskリソース（LUN）にロックをかけなければならない。しか し、サーバhp1では引き続きOracleサービスは稼動中でLUNはロックされたままなので、サーバhp2がSCSI Reservationを発行するとReservation Conflictというエラーとなってしまう。ここでLifeKeeperはハートビートが途絶えている状態であることを認識しているため、強制的にロッ クを奪取する動作に移る。

   具体的にはTarget ResetをLUNに対して発行しLUNロックを強制的に解除した後、再度SCSI Reservationを発行するのである。強制的にLUNロックの奪取に成功したサーバhp2は順次上位のリソースの起動処理に入る。そして、ファイル システムの起動処理が完了したら、次にOracleリソース起動が実行される。最後に最上位のリソースであるIPリソースの起動が行われて、Oracle リソース全体の引き継ぎが完了する。

   一方、ロックを奪取されてしまったサーバhp1は、ロックの確認を実行してReservation Conflictエラーを検出する。そして、スプリットブレインが発生しサーバhp2がロックを奪取したと判断し、自らサービスを開放すべく OSのリブートを実行するという動作に入る。 ファイルシステムリソースが存在する場合はこのようにActive側がロックを奪取されることをトリガーとしてリブートし共有データを保護する。

   もしファイルシステムリソースが存在しない場合にはこのようなリブートは起こらない。例えばIPリソースしかないクラスタ環境の場合、ハートビート 障害が起きると、IPリソースはサーバhp1とサーバhp2の両方でActiveになってしまいそうである。しかし、LifeKeeperのIP ARKはIPリソースをActiveにする時点で、ネットワーク上に同一のIPアドレスが存在していないかどうかのチェックを行なうため、もしIPリソー スがサーバhp1でActiveであればサーバhp2でのIPリソースの起動は失敗するシナリオとなっている。

   LifeKeeperはこのように様々な状況に的確に対応できるシナリオによって、データの保護およびサービスの保護を実現している。

まとめ

   LifeKeeperの実装するクラスタ技術の実装について簡単に説明をしたが、実際の構築方法や操作などについては紙面の都合で触れることができなかった。

   それらに関しては連載「LifeKeeperのすべて」を是非ご参照いただきたい。今後、LifeKeeperのインストールから設定、操作方法などについて解説をしていく予定である。