test

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

定足数、定足数デバイス、障害防護

定足数は、クラスタ環境でよく使用される用語であり、分散型システムで頻繁に出てくる概念です。基本的には、この定足数は、議会で法案を通過させるために (つまり、過半数の了解を得て、合意に達するために) 必要な定足数と何の違いもありません。定足数を構成する数は、問題によって変わる可能性があります。単純に全投票が過半数を超えればよいこともあれば、3 分の 2 の多数を得なければならないこともあります。これと同じことが、分散型システムの一群の通信プロセスにも当てはまります。システムを効果的に動作させるには、またシステムの動作について重要な決定を下すには、それらプロセスが、求められる定足数に合意する必要があります。そして、定足数が得られるまでメッセージをやりとりすることによって、内在する問題に関して合意を得るように努めます。

Sun Cluster では、2 種類の定足数が使用されます。

CMM 定足数

Sun Cluster および Solstice HA クラスタ製品は、異なる方法で CMM 定足数を決定していました。2.0 および 2.1 を含む以前のリリースの Sun Cluster では、クラスタフレームワークによって CMM 定足数が決定され、Solstice HA では、Solstice DiskSuite ボリュームマネージャによって定足数が決定されていました。Sun Cluster 2.2 は、Sun Cluster 2.x と Solstice HA 1.x の両方に基づいています。Sun Cluster 2.2 では、CMM 定足数の決定は、ボリュームマネージャの Solstice DiskSuite、SSVM、CVM のいずれかに依存します。ボリュームマネージャが Solstice DiskSuite の場合、CMM 定足数は、Solstice DiskSuite が管理する、定足数のメタデバイス状態データベースの複製によって決定されます。使用されているボリュームマネージャーが SSVM または CVM の場合は、クラスタネットワークによって決定されます。

Sun Cluster 2.2 では、CMM 定足数は次のようにして決定されます。

ノードがクラスタに結合したり、クラスタから切り離されたとき、あるいはクラスタインターコネクト (ノード間の冗長プライベートリンク) で問題が発生した場合は、クラスタ定足数を決定する必要があります。Solstice HA 1.x では、クラスタインターコネクトの障害は二重障害とみなされていました。二重障害の場合、ソフトウェアによってデータの完全性は保証されますが、ユーザーの介入なしにクラスタが動作を継続できる保証はありません。システム設計では、二重障害に対して手動介入が行われるようになっていました。これは、可用性が維持されたとしても、データの完全性が損なわれる可能性のある自動応答に比べて、手動介入がデータの完全性を保証する最も安全な手段と判断されたためです。

Sun Cluster 2.x ソフトウェアは、データの完全性の維持とともに、ユーザーの介入なしにクラスタの可用性を維持するように設計されています。クラスタの可用性を維持するため、Sun Cluster 2.x は、いくつかの新しいプロセスを実装しています。たとえば、定足数デバイスや端末集配信装置、あるいはシステムサービスプロセッサがそうです。Solstice HA 1.x は Solstice DiskSuite を使用して、クラスタ定足数を決定するため、Sun Cluster 2.2 では、ボリュームマネージャーがクラスタ定足数を決定し、またはクラスタインターコネクトで問題が発生したときに発生することを決定する最大の要因であることに注意してください。クラスタインターコネクトの障害が及ぼす影響については、「定足数デバイス (SSVM と CVM)」で説明します。

CCD 定足数

クラスタ構成データベース (CCD) は、有効で整合性のとられた CCD コピーを選出するにあたって定足数を得る必要があります。CCD の概要については、「クラスタ構成データベース」を参照してください。

Sun Cluster には、どのような構成でも、クラスタの各ノードから実際の記憶装置に直接アクセスすることを保証する記憶装置のトポロジはありません。そうすることによって、1 つの論理ボリュームを使用して CCD データベースが格納される可能性を排除し、クラスタフレームワークの再起動を終えるまで正しく更新が伝達されるようにしています。CCD は、クラスタインターコネクト経由でそのピア (代理) と通信します。クラスタのメンバーではないノードから、この論理リンクを利用することはできません。次に、簡単な例を使用して、CCD 定足数に求められる条件を説明します。

