災害復旧管理の概要

この節では、災害復旧状況と、管理者が実施できる作業の例を示します。

X 社には、地理的に離れたクラスタが 2 つあります。1 つはパリの cluster-paris、もう 1 つはニューヨークの cluster-newyork です。これらのクラスタは、パートナークラスタとして構成されています。パリのクラスタは主クラスタ、ニューヨークのクラスタは二次クラスタとして構成されています。

暴風雨の影響による停電のため、cluster-paris クラスタが一時的に停止しました。管理者に関係するものとして、次のイベントが発生します。

1. cluster-paris と cluster-newyork の間でハートビート通信が停止しました。パートナーシップの作成中に、ハートビート通知を行うように構成したため、管理者に電子メールでハートビート喪失通知が送信されます。

   パートナーシップやハートビート通知の構成方法については、「パートナーシップの作成と変更」を参照してください。

2. 管理者は、電子メール通知を受け取り、社内の処置規定に従って検証を行いました。この結果、二次クラスタによるテイクオーバーが必要な状況が発生したため、切り離しが行われたことがわかりました。テイクオーバーにはコストがかかります。このため X 社は、主クラスタを 2 時間以内に修復できない場合にしか、テイクオーバーを許可しません。

   Sun StorEdge Availability Suite 3.2.1 を使用しているシステム上で発生した切り離しの検証方法については、「Sun StorEdge Availability Suite 3.2.1 データ複製を使用するシステム上でのクラスタの障害の検出」を参照してください。

   Hitachi TrueCopy を使用しているシステム上で発生した切り離しの検証方法については、「Hitachi TrueCopy データ複製を使用するシステムでのクラスタ障害の検出」を参照してください。

3. cluster-paris クラスタがオンラインに戻るまで、少なくともあと 1 日はかかります。そこで管理者は、ニューヨークのノード上で geopg takeover コマンドを実行し、ニューヨークに置かれた二次クラスタ cluster-newyork 上の保護グループを有効にします。

   Sun StorEdge Availability Suite 3.2.1 のデータ複製を使用しているシステム上でテイクオーバーを実行する方法については、「Sun StorEdge Availability Suite 3.2.1 を使用するシステム上での強制テイクオーバー」を参照してください。Hitachi TrueCopy データ複製を使用しているシステム上でテイクオーバーを行う方法については、「Hitachi TrueCopy データ複製を使用するシステムでのテイクオーバーの強制実行」を参照してください。

4. テイクオーバーが行われると、二次クラスタ cluster-newyork が新たに主クラスタになります。停止したパリのクラスタは、まだ主クラスタとして構成されています。このため、cluster-paris は、再起動すると同時にそれ自体がそれまでダウンしていて、パートナークラスタから切り離されていたことを認識します。その後、cluster-paris はエラー状態になります。この状態の修復には、管理アクションが必要です。このクラスタでは、データの回復と再同期も必要になる可能性があります。

   Sun StorEdge Availability Suite 3.2.1 データ複製を使用しているシステム上でテイクオーバーを実行したあとのデータの回復方法については、「テイクオーバー後の Sun StorEdge Availability Suite 3.2.1 データの回復」を参照してください。Hitachi TrueCopy データ複製を使用しているシステム上でテイクオーバーを行う方法については、「Hitachi TrueCopy 複製を使用するシステムでの元の主クラスタへのサービスのフェイルバック」を参照してください。