この章では、Solstice DiskSuite の dual-string メディエータについて説明します。この機能によって、Sun Cluster は 2 つのディスク string だけを使用して高可用性データサービスを実行できます。Solstice DiskSuite の機能と概念の詳細は、Solstice DiskSuite のマニュアルを参照してください。
この章で説明する手順は次のとおりです。
Sun Cluster では、dual-string (2 つのディスク string だけを使用した構成) はユーザーが介入をすることなく、単一のノードやドライブの単一の string に起きる障害を回避する必要があります。
dual-string 構成では、メタデバイス状態データベースの複製は、複製のちょうど半分が 1 つの string に、残りの半分が 2 つめの string に存在するように置かれます。現行データの大部分を提示するためには、複製の定足数 (半分 + 1 以上) が必要です。dual-string 構成では、1 つの string が使用できなくなると、複製の定足数を使用できません。
メディエータは、メディエータデータを格納するホスト (ノード) です。メディエータデータは、ほかのメディエータの位置情報を提供します。メディエータには、複製データベースに格納されているコミット回数と同じコミット回数が格納されています。このコミット回数は、メディエータデータが複製データベース内のデータと同期がとれていることを確認するために使用されます。メディエータデータは、使用前に個々に検証されます。
Solstice DiskSuite は、オペレーション状況が「安全」な時点を判定するために、複製定足数 (半分 + 1) を必要とします。これにより、データの正当性が保証されます。dual-string 構成では、アクセス可能な string が 1 つだけという場合があります。このような状況では、複製定足数を得ることは不可能です。メディエータが使用されていてメディエータ定足数が存在する場合は、メディエータデータを使用して、アクセス可能な string 上のデータが最新のものであり、安全に使用できるかどうかを確認できます。
Sun Cluster ソフトウェアにメディエータを導入すると、dual-string 構成で単一の string に障害が発生した場合にほとんどの現行データを提示できます。
一部の dual-string 障害において不要なユーザー介入を防ぐために、ゴールデンメディエータという概念が実装されました。複製データベースのちょうど半分がアクセス可能なときにメディエータホストの更新が必要なイベントが発生すると、2 つのメディエータの更新が試みられます。最初の更新は、コミット回数の変更を試み、メディエータを「非ゴールデン」に設定します。2 つめの更新は、最初の段階ですべてのメディエータホストが正常なことが確認され、かつアクセス可能な複製 (これらはコミット回数が増えている) の数が複製の合計数のちょうど半分であった場合だけ発生します。すべての条件が満たされると、2 つめの更新によってメディエータの状態が「ゴールデン」に設定されます。これにより、ユーザーの介入なしで、ゴールデン状態のホストに対するテイクオーバーが進行します。状態がゴールデンではない場合、データは読み取り専用に設定されます。テイクオーバーやフェイルオーバーを正常に行うためにはユーザーの介入が必要です。ユーザーがテイクオーバーやフェイルオーバーを開始するには、複製のちょうど半分がアクセス可能でなければなりません。
ゴールデン状態は、揮発性メモリー (RAM) にだけ格納されます。いったんテークオーバーが発生すると、メディエータデータは再更新されます。メディエータホストのどれかが更新不可能な場合、ゴールデン状態が取り消されます。状態は RAM だけに格納されるため、メディエータホストを再起動するとゴールデン状態が取り消されます。メディエータのデフォルト状態はゴールデンではありません。
図 9-1 は、2 つの Sun Cluster ノードに 2 つの string とメディエータが構成された Sun Cluster システムを示しています。
ノードの数に関係なく、クラスタ内には 2 つのメディエータホストしか存在しません。このクラスタ内でメディエータを使用しているディスクセットはすべて、メディエータホストが同じです。これは、メディエータホストが、このディスクセットをマスターできるサーバーセットのメンバーでない場合も同様です。
図を簡潔にするため、この構成では 1 つのディスクセットと対称構成しか示していません。ディスクセットの数は、この場合は重要ではありません。安定状態では、ディスクセットは phys-hahost1 によってマスターされます。
通常、複製データベースの半分 + 1 がアクセス可能な場合、メディエータは使用されません。複製のちょうど半分がアクセス可能な場合は、メディエータのコミット回数を使用して、アクセス可能な半分が最新状態であるかどうかを確認できます。正しいメディエータコミット回数が使用されるようにするには、両方のメディエータをアクセス可能にするか、メディエータの 1 つをゴールデンに設定する必要があります。メディエータ定足数は、メディエータの半分 + 1 です。メディエータ定足数は、複製の定足数には関係ありません。
メディエータを使用すると、単一障害および一部の二重障害からの回復が行えます。Sun Cluster で保証されているのは単一障害からの自動回復だけであるため、この節では単一障害からの回復についてだけ詳細を述べます。二重障害については、一般的な回復処理だけを示します。
図 9-1 は、安定状態の dual-string 構成を示しています。メディエータは、両方の Sun Cluster ノードで確立されています。そのため、メディエータ定足数が存在し、メディエータが使用されるようにするには、両方のノードを動作させる必要があります。1 つの Sun Cluster ノードで障害が発生した場合、複製定足数は存在します。ディスクセットのテイクオーバーが必要な場合、メディエータを使用せずにテークオーバーは発生します。
以下の各節では、メディエータを使用して障害を回復する方法を説明します。
図 9-2 は、1 つの Sun Cluster ノードに障害が発生した状況を示しています。この場合は、複製定足数が使用できるため、メディエータソフトウェアは使用されません。Sun Cluster ノード phys-hahost2 は、以前に phys-hahost1 によってマスターされていたディスクセットをテイクオーバーします。
回復処理は、Sun Cluster ノードに障害が発生して 3 つ以上のディスク string が存在する場合に行う処理と同じです。通常、phys-hahost1 がクラスタに再度加わった後で、スイッチオーバーを行います。これ以外の管理作業を行う必要はありません。スイッチオーバーの手順については、haswitch(1M) のマニュアルページを参照してください。
図 9-3 は、図 9-1 に示した安定状態から単一の string に障害が発生した場合を示しています。String 1 に障害が発生すると、phys-hahost1 と phys-hahost2 双方のメディエータホストはそのイベントを反映するように更新され、システムは次に示すように継続して動作します。
テイクオーバーは発生しない。
Sun Cluster ノード phys-hahost1 は継続してディスクセットを所有する。
String 1 は、障害が発生したため String 2 との同期をとり直す必要がある。同期をとり直す方法については、『Solstice DiskSuite ユーザーズガイド』と metareplace(1M) のマニュアルページを参照してください。
コミット回数が増やされ、メディエータはゴールデンのまま留まります。
この場合に必要な管理作業は、3 つ以上の string 構成で単一の string に障害が発生する場合に必要な処理と同じです。これらの作業の詳細は、使用しているディスク拡張装置のマニュアルを参照してください。
図 9-4 は、String 1 と phys-hahost2 に障害が発生した二重障害を示しています。string にまず障害が発生し、その後ホストに障害が発生した場合、phys-hahost1 上のメディエータはゴールデンである可能性があります。この場合の状況を次に示します。
phys-hahost1 上のメディエータはゴールデンである。
メディエータの半分が使用できる。
複製の半分がアクセス可能である。
phys-hahost1 のメディエータコミット回数は、String 2 の複製で確認できるコミット回数に一致する。
このような障害は、Sun Cluster によって自動的に回復します。ディスクセットのマスターは、phys-hahost2 によってマスターされていた場合、phys-hahost1 にテークオーバーされます。phys-hahost1 によってマスターされていた場合は、phys-hahost1 がそのままマスターを続けます。String 1 の修復が終わった時点で、String 1 のデータは String 2 のデータと同期をとり直す必要があります。同期をとり直す方法については、『Solstice DiskSuite ユーザーズガイド』と metareplace(1M) のマニュアルページを参照してください。
この状況では回復が可能ですが、3 つめの障害が発生するとクラスタが使用できなくなるため、障害が発生したコンポーネントは速やかに復元してください。
phys-hahost1 のメディエータがゴールデンではない場合、このケースは Sun Cluster によって自動回復されず、管理者の介入を必要とします。この場合、Sun Cluster はエラーメッセージを生成し、論理ホストは保守モード (読み取り専用) に置かれます。このような多重障害が発生した場合は、ご購入先にお問い合わせください。
メディエータの管理は、medstat(1M) と metaset(1M) コマンドを使用して行います。これらのコマンドを使用すると、メディエータホストの追加と削除、メディエータデータの確認と修復などが行えます。詳細は、medstat(1M)、metaset(1M)、mediator(7) の各マニュアルページを参照してください。
この作業は、Solstice DiskSuite のインストールと構成が終わった後で行なってください。
すべてのノードでクラスタソフトウェアを起動します。
最初のノードで次のコマンドを実行してください。
# scadmin startcluster |
残ったほかのノードで次のコマンドを実行してください。
# scadmin startnode |
各ノードのプライベートリンクの名前を確認します。
grep(1) を使用して、clustername.cdb ファイルに含まれているプライベートリンクを確認してください。
host1# grep "^cluster.node.0.hostname" ¥ /etc/opt/SUNWcluster/conf/clustername.cdb cluster.node.0.hostname : host0 host1# grep "cluster.node.0.hahost" ¥ /etc/opt/SUNWcluster/conf/clustername.cdb | grep 204 204.152.65.33 host1# grep "^cluster.node.1.hostname" ¥ /etc/opt/SUNWcluster/conf/clustername.cdb cluster.node.1.hostname : host1 host1# grep "cluster.node.1.hahost" ¥ /etc/opt/SUNWcluster/conf/clustername.cdb | grep 204 204.152.65.34 |
この例では、204.152.65.33 が host0 のプライベートリンクで、204.152.65.34 が host1 のプライベートリンクです。
metaset(1M) コマンドを使用して、メディエータを構成します。
ディスクセットに接続された各ホストを、そのディスクセットトのメディエータとして追加します。各コマンドは、現在ディスクセットをマスターしているホストで実行してください。ディスクセットの現在のマスターは、hastat(1M) コマンドで確認できます。論理ホストについて hastat(1M) が返す情報に、ディスクセットマスターが示されています。
host1# metaset -s disksetA -a -m host0,204.152.65.33 host1# metaset -s disksetA -a -m host1,204.152.65.34 host1# metaset -s disksetB -a -m host0,204.152.65.33 host1# metaset -s disksetB -a -m host1,204.152.65.34 host1# metaset -s disksetC -a -m host0,204.152.65.33 host1# metaset -s disksetC -a -m host1,204.152.65.34 |
metaset(1M) コマンドは、プライベートリンクを別名として扱います。
phys-hahost1# medstat -s diskset |
出力の解釈については、medstat(1M) のマニュアルページを参照してください。指定したディスクセットのメディエータホストのメディエータデータが不正であることが表示された場合は、次の方法を参照して問題を修正してください。
medstat(1M) コマンドは、メディエータの状態を確認します。この作業は、medstat(1M) を実行し、メディエータホストに問題があることが報告された場合に行なってください。
影響を受けるディスクセットから問題のあるメディエータホストを削除します。
影響を受けるディスクセットを所有している Sun Cluster ノードにログインし、次のコマンドを入力してください。
phys-hahost1# metaset -s diskset -d -m bad_mediator_host |
メディエータホストとその別名を復元します。
phys-hahost1# metaset -s diskset -a -m bad_mediator_host, physical_host_alias,... |
プライベートリンクは、メディエータホストの別名として割り当てる必要があります。metaset(1M) コマンド行に、まず実際のホストの IP アドレスを指定し、続いて HA プライベートリンクを指定してください。この場合の metaset(1M) コマンドの使用法については、mediator(7) のマニュアルページを参照してください。
二重障害の中には、Sun Cluster によって自動回復しない場合もあります。次に例を示します。
dual string 構成でノードと string の両方に障害が発生したが、残ったノード上のメディエータがゴールデンでない場合。詳細は、「ホストと string の障害」で説明しています。
メディエータデータが不正であるか古い、あるいはノードの 1 つまたは両方に存在しない状況にあり、dual string 構成内の string の 1 つに障害が発生する。影響を受けた論理ホストの所有権を取得しようと試みるが失敗する。
dual string 構成で 1 つの string に障害が発生したが、残った string 上の正常な複製の数が、障害が発生したディスクセットの複製の合計数の半分に満たない。DiskSuite は次にこれらの複製を更新しようと試みるが、システム障害が発生する。
自動回復しない障害が発生し、手動の回復作業が完了する前に、影響を受けた論理ホストを保守モードから戻す試みがなされる。
ディスクセット、複製、メディエータの状態を定期的に監視することは非常に重要です。これらの監視には、medstat(1M) コマンドが便利です。多重障害を悪化させる危険性を避けるために、問題のあるメディエータデータ、複製、ディスクは常に速やかに修復してください。
この種の障害が発生した場合、次のようなエラーメッセージの 1 つがログに記録されます。
ERROR: metaset -s <diskset> -f -t exited with code 66 ERROR: Stale database for diskset <diskset> NOTICE: Diskset <diskset> released ERROR: metaset -s <diskset> -f -t exited with code 2 ERROR: Tagged data encountered for diskset <diskset> NOTICE: Diskset <diskset> released ERROR: metaset -s <diskset> -f -t exited with code 3 ERROR: Only 50% replicas and 50% mediator hosts available for diskset <diskset> NOTICE: Diskset <diskset> released |
最終的に、次のメッセージも表示されます。
ERROR: Could not take ownership of logical host(s) <lhost>, so switching into maintenance mode ERROR: Once in maintenance mode, a logical host stays in maintenance mode until the admin intervenes manually ERROR: The admin must investigate/repair the problem and if appropriate use haswitch command to move the logical host(s) out of maintenance mode |
この種の二重障害では、データの完全性維持を優先するため、高可用性は犠牲になります。そのため、データがしばらく使用できなくなる可能性があります。また、完全なデータ回復やデータの整合性は保証されません。
ログメッセージを調べ、問題を見極め、障害が発生したハードウェアをできるかぎり修復した後、mediator(7) のマニュアルページに説明されている特殊な metaset(1M) オプションのいくつかを使用して、データアクセスを復元できる場合があります。しかし、これらのオプションの使用は、不正なデータの回復を避けるために、細心の注意を払う必要があります。
2 つの string 間の相互アクセスは、絶対に行わないでください。このようなアクセスが試みられると、状況は悪化します。
データのクライアントアクセスを復元する前に、データセット全体、またはそのデータセットに対する最近のトランザクションによって影響を受けているデータに対して任意の妥当性検査を行なってください。
論理ホストを保守モードから戻す haswitch(1M) コマンドを実行する前に、必ず関連するディスクセットの所有権を解放してください。
次の syslog (コンソール) メッセージは、メディエータまたはメディエータデータに問題があることを示しています。この問題を解決するには、「不正なメディエータデータを修正するには」の手順に従ってください。
Attention required - medstat shows bad mediator data on host %s for diskset %s Attention required - medstat finds a fatal error in probing mediator data on host %s for diskset %s! Attention required - medstat failed for diskset %s |