Sun Cluster Geographic Edition Sun StorEdge Availability Suite 向けデータ複製ガイド

第 3 章 Sun StorageTek Availability Suite データ複製を使用するサービスの移行

この章では、保守管理を行う場合やクラスタ障害が発生した場合のサービスの移行について説明します。内容は次のとおりです。

Sun StorageTek Availability Suite データ複製を使用するシステム上でのクラスタの障害の検出

この節では、主クラスタまたは二次クラスタで障害が検出される際に発生する内部プロセスについて説明します。

主クラスタの障害の検出

ある保護グループの主クラスタに障害が発生すると、パートナーシップの二次クラスタがその障害を検出します。障害が発生するクラスタは複数のパートナーシップのメンバーである可能性があるため、このような障害の検出も複数発生する可能性があります。

保護グループ全体の状態が Unknown 状態に変化すると、次の動作が発生します。

ハートビート異常がパートナークラスタによって検出されます。
ハートビート喪失が一時的なものではないことと、主クラスタに障害が発生していることを確認するため、緊急モードでハートビートが有効になります。このデフォルトのタイムアウト間隔の間、つまり、ハートビート機構が主クラスタの状態を確認 (照会) しようと再試行している間、ハートビートは OK 状態のままです。Error 状態ではハートビートのプラグインだけが現れます。

この照会間隔は、ハートビートの Query_interval プロパティーを使用して設定します。設定した Query_interval が 4 回 (再試行 3 回と緊急モード検証 1 回) 経過してもハートビート異常が続く場合は、ハートビート喪失イベントが生成され、システムログに記録されます。デフォルトの照会間隔を使用する場合、緊急モードの再試行動作によって、ハートビート喪失通知は約 9 分間遅れる可能性があります。メッセージは、グラフィカルユーザーインタフェース (GUI) と geoadm status コマンドの出力に表示されます。

ロギングについての詳細は、『Sun Cluster Geographic Edition System Administration Guide』の「Viewing the Sun Cluster Geographic Edition Log Messages」を参照してください。

二次クラスタの障害の検出

ある保護グループの二次クラスタに障害が発生すると、同じパートナーシップのクラスタがその障害を検出します。障害が発生したクラスタは複数のパートナーシップのメンバーである可能性があるため、このような障害の検出も複数発生する可能性があります。

障害の検出中、次のアクションが発生します。

ハートビート異常がパートナークラスタによって検出されます。
二次クラスタが停止していることを確認するため、ハートビートが緊急モードでアクティブ化されます。
クラスタから管理者に通知が送られます。障害が発生したクラスタが二次クラスタとして動作しているすべての保護グループが検出されます。これらの保護グループの状態が Unknown になります。

Sun StorageTek Availability Suite を使用するサービスをスイッチオーバーで移行する

パートナークラスタにサービスを順番に移行する場合は、Sun StorageTek Availability Suite 保護グループのスイッチオーバーを実行します。スイッチオーバーは次の手順で行われます。

元の主クラスタ cluster-paris 上で、アプリケーションサービスが非管理状態になります。

どのクラスタが cluster-paris かを確認するために、『Sun Cluster Geographic Edition System Administration Guide』の「Example Sun Cluster Geographic Edition Cluster Configuration」を参照してください。
データ複製の役割が逆になり、今度は、新しい主クラスタ cluster-newyork から元の主クラスタ cluster-paris に対して継続して複製が行われます。
新しい主クラスタ cluster-newyork で、アプリケーションサービスがオンラインになります。

この節では、次の内容について説明します。

Sun StorageTek Availability Suite 保護グループを主クラスタから二次クラスタにスイッチオーバーする方法

始める前に

スイッチオーバーを行うには、主クラスタと二次クラスタ間のデータ複製が有効になっている必要があります。また、これら 2 つのクラスタ上のデータボリュームが同期している必要があります。

主クラスタから二次クラスタへ保護グループのスイッチオーバーを行うには、次の条件が満たされている必要があります。

両方のクラスタで Sun Cluster Geographic Edition ソフトウェアが動作している。
二次クラスタがパートナーシップのメンバーである。
両方のクラスタパートナーが互いに到達可能である。
保護グループの全体的な状態が OK になっている。

