本番に間に合わないプランの立案と設計

DRインフラストラクチャーのキャパシティは、計画に別段の定めがない限り、本番のワークロードを管理できなければならない。 本番環境と一致しないリソースでDRを実施することは、コストの観点からは魅力的に見えるかもしれないが、災害の影響をより深刻にする可能性がある。

ディザスタリカバリ環境を計画し、実装する際には、その環境自体の回復力要件を考慮する。 DRの実装に必要な高可用性要件を減らしてコストを削減しようとしてはならない。 災害が発生した場合、生産ワークロードには回復力のある環境が必要だ。 クラウドのサービスはスケーラブルなので、後から容量を追加することができるが、災害が引き起こす地域需要の増大は、短期的な容量不足を招く可能性がある。

非技術的な単一障害点を忘れる

単一障害点（SPOF）は、技術だけでなく、ソリューションのどこにでもあり得る。 ソリューションは、人、ベンダー、プロバイダー、およびその他の外部依存関係に依存する場合があります。 SPOFを明確にし、依存関係を緩和する。 災害時回復テストの最初のセッション中に SPOF を検出できるように準備してください。

SPOF の中で、プロバイダー・リスクは DR 計画で考慮すべき条件です。 実動と DR の両方が同じプロバイダー上にある場合は、リスク状態が増大するため、慎重に検討する必要があります。

プラン A のみの場合

災害にはさまざまな形態があるため、ある特定の災害シナリオを想定した計画を立てると、他の災害シナリオに対して脆弱になってしまう。 DR計画を考える際には、いくつかの異なる災害シナリオを検討し、計画がいかに柔軟であるかを示す。

プランのテストが不十分

テストされていないDRソリューションは、成功が最も重要なときに障害に遭遇する可能性を高める。 テストは、動作するソリューションがあることを検証するために不可欠である。 テストする条件も重要で、いくつかのテストシナリオを作成する必要がある。

一方の拠点で計画的な運用停止を行い、もう一方の拠点できちんと整理された再起動を行うことで、DRテストが確実に機能するようになります。 しかし、実際の緊急事態では、単純な完全シャットダウンが起こるとは限らない。

緊急事態の結果として作業負荷が徐々に影響を受ける「ローリング災害状態」をシミュレートすることで、想定される緊急事態をできるだけ忠実に模倣するようにテストを設計する。 漸進的な衝撃は、ソリューションの回復力をテストし、ストレス条件に対する耐性についての洞察を提供します。

高可用性

高可用性とディザスタリカバリはイコールではありません。 IBM Cloudでは、 IBM Cloudのマルチゾーン・リージョン（MZR）を利用して、デプロイメントが高可用性であることを確認することを推奨しています。 各MZRには最低3つのゾーンがあり、高度に相互接続されているが、運用上は別々のデータセンターとなっている。 多くの場合、問題や停電は地域全体ではなく、単一のゾーンだけに影響する。 MZRの全ゾーンにワークロードをデフォルトで展開することで、ダウンタイムを短縮し、災害を呼び出す必要性を減らすことができる。 第2リージョンへのフェイルオーバーは、フェイルバックと同様、大きなプロセスとなる可能性がある。 しかし、MZRはデータの破損や悪意のある被害などの災害を防ぐことはできない。

規制とコンプライアンス

ワークロードやデータの中には、厳しい業界規制やコンプライアンス基準の対象となるものがあり、それが実行や保存が可能な物理的な場所に影響を及ぼすことがあります。 災害復旧サイトの場所を選択する際には、選択した地域が必要な規制やコンプライアンスを満たしていることを確認する。 データを複製する場所も確認する必要がある。

地域横断 Object Storage バケットは、異なる地域にデータを複製する方法を提供しますが、データが地域的な制限を受ける場合は注意して使用してください。 組織や業界のコンプライアンス規則に違反する国や地域のリージョンにデータが転送されないことを確認する。

災害復興地域のキャパシティ

