test

Sun Cluster 2.2 ソフトウェアのインストール

障害防護

どのようなクラスタシステムであれ、ノードがクラスタのメンバーでなくなった場合は、そのノードが多重ホストディスクに引き続き書き込みを行えないようにする必要があります。そのようにしなかった場合、データが破壊される可能性があるためです。クラスタの残りのノードは、多重ホストディスクに対する読み取りと書き込みを開始できる必要があります。クラスタのメンバーでなくなったノードが引き続き多重ホストディスクに書き込みを行うと、残りのノードが行なっている更新内容に混乱が生じ、最終的には破壊されることになります。

クラスタのメンバーでなくなったノードがディスクに書き込みを行うのを防止することを、障害防護といいます。障害防護は、実際のクラスタが異なるパーティションに存在するときに、隔離されたノードがその専用のパーティションに独立したクラスタとして現れるのを防ぐことによって、データの完全性を保証する上で非常に重要です。

注意 - 注意 -

一方のノードに障害が発生した場合、2 つのクラスタノードは非常に異なるビューを持つことになるため、障害ノードが入出力を行えないようにすることは非常に大切です。障害ノードのクラスタビューには両方のクラスタメンバーが含まれるのに対し (再構成されていないため)、残りのノードのクラスタビューはノード 1 つ (残ったノード自体) のクラスタで構成されます。

2 ノードのクラスタで 1 つのノードが停止するか、1 つのノードで問題が発生した場合、もう一方のノードは、障害ノードからのハートビートを検出して、唯一のクラスタメンバーになるように自身を再構成します。この再構成には、共有デバイスを防護して、多重ホストディスクに対する入出力が行われないようにするという処理も含まれます。ノード 2 つだけのあらゆる Sun Cluster 構成において、この処理は、多重ホストディスクに対する SCSI-2 予約機能を利用することによって行われます。残りのノードはディスクを予約し、障害ノードが予約ディスクに入出力を行うのを防ぎます。SCSI-2 予約は本質的に不可分の処理であり、2 つのノードが同じデバイスを同時に予約しようとすると、必ず一方が成功し、もう一方が失敗します。

障害防護 (SSVM と CVM)

障害防護は、クラスタのトポロジによって異なります。最も単純なのは、2 ノードのクラスタの場合です。

2 ノードのクラスタの障害防護

2 ノードのクラスタでは、定足数デバイスによって、クラスタに残るノードが決定されます。障害ノードが定足数デバイスを予約することはできないため、障害ノードはその専用クラスタを起動できなくなります。SCSI-2 予約機能を使用して、障害ノードに防護がはられ、障害ノードによる多重ホストディスクの更新が防がれます。

3 ノード以上のクラスタの障害防護

2 ノードのクラスタで使用される SCSI-2 予約モデルで問題なのは、SCSI 予約がホストに固有であるという点です。共有デバイスに予約要求を発行した場合、事実上、ホストは、障害があるかどうかに関係なく、そのデバイスにアクセスできる別のすべてのノードを締め出します。その結果、OPS などの共有ディスク環境で 3 つ以上のノードが多重ホストディスクに接続されていると、この予約モデルは破綻します。

たとえば、3 ノードのクラスタでノードの 1 つが停止すると、残り 2 つのノードは再構成します。しかし、残りのノードは SCSI 予約要求を発行して、障害ノードから土台の共有デバイスを保護することはできません。これは、SCSI 予約要求を発行すると、一方の残りのノードも締め出されるためです。しかし、予約をしないと、障害ノードが稼動し、そのクラスタビューが最新でなくなっているにもかかわらず、共有デバイスに入出力要求を発行する可能性があります。

すべてのクラスタノードから直接、アクセス可能な記憶装置を持つ 4 ノードのクラスタを考えてみます。ノードの 1 つが停止し、残り 3 つのノードが再構成しても、残りのノードは SCSI 予約要求を発行して、障害ノードから実際の共有デバイスを保護することはできません。これは、予約することによって、正当なクラスタメンバーの一部もデバイスに対して入出力要求を発行できなくなるためです。しかし、予約をしないと、障害ノードが稼動し、そのクラスタビューが最新でなくなっているにもかかわらず、共有デバイスに入出力要求を発行するという危険性があります。

