NAKIVO による災害復旧：計画、導入、およびテスト

バックアップと災害復旧は、あらゆる組織や業界におけるデータ保護戦略の基盤となっています。 災害復旧 これは、本番サイトが利用不能になった際に、セカンダリサイト(災害復旧サイトと呼ばれる)で仮想マシンおよびそこで実行されているサービスを復旧させるプロセスです。必要なソフトウェアを備えた冗長化されたサーバー、コンピュータ、ネットワーク機器を収容しており、これら セカンダリDRサイトには、さまざまな種類があります 冗長性のレベルによって異なります。

NAKIVO Backup & Replication Site Recovery機能が含まれており、プライマリサイトがダウンした際にワンクリックで開始できる高度な復旧シーケンス(サイト全体のフェイルオーバーを含む)を作成できます。このブログ記事では、IT災害復旧計画、テスト、NAKIVOの統合ソリューションを用いた災害復旧の実行など、災害復旧(DR)戦略の主要な構成要素について解説しています。

NAKIVOで可用性を確保

仮想インフラストラクチャにおけるサービス可用性の厳しい要件を満たします。堅牢な災害復旧(DR)のオーケストレーションおよび自動化機能により、稼働時間の目標を達成します。

ソリューションをご覧ください

ステップ1. 災害復旧計画の策定

効果的な災害復旧のための不可欠なステップとして、計画策定においては、組織の復旧ニーズを評価するとともに、災害復旧ワークフローにどのような構成要素、手順、およびプロセス盛り込むべきかを包括的に把握することが必要です。

災害復旧の計画:ベストプラクティス

1. 事業影響度分析を実施する

A ビジネス影響分析(BIA) これは、重大なインシデントや自然災害が事業運営に及ぼす潜在的な悪影響を評価するために使用されます。この分析では、さまざまなVMの優先順位、復旧順序、および障害が事業運営に重大な影響を及ぼすまでの許容時間を決定します。例えば、あるVMの障害は遅延や不便をもたらすだけである一方、別のVMの障害は事業に不可欠な業務の完全な停止につながる可能性があります。

2. 関連するリスクを評価する

DR計画を策定する前に、組織の業務および事業継続に対するリスクに関する関連データを収集してください。地域によっては、竜巻よりも長期の停電やウイルス攻撃の方が発生しやすい場合もありますが、自然災害が頻繁に発生する地域もあります。 リスク評価を行うことで、特定の脅威に対する適切な保護レベルを判断し、リスクを最小限に抑え、影響を軽減するための対策を講じることができます。リスクを完全に排除することはできませんが、直面する可能性の高い災害シナリオに対して、より万全な備えができるようになります。

3. 災害復旧に関する文書を作成する

リスクとそのビジネスへの潜在的な影響を特定できれば、災害復旧プロセスの策定において、どこに注力すべきかをより深く理解できるようになります。 文書の復旧手順、すべての重要な手順と災害復旧(DR)対策を詳細に記述し、環境の変化を反映させるために文書を定期的に更新する。文書には以下を含める必要がある:

• Disaster recovery scope. インフラストラクチャを構成する各ハードウェアおよびソフトウェアコンポーネントの重要度を評価し、業務に不可欠な運用に関わるものを災害復旧計画に盛り込んでください。重要な情報を格納している仮想マシン(VM)、ITシステム、およびサービスの継続的な提供を確保するためにその稼働が不可欠なアプリケーションは、復旧の最優先対象とすべきです。
• VM recovery order. 特定のVMは、別のVMに格納されているソフトウェアや情報に依存している場合があり、そのため、単独で動作させたり、任意の順序で起動したりすることはできません。復旧作業を円滑に進め、DRサイトでのソフトウェア間の競合リスクを排除するために、復旧順序を指定する必要があります。たとえば、Active Directory認証を使用するファイルサーバーを搭載したVMを起動するには、Active Directoryドメインコントローラーを実行しているVMが起動して稼働している必要があります。

もう1つの例として、Webサービスが挙げられます。Webサービスは、多くの場合、複数の異なるVMにインストールされたソフトウェアに依存しています。次のような処理の流れを実装する必要があるかもしれません:

1. データベースサーバーが動作するVMを最初に起動する必要があります。
2. これで、アプリケーションサーバーが搭載されたVMを起動できます。
3. そうして初めて、Webサーバーが動作するVMを起動できます。