災害は多くの顧客に影響を及ぼし、顧客は災害復旧計画を策定する。 追加的な需要は、故障した地域に最も近い1つ以上の地域の能力に深刻な負担をかけるかもしれない。 その結果、利用可能な資源が不足する可能性がある。 例えば、 us-south に障害が発生した場合、多くの顧客はまず us-east 地域での復旧を選択する可能性が高い。 eu-gb が失敗すれば、 eu-de にさらに多くの需要が集中すると予想される。

災害によって需要が高まった場合、最初に選択したインフラが復旧地域で提供できない可能性がある。 これには、人気のあるVPC VSIプロファイルが含まれます。 別のVSIプロファイルが必要な状況を考慮できるよう、アプリケーションのさまざまなアーキテクチャを考慮に入れてください。 代替インフラの使用に耐えられないアプリケーションの場合は、災害を想定して災害復旧地域に必要なだけの容量を構築または予約しておくか、容量の問題を回避するために離れた別の場所を検討することを検討してください。

選択した地域でバックアップをリストアできることを確認する。 例えば、コンプライアンス境界を越えた地域ではデータベースをリストアできない。 ベストプラクティスとして、データ復元のタイミングを必ずテストし、地域全体が影響を受けるような大規模災害の場合、多くの顧客が一度にデータ復元を試みるため、時間が延びる可能性があることを考慮してください。

接続性

ネットワーキング・サービスは、サードパーティの活動や物理インフラストラクチャのさらなるインストールを必要とする場合があるため、プロビジョニングや設定に時間がかかる場合がある。 DR計画を作成する際には、そのようなサービスのリードタイムを考慮してください。 これらのサービスを前もって用意しておくのが最適だ：

• Direct Link Transit Gateway ローカルおよび グローバル Transit Gateway
• VPCエッジ
• VPNゲートウェイと接続
• DNSハブ＆スポークのVPCセットアップによるプライベートDNS
• 共有サービス用VPE
• コンテキスト・ベースの制限ルール
• プライベートDNSのグローバルロードバランサー
• CIS パブリック LBaaS, VPE プライベート・パスおよび PPNLB 付き

を活用してください。 VPC landing zone デプロイ可能なアーキテクチャと FSクラウドのリファレンス・アーキテクチャを活用して、事前または災害復旧時の接続を準備します。

部分的または完全なフェイルオーバー

クラウドはさまざまなサービスで構成されており、アプリケーションは連携する複数のコンポーネントに依存することができる。 災害復旧計画は通常、地域レベルでの壊滅的な障害に備え、地域内のすべてのサービスが失われることを想定している。 しかし、孤立したサービス停止は、地域の他のサービスに影響を与えることなく発生する可能性がある。

このような場合、他のリージョンへの完全なフェイルオーバーが必要なのか、それとも障害が発生したコンポーネントのみに対処する必要があるのかを評価することが極めて重要である。

例えば、データベース・サービスに致命的な障害が発生した場合、ウェブ・サービスを含むワークロード全体をフェイルオーバーする必要があるか？ それとも、他のコンポーネントは、別のリージョンにあるスタンバイのリード・レプリカ・データベースに簡単に切り替えられるのでしょうか？

このようなシナリオに対処しやすいかどうかは、ワークロードがどのように設計され、構成されているかによる。 サービス名のハードコーディングは避け、部分的な停止時にスムーズな移行を可能にするため、ネットワーク遅延などの要因を考慮したアーキテクチャにすること。

フェイルバック

もうひとつ考慮すべきは、災害が一段落した後のフェイルバックの位置だ。 フェイルバック手順はDR計画に文書化されている。 フェイルバックの考慮事項は以下の通り：

• フェイルバックするのか、リカバリー先で通常通り走り続けるのか？
• フェイルバックが必須の場合、いつ試みるのか？
• フェイルバックはどのように機能するのか？

フェイルバックは災害と同じくらい複雑で破壊的な可能性があるため、フェイルバックが必要かどうかを検討する必要がある。 その代わり、2カ所目でもサービスを継続できるのか？ フェイルバックのタイミングも重要だ。 災害の原因となった状況が解決され、フェイルバックによって混乱が長引かないことを確認する必要がある。

フェイルバックを実行するかどうかにかかわらず、DRプロビジョンは再作成またはリセットする必要がある。