クラスタノードの 1 つにログインします。

この手順を行うには、Geo Management RBAC 権利プロファイルがユーザーに割り当てられている必要があります。RBAC についての詳細は、『Sun Cluster Geographic Edition System Administration Guide』の「Sun Cluster Geographic Edition Software and RBAC」を参照してください。

スイッチオーバーを開始します。

スイッチオーバーでは、保護グループに属するアプリケーションリソースグループの停止と起動が行われます。
# geopg switchover [-f] -m newprimarycluster protectiongroupname
-f

ユーザーに確認することなく、強制的にコマンドを実行します

-m newprimarycluster

保護グループの主クラスタにするクラスタの名前を指定します。

protectiongroupname

保護グループの名前を指定します

例 3–1 主クラスタから二次クラスタへの強制的なスイッチオーバー

この例では、二次クラスタへのスイッチオーバーを実行する方法を示します。

# geopg switchover -f -m cluster-newyork avspg

スイッチオーバー中に Sun Cluster Geographic Edition ソフトウェアが実行する処理

geopg switchover コマンドを実行すると、ソフトウェアにより、デバイスグループに関連付けられているボリュームセットの状態が replicating になっているかが確認されます。その後、元の主クラスタに対して、次の処理が実行されます。

保護グループ内のすべてのアプリケーションリソースグループと内部リソースグループ (軽量リソースグループなど) 間のアフィニティーとリソースの依存関係を削除します
アプリケーションリソースグループをオフラインにし、unmanaged 状態にします
書き込みが完了するまで待機します
保護グループ内のデバイスグループに対応する主ボリュームのマウントを解除します
すべてのボリュームセットをロギングモードにして、データ複製を停止します
すべてのボリュームセットの役割を逆転させます

元の二次クラスタでは、同じコマンドによって次の処理が行われます。

すべてのボリュームセットをロギングモードにします
すべてのボリュームセットの役割を逆転させます
自動同期機能を有効にして更新同期を行い、データ複製を開始します
RoleChange_ActionCmd プロパティーに定義されているスクリプトを実行します
すべてのアプリケーションリソースグループをオンラインにし、アプリケーションリソースグループと内部リソースグループ (軽量リソースグループなど) 間にアフィニティーを追加します

コマンドが正常に実行された場合、二次クラスタ cluster-newyork が保護グループの新しい主クラスタになります。元の主クラスタ cluster-paris は新しい二次クラスタになります。ローカルクラスタ上の保護グループの役割に従って、保護グループのデバイスグループと関連付けられているボリュームセットの役割が逆転します。新しい主クラスタのアプリケーションリソースグループがオンラインになります。新しい主クラスタから新しい二次クラスタへのデータ複製が開始されます。

このコマンドは、それまでの操作のうち 1 つでも失敗したものがあると、エラーを返します。個々のコンポーネントの状態を表示するには、geoadm status コマンドを実行します。失敗の原因によっては、保護グループの Configuration の状態が Error に設定されることがあります。保護グループは、有効になっている場合と無効になっている場合があります。

保護グループの Configuration の状態が Error に設定されている場合は、「Sun StorageTek Availability Suite 保護グループを検証する」の手順に従って、保護グループを再検証します。

個々のパートナークラスタ上で保護グループの構成が一致していない場合は、「Sun StorageTek Availability Suite 保護グループを再同期させる」の手順に従って、構成を再同期させる必要があります。

Sun StorageTek Availability Suite を使用するシステム上での強制テイクオーバー

主ボリュームと二次ボリュームのデータが完全に整合しているかどうかにかかわらず二次クラスタ上でアプリケーションをオンラインにする必要がある場合は、テイクオーバーを実行します。ここでは、保護グループがすでに起動されているものと仮定します。

テイクオーバーは次の手順で行われます。

以前の主クラスタ cluster-paris が到達可能であり、保護グループが通知処理またはそれ以外の理由でロックされていない場合は、保護グループが無効になります。

どのクラスタが cluster-paris かを確認するために、『Sun Cluster Geographic Edition System Administration Guide』の「Example Sun Cluster Geographic Edition Cluster Configuration」を参照してください。
元の主クラスタ cluster-paris のデータボリュームが、新しい主クラスタ cluster-newyork にテイクオーバーされます。