次に、票割れが発生したときの問題を考えてみます。4 ノードのクラスタでは、さまざまなインターコネクト障害が考えられます。ここでは、パーティションの内部の各メンバーは互いに通信でき、パーティションの外部のクラスタノードとは通信できない、一群のクラスタノード全体を 1 つのパーティションと定義します。インターコネクト障害が発生すると、それぞれが 2 ノードで構成される 2 つのパーティション、あるいは 3 ノードと 1 ノードの 2 つのパーティションが形成される状況が考えられます。あるいは、4 ノードのクラスタが、ノードが 1 つずつの 4 つのパーティションになる可能性もあります。このどの状況でも、Sun Cluster は、残すパーティションと終了するパーティションについて、矛盾のない合意を得ようとします。

例 1: それぞれが 2 ノードで構成される 2 つのパーティションが形成された場合。2 ノードのクラスタにおける 1 対 1 の票割れのときと同様、どちらのパーティションの CMM も、残すパーティションと終了するパーティションを最終的に決定するための定足数は得られません。データの完全性と高可用性を実現するには、両方のパーティションを残すか、両方のパーティションを停止します。ノード 2 つのクラスタのときと同様、この問題は外部のデバイス (定足数ディスク) によって決定される可能性があります。それぞれのパーティション内の指名されたノードは、指定された定足数デバイスの予約を争うことができ、いずれかのパーティションが予約に成功します。そして、SCSI-2 予約の性質上、定足数デバイスの予約に成功したノードは同じパーティション内のもう一方のノードがデバイスにアクセスできないようにします。定足数デバイスには有用なデータが含まれており、もう一方のノードが定足数デバイスにアクセスすることが望ましくないためです。

例 2: 3 ノードと 1 ノードの 2 つのパーティションが形成された場合。過半数のパーティションが十分な定足数を得ているとしても、ここで最も重要な問題は、単独で分離されたノードが別の 3 つのノードに何が起きたのか分からないということです。3 つのノードが有効なクラスタを形成していれば、この単独ノードは終了すればよいでしょう。しかし、3 つのノードが有効なクラスタを形成していないことも考えられます。何らかの理由で、3 つのノードのすべてで問題が発生しているかもしれません。この場合、単独で切り離されたノードは踏査し続け、可用性を維持する必要があります。完全に通信手段が失われていて、調停する外部デバイスが存在しない場合は、決定することは不可能です。構成済みの外部定足数デバイスの予約を争うと、結果的に例 1 よりもさらに悪い状況になります。過半数パーティションのノードの 1 つが定足数デバイスを予約した場合、そのノードは、同じパーティション内の別の 2 つのノードがその定足数デバイスにアクセスできないようにします。しかし、さらに悪いことに、単独で分離されたノードが予約に成功した場合は、正常な可能性のある 3 つのノードがクラスタから失われる可能性があります。ここでもまた、ディスク予約による解決はうまく機能しません。

ディスク予約手法を利用できない場合もまた、インターコネクト障害や操作エラーが発生したときに、それぞれが分離された専用のパーティション内に複数の独立したクラスタが形成されやすくなります。上記の例 2 を考えてください。CMM または外部エンティティが何らかの方法で、過半数パーティションの 3 つのノードが留まり、単独で分離されたノードが終了するよう決定し、後で管理者が、インターコネクトを修復することなく終了されたノードを起動しようとしたと仮定します。単独ノードは依然として、どの残りのメンバーとも通信できないため、クラスタ内の唯一のノードと考えて、定足数デバイスを予約しようとします。上記で説明した理由により、事実上、低速デバイスの予約はないので、この試みは成功し、単独のノードは、自身を唯一のクラスタメンバーとする独立したクラスタを形成します。

つまり、すべてのノードから直接、アクセス可能な記憶装置を持つ 3 ノードまたは 4 ノードのクラスタに対して、単純な定足数予約手法は利用できません。次の 3 つの問題を解決するには、新しい手法が必要です。

  1. 3 ノードまたは 4 ノードのクラスタにおける票割れ状態をすべて解決する方法

  2. 障害ノードから共有デバイスを障害防護する方法

  3. 分離されたパーティションが複数の独立したクラスタを形成するのを防ぐ方法