• RTO and RPO in disaster recovery. 設定する 目標復旧時間 (RTO) および 復旧ポイント目標 (RPO)は、災害復旧計画における優先度の異なるVMごとに設定されます。たとえば、財務システム用のVMは、アーカイブ文書の保存に使用されるVMよりも、復旧目標が短くなる場合があります。
• Dependencies. スタッフとITコンポーネント間の依存関係チェーンを特定する際は、スタッフと連携し、彼らの状況を考慮に入れて、復旧の失敗につながるような脆弱なリンクが生じないようにしてください。例えば、他の部門の従業員が業務を行う上でその財務業務に依存している場合、経理部門が使用する仮想マシン(VM)を最優先で復旧させる必要があるかもしれません。
• Staff. 災害復旧(DR)プロセスに関与するチームメンバーに、役割と責任を割り当ててください。DRサイトにて業務を行う場合は、必要な機器、オフィス家具、ハードウェアがすべて整ったワークステーションが設置されていることを確認し、業務の中断を最小限に抑えて作業を継続できるようにしてください。災害発生時に従業員がリモートで業務を行える場合は、事前にVPNアクセスを設定し、VPNアカウントを付与しておいてください。
• Hardware requirements. 災害復旧計画の成否は、DRサイトに設置されたハードウェアの性能と機能に大きく左右されます。以下のいくつかの要因を考慮する必要があります:
• サーバーには、移行されたワークロードを維持するのに十分なCPU、メモリ、およびディスク容量が備わっている必要があります。CPUのパフォーマンスが低かったり、メモリが不足していたりすると、VMの速度に影響を及ぼす可能性があり、ディスクの速度が不十分だと、VMのパフォーマンスが低下します。
• ネットワークは、復旧したVMが互いに通信できるよう、十分な帯域幅を確保しなければなりません。 共有ストレージ、および必要に応じてユーザーとも連携して。

ステップ2. 災害復旧の準備

ドキュメントが揃ったら、災害復旧サイトの準備を行い、重要なワークロードのレプリケーションをそのサイトに向けて設定することで、災害復旧の準備を進めることができます。レプリケーションは、以下の場合に必要です。 VMのフェイルオーバー プライマリインフラストラクチャがダウンした際、レプリカVMへ切り替える。

VMレプリケーションとは何ですか？

仮想マシンのレプリケーションとは、ソースVMの完全な複製("VMレプリカ"と呼ばれる)を別のホスト(ターゲットホスト)上に作成するプロセスです。VMレプリカは通常のVMであり、必要になるまでは電源オフの状態のままですが、必要になった時点で、そのホスト上でほぼ瞬時に起動して稼働を開始することができます。

作成方法を確認し、 VMwareのレプリケーションジョブを設定する in NAKIVO Backup & Replication 詳細については。

ビジネスの継続性と高可用性を維持する目的で、ソース(本番)VMからDRサイトにあるVMレプリカへワークロードを切り替えるプロセスは、フェイルオーバーと呼ばれます。

VMレプリケーションのベストプラクティス

次のようなものがあります 複製に関するさまざまなベストプラクティス プロセスの信頼性と有効性をさらに高めるためです。ここでは、次の2つの重要なポイントに焦点を当てます:

• Perform VM replication at the host level rather than the guest level. 仮想化レイヤーとは、物理ハードウェアとVM上で動作するゲストOSとの間にある中間層のことです。仮想化レベルで行われるレプリケーションは"ホストレベル"と呼ばれ、ゲストレベルのレプリケーションよりも効率的です。
• Use application-aware replication to avoid data loss. これらのアプリケーションが実行中の状態で、特別な操作を行わずにレプリケーションに必要なVMのスナップショットを取得すると、予期せぬ停電やシャットダウンと同様の影響が生じ、データが失われる可能性があります。

アプリケーション対応の手法では、アプリケーションが凍結(クワイエスド状態)され、メモリがフラッシュされるため、スナップショットが取得されるまではディスクへの書き込みが行えません。一貫性のあるスナップショットが取得されると、VMのレプリカを作成できます。このようなVMレプリカは、その中のアプリケーションが正常に動作した状態で、正常に復元することができます。
NAKIVO Backup & Replication VMware VM、Hyper-V VM、および EC2 インスタンスに対して、アプリケーションを意識したホストレベルのレプリケーションをサポートしており、Microsoft SQL Server、Exchange Server、および Active Directory ドメイン コントローラー向けの特別な機能を備えています。