A、B、C の 3 つのノードで構成されるクラスタがあると仮定します。ノード A がクラスタから切り離され、クラスタのメンバーとして B と C が残ります。CCD が更新され、その更新がノード B と C に伝達されます。その後、ノード B と C がクラスタから切り離され、ノード A が再起動されたとします。しかし、前回クラスタから切り離された後でノード B と C 上で発生した更新を知る手段はないので、ノード A には、CCD データベースの最新コピーは存在しません。実際、どのノードが先に起動された場合でも、CCD データベースの最新コピーがどのノードに存在するのかを、明確な方法で判断することは不可能です。CCD データベースの最新コピーを確定するために必要な情報が得られるのは、3 つのノードがすべて再起動されたときだけです。 有効な CCD を選出できなかった場合、CCD に対する照会あるいは更新操作はすべて不正な CCD エラーとなって失敗します。実際問題として、有効な CCD コピーを確定する前にクラスタのすべてのノードを起動するというのは、条件として厳しすぎます。

この条件は、更新操作に制限を設けることによって緩めることができます。クラスタにおいて現在構成済みのノード数を N とすると、更新を伝達するには、少なくとも floor (n/2) + 1 [floor(n) = (n modulo 1 = 0) の場合 n、(n modulo 1 != 0) の場合 n - (n modulo 1)] で表される数のノードが動作している必要があります。クラスタの再起動時に有効なデータベースを選出するには、同じ内容のコピーが ceiling (n/2) [ceiling(n) = (n modulo 1 = 0) の場合 n、(n modulo 1 != 0) の場合 n + 1 - (n modulo 1)] 個存在していれば十分です。その場合、有効な CCD が存在していないすべてのクラスタノードに有効な CCD が伝達されます。

CCD が無効であっても、ノードのクラスタへの結合は許可されることに注意してください。ただし、この状態で、CCD を更新したり、CCD に照会を行ったりすることはできません。このことは、クラスタフレームワークの、CCD に依存する全コンポーネントが機能不全の状態に留まることを意味します。具体的には、論理ホストをマスターしたり、データサービスを起動したりできなくなります。CCD を使用できるようになるのは、定足数に達するために必要な数のノードがクラスタに結合した後だけです。これに代わる方法として、管理者が最高の CCD 生成番号を持つ CCD データベースを回復することもできます。

CCD 定足数の問題は、再構成中に少なくとも 1 つのノードを動作したままにしておくことによって回避できます。この場合は、いずれかのノード上の有効なコピーが新たに結合するノードに伝達されます。また、最新の CCD コピーを持つノードからクラスタが起動されるようにするという方法もあります。それでも、データベースの更新中にシステムがクラッシュした後で、回復アルゴリズムが CCD コピー間の不整合を検出する可能性はかなりあります。そうした場合は、管理者が ccdadm(1M) の復元オプションを使用してデータベースを復元する必要があります。CCD にはまた、データベースの現在の内容のバックアップを可能にするチェックポイント機能もあります。システム構成に変更を加えた場合は、CCD データベースのバックアップコピーを作成してください。バックアップコピーを作成しておくことによって、後でデータベースを復元することができます。従来のリレーショナルデータベースに比べて CCD データベースのサイズはかなり小さく、バックアップおよび復元操作は、ほんのわずかな時間で完了します。

2 ノードのクラスタの CCD 定足数

2 ノードのクラスタの場合、前述の定足数過半数の規則で更新が正しく行われるには、両方のノードがクラスタのメンバーである必要があり、この条件は厳しすぎます。また、この構成で一方のノードだけ動作しているときに更新を許可した場合は、クラスタを再起動する前にデータベースを手動で整合させる必要があります。この整合は、最新のコピーを持つノードを先に再起動するか、両方のノードが結合した後に ccdadm(1M) の復元操作でデータベースを復元することによって行うことができます。後者の場合、両方のノードがクラスタに結合できるとしても、復元操作が完了するまで CCD は無効な状態に置かれます。

この問題は、共有ディスクデバイスにデータベース用の恒久的な記憶装置を設定することによって解決します。共有コピーが使用されるのは、1 つのノードがアクティブなときだけです。2 つ目のノードが結合すると、共有 CCD コピーの内容がそれぞれのノードのローカルコピーにコピーされます。

ノードの 1 つがクラスタから切り離されると、ローカル CCD の内容を共有コピーにコピーすることによって再び共有コピーがアクティブになります。これにより、1 つのノードがクラスタに存在するときにだけ更新が可能になり、クラスタの再起動にまたがって信頼性の高い更新の伝達が行われるようになります。

CCD の共有コピー用に共有記憶装置を利用することの欠点は、この目的のためにだけ 2 つのディスクを確保する必要があることです。ボリュームマネージャは、これらのディスクが別の目的に使用されないようにします。2 つのディスクの利用は、上記の手続き上の制限によって生じるアプリケーションの停止時間を了解し、実際の環境で許される場合は、回避できます。

