【技術ブログ：第七回】Zerto編～DR検証 影響ゼロの「定期DRテスト」 (Failover Test) ～

今回のテーマ

横河レンタ・リース株式会社　技術検証ブログへようこそ。

今回はZertoを使用した『影響ゼロの「定期DRテスト」 (Failover Test) 』　について解説します。

※本内容はDR対策に焦点を当てて『HPE Morpheus VM Essentials』環境での構成方法を説明します。

※本記事における「影響ゼロ」とは、テスト用ネットワークの分離およびRe-IPを適切に設定し、
　本番環境への影響を抑えて実施することを指します。

※本技術ブログでは可能な限り実機検証に基づいた内容をお届けします。

前回の記事もあわせてご覧ください。

【技術ブログ:第六回】Zerto編～DR環境構築 (VM Essentials) ～｜コラム｜横河レンタ・リース株式会社

本記事の目標と対象読者

本記事では、HPE Morpheus VM Essentials 環境において、ZertoのFailover Testを実施できるようになることを目標としています。

主な対象読者は、HPE Morpheus VM Essentials 管理者およびDR (Disaster Recovery) 担当者です

DRテストの重要性

DR対策は「レプリケーションを構成したら終わり」ではありません。

レプリケーションが正常に動作していても、実際の災害時にはOSが起動しない、ネットワーク設定が想定と異なる、アプリケーションが動作しないといった問題が発生する可能性があります。

つまり、「データがコピーされていること」と「業務を継続できること」は必ずしも同じではありません。

実際にDR環境でシステムを起動し、サービス継続性や復旧時間を検証して初めて、その仕組みが有効に機能することを確認できます。

ZertoのFailover Testは、本番環境に影響を与えることなくDRサイトでリカバリーの検証を実施できる機能です。

災害発生時のリハーサルとして活用することで、復旧手順の確認や潜在的な問題の洗い出しが可能となり、より確実なDR対策の実現につながります。

DRテストの検証準備

では、DRテストをするために以下の検証環境を準備します。

作成する仮想マシンは以下の条件で作成します。

• ZertoのDRテスト用に仮想マシンを2台用意します。

• WebサーバーがDBサーバーのデータベースを参照し情報を表示します。

• ホスト名とIPを/etc/hostsで管理し、移行後には/etc/hosts内のIP設定を変更するだけで参照情報 (データベース) を表示できるようにします。

仮想マシンの構成イメージ

Zertoでは、本番フェイルオーバー用とFailover Test用に異なるネットワークおよびIPアドレスを設定できます。テスト用ネットワークを本番ネットワークから適切に分離し、Re-IPを設定することで、本番環境への影響を抑えながらDRテストを実施できます。

今回の検証環境ではデータベースとしてMariaDBを使用し、それを表示するWebサーバーを構成します。テストDR発動時はテスト用のIPアドレスを使用します。

Re-IPについて

移行後の仮想マシンのIPアドレス設定はVPGの設定/編集画面からRe-IP機能で設定できます。

※Edit VPGのNICs項目

Webページの内容

データベース接続は以下のWebページで成否を判断できるようにします。

Zerto検証環境の構成イメージ

Zerto検証環境の構成イメージは上図の通りです。

VPG (保護グループ) には検証用で作成したDBサーバーとWebサーバーの仮想マシンを含めます。

その他環境情報については以下の通りです。

影響ゼロの「定期DRテスト」 (Failover Test)

影響ゼロの「定期DRテスト」 (Failover Test) 確認内容

いよいよ、DRのFailover Testを実施します。

本検証の確認観点として、以下の目標を決め想定通りの結果になるか確認を進めていきます。

Failover Testの実施

Failover Testのオペレーションです。

わずか数ステップでFailover Testを実施することが可能です。

Zertoの管理画面から「Failover Test」を選択し、対象となるVPGとチェックポイントを指定してテストを開始します。開始後はTasks画面で進捗を確認し、処理が「Waiting」状態になったこと、およびFailover Testの停止ボタンが表示されたことを確認します。

影響ゼロの「定期DRテスト」 (Failover Test) 結果

1. フェイルオーバーテスト発動時にエラーなくセカンダリサイトに仮想マシンが作成されること
   結果：DRサイト側で問題なくテスト用のインスタンスが作成されていることを確認できました。
   
   
   

2. テスト用のIPアドレスでセカンダリサイトに仮想マシンが作成されること (※デプロイ時間を計測)
   結果：Failover Test用のIPで設定されていることを確認 (VME Managerのインスタンス->ネットワーク タブ)
   VME Managerのインスタンス履歴を確認したところ、Failover Test用インスタンスのデプロイ処理は、各サーバーとも数秒で完了していました。一方、仮想マシンのOS起動まで含めると、利用可能になるまで数分程度かかりました。
   
   
   

3. 本番サイトの仮想マシンが停止しないこと、本番サイトのWebページは継続して表示されること
   結果：本番サイトの仮想マシンは稼働を続けており、Webページも表示されていることを確認しました
   
   
   

4. セカンダリサイト側の仮想マシンの設定変更でWebページが表示されること
   結果：/etc/hostsの修正後、Failover Test用のDBサーバーに接続できることを確認しました。
   
   
   Failover Testの終了オペレーションです。
   こちらも開始と同様、数ステップで終了することができます。
   
   
   

5. テスト終了時に問題なくセカンダリサイトから仮想マシンが削除されること
   結果：DRサイト側のDRテスト用のインスタンスが削除されたことを確認しました。
   
   
   

影響ゼロの「定期DRテスト」 (Failover Test) 結果サマリ

ということで、こちらが本検証の結果サマリになります。

まとめ

今回は、ZertoのFailover Testを使用し、本番環境への影響を抑えながらDR環境を検証する流れをご紹介しました。

検証では、DRサイトへの仮想マシンの作成、テスト用IPアドレスの適用、本番環境の継続稼働、WebサーバーからDBサーバーへの接続、テスト終了後の仮想マシン削除まで確認できました。

DR対策は、レプリケーションを構成した時点で完了するものではありません。サーバー上のOS、ミドルウェア、アプリケーションは継続的に更新されるため、DR環境についても定期的な動作確認が必要です。Failover Testを継続的に実施することで、復旧手順や設定上の課題を事前に把握し、実際の災害時により確実なサービス復旧を行うための準備につながります。

次回予告

次回のZerto DR編では、「データロスなしの計画移行・メンテナンス (Failover Live＋逆保護) 」をご紹介します。

本ブログを最後までお読みいただき、ありがとうございました。引き続きよろしくお願いいたします。

著者紹介

デスクトップ製品のコールセンターからインフラエンジニアまで幅広く業務を経験、IT業界には21年以上携わってきたエンジニア。本ブログでは、可能な限り実機検証に基づいた情報をお届けします。

横河レンタ・リース株式会社は「実機検証で知りえた知見を皆さまへ」をキャッチフレーズに、今後もVM Essentialsをはじめとする仮想化基盤の技術情報を発信してまいります。VM Essentialsの導入検討やVMwareからの移行にお悩みの方は、お気軽にご相談ください。 

お問い合わせ (総合) | 法人向けパソコン (PC) ・計測器レンタルなら横河レンタ・リース