ステップ3. 災害復旧ワークフローの作成

DRワークフローを作成するには、次のような専用の災害復旧ソリューションが必要です。 NAKIVO Backup & Replication, これには、DR(災害復旧)のプロセスを調整・自動化する組み込みのSite Recovery機能が備わっています。

• 災害復旧ワークフローとは何ですか？
• DRワークフローで実行可能なアクション
• 災害復旧ワークフローの作成方法
• NAKIVOのSite Recovery設定手順解説

1. アクション
2. ネットワーク
3. Re-IP
4. 試験スケジュール
5. オプション

災害復旧ワークフローとは何ですか？

DRワークフローとは、ワークロードをレプリカへ安全かつ迅速にフェイルオーバーさせるための災害復旧プロセスの一環として実行される一連のアクションのことです。このワークフローでは、ソースVM、ターゲットVM、満たすべき条件などに関連するアクションを用いて、フェイルオーバーのプロセスを整理します。災害復旧手順の中には、他のアクションの実行結果に依存するものもあるため、アクションの実行順序を定義する必要があります。

利用可能なサイト復旧アクション

Site Recovery 機能を使用すると、単一のワークフロー内でアクションと条件を組み合わせることで、複雑な DR シーケンスを作成できます。各アクションは、テストモードのみ、本番モードのみ、または両方のモード(これがデフォルト設定です)で実行できます。 NAKIVO Backup & Replication.

シーケンスには、以下のアクションのいずれか、またはすべてを含めることができます:

• Failover – レプリカの VMware VM、Hyper-V VM、または EC2 インスタンスへのフェイルオーバーを開始します。
• Failback – VMレプリカのワークロードをソースVMに戻します。フェイルオーバー時点以降にVMレプリカで行われた変更は、フェイルバック操作の実行時にソースVMに書き込まれます。これによりVM間の同期が取られ、ソースVMは再び実際の運用状態に戻ります。
• Start – VMware VM、Hyper-V VM、または EC2 インスタンスを起動します。
• Stop – 実行中の VMware VM、Hyper-V VM、EC2 インスタンスを停止します。
• Run job – バックアップジョブ、レプリケーションジョブ、サイトリカバリジョブ、バックアップコピージョブ、またはFlash VMブートジョブを実行します。
• Stop jobs – ジョブを停止します(前の項目に挙げられたジョブのいずれか)。
• Run script – 以下のいずれかの対象(Director がインストールされているサーバー、リモートの Windows サーバー、リモートの Linux サーバー、VMware 仮想マシン、Hyper-V 仮想マシン、または EC2 インスタンス)でスクリプトを実行します。
• Attach repository – が使用するバックアップリポジトリを接続します NAKIVO Backup & Replication バックアップを保存するために。
• Detach repository – バックアップリポジトリを切り離します。
• Send email – 作成したメッセージを、指定された1人または複数の受信者にメールとして送信します。
• Wait – 指定された時間待ってから、次のアクションに進みます。
• Check condition – 入力内容(リソース名の全部または一部)に基づいて、以下の条件のいずれかをチェックします:
• そのリソースは存在します
• リソースは実行中です
• IPアドレス/ホスト名に接続可能

Site Recovery ワークフローの構築方法

では、[サイトリカバリー] ジョブを作成する方法の例を見てみましょう。 NAKIVO Backup & Replication.

当社の体制

ここでは、VMware vSphere 仮想マシンを稼働させるプライマリ(本番)サイトと、遠隔地にあるDRサイトという構成について検討します:

• DC-VM これは、Active Directory ドメイン コントローラーを実行している Windows ベースの仮想マシンです。
• FS-VM これは、ファイルサーバーが稼働しているWindowsベースの仮想マシンです(ファイル共有にはSMBプロトコルが使用されています)。ユーザー認証にはActive Directoryが使用されています。Oracleデータベースのダンプファイルは、このファイルサーバーに保存されています。
• Ora-DB Oracleデータベースが実行されているVMです。

災害復旧サイトには、以下の仮想マシンが含まれています:

• DC-VM-レプリカ そして FS-VM-レプリカ これらは本番用VMのレプリカです。フェイルオーバーのターゲットとして使用できます。
• DB-VM は、Linuxをベースとした仮想マシンであり、 Oracle Database ソフトウェアがインストールされています ただし、データベースは含まれていません。

データベースは、以下の方法でバックアップされます。 NAKIVO Backup & Replication データベースレベルで、 FS-VM 生産現場で(これ Oracleデータベースのバックアップ (アプリケーションと一貫性がある)。 FS-VM そして DC-VM NAKIVOソリューションにより、ホストレベルでDRサイトへレプリケーションされます。

VMの復旧手順

生産サイトが停止する事態が発生した際には、DRサイトにおいて、以下の手順に従ってコンポーネントを復旧させる必要があります。

1. のフェイルオーバー DC-VM ～へ DC-VM-レプリカ。

2. かつて DC-VM-レプリカ が稼働中、のフェイルオーバー FS-VM ～へ FS-VM-レプリカ. この順序で操作しなければならないのは、 FS-VM ～に依存している DC-VM ファイルサーバーでのユーザー認証のために。
3. これら2台のVMが起動したら、 DB-VM ダンプが保存されているファイルサーバー上の共有ディレクトリにアクセスできます。さて、 DB-VM を開始できます。

4. かつて DB-VM が実行されている場合は、ファイルサーバーにあるダンプからデータベースを復元できるスクリプトを実行してください。上の図の青い矢印は、依存関係を示しています。

フェイルオーバー処理が実行された後、電源が投入されたVMレプリカ上でサービスが起動し、次のレプリカへのフェイルオーバーやアプリケーション・データベースの復旧が行われるまでには、ある程度の時間がかかる場合があることに注意してください。この待機時間は、DR手順の一部として考慮する必要があります。

この順序でVMのフェイルオーバーを行うには、 NAKIVO Backup & Replication 以下のロジックに基づき:

• Action 1: DC-VMのフェイルオーバー. この処理が完了するまで待ってから、次の手順に進んでください。この処理が失敗した場合は、ジョブを停止してください。
• Action 2. ちょっと待って 3分間。
• Action 3. 状態を確認する の DC-VM-レプリカ. リソースが実行中かどうかを確認します。リソースが実行中の場合は、Site Recovery ジョブの次のアクションに進みます。実行中でない場合は、ジョブを停止し、失敗として処理します。
• Action 4. FS-VMのフェイルオーバー. 次の処理に進む前に、この処理が完了するまで待ちます。この処理が失敗した場合は、ジョブを停止してください。
• Action 5. ちょっと待って 3分間。
• Action 6. 状態を確認する の FS-VM-レプリカ. リソースが実行中の場合は、Site Recovery ジョブの次のアクションに進みます。実行中でない場合は、ジョブを停止し、失敗として処理します。
• Action 7. DB-VM を起動する. 次の処理に進む前に、この処理が完了するまで待機してください。この処理が失敗した場合は、ジョブを停止してください。
• Action 8. ちょっと待って 5分間。
• Action 9. スクリプトを実行する. 対象タイプ:VMware VM。対象VM:DB-VM。スクリプトのパス:/home/oracle/restore_db.sh(このステップを追加する際は、スクリプトを実行するための十分な権限を持つアカウントのユーザー名とパスワードを入力する必要があります)。

NAKIVOのSite Recovery 操作ガイド

上記で説明した計画に基づいて、新しい Site Recovery ジョブを作成しましょう。 Jobs あなたの NAKIVO Backup & Replication 例えば、[クリック] Create > Site recovery job.

1. アクション

その 新しいサイト復旧ジョブウィザード が起動します。左側のパネルには、ジョブに追加できるアクションが表示されています。アクションをクリックするだけで、シーケンスに追加できます。なお、1つのシーケンス内で異なるプラットフォーム向けのアクションを混在させることはできません(ここではVMware VM用のジョブを作成しています)。

アクション 1. DC-VM のフェイルオーバー

1. 左側のペインで、[ ] をクリックします。 Failover VMware VMs.

2. 左側のペインで、既存のレプリケーションジョブからVMレプリカを選択します。このワークフローでは、次の対象へのフェイルオーバーを行います。 DC-VM-レプリカ これが最初の操作です。右側のペインで、リカバリポイントを選択できます。デフォルトでは、最新のリカバリポイントが使用されます。

クリック Next 続きを読む。

3. 災害復旧のために フェイルオーバー オプションでは、選択を解除できます Power off source VMs – このオプションを使用すると、ソースVMとレプリカが同じネットワークを使用している場合に、IPアドレスの競合を防ぐことができます。

上記の論理に基づき、以下の選択肢を選定します:

• このアクションを実行する場所: Run this action in both testing and production mode
• 待機行動: Wait for this action to complete
• エラー処理: Stop and fail the job if this action fails

クリック Save 作成したアクションを保存するには。

手順 2. 3分間待つ

A 待って このケースでは、このアクションが有用です。なぜなら、ワークフロー内の次のフェイルオーバーアクション(～へのフェイルオーバー)が FS-VM-レプリカ) には、 DC-VM-レプリカ Active Directory ドメイン サービスがすでに稼働している状態である。

