フェイルオーバーとフェイルバック：災害復旧における主な違い
現代社会において、どの企業も時折、データの破損や業務に不可欠なオペレーションの停止に見舞われる可能性があります。しかし、サービスがほんの少しでも中断しただけでも、顧客の信頼を損ない、最終的には多大な損失につながる恐れがあります。企業、特に仮想マシン(VM)上でサービスを運用している企業は、 仮想マシン(VM)の災害復旧(DR)計画を策定する 高可用性と事業継続性を確保するためです。本ブログ記事では、DRプロセスにおけるフェイルオーバーとフェイルバックの役割について解説し、これらの戦略を活用して事業を保護する方法について説明します。
VMのディザスタリカバリとは？
VMの災害復旧 災害発生後、ビジネスインフラを通常の状態に復旧させるプロセスです。災害とは、自然災害や人為的災害を問わず、組織の業務を危険にさらすあらゆる事象を指します。基本的に、VM(仮想マシン)の災害復旧は、組織の仮想化環境の復旧を目的としています。あらゆるDRプロセスの最終的な目標は、ビジネス業務をほぼ瞬時に再開し、最も重要なデータを保護することで、事業継続を確保することです。
DR対策は、3つのタイプに分類されます。 予防策 は、ある事象の発生を防ぐことを目的としています。 是正措置 災害発生時にシステムを復旧させることを目的としています。 捜査措置 これらは、潜在的なリスクを特定し、それらを軽減するために用いられます。
フェイルオーバーとフェイルバックの違い
災害は、ほとんどの場合、予期せず発生します。災害復旧(DR)の事態においては、重大な被害が生じる前に、企業の仮想化インフラをできるだけ早く復旧させることが極めて重要です。 フェイルオーバー そして フェイルバック これにより、生産拠点が災害の影響を受けた場合でも、事業を円滑に継続することが可能になります。
フェイルオーバーとは何ですか？
フェイルオーバーとは、ミッションクリティカルなワークロードをプライマリの運用センターから転送し、オフサイトの拠点でシステムを復旧させるプロセスです。フェイルオーバーの主な目的は、災害やサービス障害がビジネスサービスや顧客に及ぼす悪影響を軽減することです。ソフトウェアやハードウェアの障害が発生した場合、そのレプリカへフェイルオーバーを行うことで、影響を受けた仮想マシンを迅速に復旧させることができます。
VMレプリカを使用したフェイルオーバー
フェイルオーバー時には、本番サイトの元のVMに代わって、リモートサイトにあるVMレプリカが起動されます。最新の復旧ポイント(特定の時点におけるVMの状態を表すもの)へのフェイルオーバーが可能です。レプリケーションジョブを可能な限り頻繁に実行することで、複数の復旧ポイントを作成でき、災害発生時のデータ損失を最小限に抑えることができます。レプリカへのフェイルオーバーは、ハードウェアやソフトウェアの障害が発生した際の災害復旧に適した、コスト効率の高いソリューションです。
フェイルオーバー・クラスタリング
フェイルオーバー・クラスタとは、アプリケーションやサービスの高可用性を確保するために連携して動作する、独立したコンピュータのグループを指します。フェイルオーバー・クラスタは、VMが実行されている2台以上の相互接続されたサーバー(またはノード)と、VMのファイルが保存されている共有ストレージで構成されます。いずれかのサーバーに障害が発生した場合、それらのVMは別のサーバー上で復旧されます。フェイルオーバー・クラスタは、ハードウェア障害からのみVMを保護します。 フェイルオーバークラスタリングは、レプリカへのフェイルオーバーよりもコストがかかります。しかし、災害発生時にセカンダリサイト上でVMが自動的に起動されるため、ダウンタイムをほぼゼロに抑えることができます。
フェイルバックとは何ですか？
災害発生後にプライマリサイトを復旧し、関連する問題をすべて解決したら、業務をソースVMに戻すことができます。
のフェイルバック機能を使用すると、ソースホスト(または任意の新しい場所)にある元のVMを復旧し、VMレプリカから元のVMへワークロードを戻すことができます。 ただし、フェイルオーバー以降、VMレプリカに何らかの変更が生じている可能性があります。そのため、重要な情報が失われないよう、フェイルバックを実行する前に元のVMとVMレプリカを同期させる必要があります。フェイルバックでは、変更されたデータのみが元のシステムに送信されます。
災害復旧の一環としてのフェイルオーバーおよびフェイルバックのプロセス
DR発生時には、フェイルオーバーおよびフェイルバックの処理が開始されます。その手順は以下の通りです:
- 本番サイトのソースVMは、DRサイトへレプリケートされます。VMレプリカの仮想ディスク上のデータは、レプリケーション実行時点におけるソースVMの仮想ディスク上のデータと完全に同一です。災害が発生した場合(または災害が予見される場合)、VMレプリカへのフェイルオーバーが開始されます。
- フェイルオーバー中は、システムのワークロードがDRサイトに移行されます。しかし、運用が続くにつれて、レプリカVMに何らかの変更が生じる場合があります。元のシステムはオフライン状態であり、行われた変更を一切反映しないため、こうしたデータを保存することが重要です。したがって、すべての変更はVMレプリカの仮想ディスクにのみ書き込まれます。
- 災害による悪影響が解消された(または潜在的な脅威が去った)後、プライマリサイトは通常通り稼働できるようになります。そこでフェイルバック操作が実行され、すべてのワークロードがDRサイトから本番サイトへ戻され、更新されたデータがソースVMに受信されます。これにより、元のVMとVMレプリカの状態が同期されます。
仮想マシン(VM)の災害復旧におけるフェイルオーバーおよびフェイルバックのベストプラクティス
- 規制への準拠を確保する。 一部の組織では、極めて機密性の高いデータを扱っているため、HIPAAやPCI DSSなどの規制への準拠が求められます。該当する場合は、フェイルオーバーおよびフェイルバックに関するDR戦略が、適用されるセキュリティ基準を満たしているかどうかを確認する必要があります。
- ライセンスを確認してください。 ソフトウェアのドキュメントを確認し、アプリケーションスタックにライセンス上の制限がないか確認してください。もし制限がある場合は、事前に問題を解決し、すべての要件が満たされていることを確認する必要があります。
- 災害復旧計画の範囲を定義してください。 VM DR計画の範囲を明確にすることで、保護すべきシステムを特定し、期待される成果や想定される制約を明らかにします。計画のあらゆる側面をカバーできるよう、仮想環境に十分な技術的容量が確保されていることを確認してください。
- 信頼性の高いデータ保護ソリューションをお選びください。 仮想環境に適切なライセンスを取得したデータ保護ソリューションを導入することは、効率的なパフォーマンスとシームレスな統合のために不可欠です。災害復旧(DR)計画の策定にあたっては、仮想インフラストラクチャを復旧し、すべての業務を本番サイトに戻すまでに製品が要する時間を明確に把握しておく必要があります。
- フェイルオーバーとフェイルバックの責任者を決定する。 経営陣は復旧チームのメンバーを指名し、各メンバーに具体的な役割を割り当てるべきである。実際の復旧時に混乱が生じないよう、フェイルオーバーおよびフェイルバックの運用を監視する責任者を明確にしておく必要がある。
- ITスタッフに対し、フェイルオーバーおよびフェイルバックの運用について研修を行う。 前のポイントに続き、IT担当者がフェイルオーバーおよびフェイルバックの運用を行うために必要な知識と資格を備えていることを確認してください。担当者は、万が一計画通りに進まない場合に備えて万全の準備を整えておく必要があります。また、状況に応じて柔軟に対応し、発生した問題に対処できるよう、運用内容を十分に理解していなければなりません。
- サービスレベル契約(SLA)を見直す。 サービスレベル契約(SLA)とは、サービスプロバイダーとその顧客との間で締結される契約であり、プロバイダーが満たすべき要件やサービス基準を定めたものです。したがって、SLAが最新の状態であることを確認し、その適用範囲がDR環境にも及ぶようにしてください。
- 定義する RTO そして RPO. A 目標回復時間 (RTO)とは、重大な損害や致命的な損失を防ぐために、災害発生後に事業運営を復旧させなければならない期間を指す。 復旧時点目標 (RPO)とは、ビジネスに許容できないレベルの損害を与えることなく、失ってもよいデータの量(時間単位で測定)を指します。RPOは、本質的に、災害発生時に仮想マシン(VM)を復元できる最も古い時点を意味します。 RTOおよびRPOは、主に災害発生時の組織の優先順位に基づいて設定する必要があります。バックアップやレプリケーションジョブの頻度を増やすことは、時間とリソースを要する作業ですが、RPOを大幅に改善することができます。優先順位が最も高いコンポーネントには、より短いRTOを割り当て、それらを最優先で復旧させる必要があります。なお、RTOとRPOは、アプリケーションとVMごとに個別に設定する必要がある点に留意してください。
- DRサイトを常設サイトとして運用する可能性を検討してください。 大規模な災害により、主要データセンターの復旧が不可能になる事態が発生し、事業に影響が及ぶ可能性があります。そのため、DRサイトを恒久的な拠点として活用する可能性を検討し、このような大規模な事態に備えておくことが重要です。 当然ながら、これは多額の費用を要する解決策であり、多大なリソースを消費し、設備、ソフトウェア、施設に関する多額のコストが発生します。たとえすぐに計画を実行に移さなかったとしても、どのような対応が必要になるかを検討しておくことは有益です。
- フェイルオーバー操作をテストする。 フェイルオーバー手順をテストすることで、DRサイトにおいて仮想インフラストラクチャが適切に復旧できるかどうかを確認し、本番サイトが利用不能になった場合でも、あらかじめインストールされたアプリケーションが正常に動作することを検証できます。
- フェイルバック操作をテストする。 こうすることで、DRサイトから元のサイトへ、自社の業務を確実に復旧させることができます。
- 災害復旧計画を全面的にテストしてください。 DR計画全体をテストすることも有益です。DR事象をシミュレートすることで、計画の弱点を特定するのに役立ちます。その結果、組織が採用しているDR戦略を改善・適応させることができます。不備があり、時代遅れのDR計画は、組織の事業継続に重大な支障をきたす恐れがあります。
フェイルオーバーとフェイルバック NAKIVO Backup & Replication
NAKIVO Backup & Replication 限定の サイト復旧 この機能により、どのような複雑さを持つ自動化された復旧ワークフロー(またはジョブ)でも作成できます。サイト復旧(SR)ワークフローには、フェイルオーバー、フェイルバック、VMの起動/停止、ジョブの実行/停止、リポジトリの接続/切断など、一連のカスタム操作が含まれます。これらの操作は任意の順序で配置することができ、DRプロセスの完全な自動化とオーケストレーションを実現します。 さらに、本番環境に影響を与えることなく、いつでも簡単にSRジョブの変更、追加、テストを行うことができます。したがって、SRワークフローを活用することで、最も高度なDR計画であっても、構築、テストを経て、スムーズに実装することが可能です。
災害復旧におけるフェイルオーバー
フェイルオーバー処理は、ほとんどのSRワークフローにおいて不可欠な要素です。フェイルオーバーを伴うサイト復旧は、保護対象となるソースVMのレプリカを事前に作成している場合にのみ実行可能です。これらのレプリカは、災害発生時にフェイルオーバーのターゲットとして使用されます。ワークロードは、影響を受けた本番サイトのソースVMから、DRサイトのVMレプリカへと移行されます。
NAKIVO Backup & Replication 3種類のフェイルオーバーについて説明しました:
- 計画的なフェイルオーバー これは、潜在的な脅威が存在する場合や災害が予想される場合に、システムを予防的に保護するために使用されます。気象災害の通知を受けた場合や、その地域で計画停電が予定されている場合は、計画的なフェイルオーバーを開始できます。この場合、ソリューションはワークロードをレプリカに移行する前に、ソースVMとそのレプリカ間でデータを同期させるため、データの損失を完全に防ぐことができます。
- フェイルオーバーのテスト これにより、フェイルオーバー戦略が適切に機能しているか、また災害復旧(DR)発生時に信頼できるものかどうかを判断できます。テストフェイルオーバーは、計画的なフェイルオーバーと同様に実行されますが、プライマリ環境に支障をきたさないよう、テストモードで行われたすべての変更は直ちに元に戻されます。さらに、災害復旧(DR)発生時にワークフローが十分に高速に実行されるかどうかもテストできます。 NAKIVO Backup & Replication これにより、サイト復旧ジョブのRTOを設定できます。ジョブの完了に設定時間を超える時間がかかった場合、テストは失敗とみなされます。テスト／実行レポートがメールで送信されますので、これを確認してDR計画の不備を特定し、解決することができます。
- 緊急フェイルオーバー 本番環境に障害が発生し、ソースVMに接続できなくなった直後に実行されます。 NAKIVO Backup & Replication…により、ワンクリックでプライマリサイトからDRサイトへワークロードを移行できます。これにより、一部のデータが失われる可能性はありますが、ダウンタイムを最小限に抑えることが保証されます。
DRサイトにおけるVMの再保護
フェイルオーバーが完了したら、DRサイトで稼働しているVMレプリカが保護されていることを確認する必要があります。VMレプリカも破損する可能性があるため、他にコピーが存在しない場合、それらを直ちに復旧することは不可能になります。
ただし、 NAKIVO Backup & Replication これにより、災害復旧(DR)事象発生後も、仮想インフラストラクチャが確実に再保護されます。DRサイトで稼働中のVMを別の場所に複製するだけで済みます。そのため、万が一の事態が発生しても、新しいVMレプリカへ容易にフェイルオーバーできます。また、フェイルオーバー完了後すぐにDRサイトで稼働中のVMの複製を自動的に開始するようSRワークフローを設定することで、高いレベルの保護を保証できます。
ディザスタリカバリにおけるフェイルバック
フェイルバックは、SRワークフローでフェイルオーバーが発生した後にのみ実行できます。しばらくしてプライマリサイトが復旧し、正常に稼働し始めたら、元のソースVMでの運用を再開できます。 この目的のため、元のVMに代わって稼働していたVMレプリカから、このVMへフェイルバックを行うことができます。VMのワークロードをプライマリ本番サイトへ戻すことができない場合(例:復元できない場合など)、DRサイトよりも長期的な解決策として、任意の新しい場所へ移行することができます。
フェイルバックは、本番モードまたはテストモードで実行できます。
- テストモードでのフェイルバック これは、実際のフェイルバック処理中に問題が発生することなく、SRジョブが正常に実行できるかどうかを確認することを目的としています。この場合、VMレプリカからソースVMへの増分または完全なレプリケーションは1回のみ実行されますが、テスト目的としてはこれで十分です。IPアドレスとネットワーク設定が正しいことを確認してください。 データ損失を防ぐため、ソースVMとVMレプリカは同期され、その後ソースVMが起動されます。なお、フェイルバック処理中にVMに加えられたすべての変更は、テスト完了後に破棄され、仮想環境はフェイルバック前の状態に戻されます。テストモードでは、サイトリカバリジョブをオンデマンドまたはスケジュールに基づいて実行できます。
- 本番環境でのフェイルバック これは、DRフェイルオーバー後に本番環境を復旧させたい場合に実行されます。本番モードでは、サイトリカバリジョブはオンデマンドでのみ実行可能です。本番モードでのフェイルバックの手順は、基本的にテストモードでのフェイルバックと同じです。ただし、このプロセスでデータ損失がゼロになるよう、VMレプリカからソースVMへのレプリケーションが2回実行されます。 レプリケーション操作が完了すると、元のソースVM(本番サイト)の電源がオンになり、DRサイトのVMレプリカの電源がオフになります。(この最後のステップ、つまりDRサイトのVMレプリカの電源をオフにする操作は、本番モードでのみ行われることに注意してください。)
結論
フェイルオーバーとフェイルバックの仕組みを理解し、それらを仮想マシンの災害復旧計画に組み込むことで、仮想環境を予期せぬ事態から保護することができます。フェイルオーバーにより、ミッションクリティカルなデータが確実に保護され、すべてのワークロードが迅速に災害復旧サイトへ移行されます。フェイルバックを利用すれば、数回のクリック操作で災害復旧サイトから本番サイトへ切り替えることが可能です。これら2つの操作を組み合わせることで、データ損失を最小限に抑え、ダウンタイムを短縮することができます。