Sun Cluster 2.2 の CMM 定足数の問題と同様に、共有 CCD は、あらゆる Sun Cluster 構成でサポートされるわけではありません。ボリュームマネージャが Solstice DiskSuite の場合、共有 CCD はサポートされません。共有 CCD が使用されるのはノードの 1 つがアクティブなときだけであるため、共有 CCD によって障害に対処するのは一般的ではありません。

定足数デバイス (SSVM と CVM)

いくつかの状況では (たとえば、2 ノードのクラスタで、両方のクラスタインターコネクトで問題が発生し、両方のノードがまだクラスタのメンバーとして残っている場合)、クラスタ定足数の問題を解決するにあたって、Sun Cluster はハードウェアデバイスの助けを必要とします。定足数デバイスとは、そうしたデバイスのことです。

ボリュームマネージャとして Sun StorEdge Volume Manager (SSVM) または Cluster Volume Manager (CVM) のいずれかを使用しているクラスタでは、定足数デバイスを使用する必要があります。Solstice DiskSuite は、専用のメタデバイス状態データベースの複製を使用することによってクラスタ定足数を確保するので、定足数デバイスを必要としません。つまり、Solstice DiskSuite 構成では、定足数デバイスは必須ではなく、サポートもされません。Solstice DiskSuite を使用するクラスタのインストールでは、scinstall(1M) プログラムによって定足数デバイスが求められたり、受け付けられたりすることはありません。

定足数デバイスは、scinstall(1M) コマンドを使用したクラスタのインストール作業で指定する単なるディスクまたはコントローラです。定足数デバイスは論理的な概念であり、定足数デバイスとして選択された 1 つの具体的なハードウェアに関して、特別な意味はありません。ただし、定足数デバイスは、個別にインポートしたり、エクスポートされる、専用のディスクグループのメンバーである必要があります。SSVM で、ディスクの一部を独立したディスクグループのメンバーにすることはできないので、定足数デバイスにはディスク全体とそのプレックス (ミラー) が必要になります。任意の時点で定足数デバイスがインポートされるノードがどのノードなのかを確定することはできないので、定足数に必要なデータ以外のデータを有用な形で保管することはできません。

定足数デバイスは、ノード間で共有される多重ホストディスクの更新が、いつでも 1 つのノードによってだけ行われるようにします。定足数デバイスは、ノード間のクラスタインターコネクトが失われた場合に使用されます。ノード (ノード 3 つ以上のクラスタの場合は複数のノード) が、過半数の定足数の一部であることを証明できない場合は、そのノードは共有データの更新を試みてはなりません。すべてのノードが採決を行なって、どのノードがクラスタに留まるかを決定します。各ノードは、自身が通信できるノード数を判断します。クラスタの半数以上のノードと通信できる場合、そのノードは過半数の定足数の構成員となり、クラスタのメンバーに留まることが許可されます。ノードが過半数の定足数の一部でない場合、そのノードは終了し、クラスタから切り離されます。

定足数デバイスは「第 3 の投票」として働き、同じ得票数になるのを防ぎます。たとえば、ノード 2 つのクラスでクラスタインターコネクトが失われた場合、それぞれのノードは、定足数デバイスを確保しようとして競合します。図 1-9 は、多重ホストディスク格納装置の 1 つに定足数デバイスが存在する 2 ノードのクラスタ構成を表しています。

図 1-9 定足数デバイスを持つ、2 ノードのクラスタ

Graphic

定足数デバイスを確保したノードは 2 票の定足数を獲得し、残りのノードは 1 票だけになります。定足数を得たノードは専用のクラスタを起動して、多重ホストディスクをマスターし、もう一方のノードは終了します。

クラスタの再構成では、新しいシステム構成を承認するにあたって、一群のノードと定足数デバイスが投票を行います。再構成は、過半数の定足数に達した場合にだけ行われます。再構成後、ノードがクラスタに留まるのは、そのノードが過半数の定足数を構成する場合だけです。

注 -

3 ノード以上のクラスタでは、多重ホストディスクに対するアクセス権を共有する各ノードセットに対して、定足数デバイスを使用するように構成する必要があります。

3 ノード以上のクラスタでは、定足数デバイスの概念が少し異なります。定足数デバイスを共有しないノードで同数の票割れが発生した場合 (この状態を「票割れ (split-brain)」パーティションという) は、どのノードセットが新しいクラスタになり、どのセットが終了するかを決定する必要があります。定足数デバイスがこの状況に対処することはありません。インストール作業の一貫として定足数デバイスを設定するときに、そうしたパーティションが発生したときにどのようなことを行わせるかを決定する問い合わせがあります。票割れパーティションが発生した場合は、クラスタソフトウェアに自動的に新しいクラスタメンバーシップを選択させるようにしたか、あるいは手動介入を指定したかによって、2 つあるイベントのいずれかが発生します。