1. の左ペインで アクション 画面上で、クリックして Wait.

2. 待機時間を選択してください(ここでは 3分).

最初のアクションの場合と同じようにアクションのオプションを選択し、[クリック] をクリックします。 Save.

新しいアクションは、前のアクションの後に、リストの一番下に追加されます。アクションの順序を変更したり、編集したり、削除したりすることができます。アクションの上にマウスを合わせると、オプションが表示されます。

アクション 3. の状態を確認する DC-VM-レプリカ

1. の左ペインで アクション 画面上で、[クリック] Check condition 最初のアクションでフェイルオーバーされたVMが稼働しているかどうかを確認するため。

2. このアクションを次のように設定してください:

• 条件タイプを選択してください: Resource is running。その他の選択肢は次のとおりです。 リソースが存在します または IPアドレス／ホスト名 にアクセス可能です。
• リソースの種類を選択してください: VMware VM.
• 認証方法を選択してください: Name (もう一つの選択肢は ID) を使用して、対象のVMを特定します。VM名の任意の部分を使用できます。ここでは正確な名前がわかっているため、 Equals 関数。
• 検索文字列を指定してください: DC-VM-replica.

これで、VMwareの仮想マシン""の名前が DC-VM-レプリカ 実行中です。クリックしてください Save 続行するには。

アクション 4. FS-VM のフェイルオーバー

1. "～と同様に" アクション1、をクリック Failover VMware VMs.

2. 弊社では、以下の条件に基づき選定いたします。 FS-VM-レプリカ この場合は、ここをクリックしてください。 Next, その後、フェイルオーバーのアクションについて、 アクション1 そして、クリックして Save.

手順 5. 3分間待つ

クリック Wait そして、このアクションを、先ほど行ったのと同じように設定し、 アクション 2. 指定された時間は、やはり 3分 私たちのケースでは。

アクション 6. の状態を確認する FS-VM-レプリカ

クリック Check condition VMwareの仮想マシンが FS-VM-レプリカ が実行中です。詳しくは、 アクション 2 そして、VM名を除いて、同じオプションを選択します。

アクション7. 開始 DB-VM

1. クリック Start VMware VMs の左ペインで アクション 画面。

2. 選択 DB-VM. 以下のことが確認でき次第、このVMを起動できます。 FS-VM-レプリカ が実行中です。ページの下部で、これまでの操作と同じアクションオプションを選択してください。その後、をクリックします。 Save.

手順 8. 5分間待つ

5分間お待ちください。クリックしてください Wait そして、このアクションを、次と同様に設定します。 アクション 2. これで、Oracle サービスを起動するには十分な時間があるはずです。 DB-VM.

アクション 9. スクリプトを実行する

1. その アクション 画面をクリック Run script. 念のため、このスクリプトは、に保存されているダンプから、データベースレベルでOracleデータベースを復元することを目的としていることを思い出してください。 FS-VM-レプリカ.

2. スクリプトのオプションを指定します。今回の場合は:

• 対象タイプ: VMware 仮想マシン
• 対象VM: DB-VM
• スクリプトのパス: /home/oracle/restore.db.sh
• ユーザー名: オラクル
• パスワード:(パスワード)

スクリプトのパス、ユーザー名、パスワードは環境によって異なります。スクリプトファイルが実行可能であること、およびユーザーがスクリプトを実行するための十分な権限を持っていることを必ず確認してください。この例では、アクションのオプションは通常通り設定されています。

クリック Save 準備ができたら、続けてください。