3 ノードまたは 4 ノードのクラスタにおける票割れ状態を解決するには、 手動介入段階の操作エラーによってクラスタの完全性が損なわれる可能性があることに注意しながら、発見的な手法と手動介入を組み合わせます。「定足数デバイス (SSVM と CVM)」では、3 ノード以上のクラスタについて、クラスタパーティションが発生した場合の処置を決定するために指定できるポリシーについて説明しました。干渉主義のポリシーを選択した場合、すべてのパーティションの CMM は、各パーティションのすべてのクラスタ動作を一時停止して、有効なクラスタを形成し続けるパーティションと終了するパーティションについて、オペレータからの入力を待ちます。この場合、特定の 1 つのパーティションを残して、別のすべてのパーティションを終了させる作業は管理者が行います。複数のパーティションが有効なクラスタを形成できるようにすると、読み出し不可能なデータ破壊が発生する可能性があります。

事前決定的なポリシーを選択した場合は、優先するノード (クラスタ内の最大または最小のノード ID を持つノード) が要求され、票割れ状態が発生すると、優先ノードを含むパーティションが自動的に新しいクラスタになります (可能な場合のみ)。この場合、別のすべてのパーティションは、管理者が介入することによって、手動で終了する必要があります。2 ノードのクラスタの場合、選択された定足数デバイスは、票割れが発生したときに同数になるのを防ぐ目的にのみ使用されます。票割れ状態は、4 ノードのクラスタでも発生することがあります。4 ノードのクラスタで票割れ状態が発生すると、2 つのクラスタメンバーだけアクティブになります。ここでも定足数デバイスは 1 つの役割を果たしますが、その働きは限られたものです。

パーティションを残すように選択した後で問題になるのは、終了しているはずの別のパーティションからどのようにデータを効果的に保護するかということです。別のすべてのパーティションを終了しようとしても、パーティションを終了するコマンドがすぐには正しく実行されない可能性があります。効果的な障害防護機能がないと、終了要求を処理する前に、停止したノードが突然再稼動し、共有デバイスに保留中の入出力要求を発行する危険性が常に伴います。この場合、障害ノードは、パーティション内に有効なクラスタが形成される前にリセットされます。

障害ノードが再稼動して、多重ホストディスクに入出力要求を発行するのを防ぐには、残りのノードの 1 つが障害ノードを強制的に終了させ、端末集配信装置またはシステムサービスプロセッサ (Sun Enterprise 10000 システムの場合) によって、そのノードを OpenBoot PROM モードにして、オペレーティングシステムの停止イメージを終了します。OpenBoot PROM のプロンプトに対して go と入力することによって、誤ってシステムの動作が再開されるのを防止します。残りのクラスタメンバーは、クラスタの再構成プロセスに進む前に終了処理からの肯定応答を待ちます。

終了コマンドに対する応答がない場合は、パワーシーケンサ (存在する場合) が動作して、障害ノードの電源が入れ直されます。この動作に失敗した場合、システムは次のメッセージを表示して、クラスタの再構成を続行するための情報の入力を求めます。

/opt/SUNWcluster/bin/scadmin continuepartition localnode clustername
¥007*** ISSUE ABORTPARTITION OR CONTINUEPARTITION ***
You must ensure that the unreachable node no longer has access to the 
shared data. You may allow the proposed cluster to form after you have 
ensured that the unreachable node has aborted or is down.
Proposed cluster partition:
注 -

残りのノード上で scadmin continuepartition コマンドを発行する前に、必ず、障害ノードを正しく終了させてください。

パーティション化されて、分離され、終了されたノードは、最終的には起動します。何らかの誤りで、管理者がインターコネクトを修復することなくそのノードをクラスタに結合させようとした場合は、そのノードが既存のクラスタと通信できないときに、独自の有効なクラスタパーティションを形成するのを防ぐ必要があります。

3 ノードと 1 ノードの 2 つのパーティションが形成されていると仮定します。この場合は、過半数パーティションの指定されたノードは分離されたノードを終了し、3 つのノードはそれら専用のパーティション内に有効なクラスタを形成します。その後、管理者が startcluster(1M) コマンドを実行して、確認を求められたときに肯定的な応答をすると、分離されたノードは、起動後に独自のクラスタを形成しようとします。分離されたノードは自身がクラスタ内の唯一のノードであると判断するため、定足数デバイスの予約を試み、実際にその試みに成功します。これは、有効なパーティション内に 3 つのノードがあり、そのどれも、別のノードを締め出すことなしに定足数デバイスを予約できないためです。