注 –
このデータは、元の主クラスタのデータボリュームとは一致していないことがあります。新しい主クラスタ cluster-newyork から元の主クラスタ cluster-paris へのデータ複製が停止します。
データ複製を行うことなく保護グループが有効になります。

テイクオーバーの前後で考えられる主クラスタと二次クラスタの条件についての詳細は、『Sun Cluster Geographic Edition System Administration Guide』の付録 C「Takeover Postconditions」を参照してください。

ここからは、二次クラスタによる強制テイクオーバーの実施に必要な手順と、その後のデータの回復方法について説明します。

Sun StorageTek Availability Suite サービスを二次クラスタへ即時に強制的テイクオーバーする

始める前に

二次クラスタに主クラスタの処理を引き受けさせるためには、次の条件が満たされている必要があります。

クラスタ上で Sun Cluster Geographic Edition ソフトウェアが稼働中である。
クラスタがパートナーシップのメンバーである。
二次クラスタ上で保護グループの Configuration の状態が OK である。

二次クラスタ内のノードの 1 つにログインします。

この手順を行うには、Geo Management RBAC 権利プロファイルがユーザーに割り当てられている必要があります。RBAC についての詳細は、『Sun Cluster Geographic Edition System Administration Guide』の「Sun Cluster Geographic Edition Software and RBAC」を参照してください。

テイクオーバーを開始します。
# geopg takeover [-f] protectiongroupname
-f

ユーザーに確認することなく、強制的にコマンドを実行します

protectiongroupname

保護グループの名前を指定します

例 3–2 二次クラスタによる強制テイクオーバー

この例では、二次クラスタ cluster-newyork による avspg の強制テイクオーバーの方法を示します。

phys-newyork-1 は二次クラスタの第 1 ノードです。どのノードが phys-newyork-1 かを確認するために、『Sun Cluster Geographic Edition System Administration Guide』の「Example Sun Cluster Geographic Edition Cluster Configuration」を参照してください。

phys-newyork-1# geopg takeover -f avspg

次の手順

テイクオーバー後の主クラスタと二次クラスタの状態についての詳細は、『Sun Cluster Geographic Edition System Administration Guide』の付録 C「Takeover Postconditions」を参照してください。

テイクオーバー中に Sun Cluster Geographic Edition ソフトウェアが実行する処理

geopg takeover コマンドを実行すると、ソフトウェアにより、二次クラスタ上のボリュームセットの状態が Replicating または Logging であることが確認されます。

元の主クラスタ cluster-paris にアクセスできる場合は、次の処理が実行されます。

保護グループが有効であった場合、保護グループ内のすべてのアプリケーションリソースグループと内部リソースグループ間のアフィニティーとリソースの依存関係を削除します
アプリケーションリソースグループがオフラインになり、unmanaged 状態になります
保護グループ内のデバイスグループに対応する主ボリュームのマウントを解除します
すべてのボリュームセットをロギングモードにして、データ複製を停止します
すべてのボリュームセットの役割を逆転させます

元の二次クラスタ cluster-newyork 上では、次の処理が実行されます。

すべてのボリュームセットをロギングモードにします
すべてのボリュームセットの役割を逆転させます
RoleChange_ActionCmd プロパティーに指定されているスクリプトを実行します
テイクオーバーを行う前、元の二次クラスタ上で保護グループがアクティブだった場合、すべてのアプリケーションリソースグループをオンラインにし、アプリケーションリソースグループと内部リソースグループ間にアフィニティーとリソースの依存関係を追加します。

コマンドが正常に実行された場合、二次クラスタ cluster-newyork が保護グループの新しい主クラスタになります。ローカルクラスタ上の保護グループの役割に従って、保護グループのデバイスグループと関連付けられているボリュームセットの役割が逆転します。テイクオーバーを行う前、元の二次クラスタ上で保護グループがアクティブだった場合、新しい主クラスタ上でアプリケーションリソースグループがオンラインになります。元の主クラスタにアクセスできる場合、このクラスタが保護グループの新しい二次クラスタになります。保護グループのデバイスグループに関連付けられているすべてのボリュームセットの複製は、停止します。