3. これで、設定済みのすべてのアクションを確認できます。""をクリックしてください。 Next このボタンをクリックして、災害復旧計画に基づいてSite Recoveryジョブの設定を続行してください。

2. ネットワーク

本番サイトとDRサイトのVMが 異なるネットワークに接続されている, 選択 Enable network mapping. クリック Create new mapping、ポップアップウィンドウで、ソースネットワーク、宛先ネットワーク、およびSite Recoveryジョブのテストに使用するネットワークを選択します。
をクリックします。 Save ネットワークマッピングルールを保存するには、[] をクリックします。 Next.

注記: 他のレプリケーション、フェイルオーバー、またはSite Recoveryジョブでマッピングルールを設定済みの場合は、それらのルールを使用することもできます。

3. Re-IP

送信元サイトと受信先サイトでVM接続に使用されるネットワークのアドレスが異なる場合は、以下を選択してRe-IPを有効にする必要があります。 Enable Re-IP.

1. をクリックして、新しいRe-IPルールを作成します Create new rule. ソース設定とターゲット設定を指定し、[] をクリックします。 Save.

2. クリック Select VMs そして、Re-IP を適用する仮想マシンを選択します。仮想マシンのゲスト OS でネットワーク設定を変更できる十分な権限を持つユーザーの認証情報を指定する必要があります。

4. 試験スケジュール

テストモードで Site Recovery ジョブを実行し、災害復旧テストを行うことを目的としたスケジュールを別途作成できます。これにより、必要な時間枠内でジョブが正常に実行できるかどうかをテストできます。完了したら、[次へ] をクリックします。
Site Recovery ジョブのテストについては、手順 6 で詳しく説明します。

5. オプション

ジョブ名と復旧時間目標を入力してください。[クリック] Finish 設定が完了したら。

ステップ4. 環境の再保護

VMのフェイルオーバーが完了し、ワークロードがDRサイトに移行されると、元の本番用VMはオフライン状態となり、DRサイトにあるレプリカだけが機能するコピーとなります。この状態で、電源が入ったVMレプリカに障害が発生した場合、データやワークロードを迅速に復元する手段はなくなります。

DRサイトで実行中のVMを保護するためには、これらのVMを別の安全な場所にレプリケートする必要があります。そうすることで、DRサイトで実行中のVMに障害が発生した場合でも、新しいVMレプリカへ迅速にフェイルオーバーできます。

Site Recovery機能を使用すると、VMのフェイルオーバーが完了次第、自動レプリケーションを設定できます。ここでは、フェイルオーバー後にSite Recoveryジョブを使用してVMを再保護する方法の手順例を紹介します。

1. その Jobs ページで、先ほど作成した Site Recovery ジョブの名前を右クリックします。[クリック] Edit コンテキストメニュー内で。

2. 先ほどSite Recoveryジョブに追加したフェイルオーバーアクションを確認できます。それを見つけてクリックしてください。 Run jobs Site Recovery の左パネルにあるアクション一覧から Actions 画面。

3. ジョブ一覧からレプリケーション・ジョブを選択します。通常どおりアクションのオプションを選択し、[] をクリックします。 Save.

4. [追加] ちょっと待って フェイルオーバー操作とレプリケーションジョブの間に実行されるアクションです。これにより、VMレプリカが起動し、オペレーティングシステムを読み込むための時間が確保されます(電源がオフのVMはレプリケートできません)。左ペインの"アクション"リストで、[ ] をクリックします。 Wait.

5. 待機時間を選択してください。5分あれば十分でしょう。アクションのオプションを選択して、クリックしてください。 Save.

6. アクションを追加すると、そのアクションはアクションリストの最後に追加されます。[クリック] Move up そして、 ちょっと待って 4番目の位置から3番目の位置へのアクション――これはレプリケーションの前に実行される必要があります。

これで、アクションが必要な順序に並べ替えられました。

