この章では、保守管理を行う場合やクラスタ障害が発生した場合のサービスの移行について説明します。この章の内容は次のとおりです。
この節では、主クラスタまたは二次クラスタで障害が検出される際に発生する内部プロセスについて説明します。
ある保護グループの主クラスタに障害が発生すると、パートナーシップの二次クラスタがその障害を検出します。障害が発生するクラスタは複数のパートナーシップのメンバーである可能性があるため、このような障害の検出も複数発生する可能性があります。
主クラスタに障害が発生すると、次のアクションが発生します。障害中、該当する保護グループは Unknown 状態になります。
ハートビート異常がパートナークラスタによって検出されます。
ハートビート喪失が一時的なものではないことと、主クラスタに障害が発生していることを確認するため、緊急モードでハートビートが有効になります。このデフォルトのタイムアウト間隔の間、つまり、ハートビート機構が主クラスタの状態を確認 (照会) しようと再試行している間、ハートビートは Online 状態のままです。
この照会間隔は、Query_interval ハートビートプロパティーで設定します。構成した間隔が経過してもハートビート異常が継続する場合、ハートビート喪失イベントが生成され、システムログに記録されます。デフォルトの照会間隔を使用する場合、緊急モードの再試行動作によって、ハートビート喪失通知は約 9 分間遅れる可能性があります。メッセージは、グラフィカルユーザーインタフェース (GUI) と geoadm status コマンドの出力に表示されます。
ログについての詳細は、「Sun Cluster Geographic Edition のログメッセージの表示」を参照してください。
ある保護グループの二次クラスタに障害が発生すると、同じパートナーシップのクラスタがその障害を検出します。障害が発生したクラスタは複数のパートナーシップのメンバーである可能性があるため、このような障害の検出も複数発生する可能性があります。
障害の検出中、次のアクションが発生します。
ハートビート異常がパートナークラスタによって検出されます。
二次クラスタが停止していることを確認するため、ハートビートが緊急モードでアクティブ化されます。
クラスタから管理者に通知が送られます。障害が発生したクラスタが二次クラスタとして動作しているすべての保護グループが検出されます。該当する保護グループは Unknown 状態になります。
パートナークラスタにサービスを順番に移行する場合は、Hitachi TrueCopy 保護グループのスイッチオーバーを実行します。スイッチオーバーは次の手順で行われます。
元の主クラスタ cluster-paris 上で、アプリケーションサービスがオフラインになります。
どのクラスタが cluster-paris かについては、図 2–1 を参照してください。
データ複製の役割が逆になり、今度は、新しい主クラスタ cluster-newyork から元の主クラスタ cluster-paris に対して継続して複製が行われます。
新しい主クラスタ cluster-newyork で、アプリケーションサービスがオンラインになります。
geopg switchover コマンドを使用してスイッチオーバーを開始すると、データ複製サブシステムが両方のクラスタでいくつかの検証を実行します。スイッチオーバーが実行されるのは、両方のクラスタで検証手順が成功した場合だけです。
まず、複製サブシステムは、Hitachi TrueCopy デバイスグループの全体的なデバイスグループ状態が有効であるかどうか検査します。 次に、複製サブシステムは、ターゲットの主クラスタ cluster-newyork のローカルのデバイスグループ状態が 23、33、43、または 53 であることを検査します。ローカルのデバイスグループの状態は、pairvolchk -g device-group-name -ss コマンドで返されます。これらの値は、PVOL_PAIR 状態または SVOL_PAIR 状態に対応します。次の表に、新しい主クラスタ cluster-newyork に指定される Hitachi TrueCopy コマンドを示します。
表 11–1 新しい主クラスタでの Hitachi TrueCopy スイッチオーバー検証
全体的なデバイスグループ状態 |
ローカルクラスタでの有効なデバイスグループ状態 |
cluster-newyork で実行される Hitachi TrueCopy スイッチオーバーコマンド |
---|---|---|
SMPL |
なし |
なし |
通常の主クラスタ |
23、43 |
Hitachi TrueCopy デバイスグループはすでに PVOL_PAIR 状態であるため、コマンドは発行されません。 |
通常の二次クラスタ |
33、53 |
horctakeover -g dg [-t] Hitachi TrueCopy デバイスグループの fence_level が async のときは、-t オプションを指定します。この値は、保護グループの Timeout プロパティーの 80% として計算されます。たとえば、保護グループの Timeout が 200 秒である場合、このコマンドで -t オプションを使用したときの値は 200 秒の 80%、つまり、160 秒になります。 |
テイクオーバー主クラスタ |
なし |
なし |
テイクオーバー二次クラスタ |
なし |
なし |
スイッチオーバーが正常に完了したあと、データ複製レベルで、主ボリュームと二次ボリュームの役割が切り替わっています。スイッチオーバー前の PVOL_PAIR ボリュームは SVOL_PAIR ボリュームになります。スイッチオーバー前の SVOL_PAIR ボリュームは PVOL_PAIR ボリュームになります。データ複製は、新しい PVOL_PAIR ボリュームから 新しい SVOL_PAIR ボリュームに継続されます。
スイッチオーバー操作の一部として、新しい主クラスタでアプリケーションがオンラインになることができるかどうかにかかわらず、保護グループの Local-role プロパティーも切り替わります。保護グループの Local role が Secondary であったクラスタでは、保護グループの Local-role は Primary になります。保護グループの Local-role が Primary であったクラスタでは、保護グループの Local-role は Secondary になります。
スイッチオーバーを正常に完了するためには、主クラスタと二次クラスタ間のデータ複製が有効状態で、かつ、これら 2 つのクラスタ上のデータボリュームが同期していなければなりません。
主クラスタから二次クラスタへ保護グループのスイッチオーバーを行うには、次の条件が満たされている必要があります。
両方のクラスタで Sun Cluster Geographic Edition ソフトウェアが起動し、動作している。
二次クラスタがパートナーシップのメンバーである。
両方のクラスタパートナーが互いに到達可能である。
保護グループが OK 状態である。
Cluster_dgs プロパティーを構成してある場合、この プロパティーに指定されているデバイスグループに書き込むことができるのは保護グループに属するアプリケーションだけです。
クラスタノードの 1 つにログインします。
この手順を行うには、Geo Management RBAC 権利プロファイルがユーザーに割り当てられている必要があります。RBAC の詳細は、「Sun Cluster Geographic Edition ソフトウェアと RBAC」を参照してください。
スイッチオーバーを開始します。
スイッチオーバーでは、保護グループに属するアプリケーションリソースグループの停止と起動が行われます。
# geopg switchover [-f] -m new-primary-cluster protection-group-name |
ユーザーに確認することなく、強制的にコマンドを実行します。
保護グループの新しい主クラスタにするクラスタの名前を指定します。
保護グループの名前を指定します。
次に、二次クラスタにスイッチオーバーする例を示します。
# geopg switchover -f -m cluster-newyork tcpg |
主ボリュームと二次ボリュームのデータが完全に整合しているかどうかにかかわらず二次クラスタ上でアプリケーションをオンラインにする必要がある場合は、テイクオーバーを実行します。テイクオーバーは次の手順で行われます。
元の主クラスタ cluster-paris に到達できる場合、元の主クラスタでアプリケーションサービスがオフラインになります。
どのクラスタが cluster-paris であるかについては、図 2–1 を参照してください。
元の主クラスタ cluster-paris のデータボリュームが、新しい主クラスタ cluster-newyork にテイクオーバーされます。
このデータは、元の主クラスタのデータボリュームとは一致していないことがあります。テイクオーバー後、新しい主クラスタ cluster-newyork から元の主クラスタ cluster-paris へのデータ複製が停止されます。
新しい主クラスタ cluster-newyork で、アプリケーションサービスがオンラインになります。
テイクオーバー前後に主クラスタと二次クラスタに考えられる状態についての詳細は、付録 C 「テイクオーバー後の状態」を参照してください。
これ以降の節では、二次クラスタによるテイクオーバーを強制実行するときに行う必要がある手順について説明します。
geopg takeover コマンドを使用してテイクオーバーを開始すると、両方のクラスタに対してデータ複製サブシステムがいくつかの検証を実行します。これらの手順は、元の主クラスタでは、その主クラスタに到達できる場合だけに行われます。元の主クラスタでの検証が失敗する場合でも、テイクオーバーは実行されます。
まず、複製サブシステムは、Hitachi TrueCopy デバイスグループの全体的なデバイスグループ状態が有効であるかどうか検査します。 続いて、複製サブシステムは、ターゲットの主クラスタ cluster-newyork のローカルのデバイスグループ状態が 32 または 52 でないことを検査します。これらの値は SVOL_COPY 状態に対応しています (この状態では horctakeover コマンドは失敗する)。次の表に、テイクオーバーに使用する Hitachi TrueCopy コマンドを示します。
表 11–2 新しい主クラスタでの Hitachi TrueCopy テイクオーバー検証
全体的なデバイスグループ状態 |
有効なローカルのデバイスグループ状態 |
cluster-newyork で発行される Hitachi TrueCopy テイクオーバーコマンド |
---|---|---|
SMPL |
すべて |
コマンドは発行されません。 |
通常の主クラスタ |
すべて |
コマンドは発行されません。 |
通常の二次クラスタ |
32 および 52 を除く、すべての通常の二次クラスタの状態 |
horctakeover -S -g dg [- t] Hitachi TrueCopy デバイスグループの fence_level が async のときは、-t オプションを指定します。この値は、保護グループの Timeout プロパティーの 80% として計算されます。たとえば、保護グループの Timeout が 200 秒である場合、このコマンドで -t オプションを使用したときの値は 200 秒の 80%、つまり、160 秒になります。 |
テイクオーバー主クラスタ |
すべて |
コマンドは発行されません。 |
テイクオーバー二次クラスタ |
すべて |
pairsplit -R-g dg pairsplit -S-g dg |
複製の観点から見れば、テイクオーバーが成功したあと、テイクオーバー操作の一部として、新しい主クラスタでアプリケーションがオンラインになることができるかどうかにかかわらず、保護グループの Local-role プロパティーは新しい役割を反映するように変更されます。保護グループの Local-role が Secondary であった cluster-newyork では、保護グループの Local-role は Primary になります。保護グループの Local-role が Primary であった cluster-paris では、次のことが発生する可能性があります。
このクラスタに到達できる場合、保護グループの Local-role は Secondary になります。
このクラスタに到達できない場合、保護グループの Local-role は Primary のままです。
テイクオーバーが成功した場合、アプリケーションはオンラインになります。別の geopg start コマンドを発行する必要はありません
テイクオーバーが成功したあと、新しい主クラスタ cluster-newyork と以前の主クラスタ cluster-paris の間でのデータ複製が停止されます。geopg start コマンドを実行する場合、-n オプションを使用して、複製が再開されないようにする必要があります。
二次クラスタに主クラスタの処理を引き受けさせるためには、次の条件が満たされている必要があります。
クラスタ上で Sun Cluster Geographic Edition ソフトウェアが稼働中である。
クラスタがパートナーシップのメンバーである。
二次クラスタ上で保護グループの Configuration の状態が OK である。
二次クラスタ内のノードの 1 つにログインします。
この手順を行うには、Geo Management RBAC 権利プロファイルがユーザーに割り当てられている必要があります。RBAC の詳細は、「Sun Cluster Geographic Edition ソフトウェアと RBAC」を参照してください。
テイクオーバーを開始します。
# geopg takeover [-f] protection-group-name |
ユーザーに確認することなく、強制的にコマンドを実行します
保護グループの名前を指定します
この例では、二次クラスタ cluster-newyork による tcpg のテイクオーバーを強制実行する例を示します。
phys-newyork-1 は二次クラスタの第 1 ノードです。どのノードが phys-newyork-1 であるかについては、「Sun Cluster Geographic Edition クラスタ構成の例」を参照してください。
phys-newyork-1# geopg takeover -f tcpg |
テイクオーバーが正常に完了すると、二次クラスタ (cluster-newyork) が保護グループの主クラスタになり、この二次クラスタ上でサービスがオンラインになります。元の主クラスタ cluster-paris が回復したところで、フェイルバックと呼ばれる処理を行なって元の主クラスタ上で再びサービスをオンラインにすることができます。
Sun Cluster Geographic Edition ソフトウェアでは、次の 2 種類のフェイルバックがサポートされています。
フェイルバックスイッチオーバー。フェイルバックスイッチオーバーの場合、アプリケーションは、元の主クラスタ cluster-paris のデータが二次クラスタ cluster-newyork のデータと再同期されたあとで、元の主クラスタでオンラインに戻ります。
どのクラスタが cluster-paris で、どのクラスタが cluster-newyork であるかについては、図 2–1 を参照してください。
フェイルバックテイクオーバー。フェイルバックテイクオーバーの場合、アプリケーションは、元の主クラスタ cluster-paris でオンラインに戻って、元の主クラスタにある現在のデータを使用します。二次クラスタ cluster-newyork が主クラスタとして活動していた間に発生した更新はすべて破棄されます。
この手順は、元の主クラスタ cluster-paris のデータが現在の主クラスタ cluster-newyork のデータと再同期されたあとで、アプリケーションを元の主クラスタで再起動するときに使用します。
フェイルバックスイッチオーバーを実行する前に、cluster-newyork ではテイクオーバーが発生していました。現在のクラスタの役割は次のとおりです。
元の主クラスタ cluster-paris が停止していた場合、そのクラスタが起動していること、および、そのクラスタで Sun Cluster Geographic Edition インフラストラクチャーが有効であることを確認します。クラスタの起動についての詳細は、「クラスタの起動」を参照してください。
cluster-newyork の保護グループの役割は primary です。
cluster-paris の保護グループの役割は、テイクオーバー中にその保護グループに到達できるかどうかによって、primary または secondary のどちらかです。
元の主クラスタ cluster-paris を現在の主クラスタ cluster-newyork と再同期させます。
cluster-paris はその独自の構成を失い、cluster-newyork 構成をローカルに複製します。パートナーシップ構成と保護グループ構成の両方を再同期させます。
cluster-paris で、パートナーシップを再同期させます。
# geops update partnership-name |
パートナーシップの名前を指定します
複数の保護グループにフェイルバックスイッチオーバーを実行している場合でも、この手順は 1 度実行するだけで済みます。
パートナーシップの同期についての詳細は、「パートナーシップの再同期」を参照してください。
cluster-paris で、各保護グループを再同期させます。
cluster-newyork 上の保護グループの役割は primary であるため、この手順によって cluster-paris 上の保護グループの役割が確実に secondary となります。
# geopg update protection-group-name |
保護グループの名前を指定します
保護グループの同期についての詳細は、「Hitachi TrueCopy 保護グループの再同期」を参照してください。
cluster-parisで、クラスタの各保護グループの構成を検証します。
# geopg validate protection-group-name |
単一の保護グループを識別する一意の名前を指定します
詳細は、「Hitachi TrueCopy 保護グループを検証する方法」を参照してください。
cluster-paris で、各保護グループを有効にします。
cluster-paris の保護グループの役割は secondary であるため、geopg start コマンドは cluster-paris でアプリケーションを再起動しません。
# geopg start -e local protection-group-name |
コマンドの適用範囲を指定します
範囲を local に指定した場合、このコマンドはローカルクラスタだけを対象に実行されます。
保護グループの名前を指定します
フェイルバックスイッチオーバーを行う際には、現在の二次クラスタ cluster-paris のデータを現在の主クラスタ cluster-newyork のデータと同期させる必要があるため、-n オプションを指定しないでください。
保護グループの役割が secondary であるため、現在の二次クラスタ cluster-paris のデータが現在の主クラスタ cluster-newyork のデータに同期します。
geopg start コマンドの詳細は、「Hitachi TrueCopy 保護グループを有効にする方法」を参照してください。
スイッチオーバーを実行する前に、データが完全に同期するまで待機します。
cluster-newyork の保護グループの状態が OK になると、データは完全に同期しています。cluster-newyork の Hitachi TrueCopy デバイスグループの状態が PVOL_PAIR であり、cluster-paris の Hitachi TrueCopy デバイスグループの状態が SVOL_PAIR であるとき、保護グループのローカル状態は OK です。
cluster-newyork の保護グループの状態が OK であることを確認するには、次のコマンドを使用します。
phys-newyork-1# geoadm status |
出力の保護グループセクションを参照してください
どちらか一方のクラスタで、各保護グループについて cluster-newyork から cluster-paris へのスイッチオーバーを実行します。
# geopg switchover [-f] -m cluster-paris protection-group-name |
詳細は、「Hitachi TrueCopy 保護グループを主クラスタから二次クラスタにスイッチオーバーする方法」を参照してください。
cluster-paris は、元の役割である、保護グループの主クラスタに戻ります。
元の主クラスタ cluster-paris 上でアプリケーションを再起動し、元の主クラスタ上の現在のデータを使用するには、次の手順を実行します。二次クラスタ cluster-newyork が主クラスタとして機能していた間に発生した更新はすべて破棄されます。
条件付きですが、元の主クラスタ cluster-paris のデータの使用は再開できます。cluster-newyork でのテイクオーバー操作のあとは、どのような時点でも、新しい主クラスタ cluster-newyork から元の主クラスタ cluster-paris にデータを複製していてはいけません。新しい主クラスタと元の主クラスタの間でデータの複製を行わないようにするために、geopg start コマンドを使用するときには常に、-n オプションを使用しておく必要があります。
フェイルオーバーテイクオーバー操作を開始する前、クラスタには次の役割が割り当てられています。
cluster-newyork の保護グループの役割は primary です。
cluster-paris の保護グループの役割は、テイクオーバー中にその保護グループに到達できるかどうかによって、primary または secondary のどちらかです。
元の主クラスタ cluster-paris を元の二次クラスタ cluster-newyork と再同期させます。
cluster-paris はその独自の構成を失い、cluster-newyork 構成をローカルに複製します。
cluster-paris で、パートナーシップを再同期させます。
# geops update partnership-name |
パートナーシップの名前を指定します
複数の保護グループにフェイルバックテイクオーバーを実行している場合でも、この手順は 1 度実行するだけで済みます。
パートナーシップの同期についての詳細は、「パートナーシップの再同期」を参照してください。
Hitachi TrueCopy デバイスグループ devgroup1 を SMPL 状態にします。
pairsplit コマンドを使用して、cluster-paris と cluster-newyork の両方のクラスタの保護グループにある Hitachi TrueCopy デバイスグループを SMPL 状態にします。使用する pairsplit コマンドは、Hitachi TrueCopy デバイスグループのペアの状態によって変わります。次の表に、いくつかの典型的なペアの状態ごとに、cluster-paris で使用する必要があるコマンドの例を示します。
cluster-paris でのペアの状態 |
cluster-newyork でのペアの状態 |
cluster-paris で使用される pairsplit コマンド |
---|---|---|
PSUS または PSUE |
SSWS |
pairsplit -R -g dgname pairsplit -S -g dgname |
SSUS |
PSUS |
pairsplit -S -g dgname |
pairsplit コマンドについての詳細は、『Sun StorEdge SE 9900 V Series Command and Control Interface User and Reference Guide』を参照してください。
このコマンドが正常に完了した場合、pairdisplay コマンドの出力に devgroup1 が次のように表示されます。
phys-paris-1# pairdisplay -g devgroup1 Group PairVol(L/R) (Port#,TID,LU),Seq#,LDEV#,P/S,Status,Fence,Seq#,P-LDEV# M devgroup1 pair1(L) (CL1-A , 0, 1) 12345 1..SMPL ---- ----,----- ---- - devgroup1 pair1(R) (CL1-C , 0, 20)54321 609..SMPL ---- ----,----- ---- - devgroup1 pair2(L) (CL1-A , 0, 2) 12345 2..SMPL ---- ----,----- ---- - devgroup1 pair2(R) (CL1-C , 0,21) 54321 610..SMPL ---- ----,----- ---- - |
.
cluster-paris で、各保護グループを再同期させます。
cluster-newyork の保護グループのローカルな役割は現在 primary であるため、この手順によって cluster-paris の保護グループのローカルな役割が確実に secondary となります。
# geopg update protection-group-name |
保護グループの名前を指定します
保護グループの再同期についての詳細は、「保護グループを再同期させる方法」を参照してください。
cluster-parisで、クラスタの各保護グループの構成を検証します。
# geopg validate protection-group-name |
単一の保護グループを識別する一意の名前を指定します
詳細は、「Hitachi TrueCopy 保護グループを検証する方法」を参照してください。
cluster-paris 上で、データ複製を行わずに、二次クラスタの役割が割り当てられている各保護グループを有効にします。
cluster-paris の保護グループの役割は secondary であるため、geopg start コマンドは cluster-paris でアプリケーションを再起動しません。
# geopg start -e local -n protection-group-name |
コマンドの適用範囲を指定します
範囲を local に指定した場合、このコマンドはローカルクラスタだけを対象に実行されます。
保護グループを有効にしたときにデータ複製を開始しないようにします
-n オプションを指定する必要があります。
保護グループの名前を指定します
詳細は、「Hitachi TrueCopy 保護グループを有効にする方法」を参照してください。
-n オプションが cluster-paris に指定されているため、cluster-newyork から cluster-paris への複製は開始されません。
cluster-paris 上で、各保護グループのテイクオーバーを開始します。
# geopg takeover [-f] protection-group-name |
ユーザーに確認することなく、強制的にコマンドを実行します
保護グループの名前を指定します
geopg takeover コマンドの詳細は、「Hitachi TrueCopy サービスを二次クラスタにより即座に強制テイクオーバーする方法」を参照してください。
この時点で、cluster-paris の保護グループの役割は primary であり、cluster-newyork の保護グループの役割は secondary です。アプリケーションサービスは現在、cluster-paris でオンラインです。
cluster-newyork で、各保護グループを有効にします。
手順 4 の終わりで、cluster-newyork の保護グループのローカル状態は Offline です。保護グループのローカル状態の監視を開始するには、cluster-newyork の保護グループを有効にする必要があります。
cluster-newyork 上の保護グループには secondary の役割が割り当てられているので、geopg start コマンドを実行しても、アプリケーションは cluster-newyork 上では再起動しません。
# geopg start -e local [-n] protection-group-name |
コマンドの適用範囲を指定します
範囲を local に指定した場合、このコマンドはローカルクラスタだけを対象に実行されます。
保護グループを有効にしたときにデータ複製を開始しないようにします
このオプションを省略した場合、データ複製サブシステムは保護グループと同時に起動されます。
保護グループの名前を指定します
geopg start コマンドの詳細は、「Hitachi TrueCopy 保護グループを有効にする方法」を参照してください。
geopg switchover コマンドを実行すると、 horctakeover コマンドが Hitachi TrueCopy データ複製レベルで実行されます。horctakeover コマンドが値 1 を返した場合、スイッチオーバーは成功です。
Hitachi TrueCopy の用語では、スイッチオーバーのことを「スワップテイクオーバー」と呼びます。horctakeover コマンドは、スワップテイクオーバーを実行できない場合があります。このような場合は、1 以外の値が返されます (スイッチオーバー障害を示す)。
障害が発生した場合、通常、horctakeover コマンドは値 5 を返します (SVOL-SSUS-takeover を示す)。
horctakeover コマンドがスワップテイクオーバーの実行に失敗する理由の 1 つに、データ複製リンク ESCON/FC が停止していることがあります。
スワップテイクオーバー以外の結果は、二次ボリュームが主ボリュームと完全には同期していない可能性があることを示します。スイッチオーバー障害のケースの場合、Sun Cluster Geographic Edition ソフトウェアは新しい主クラスタになる予定のクラスタではアプリケーションを起動しません。
この節の残りの部分では、スイッチオーバー障害につながる初期条件を示して、スイッチオーバー障害から回復する方法について説明します。
この節では、スイッチオーバー障害が発生するケース例を示します。このケースでは、cluster-paris が元の主クラスタであり、cluster-newyork が元の二次クラスタです。
次のようにスイッチオーバーを実行すると、cluster-paris から cluster-newyork にサービスが切り替わります。
phys-newyork-1# geopg switchover -f -m cluster-newyork tcpg |
geopg switchover コマンドの処理中、horctakeover コマンドは SVOL-SSUS-takeover を実行して、Hitachi TrueCopy デバイスグループ devgroup1 に対して 値 5 を返します。結果として、geopg switchover コマンドは次のような障害メッセージを返します。
Processing operation.... this may take a while .... "Switchover" failed for the following reason: Switchover failed for Truecopy DG devgroup1 |
この障害メッセージが発行されたあと、2 つのクラスタは次のような状態になります。
cluster-paris: tcpg role: Secondary cluster-newyork: tcpg role: Secondary phys-newyork-1# pairdisplay -g devgroup1 -fc Group PairVol(L/R) (Port#,TID,LU),Seq#,LDEV#.P/S, Status,Fence,%, P-LDEV# M devgroup1 pair1(L) (CL1-C , 0, 20)12345 609..S-VOL SSWS ASYNC,100 1 - devgroup1 pair1(R) (CL1-A , 0, 1) 54321 1..P-VOL PSUS ASYNC,100 609 - |
この節では、前の節で説明した障害シナリオから回復するための手順について説明します。これらの手順は、該当するクラスタでアプリケーションをオンラインにします。
Hitachi TrueCopy デバイスグループ devgroup1 を SMPL 状態にします。
pairsplit コマンドを使用して、cluster-paris と cluster-newyork の両方のクラスタの保護グループにあるデバイスグループを SMPL 状態にします。前の節で示したペアの状態の場合、pairsplit コマンドを実行するべきです。
phys-newyork-1# pairsplit -R -g devgroup1 phys-newyork-1# pairsplit -S -g devgroup1 |
保護グループのクラスタの 1 つを Primary にします。
元の主クラスタでアプリケーションを起動する予定がある場合は、保護グループの元の主クラスタ cluster-paris を Primary にします。アプリケーションは、元の主クラスタで現在のデータを使用します。
元の二次クラスタでアプリケーションを起動する予定がある場合は、保護グループの元の二次クラスタ cluster-newyork を Primary にします。アプリケーションは、元の二次クラスタで現在のデータを使用します。
horctakeover コマンドはスワップテイクオーバーを実行していないため、cluster-newyork のデータボリュームは cluster-paris のデータボリュームと同期していない可能性があります。元の主クラスタにあるのと同じデータを使用してアプリケーションを起動する予定の場合は、元の二次クラスタを Primary にしないでください。
元の主クラスタで保護グループを無効にします。
phys-paris-1# geopg stop -e Local tcpg |
保護グループの構成を再同期させます。
このコマンドは、cluster-paris の保護グループ構成を、cluster-newyork の保護グループ構成情報と一致するように更新します。
phys-paris-1# geopg update tcpg |
geopg update コマンドが正常に実行されたあと、各クラスタで保護グループ tcpg の役割は次のようになります。
cluster-paris: tcpg role: Primary cluster-newyork: tcpg role: secondary |
パートナーシップの両方のクラスタで保護グループを有効にします。
phys-paris-1# geopg start -e Global tcpg |
このコマンドは、cluster-paris でアプリケーションを起動します。cluster-paris から cluster-newyork へのデータ複製が開始されます。
保護グループの構成を再同期させます。
このコマンドは、cluster-newyork の保護グループ構成を、cluster-paris の保護グループ構成情報と一致するように更新します。
phys-newyork-1# geopg update tcpg |
geopg update コマンドが正常に実行されたあと、各クラスタで保護グループ tcpg の役割は次のようになります。
cluster-paris: tcpg role: Secondary cluster-newyork: tcpg role: Primary |
パートナーシップの両方のクラスタで保護グループを有効にします。
phys-newyork-1# geopg start -e Global tcpg |
このコマンドは、cluster-newyork でアプリケーションを起動します。cluster-newyork から cluster-paris へのデータ複製が開始されます。
このコマンドは、cluster-paris 上のデータを上書きします。
データ複製レベルでエラーが発生した場合、関連するデバイスグループの複製リソースグループ内のリソースの状態に、そのエラーが反映されます。
データ複製レベルでエラーが発生した場合、関連するデバイスグループの複製リソースグループ内のリソースの状態に、そのエラーが反映されます。
Resource status のさまざまな値を実際の複製ペアの状態に対応付ける方法については、表 10–6 を参照してください。
複製リソースの状態は、scstat -g コマンドを次のように使用すると検査できます。
phys-paris-1# scstat -g |
scstat -g コマンドを実行すると、次のようなメッセージが返ることがあります。
... --Resources -- Resource Name Node Name State Status Message ------------- --------- ----- -------------- Resource: r-tc-tcpg1-devgroup1 phys-paris-2 Offline Offline Resource: r-tc-tcpg1-devgroup1 phys-paris-1 Online Faulted - P-VOL:PSUE Resource: hasp4nfs phys-paris-1 Offline Offline Resource: hasp4nfs phys-paris-2 Offline Offline ... |
保護グループに含まれるすべてのデバイスグループの全体的なリソース状態を表示するには、geoadm status コマンドを使用します。たとえば、先の例における scstat -g コマンドの出力は、Hitachi TrueCopy デバイスグループ devgroup1 が cluster-paris で PSUE 状態であることを示しています。表 10–6 は、PSUE 状態がリソース状態 FAULTED に対応することを示しています。したがって、保護グループのデータ複製状態も FAULTED です。この状態は、geoadm status コマンドの出力に反映され、保護グループの状態が Error として表示されます。
phys-paris-1# geoadm status Cluster: cluster-paris Partnership "paris-newyork-ps" : OK Partner clusters : cluster-newyork Synchronization : OK Heartbeat "paris-to-newyork" monitoring "cluster-newyork": OK Heartbeat plug-in "ping_plugin" : Inactive Heartbeat plug-in "icrm_plugin" : OK Heartbeat plug-in "tcp_udp_plugin" : OK Protection group "tcpg" : Error Partnership : paris-newyork-ps Synchronization : OK Cluster cluster-paris : Error Role : Primary PG activation state : Activated Configuration : OK Data replication : Error Resource groups : OK Cluster cluster-newyork : Error Role : Secondary PG activation state : Activated Configuration : OK Data replication : Error Resource groups : OK Pending Operations Protection Group : "tcpg" Operations : start |
エラー状態から回復するには、次の手順の一部または全部を実行することをお勧めします。
Hitachi TrueCopy のマニュアルに記載されている手順に従って、FAULTED 状態になった原因を調べます。この状態は PSUE として示されます。
Hitachi TrueCopy の所定の手順に従って、障害状態から回復します。
回復手順によってデバイスグループの状態が変化した場合、この状態は自動的にリソースによって検出され、新しい保護グループの状態として報告されます。
保護グループ構成を検証し直します。
phys-paris-1# geopg validate protection-group-name |
Hitachi TrueCopy 保護グループの名前を指定します
保護グループ構成の状態を確認します。
phys-paris-1# geopg list protection-group-name |
Hitachi TrueCopy 保護グループの名前を指定します
保護グループの実行時状態を確認します。
phys-paris-1# geoadm status |