注意 –

テイクオーバーが正常に完了すると、データ複製は停止します。複製を引き続き中断したままにする場合は、geopg start コマンドを -n オプション付きで実行します。このオプションを指定すると、新しい主クラスタから新しい二次クラスタへのデータ複製が行われません。

テイクオーバー後の Sun StorageTek Availability Suite データの回復

テイクオーバーが正常に完了すると、二次クラスタ cluster-newyork が保護グループの主クラスタになり、この二次クラスタ上でサービスがオンラインになります。元の主クラスタが回復したところで、「フェイルバック」と呼ばれる処理を行なって元の主クラスタ上で再びサービスをオンラインにすることができます。

Sun Cluster Geographic Edition ソフトウェアでは、次の 2 種類のフェイルバックがサポートされています。

「フェイルバックスイッチオーバー」。フェイルバックスイッチオーバーの場合、アプリケーションは、元の主クラスタ cluster-paris のデータが二次クラスタ cluster-newyork のデータと再同期されたあとで、元の主クラスタでオンラインに戻ります。

どのクラスタが cluster-paris と cluster-newyork かを確認するために、『Sun Cluster Geographic Edition System Administration Guide』の「Example Sun Cluster Geographic Edition Cluster Configuration」を参照してください。
「フェイルバックテイクオーバー」。フェイルバックテイクオーバーの場合、アプリケーションは元の主クラスタ上で再度オンラインに戻って、主クラスタ上の現在のデータを使用します。二次クラスタ上で更新が行われていたとしても、その内容は破棄されます。

元の主クラスタを再び起動したあとに、新しい主クラスタ cluster-newyork を主クラスタとして残し、元の主クラスタ cluster-paris を二次クラスタとして残す場合は、スイッチオーバーやテイクオーバーを実行せずに、保護グループの構成を再同期させて再検証することができます。

この節では、次の内容について説明します。

保護グループの構成を再同期させて再検証する

次の手順を実行して、元の主クラスタ cluster-paris 上のデータと現在の主クラスタ cluster-newyork との間でデータの再同期と再検証を行います。

始める前に

保護グループの構成の再同期と再検証を行う前、cluster-newyork ではすでにテイクオーバーが発生しています。現在のクラスタの役割は次のとおりです。

元の主クラスタ cluster-paris が停止していた場合、そのクラスタが起動していること、および、そのクラスタで Sun Cluster Geographic Edition インフラストラクチャーが有効であることを確認します。クラスタの起動についての詳細は、『Sun Cluster Geographic Edition System Administration Guide』の「Booting a Cluster」を参照してください。
cluster-newyork の保護グループの役割は primary です。
cluster-paris 上の保護グループの役割は、cluster-newyork からのテイクオーバー中に cluster-paris に到達できたかどうかによって、primary か secondary のいずれかになります。

元の主クラスタ cluster-paris を現在の主クラスタ cluster-newyork と再同期させます。

クラスタ cluster-paris はその独自の構成を失い、cluster-newyork 構成をローカルに複製します。パートナーシップ構成と保護グループ構成の両方を再同期させます。
1. cluster-paris 上で、ローカルクラスタ上の保護グループを無効にします。
  # geopg stop -e Local protectiongroupname
  -e Local
  
  コマンドの範囲を指定します。
  
  範囲を local と指定すると、ローカルクラスタだけがコマンドの対象となります。
  
  protectiongroupname
  
  保護グループの名前を指定します。
  
  保護グループがすでに無効になっている場合は、保護グループ内のリソースグループの状態は通常 Error です。状態が Error であるのは、アプリケーションリソースグループが現在管理されていてオフラインであるためです。
  
  保護グループを無効にすると、アプリケーションリソースグループは管理対象でなくなり、Error 状態が解消されます。
2. cluster-paris で、パートナーシップを再同期させます。
  # geops update partnershipname
  partnershipname
  
  パートナーシップの名前を指定します
  
  注 –
  複数の保護グループを再同期させている場合でも、この手順は 1 回実行するだけで済みます。
  
  パートナーシップの同期についての詳細は、『Sun Cluster Geographic Edition System Administration Guide』の「Resynchronizing a Partnership」を参照してください。