7. これで、Site Recoveryジョブを使用して、VMのフェイルオーバーや、フェイルオーバーに使用されたVMレプリカの自動再保護を実行する準備が整いました。ホームページでSite Recoveryジョブの名前を右クリックし、[ Run job コンテキストメニュー内で。

ステップ 5. フェイルバック

フェイルバックとは、DRサイトにある仮想マシンを、その最新の状態のまま、元の本番サイトまたは新しい本番サイトへ復元するプロセスです。フェイルバックが必要な理由を理解するために、まずフェイルオーバーの仕組みを振り返ってみましょう:

1. 災害が発生した場合(または発生が予測される場合)、VMのレプリカへのフェイルオーバーが実行されます。

2. VMへの変更(たとえば、顧客がオンラインで購入を行う際にデータベースに追加されるトランザクションなど)は、VMレプリカの仮想ディスクに書き込まれます。一部のブロックは書き込まれ、他のブロックは消去されます。ソースVMの仮想ディスクには、これらのトランザクションは含まれていません。

3. インシデントが解決され、本番サイトが再び稼働可能になったら、ワークロードを本番サイトに戻す必要があります。VMレプリカの更新されたデータを、元のVMに転送する必要があります。また、フェイルバックを使用して、逆レプリケーションによりVMを再同期させる必要があります。

でのフェイルバックの設定 NAKIVO Backup & Replication

フェイルバックは、本番モードまたはテストモード(テスト終了後、フェイルバック操作によって仮想環境に加えられたすべての変更がフェイルバック前の状態に戻される)のいずれかで実行できます。

それぞれのケースがどのように機能するのか、詳しく見ていきましょう。

フェイルバックの準備

まず、フェイルオーバー操作を含む Site Recovery ジョブを作成する必要があります。この手順については、先ほど詳しく説明しました。

• フェイルオーバーを実行するには、レプリケーションジョブとVMレプリカが必要です。
• フェイルバックを実行するには、Site Recovery ジョブにフェイルオーバーアクションを含める必要があります。
• VMレプリカはフェイルオーバー状態である必要があります。したがって、フェイルオーバーを実行した後にのみ、フェイルバックを実行できます。

フェイルバックの実行

failback を実行する方法について、例を挙げて説明しましょう。 NAKIVO Backup & Replication.

1. フェイルオーバーが Site Recovery ジョブの一環として実行されていることを確認してください(このジョブはすでに作成されているはずです)。

2. 新しい Site Recovery ジョブを作成します。このジョブにフェイルバックのアクションを組み込むことができます。[ Jobs ページで、[クリック] Create > Site recovery job.

その 新しいサイト復旧ジョブウィザード がリリースされました。

1. Actions.

1. 左側のペインで、[ ] をクリックします。 Failback VMware VMs (その他の環境では、以下を使用してください) Failback Hyper-V VMs または Failback EC2 Instances).

2. フェイルオーバー操作を適用するVMレプリカを選択します。[クリック] Next.

3. フェイルバック先を選択します。これは、元の本番サイトでも、新しい場所でも構いません。"クリック" Next.

4. ジョブオプションを選択してください。選択してください Power off replica VMs 必要に応じて。クリック Save 準備が整いましたら、次へ進んでください。

5. フェイルバックアクションを追加すると、Site Recovery ジョブは以下のスクリーンショットのような表示になります。[クリック] Next.

2. Networks. このジョブでネットワークマッピングを有効にする必要がある場合は、このオプションを選択してください。[クリック] Next.

3. Re-IP. このジョブでRe-IPを有効にする必要がある場合は、このオプションを選択してください。[クリック] Next.

4. Test Schedule. スケジュール設定を行い、次にクリックしてください Next.

5. Options. Site Recovery ジョブのオプションを定義し、ジョブ名を入力します。VM に必要な RTO を設定したり、フェイルバックレポートの受信先メールアドレスを指定したりできます。[クリック] Finish フェイルバック機能を備えたこの新しい Site Recovery ジョブの作成を完了します。

これで、この Site Recovery ジョブを実行して、VM のフェイルバックを行うことができます。Site Recovery ジョブの名前を右クリックし、[ Run job, を選択して Test site recovery job または Run site recovery job.

手順 6. 災害復旧テストの実施

災害復旧テストを実施することで、災害発生時に復旧の準備が整っていること、および選択されたすべてのコンポーネントが設定された時間枠内に正常に復旧できることを確認できます。

主な理由は2つあります。 災害復旧テストが必要な理由:

• To make sure that everything can be recovered successfully. 災害復旧計画をテストし、問題点がいくつか見つかった場合、実際の危機的状況で深刻な問題を引き起こす前に、それらを修正することができます。
• To make sure that RTO values can be met. 災害復旧テストを実施することで、ワークロードが所定のRTO内に復旧できるかどうかを確認できます。サイト復旧テストは、必要に応じて手動で実行することも、スケジュールに基づいて自動的に実行することも可能であり、これによりプロセスがスムーズになり、時間を節約できます。

テスト環境と本番環境のフェイルオーバーの違い

フェイルオーバーの実行方法は、Site Recovery ジョブがテストモードで実行されるか、本番モードで実行されるかによって異なります。各モードごとの手順の詳細は、以下の表に示されています。

ご覧のとおり、2番目と3番目の点は、本番環境とテスト環境のワークフローで異なります。テストモードでは、ソースVMが稼働している状態で、そのVMからのレプリケーションを実行できます。一方、災害が発生した場合、ほとんどの場合、ソースVMは動作しなくなるため、レプリケーションを実行できなくなります。VM接続用のネットワークは、Site Recoveryジョブを設定する際、本番モードとテストモードの"ネットワークマッピング"オプションで個別に定義することができます。

フェイルオーバーテストのクリーンアップは、テストモードで Site Recovery ジョブを実行した後に実行されます。VM レプリカの電源がオフになり、スナップショットを介してフェイルオーバー前の状態に戻されます(フェイルオーバー操作を実行する前に、VM レプリカのスナップショットが取得されます)。その後、レプリカはフェイルオーバー状態から通常状態に切り替えられ、ソースオブジェクトからレプリカへのレプリケーションが再度有効になります。

NAKIVOのSite Recoveryにおける災害復旧テスト機能

NAKIVOのSite Recoveryにおけるテスト機能の主なポイントについて、簡単に確認しておきましょう。
1. Checking the actions included in testing
Site Recovery ジョブ内のアクションのロジックを確認してください。アクションが適切な順序で配置されているかを確認し、無限ループになっていないことを確認してください。ジョブが実行されていないときは、Site Recovery ジョブのオプションを編集できます。必要に応じて、アクションの順序を変更したり、アクションを追加・削除したり、アクションのオプションを編集したりできます。
2. Checking networking
ネットワークが正常に動作していることを確認してください。本番サイトと災害復旧(DR)サイトの間でVPN接続を使用することは可能ですが、通常状態ではこの接続を定期的に切断することはできません。また、DRサイトのネットワークも中断なく動作している必要があります。フェイルオーバーおよびフェイルバックの設定に使用した"ネットワークマッピング"および"Re-IP"の設定を確認してください。VMが誤ったネットワークに設定されている場合、ネットワーク接続が確立されない可能性があります。IP設定についても同様です。
3. Setting the test schedule
Site Recovery ジョブのテストは、Site Recovery ジョブのスケジュール設定オプションでスケジュールできます。インスタンスの Web インターフェースを開き、 NAKIVO Backup & Replication. 左側のペインで、ジョブの名前を右クリックし、[ Edit コンテキストメニュー内で。

NAKIVOのサイトリカバリーのメリット

• Comprehensive DR orchestration and automation. Site Recovery を使用すると、高度な自動化機能を備えた災害復旧計画を実施できます。VM 間の依存関係を考慮して VM の復旧順序を定義できるため、災害発生時に可能な限り効率的な復旧が可能になります。
• Flexibility to accommodate the needs of various businesses. 必要に応じて、複数のSite Recoveryジョブを作成できます。Site Recoveryジョブに組み込むことができる一連のアクションを活用することで、さまざまな状況に合わせてカスタマイズされた、独自の復旧ワークフローを作成することが可能です。
• Built into the data protection solution. Site Recovery は、 特集 に含まれる NAKIVO Backup & Replication また、本製品のその他の包括的な機能セットとともに利用可能であり、Site Recovery用に別途ライセンスを購入する必要はありません。このソリューションにより、すべてのデータ保護および災害復旧業務を単一の管理画面から一元的に管理できます。
• Significant savings compared to other DR solutions. NAKIVO Backup & Replication…は、組み込みのSite Recoveryツールを備えた、コストパフォーマンスに優れたソリューションです。この製品は、特に災害復旧市場の競合他社と比較しても、手頃な価格を維持しつつ、便利な新機能を次々と追加することで、ユーザーから引き続き高い評価を得ています。

試してみてください NAKIVO Backup & Replication

無料トライアルを利用して、本ソリューションのデータ保護機能をすべてお試しください。15日間無料。機能や容量に制限はありません。クレジットカードも不要です。

無料でお試しください