主ボリュームと二次ボリュームのデータが完全に整合しているかどうかにかかわらず二次クラスタ上でアプリケーションをオンラインにする必要がある場合は、テイクオーバーを実行します。ここでは、保護グループが起動しているものと仮定します。
テイクオーバーは次の手順で行われます。
元の主クラスタ cluster-paris にアクセスでき、保護グループが通知処理やその他の理由でロックされていない場合、元の主クラスタでアプリケーションサービスがオフラインになります。
どのクラスタが cluster-paris かを確認するために、『Sun Cluster Geographic Edition のシステム管理』の「Sun Cluster Geographic Edition クラスタ構成の例」を参照してください。
元の主クラスタ cluster-paris のデータボリュームが、新しい主クラスタ cluster-newyork にテイクオーバーされます。
このデータは、元の主クラスタのデータボリュームとは一致していないことがあります。テイクオーバー後、新しい主クラスタ cluster-newyork から元の主クラスタ cluster-paris へのデータ複製が停止されます。
新しい主クラスタ cluster-newyork で、アプリケーションサービスがオンラインになります。
テイクオーバーの前後で考えられる主クラスタと二次クラスタの条件についての詳細は、『Sun Cluster Geographic Edition のシステム管理』の付録 C「テイクオーバー後の状態」を参照してください。
これ以降の節では、二次クラスタによるテイクオーバーを強制実行するときに行う必要がある手順について説明します。
geopg takeover コマンドを使用してテイクオーバーを開始すると、両方のクラスタに対してデータ複製サブシステムがいくつかの検証を実行します。これらの手順は、元の主クラスタでは、その主クラスタに到達できる場合だけに行われます。元の主クラスタでの検証が失敗する場合でも、テイクオーバーは実行されます。
まず、複製サブシステムは、Hitachi TrueCopy デバイスグループの全体的なデバイスグループ状態が有効であるかどうか検査します。 続いて、複製サブシステムは、ターゲットの主クラスタ cluster-newyork のローカルのデバイスグループ状態が 32 または 52 でないことを検査します。これらの値は SVOL_COPY 状態に対応しています (この状態では horctakeover コマンドは失敗する)。次の表に、テイクオーバーに使用する Hitachi TrueCopy コマンドを示します。
表 3–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 のシステム管理』の「Sun Cluster Geographic Edition ソフトウェアと RBAC」を参照してください。
テイクオーバーを開始します。
# geopg takeover [-f] protectiongroupname |
ユーザーに確認することなく、強制的にコマンドを実行します
保護グループの名前を指定します
この例では、二次クラスタ cluster-newyork によって、tcpg を強制的にテイクオーバーします。
phys-newyork-1 は二次クラスタの第 1 ノードです。どのノードが phys-newyork-1 かを確認するには、『Sun Cluster Geographic Edition のシステム管理』の「Sun Cluster Geographic Edition クラスタ構成の例」を参照してください。
phys-newyork-1# geopg takeover -f tcpg |
テイクオーバー後の主クラスタと二次クラスタの状態についての詳細は、『Sun Cluster Geographic Edition のシステム管理』の付録 C「テイクオーバー後の状態」を参照してください。