3. cluster-paris で、各保護グループを再同期させます。
  
  cluster-newyork 上の保護グループの役割は primary であるため、この手順により cluster-paris 上の保護グループの役割は secondary になります。
  # geopg update protectiongroupname
  protectiongroupname
  
  保護グループの名前を指定します
  
  保護グループの同期については、「Sun StorageTek Availability Suite 保護グループの再同期」を参照してください。

cluster-paris 上で、個々の保護グループの構成を検証します。
# geopg validate protectiongroupname
protectiongroupname

単一の保護グループを識別する一意の名前を指定します

詳細は、「Sun StorageTek Availability Suite 保護グループを検証する」を参照してください。

cluster-paris で、各保護グループを有効にします。

保護グループを有効にすると、そのアプリケーションリソースグループもオンラインになります。
# geopg start -e Global protectiongroupname
-e Global

コマンドの範囲を指定します。

Global スコープを指定すると、保護グループが配備されている両方のクラスタがコマンドの対象となります。

protectiongroupname

保護グループの名前を指定します。

注意 –
現在の主クラスタ cluster-newyork から現在の二次クラスタ cluster-paris にデータを再同期させる必要があるため、-n オプションを使用しないでください。

保護グループの役割は secondary であるため、データの同期化は現在の主クラスタである cluster-newyork から二次クラスタ cluster-paris へと行われます。

geopg start コマンドの詳細は、「Sun StorageTek Availability Suite 保護グループを有効にする」を参照してください。

データが完全に同期したことを確認します。

まず、cluster-newyork 上の保護グループの状態が OK であることを確認します。
phys-newyork-1# geoadm status
出力の保護グループセクションを参照してください。

次に、複製リソースグループ AVSprotectiongroupname-rep-rg 内のすべてのリソースの状態が OK であることを確認します。
phys-newyork-1# clresource status -v AVSdevicegroupname-rep-rs

Sun StorageTek Availability Suite 複製を使用するシステム上でフェイルバックスイッチオーバーを実行する

この手順は、元の主クラスタ cluster-paris のデータが現在の主クラスタ cluster-newyork のデータと再同期されたあとで、アプリケーションを元の主クラスタで再起動するときに使用します。

フェイルバックの手順はパートナーシップ内のクラスタにのみ適用されます。ここでの手順はパートナーシップごとに 1 回実行するだけで済みます。

始める前に

フェイルバックスイッチオーバーを実行する前に、cluster-newyork ではテイクオーバーが発生していました。現在のクラスタの役割は次のとおりです。

元の主クラスタ cluster-paris が停止していた場合、そのクラスタが起動していること、および、そのクラスタで Sun Cluster Geographic Edition インフラストラクチャーが有効であることを確認します。クラスタの起動についての詳細は、『Sun Cluster Geographic Edition System Administration Guide』の「Booting a Cluster」を参照してください。
cluster-newyork の保護グループの役割は primary です。
cluster-paris 上の保護グループの役割は、cluster-newyork からのテイクオーバー中に cluster-paris に到達できたかどうかによって、primary か secondary のいずれかになります。

元の主クラスタ cluster-paris を現在の主クラスタ cluster-newyork と再同期させます。

クラスタ cluster-paris はその独自の構成を失い、cluster-newyork 構成をローカルに複製します。パートナーシップ構成と保護グループ構成の両方を再同期させます。
1. cluster-paris で、パートナーシップを再同期させます。
  phys-paris-1# geops update partnershipname
  partnershipname
  
  パートナーシップの名前を指定します
  
  注 –
  パートナーシップ内の複数の保護グループに対してフェイルバックスイッチオーバーを実行している場合でも、この手順はパートナーシップごとに 1 回実行するだけで済みます。
  
  パートナーシップの同期についての詳細は、『Sun Cluster Geographic Edition System Administration Guide』の「Resynchronizing a Partnership」を参照してください。
2. 元の主クラスタである cluster-paris 上の保護グループが有効であるかどうかを判断します。
  phys-paris-1# geoadm status