この問題を解決するには、「ノードロック」という新しい概念が必要になります。この概念では、クラスタメンバーシップ内の指定されたクラスタは、クラスタの再構成の一環として、端末集配信装置の未使用ポートに対する telnet(1) セッションを開き、クラスタのメンバーである間、そのセッションを継続します。このノードがメンバーシップから切り離されようとすると、ノードロックは、残りのクラスタメンバーの 1 つに渡されます。上記の例で、分離されたノードが独自のクラスタを形成しようとする場合、そのノードはノードロックの取得を試み、失敗します。これは、別のパーティション内のメンバーシップノードの 1 つがノードロックを保持しているためです。有効なクラスタメンバーの 1 つが何らかの理由でノードロックを取得できなかった場合、そのことが重大なエラーとはみなされることはありませんが、ただちに対応する必要があるエラーとして記録されます。ロック機能は、クラスタの運用に不可欠な機能ではなく、安全上の機能とみなされ、ロック機能に問題が発生しても、危機的なエラーとはみなされません。ロックにおける障害を素早く検出するために、Sun Cluster フレームワーク内の監視プロセスは、端末集配信装置がクラスタノードからアクセスできるかどうかを監視します。

障害防護 (Solstice DiskSuite)

ボリュームマネージャとして Solstice DiskSuite を使用する Sun Cluster 構成では、Solstice DiskSuite 自体がクラスタの定足数を決定し、障害防護機能を提供します。障害防護について、クラスタのトポロジによる明確な違いはありません。すなわち、2 ノードのクラスタも、3 ノード以上のクラスタも同様に扱われます。これが可能なのは、次の 2 つの理由によります。

ディスクの防護は、次の手順で実現されます。

  1. クラスタからノードが削除されると、残りのノード 1 つがディスクを SCSI 予約します。この後、ディスクそのものによってクラスタのメンバーでなくなったノードをはじめとする別のノードが、ディスクに対する読み取りや書き込みを行うことが防止されます。ディスクは、読み取りあるいは書き込みコマンドに対して Reservation_Conflict エラーを返します。 Solstice DiskSuite の構成では、SCSI 予約は、Sun の多重ホストに対する ioctl の MHIOCTKOWN を発行することによって行われます。

  2. クラスタ内のメンバーは、アクセスしているディスクに対して連続的に MHIOCENFAILFAST ioctl を有効にします。この ioctl はディスクドライバに対する命令であり、別のノードによって予約されていて、ディスクにアクセスできない場合に、ノードが自身をパニック状態にできるようにします。MHIOCENFAILFAST ioctl によって、ドライバは、このノードがディスクに対して発行するすべての読み取りおよび書き込みコマンドについて、返されたエラーに Reservation_Conflict エラーコードがないかどうかを調べ、またバックグラウンドで定期的に、ディスクにテストを行なって、Reservation_Conflict が発生していないかどうかを検査します。Reservation_Conflict が返された場合は、フォアグラウンドとバックグラウンド両方の制御フローパスがパニックになります。

  3. MHIOCENFAILFAST は、デュアルホストのディスク専用の ioctl ではありません。ディスクに対して MHIOCENFAILFAST を有効にしたノードが、別のノードが予約 (SCSI-2 排他予約) しているためにそのディスクにアクセスできなくなった場合、ノードはパニックになります。

ディスク防護のためのこの解決策は、SCSI-2 のディスク予約の概念に依存しています。SCSI-2 ディスク予約では、1 つのノードだけがディスクを予約することができます。

Solstice DiskSuite の構成の場合、インストールプログラムの scinstall(1M) は、SSVM や CVM の構成のときのように、定足数デバイスの指定やノードの設定を求めたり、障害防護ポリシーの選択を求めたりしません。ボリュームマネージャとして Solstice DiskSuite を指定した場合、直接接続デバイス、すなわち、3 つ以上にノードに直接接続されたデバイスを構成することはできません。Solstice DiskSuite の構成では、ノードのペアにだけディスクを接続できます。

注 -

scconf(1M) コマンドに +D フラグを指定することによって、直接接続デバイスの構成を有効にすることができますが、Solstice DiskSuite の構成では、この設定は行わないでください。