Reidによる記事です。AWSをハイブリッドクラウド戦略に組み込んでいます。組織がハイブリッドクラウド戦略を計画する際、災害時の事業継続性を確保するために、ディザスタリカバリ(DR)は重要な考慮事項です。AWSを利用したディザスタリカバリを実装するためのアーキテクチャ上の考慮事項とベストプラクティスについて説明いたします。(SRM)アドオンを中心に解説します。ディザスタリカバリが適切に設計されていない場合、災害が発生した際にサービスが失われ、サービスレベルアグリーメント(SLA)を満たせなくなることがあります。このようなサービスの喪失は、お客様に金銭的な損害や評判の低下をもたらす可能性があります。壊滅的な中断後にデータセンターをフル稼働状態に戻す方法および手順(失われたデータの回復を含む)と定義されます。AWSと適用可能なサービスがどのように適合するかについて説明します。AWSでは、複雑さと時間の範囲にわたって4つのレベルのDRサポートを提供しています。アクティブ/アクティブ)について詳しく説明します。(SDDC)でワークロードの展開を開始する準備が120分以内に整います。これにより、オンデマンドのディザスタリカバリが可能です。リソースをオンデマンドで拡張できる為、アイドル状態のリソースが使用を待機するのを防ぐ費用効果の高いアプローチです。S3)をバックアップリポジトリとして設定します。AWS認定のバックアップが必要です。バックアップデータは、設定した移動ポリシーに基づいて、S3バケットにオフロードされます。53は、プライマリデータセンターへのDNSリクエストを処理します。Replicationサーバは、ワークロードをバックアップリポジトリにバックアップします。S3のキャパシティティアにオフロードされます。SDDCクラスタを起動及び構成します。新しく作成されたSDDC内に新しいバックアップリポジトリインスタンスをデプロイ及び構成。S3に保存されている以前のデータが検出されます。初期メタデータとアーカイブインデックスの同期が実行されます。SDDCクラスタにワークロードが復元され、サービスがオンラインに戻ります。53のレコードを更新し、クラウド上の新しいセカンダリデータセンターへリクエストを処理します。AWSをリカバリサイトとして保護します。AWSでは、2ノードのパイロットライト環境から始めることができます。パイロットライト環境では、Tier-0アプリケーションだけでなく、セカンダリドメインコントローラなどの重要なユーティリティ仮想マシン(VM)を常時稼働させることができます。その後、災害発生時にオンデマンドでスケールアップできます。このアプローチを使用すると、災害発生時により多くのノードにスケールアップし、サポートされるバックアップソリューションを活用してワークロードをリカバリする必要があるまで、お客様は2ノードの料金を支払います。ベストプラクティスとして、この方法を使用する場合、SDDCクラスタ内のホストを自動的にスケーリングするスクリプトをリカバリプランに追加する必要があります。(VCDR)を活用することです。SDDCを運用する必要はありません。VCDRを使用すると、SDDCホストの小さなサブネットを事前に展開して、純粋なオンデマンドアプローチよりも低い目標復旧時間(RTO)要件で重要なアプリケーションをリカバリできます。このモデルは、SDDCのセットアップに約2時間かかる可能性があるため、RPO(目標復旧時点)とRTOが低いお客様に適しています。リカバリが必要な仮想マシンの数やサイズによっては、仮想マシンのリストアに時間がかかる場合があります。AWS内でのウォームスタンバイ次のオプションは、ウォームスタンバイのアプローチです。Schedulerを使用してスケールアップ後、バックアップからリカバリを行います。このソリューションを使用する利点は、お客様が重要なビジネスアプリケーションを保護しながら、コスト削減を実現できることです。必要なときにすべてのDRリソースに費用を支払います。業務に影響を与えることなく、アプリケーションに対するDRテストを無停止で実行できます。前述のように、お客様は災害発生時またはDRテスト中に、スケールアップを行い、バックアップからVMをリストアして、リカバリ要件を満たすことができます。SRMを利用する事によりこのDRオプションを実現する事ができます。アクティブ/アクティブアクティブ/アクティブのデプロイメントは、お客様が完全な本番環境を運用するために必要なすべてのリソースを展開することを選択した場合に使用されます。これは、アクティブ/アクティブのデータセンターを稼働し、RTOとRPOを低くしたいお客様に役立ちます。災害発生時には、ビジネスの即時のニーズを満たすためのインフラストラクチャの変更が、ほとんど、またはまったく必要ありません。SRMを構成する事ができます。AWSを使用する事により実現できます。組織によっては、従来のDRのコストと複雑さに悩まされており、リカバリソリューションを導入されておりません。AWSを使用して、コスト効率の高い方法でDRを実装できるようになります。Managerを実装するためにサポートされているデザインパターンのいくつか以下に示します。Managerを利用する事により、組織はディザスタリカバリを実装するために同等のITインフラストラクチャを用意する必要がなくなります。コロケーションデータセンターを購入またはレンタルする必要はありません。AWSをリカバリサイトとして使用し、オンデマンドで、またはAWSクラウド上で最小のvSphereクラスタの予約からリソースを消費することができます。SDDCとペアになります。AWSに複製できます。AWSに接続することもサポートされています。AWSを新しいDRワークロードのリカバリターゲットとして使用できます。AWSに置き換えることができます。5に示すように、マルチリカバリサイトアーキテクチャを構成できます。Managerで補完できます。Managerを使用してリージョン間のDR保護を行うことができます。AWSまたはオンプレミスを使用いたします。真に機能するディザスタリカバリソリューションを正常に実装するには、DRインフラストラクチャをサポートする基盤となるインフラストラクチャネットワークを適切に設計する必要があります。リカバリサイトに新しいネットワークを作成して、ネットワークインフラストラクチャを簡素化することがベストプラクティスです。AWSまたはオンプレミス)で復旧されたすべての仮想マシンのIPアドレスを再設定する機能を備えています。Toolsがインストールされていることを確認する必要があります。AWSに拡張し、これらのネットワークをリカバリネットワークとして使用しているお客様もいます。ディザスタリカバリのイベントまたはテストでは、オンプレミスのデータセンターからゲートウェイを移動するために、手動による介入が必要になることにご注意ください。ネットワークの拡張に使用されているアプライアンスの単一障害点にも注意する必要があります。DNSによる名前解決は、すべてのサービスが稼働していることを確認するために重要です。ベストプラクティスとして、フェイルオーバーとDNSによる名前解決を可能にするために、DNSインフラストラクチャをリカバリサイトに拡張したことを確認してください。53は、このシナリオで使用する優れたDNSサービスであり、災害時にオンプレミスのDNSインフラストラクチャがアクティブでなくなった場合に自動的にフェイルオーバーする機能を備えています。AWSクラスタに自動的にフェイルオーバーして、災害時にDNS解決を継続できるようにすることができます。AWSを使用してディザスタリカバリプランをサポートする場合、正常に機能するプランを確保するために留意すべき事項がいくつかあります。詳細なリカバリプランがないと、ITインフラストラクチャとビジネスクリティカルなアプリケーションをリカバリする方法を考える時間がほとんどないか、まったくないことがよくあります。災害発生後にシステムをオンラインに戻すために、DRに関する文書化された計画があることを確認してください。.システムが停止した場合に、許可されたスタッフがリカバリプランにアクセスできるようにするプロセスと手順が整っていることを確認します。S3などのクラウドベースのストレージ、またはその他のクラウドストレージサービスに、オフサイトで保存できます。DR計画用に選択したリカバリサイトは、同じ場所または爆風半径にある二次的な建物であってはなりません。ITインフラストラクチャのリカバリサイトは、プライマリサイトに影響するディザスタの影響を受けにくいエリアに存在する必要があります。サイト間の数マイルの距離では、本当に安全なリカバリサイトとしては不十分な場合があります。.お客様は、DRの場所がビジネス要件および規制要件を満たしていることを確認する必要があります。一部の地域では、気象パターンやユーティリティプロバイダに考慮する必要があります。AWSをリカバリサイトとして使用する場合は、オンプレミスのデータセンターと同じリージョンに配置しないことをお勧めします。AWSを選択できます。多くの組織ではDR計画がありますが、テストが不足しているため、実際の災害ではリカバリプロセスが困難な場合がよくあります。ITチームがフェイルオーバーとフェイルバックのプロセスに精通して機能を確認できるようにする為に、リカバリプランを定期的にテストすることをお勧めします。AWSへの実際のリカバリがどのように行われるかをシミュレートできます。災害またはテストの後にVMとアプリケーションがリカバリサイトから実行されるまで、システムリカバリは完全には完了しません。アプリケーションは、災害発生前と同じ動作状態である必要があります。このプロセスも困難な場合があるため、リカバリサイトでアプリケーションを動作させるのに必要な手順とテストの計画を文書化することをお勧めします。AWSにフェイルオーバーされた仮想マシンの起動順序を定義することで、これらのプロセスの一部を自動化できます。多くの場合、ITインフラストラクチャ環境に実装される複数の変更があります。このため、ハードウェア、ソフトウェア、ネットワークの変更など、環境に変更がある場合は常にDRプランを更新する必要があります。これにより、リカバリプランが完全に機能することが保証されます。災害復旧のターゲットとして機能させるために別のオンプレミスサイトを維持することは、労力を要し、展開と維持に多大な投資を必要とします。多くのお客様は、DRソリューションの実装の重要性を認識しており、パブリッククラウドの活用を検討しています。AWSを補完し、クラウドベースのDRに関連する多くの課題をお客様が克服できるよう支援します。Recoveryが組織にどのように役立つか知りたい場合は、以下のリソースを参照してください。