3. 元の主クラスタ上の保護グループが有効である場合は、それを停止します。
  phys-paris-1# geopg stop -e local protectiongroupname
  -e local
  
  コマンドの範囲を指定します。
  
  範囲を local と指定すると、ローカルクラスタだけがコマンドの対象となります。
  
  protectiongroupname
  
  保護グループの名前を指定します。
  
  保護グループがすでに無効になっている場合は、保護グループ内のリソースグループの状態は通常 Error です。状態が Error であるのは、アプリケーションリソースグループが現在管理されていてオフラインであるためです。
  
  保護グループを無効にすると、アプリケーションリソースグループは管理対象でなくなり、Error 状態が解消されます。
4. 保護グループが停止されていることを確認します。
  phys-paris-1# geoadm status
5. cluster-paris で、各保護グループを再同期させます。
  
  cluster-newyork の保護グループのローカルな役割は現在 primary であるため、この手順によって cluster-paris の保護グループのローカルな役割が確実に secondary になります。
  phys-paris-1# geopg update protectiongroupname
  protectiongroupname
  
  保護グループの名前を指定します
  
  保護グループの同期については、「Sun StorageTek Availability Suite 保護グループの再同期」を参照してください。

cluster-paris 上で、個々の保護グループの構成を検証します。

エラー状態の保護グループを起動することはできません。保護グループがエラー状態でないことを確認します。
phys-paris-1# geopg validate protectiongroupname
protectiongroupname

単一の保護グループを識別する一意の名前を指定します

詳細は、「Sun StorageTek Availability Suite 保護グループを検証する」を参照してください。

cluster-paris で、各保護グループを有効にします。

保護グループを有効にすると、そのアプリケーションリソースグループもオンラインになります。
phys-paris-1# geopg start -e Global protectiongroupname
-e Global

コマンドの範囲を指定します。

Global スコープを指定すると、保護グループが配備されている両方のクラスタがコマンドの対象となります。

protectiongroupname

保護グループの名前を指定します。

注意 –
データを現在の主クラスタ (cluster-newyork) から現在の二次クラスタ (cluster-paris) に同期させる必要があるため、フェイルバックスイッチオーバーを実行するときに、-n オプションは使用しないでください。

保護グループの役割は secondary であるため、データの同期化は現在の主クラスタである cluster-newyork から二次クラスタ cluster-paris へと行われます。

geopg start コマンドの詳細は、「Sun StorageTek Availability Suite 保護グループを有効にする」を参照してください。

データが完全に同期したことを確認します。

まず、cluster-newyork 上の保護グループの状態が OK であることを確認します。
phys-newyork-1# geoadm status
出力の保護グループセクションを参照してください。

次に、複製リソースグループ AVSprotectiongroupname-rep-rg 内のすべてのリソースの状態が OK であることを確認します。
phys-newyork-1# clresource status -v AVSdevicegroupname-rep-rs

両方のパートナークラスタ上で、保護グループが有効になったことを確認します。
# geoadm status

どちらか一方のクラスタで、各保護グループについて cluster-newyork から cluster-paris へのスイッチオーバーを実行します。
# geopg switchover [-f] -m clusterparis protectiongroupname
詳細は、「Sun StorageTek Availability Suite 保護グループを主クラスタから二次クラスタにスイッチオーバーする方法」を参照してください。

cluster-paris は、元の役割である、保護グループの主クラスタに戻ります。

スイッチオーバーが正常に実行されたことを確認します。

保護グループが cluster-paris 上で primary となり、cluster-newyork 上で secondary となったこと、および、「データ複製」と「リソースグループ」の状態が両方のクラスタで OK であることを確認します。
# geoadm status
各 Sun StorageTek Availability Suite 保護グループについて、アプリケーションリソースグループとデータ複製の実行時状態を検査します。
# clresourcegroup status -v resourcegroupname # clresource status -v AVSdevicegroupname-rep-rs
検査するデータ複製デバイスグループの Status フィールドと Status Message フィールドを参照してください。これらのフィールドの詳細は、表 2–1 を参照してください。

データ複製の実行時状態については、「Sun StorageTek Availability Suite データ複製の実行時状態の検査」を参照してください。