たとえば、4 ノードのクラスタがあり (全ノードが同じ記憶装置を共有していても、共有していなくてもよい)、ネットワーク障害が発生して、ノード 0 と 1、ノード 2 と 3 がそれぞれ互いに通信していると仮定します。この状況では、定足数の自動または手動決定のどちらでも使用されます。クラスタ監視ソフトウェアは、どのノードをクラスタのメンバーとすべきで、どのノードをメンバーとすべきでないかを独力で判断しようとします。最後の手段として、定足数デバイスに頼って同じ得票数にならないようにするか、あるいはクラスタドメインの手動および自動選択に頼ります (極端な状況の場合のみ)。

注 -

定足数デバイスで障害が発生するということは、2 ノードのクラスタでノードの 1 つに障害が発生することと似ています。

定足数デバイス単独で、クラスタメンバーシップに関する決定が必要になるあらゆる状況に対応できるわけではありません。たとえば、完全に動作可能な 3 ノードのクラスタがあり、それらノードのすべてが、Sun StorEdge A5000 のような多重ホストディスクのアクセス権を共有していると仮定します。ノードの 1 つが終了するか、両方のクラスタインターコネクトを失い、残る 2 つのノードが引き続き互いに通信できる場合、残り 2 つのノードが、同じ得票数になるのを回避するために定足数デバイスを確保する必要はありません。代わりに、過半数の得票 (3 票のうちの 2 票) は、互いに通信できる 2 つのノードがクラスタを形成できるかどうかを決定します。クラスタを構成する 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 の構成では、この設定は行わないでください。

クラスタのパーティション化の防止 (SSVM と CVM)

2 ノードのクラスタ

2 ノードのクラスタでインターコネクト接続が失われた場合、両方のノードは、相手からのハートビートが得られなくなったことにより、クラスタメンバーシップ内のローカルノードだけでクラスタ再構成プロセスを開始しようとします。構成済み定足数デバイスの予約に最初に成功したノードが、クラスタの唯一の残りのメンバーとして留まります。定足数デバイスの予約に失敗したノードは、終了します。

障害が発生したインターコネクトを修復することなく、終了したノードを起動しようとすると、残りのノードと通信できず、そのノードは自身をクラスタの唯一のノードとみなすため、定足数デバイスを予約しようとします。定足数デバイスは、すでにもう一方のノードによって予約されているため、この試みは失敗します。結果的に、この動作は、パーティション化されたノードが独自のクラスタを形成するのを防ぎます。

3 ノードまたは 4 ノードのクラスタ

端末集配信装置 (TC) によってリセット要求が発行された結果、4 ノードのクラスタから 1 つのノードが切り離された場合、残りのクラスタノードの中には、定足数デバイスを予約できないものが出てきます。これは、残りのノードのいずれか１つが予約することによって、残りの 2 つの正常なノードが定足数デバイスにアクセスできなくなるためです。パーティション化されたノード上で誤って scadmin startcluster コマンドを実行した場合、そのノードは別のノードと通信できないため、独自のクラスタを形成してしまいます。事実上、パーティション化されたノードが独自のクラスタを形成するのを防ぐ定足数デバイスの予約はありません。

3 ノードまたは 4 ノードのクラスタ構成では、Sun Cluster は、定足数方式ではなく、クラスタ全体のロック (ノードロック) 機能に助けを求めます。この機構では、クラスタの TC または SSP の未使用ポートが利用されます (構内全体のクラスタには、複数の TC が使用される)。インストールでは、このノードロック機能用に TC または SSP を選択してください。この情報は、CCD に格納されます。クラスタがアクティブな間、すなわち、最初のノードが正しく新しいクラスタを形成してから、最後のノードがクラスタから切り離されるまで、このロックは、常にクラスタメンバーの 1 つが保持します。ロックを保持しているノードで問題が発生した場合、ロックは自動的に別のノードに移されます。

ノードロックの働きはただ 1 つ、票割れ状態のときに、管理者のエラーによって新しいクラスタが起動されるのを防ぐことです。

注 -

クラスタに最初に結合するノードがノードロックを取得できない場合、そのノードは終了します。クラスタの 2 つ目以降のノードがノードロックを取得できなくても、ノードの障害やノードの終了が発生することはありません。

ノードロックは、次のように機能します。