Sun Cluster Geographic Edition のシステム管理

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

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

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

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

主クラスタの障害の検出

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

ある保護グループの全体的な状態が Unknown 状態に変わると、次のアクションが発生します。

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

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

ログについての詳細は、「Sun Cluster Geographic Edition のログメッセージの表示」を参照してください。

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

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

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

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

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

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

元の主クラスタ cluster-paris 上で、アプリケーションサービスがオフラインになります。

どのクラスタが cluster-paris であるかについては、図 2–1 を参照してください。
データ複製の役割が逆になり、今度は、新しい主クラスタ cluster-newyork から元の主クラスタ cluster-paris に対して継続して複製が行われます。
新しい主クラスタ cluster-newyork で、アプリケーションサービスがオンラインになります。

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

始める前に

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

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

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

手順

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

この手順を行うには、Geo Management RBAC 権利プロファイルがユーザーに割り当てられている必要があります。RBAC の詳細は、「Sun Cluster Geographic Edition ソフトウェアと RBAC」を参照してください。

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

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

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

-m new-primary-cluster

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

protection-group-name

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

例 8–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 StorEdge Availability Suite 3.2.1 保護グループを検証する方法」の手順に従って、保護グループを再評価します。

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

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

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

元の主クラスタ cluster-paris にアクセスできる場合、保護グループは無効になっています。

どのクラスタが cluster-paris であるかについては、図 2–1 を参照してください。
元の主クラスタ cluster-paris のデータボリュームが、新しい主クラスタ cluster-newyork にテイクオーバーされます。

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

テイクオーバー前後に主クラスタと二次クラスタに考えられる状態についての詳細は、付録 C 「テイクオーバー後の状態」を参照してください。

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

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

始める前に

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

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

手順

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

この手順を行うには、Geo Management RBAC 権利プロファイルがユーザーに割り当てられている必要があります。RBAC の詳細は、「Sun Cluster Geographic Edition ソフトウェアと RBAC」を参照してください。

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

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

protection-group-name

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

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

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

phys-newyork-1 は二次クラスタの第 1 ノードです。どのノードが phys-newyork-1 であるかについては、「Sun Cluster Geographic Edition クラスタ構成の例」を参照してください。

phys-newyork-1# geopg takeover -f avspg

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

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

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

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

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

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

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

注意 –

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

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

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

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

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

どのクラスタが cluster-paris で、どのクラスタが cluster-newyork であるかについては、図 2–1 を参照してください。
フェイルバックテイクオーバー。フェイルバックテイクオーバーの場合、アプリケーションは元の主クラスタ上で再度オンラインに戻って、主クラスタ上の現在のデータを使用します。二次クラスタ上で更新が行われていたとしても、その内容は破棄されます。

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

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

始める前に

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

cluster-newyork の保護グループの役割は primary です。
cluster-paris の保護グループの役割は、テイクオーバー中にその保護グループに到達できるかどうかによって、primary または secondary のどちらかです。

手順

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

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

cluster-parisで、クラスタの各保護グループの構成を検証します。
# geopg validate protection-group-name
protection-group-name

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

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

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

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

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

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

protection-group-name

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

注 –
フェイルバックスイッチオーバーを行う際には、現在の二次クラスタ cluster-paris のデータを現在の主クラスタ cluster-newyork のデータと同期させる必要があるため、-n オプションを指定しないでください。

保護グループの役割が secondary であるため、現在の二次クラスタ cluster-paris のデータが現在の主クラスタ cluster-newyork のデータに同期します。

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

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

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

次に、複製リソースグループ AVS-protection-group-name-rep-rg 内のすべてのリソースの状態が OK であることを確認します。
phys-newyork-1# scstat -g

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

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

一方のクラスタで geoadm status を使用してスイッチオーバーが正常に完了したかを確認し、複製リソース、アプリケーションリソースグループ、およびアプリケーションリソースがオンライン状態であることを検証します。

さらに、保護グループの役割が現在 cluster-paris では primary、cluster-newyork では secondary であり、「Data replication」と「Resource groups」の状態が両方のクラスタで OK と示されることも確認する必要があります。
# geoadm status

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

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

注 –

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

始める前に

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

cluster-newyork の保護グループの役割は primary です。
cluster-paris の保護グループの役割は、テイクオーバー中にその保護グループに到達できるかどうかによって、primary または secondary のどちらかです。

手順

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

cluster-paris はその独自の構成を失い、cluster-newyork 構成をローカルに複製します。
1. cluster-paris で、パートナーシップを再同期させます。
  # geops update partnership-name
  partnership-name
  
  パートナーシップの名前を指定します
  
  注 –
  複数の保護グループにフェイルバックテイクオーバーを実行している場合でも、この手順は 1 度実行するだけで済みます。
  
  パートナーシップの同期についての詳細は、「パートナーシップの再同期」を参照してください。
2. cluster-paris で、各保護グループを再同期させます。
  
  保護グループが有効に設定されている場合は、geopg stop コマンドを使用してその保護グループを無効にします。保護グループを無効にする方法については、「Sun StorEdge Availability Suite 3.2.1 保護グループを無効にする方法」を参照してください。
  # geopg update protection-group-name
  protection-group-name
  
  保護グループの名前を指定します
  
  保護グループの同期については、「Sun StorEdge Availability Suite 3.2.1 保護グループを再同期させる方法」を参照してください。

cluster-parisで、クラスタの各保護グループの構成を検証します。
# geopg validate protection-group-name
protection-group-name

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

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

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

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

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

範囲を local に指定した場合、このコマンドはローカルクラスタだけを対象に実行されます。

-n

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

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

protection-group-name

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

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

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

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

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

protection-group-name

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

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

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

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

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

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

範囲を local に指定した場合、このコマンドはローカルクラスタだけを対象に実行されます。

-n

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

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

protection-group-name

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

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

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

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

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

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

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

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

注 –

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

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

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

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

手順

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

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

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

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

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

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

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