Sun StorageTek Availability Suite 複製を使用するシステム上でフェイルバックテイクオーバーを実行する

元の主クラスタ cluster-paris 上でアプリケーションを再起動し、元の主クラスタ上の現在のデータを使用するには、次の手順を実行します。この場合、現在主クラスタとして機能している二次クラスタ cluster-newyork の更新データはすべて破棄されます。

注 –

条件付きですが、元の主クラスタ cluster-paris のデータの使用は再開できます。cluster-newyork でのテイクオーバー操作のあとは、どのような時点でも、新しい主クラスタ cluster-newyork から元の主クラスタ cluster-paris にデータを複製していてはいけません。

始める前に

フェイルバックテイクオーバー操作を開始する前、クラスタには次の役割が割り当てられています。

元の主クラスタ cluster-paris が停止していた場合、そのクラスタが起動していること、および、そのクラスタで Sun Cluster Geographic Edition インフラストラクチャーが有効であることを確認します。クラスタの起動についての詳細は、『Sun Cluster Geographic Edition System Administration Guide』の「Booting a Cluster」を参照してください。
cluster-newyork の保護グループの役割は primary です。
cluster-paris の保護グループの役割は、テイクオーバー中にその保護グループに到達できるかどうかによって、primary または secondary のどちらかです。

元の主クラスタ cluster-paris を元の二次クラスタ cluster-newyork と再同期させます。

この操作により、cluster-paris の独自の構成は削除され、cluster-newyork の構成がローカルに複製されます。
1. cluster-paris で、パートナーシップを再同期させます。
  phys-paris-1# geops update partnershipname
  partnershipname
  
  パートナーシップの名前を指定します
  
  注 –
  パートナーシップ内の複数の保護グループに対してフェイルバックテイクオーバーを実行している場合でも、この手順はパートナーシップごとに 1 回実行するだけで済みます。
  
  パートナーシップの同期についての詳細は、『Sun Cluster Geographic Edition System Administration Guide』の「Resynchronizing a Partnership」を参照してください。
2. 元の主クラスタである cluster-paris 上の保護グループが、有効であるかどうかを判断します。
  phys-paris-1# geoadm status
3. 元の主クラスタ上の保護グループが有効である場合は、それを停止します。
  phys-paris-1# geopg stop -e local protectiongroupname
4. 保護グループが停止されていることを確認します。
  phys-paris-1# geoadm status
5. cluster-paris で、各保護グループを再同期させます。
  
  保護グループが有効に設定されている場合は、geopg stop コマンドを使用してその保護グループを無効にします。保護グループを無効にする方法については、「Sun StorageTek Availability Suite 保護グループを無効にする」を参照してください。
  phys-paris-1# geopg update protectiongroupname
  protectiongroupname
  
  保護グループの名前を指定します
  
  保護グループの同期については、「Sun StorageTek Availability Suite 保護グループを再同期させる」を参照してください。

cluster-paris 上で、個々の保護グループの構成を検証します。

保護グループがエラー状態でないことを確認します。エラー状態の保護グループを起動することはできません。
phys-paris-1# geopg validate protectiongroupname
protectiongroupname

単一の保護グループを識別する一意の名前を指定します

詳細は、「Sun StorageTek Availability Suite 保護グループを検証する」を参照してください。

cluster-paris 上で、データ複製を行わずに、二次クラスタの役割が割り当てられている各保護グループを有効にします。

cluster-paris の保護グループの役割は secondary であるため、geopg start コマンドは cluster-paris でアプリケーションを再起動しません。
phys-paris-1# geopg start -e local -n protectiongroupname
-e local

コマンドの範囲を指定します。

範囲を local と指定すると、ローカルクラスタだけがコマンドの対象となります。

-n

保護グループを有効にしたときにデータ複製を開始しないようにします。

注 –
-n オプションを指定する必要があります。

protectiongroupname

保護グループの名前を指定します。

詳細は、「Sun StorageTek Availability Suite 保護グループを有効にする」を参照してください。

-n オプションが cluster-paris で使用されているため、cluster-newyork から cluster-paris への複製は開始されません。

