SCSI リザベーションを利用したストレージフェンシング

LifeKeeper for Linux は、リソースフェンシングとノードフェンシングの両方をサポートしますが、主要なフェンシングメカニズムは、SCSI リザベーションによるストレージフェンシングです。共有ストレージに対する最高レベルのデータ保護を提供するこのフェンシングを使用すると、非常に粒度の高い LUN レベルのロックによって最大限の柔軟性と最大限のセキュリティが可能になります。このアーキテクチャでベースとなる共有リソース (LUN) は、プライマリ quorum デバイスです。 quorum は、共有ストレージに対する排他的なアクセスと定義できます。つまり、この共有ストレージは 1 度に 1 台のサーバからしかアクセスできません。 quorum (排他的アクセス) を持つサーバは、「プライマリ」の役割を持ちます。 quorum の確立 (排他的アクセスをどのサーバに与えるか) は、「quorum デバイス」によって行われます。

上述の通り、リザベーションが有効の場合、quorum デバイスはその共有リソースです。共有リソースは、共有リソースに対するリザベーションを持つサーバを判断して quorum を確立します。これにより、ある 1 つのサーバがその LUN にアクセスできる限り、クラスタは実質的には単一のサーバで運用されることになります。

SCSI リザベーションは、共有のユーザデータを保護し、LifeKeeper が指定するシステムのみデータを変更できるようにします。クラスタ内外の他のシステムがそのデータを変更することは許可されません。さらに SCSI リザベーションによって、クラスタ内の複数のサーバで障害が起きた場合に、LifeKeeper 保護下のアプリケーションは共有のユーザデータに安全にアクセスできます。サーバの多数派 quorum は必要ありません。唯一の要件は、共有データの所有権の帰属が確立していることです。

quorum/witness 機能を追加すると、 quorum のメンバーシップを確立することができます。このメンバーシップがない場合、スプリットブレインの状況で複数のサーバ (場合によっては全サーバ) がお互いを終了させることも考えられます。リザベーションが有効になっている構成に Watchdog を追加すると、部分的にサーバがハングしている状態からリカバリするメカニズムが提供されます。ハングしたサーバが LifeKeeper に検出されないような場合に、Watchdog はリカバリを開始します。また、サーバがハングしてさらにリザベーションが奪われた場合に、Watchdog はそのサーバをリブートしてリカバリを開始することができます。

I/O フェンシングのための代替方式

SCSI リザベーションを利用したリソースフェンシングに加えて、LifeKeeper for Linux はリザベーションの無効化もサポートします。リザベーションが有効か無効にかかわらず、以下の 2 つの点に注意すべきです。

  • ストレージへのアクセスは LifeKeeper が制御する必要があります。
  • ストレージへの意図しないアクセス (ファイルシステムのマウント、手動の fsck など) が発生しないように細心の注意を払う必要があります。

以上の 2 つのルールを順守してリザベーションを有効にすると、LifeKeeper はたいていのエラーを防止できます。リザベーションが (単独で) 無効になった状態は、保護がない状態です。したがって、この保護を実現するには、他の選択肢を検討する必要があります。以降のセクションでは、SCSI リザベーションなしでも LifeKeeper で非常に信頼性の高い構成を実現できる各種のフェンシングオプションと代替方式を説明します。

フィードバック

お役に立ちましたか?

はい いいえ
お役に立ちましたか
理由をお聞かせください
フィードバックありがとうございました

このトピックへフィードバック

送信