cluster-paris 上で、各保護グループのテイクオーバーを開始します。
phys-paris-1# geopg takeover [-f] protectiongroupname
-f

ユーザーに確認することなく、強制的にコマンドを実行します

protectiongroupname

保護グループの名前を指定します

geopg takeover コマンドの詳細は、「Sun StorageTek Availability Suite サービスを二次クラスタへ即時に強制的テイクオーバーする」を参照してください。

この時点で、cluster-paris の保護グループの役割は primary であり、cluster-newyork の保護グループの役割は secondary です。

cluster-newyork で、各保護グループを有効にします。

cluster-newyork 上の保護グループには secondary の役割が割り当てられているので、geopg start コマンドを実行しても、アプリケーションは cluster-newyork 上では再起動しません。
phys-newyork-1# geopg start -e local [-n] protectiongroupname
-e local

コマンドの範囲を指定します。

範囲を local と指定すると、ローカルクラスタだけがコマンドの対象となります。

-n

保護グループを有効にしたときにデータ複製を開始しないようにします。

このオプションを省略した場合、データ複製サブシステムは保護グループと同時に起動されます。

protectiongroupname

保護グループの名前を指定します。

geopg start コマンドの詳細は、「Sun StorageTek Availability Suite 保護グループを有効にする」を参照してください。

データ複製を開始します。

データ複製を開始するには、主クラスタ cluster-paris 上で保護グループを有効にします。
phys-paris-1# geopg start -e local protectiongroupname
geopg start コマンドの詳細は、「Sun StorageTek Availability Suite 保護グループを有効にする」を参照してください。

各クラスタについて、保護グループが正しく設定されていることと、アプリケーションリソースグループの状態とデータ複製の状態が正常であることを確認します。
1. 保護グループが cluster-paris 上で primary となり、cluster-newyork 上で secondary となったことを確認します。各クラスタのノードの 1 つから、次のコマンドを実行します。
  # geoadm status
2. 各 Sun StorageTek Availability Suite 保護グループについて、アプリケーションリソースグループとデータ複製の実行時状態を検査します。各クラスタのノードの 1 つから、次のコマンドを実行します。
  # clresourcegroup status -v resourcegroupname # clresource status -v AVSdevicegroupname-rep-rs
  検査するデータ複製デバイスグループの Status フィールドと Status Message フィールドを参照してください。これらのフィールドの詳細は、表 2–1 を参照してください。
  
  データ複製の実行時状態については、「Sun StorageTek Availability Suite データ複製の実行時状態の検査」を参照してください。

Sun StorageTek Availability Suite データ複製エラーからの回復

データ複製レベルでエラーが発生した場合、関連するデバイスグループの複製リソースグループ内のリソースの状態に、そのエラーが反映されます。

たとえば、Sun StorageTek Availability Suite で制御されている avsdg という名前のデバイスグループの状態が Volume failed 状態 (VF) に変わったとします。この状態は、次のリソースの状態に反映されます。

Resource Status = "FAULTED"
Resource status message = "FAULTED : Volume failed"

注 –

検証はまだ正常に実行されているので、Resource State は Online のままです。

リソースの状態が変化したため、保護グループの状態も変化します。この例の場合、ローカルの Data Replication の状態、ローカルクラスタ上の Protection Group の状態、および全体の Protection Group の状態が Error に変わります。

エラー状態から回復するには、次に示す作業内の関連する部分を実行します。

データ複製エラーから回復する方法

Sun StorageTek Availability Suite のマニュアルに記載されている手順に従って、FAULTED 状態になった原因を調べます。この状態は VF として示されます。

Sun StorageTek Availability Suite の所定の手順に従って、障害状態から回復します。

回復手順によってデバイスグループの状態が変化した場合、この状態は自動的にリソースによって検出され、新しい保護グループの状態として報告されます。

保護グループ構成を検証し直します。
phys-paris-1# geopg validate protectiongroupname
protectiongroupname

Sun StorageTek Availability Suite 保護グループの名前を指定します

保護グループ構成の状態を確認します。
phys-paris-1# geopg list protectiongroupname
protectiongroupname

Sun StorageTek Availability Suite 保護グループの名前を指定します