ゾーン障害

完全なゾーン障害が発生した場合、コントロールプレーンとデータプレーンの両方がそのゾーンに影響を受ける。 影響を受けたゾーンの制御機能は利用できず、すべてのゾーンのリソースがダウンしている。 たとえば、影響を受けたゾーンの仮想サーバーインスタンスは利用できず、健全な別のゾーンに移動されません。 リージョナルリソースに加えられた変更は、そのゾーンが回復するまで 失敗したゾーンには反映されない。

他のゾーンのデータプレーンは影響を受けず、影響を受けていないゾーンのすべてのゾーン・リソースは何の混乱もなく機能し続ける。 VPCのようなリージョナル・リソースは、健全なゾーンで稼働し続ける。 制御プレーンは可用性が高く、サービスが他の影響を受けていないゾーンのリソースを管理できる。

顧客は、リソースをゾーン（障害ドメイン）に分散してアプリケーションの高可用性を管理するメカニズムを開発し、ディザスタリカバリの計画を立てるべきである。

地域的な失敗

地域的な災害が発生した場合、根本的な問題はすべて解決され、VPCのコントロール・プレーンはリソースのデータ損失を減らすことに重点を置いて復旧されます。 また、データプレーンは、復旧時点目標（RPO）と復旧時間目標（RTO）を満たすことを目的に、ストレージから顧客データの状態を復旧させることで復元される。

単一キャンパスのマルチゾーン・リージョン（SC-MZR）では、ゾーンがより緊密に関連しているため、データセンターの災害がリージョン全体に影響を及ぼす可能性がある。 サービスは、データの損失を避けるために、別のMZRへのバックアップとリカバリ戦略を採用すべきである。

ハードウェア障害

リソースは信頼性が高く、多くの場合冗長化されたハードウェアから提供されるが、予期せぬハードウェアの障害によって、これらのリソースがダウンする可能性がある。 例えば、仮想サーバー・インスタンスは、基礎となるハードウェアが故障したときに失敗するかもしれない。 この状況では、 ホスト障害復旧ポリシーが 仮想サーバーの復旧方法を決定する。 障害が発生し、ホスト障害復旧ポリシーがデフォルト設定（ restart ）に設定されている場合、コントロールプレーンはハードウェア障害を検出し、仮想サーバーを同じゾーン内の利用可能なハードウェアに移行し、仮想サーバーを再起動します。 エフェメラルディスクストレージがブートボリュームにリストアされない。 データボリュームは利用可能だが、障害時に保存されていないアプリケーションやオペレーティングシステムのキャッシュ書き込みが欠落している可能性がある。

ブロックボリュームは、高度なレプリケーション技術による冗長ハードウェアによってバックアップされ、耐障害性を向上させます。 しかし、ゾーン災害や複数ハードウェアの障害により、ブロック・ボリュームに障害が発生する可能性があります。 バックアップと復元は、データの損失や破損を軽減するための適切なアプローチである。 このアプローチは、他の IBM Cloud 地域にデータを複製することによって、地域の災害を軽減するために使用することもできます。 スナップショット機能は、バックアップとリストアをサポートするために使用することができます。 また、顧客はアプリケーションを他のゾーンに分散することで、中断を回避し、RPO/RTOを改善することができる。

ボリューム・ストレージと関連するサーバー・アプリケーションの障害の間には、強い障害相関が存在する可能性がある。 障害が発生したストレージデバイスがある場合のアプリケーションの動作を判断するために、必ずワークロードを調べ、テストしてください。

ベアメタルサーバーとそれに関連するストレージについては、 Bare Metal Servers for VPC のストレージの概要を 参照してください。 スナップショットは、ベアメタルサーバーのローカルディスクでは利用できません。 顧客はこれらのデバイスの高可用性とディザスタリカバリを管理しなければならない。

HAアプリケーションの構築

VPCロードバランサーを使用して、入ってくるリクエストを複数の仮想サーバーやベアメタルサーバーに振り分けることができます。 利用できなくなった仮想サーバーとベアメタルサーバーは、ヘルスチェックに応答しなくなる。ロードバランサーは次に、利用可能なリソースの負荷分散を行う。 アプリケーション・ロード・バランサー（ALB）を使用して、ワークロードのトラフィックを複数のゾーンの仮想サーバーに分散し、ゾーン全体が利用できなくなった場合でも利用可能なワークロードを作成できます。

ALB自体がゾーンをまたいでサブネット上に構成されている場合、単一ゾーンの障害に強い。 ネットワーク・ロードバランサーは、複数の仮想サーバー上に分散配置され、単一の仮想サーバーの障害に強いゾーンサービスです。

VPCリソースから構築されるワークロードの可用性を向上させる基本戦略は、複数のリソースにワークロードを分散させることである。 リソースをゾーン内に分散させることも、マルチゾーン・リージョン（MZR）で複数のゾーンに分散させることも、複数のリージョンに分散させることも可能である。 この 戦略では、 IBM Cloud Internet Services (CIS) とグローバルロードバランサーを使用します。

高可用性機能

IBM Cloud VPC は以下の高可用性機能をサポートしている：

顧客として、HAを作り、サポートすることができる：

ディザスターリカバリー機能

IBM Cloud VPC は、以下のディザスタリカバリ機能をサポートしている：

スナップショットからボリュームや共有を復元するには、手動での操作が必要であり、時間がかかります。 ディザスタリカバリのためにより高いレベルのサービスが必要な場合は、 IBM Cloud 「 バックアップおよびリカバリサービス 」をご覧ください。

お客様として、追加の災害復旧オプションを作成し、サポートすることができます：

災害復旧の計画

災害復旧の手順は、定期的に実践されなければならない。 計画を立てる際には、次のような失敗のシナリオと解決策を検討してください。

IBM ゾーン障害からの復旧方法

ゾーンの障害は、自然災害、停電のようなインフラの問題、情報を削除する偶発的または悪意のある行為、またはバグやエラーを含むソフトウェアの更新によって発生する可能性があります。 バグやエラーを含むソフトウェアの更新 ゾーンに障害が発生した場合、 IBM は、施設やデータセンター、物理ネットワークおよびデバイス、 物理ストレージ、物理サーバーおよびメモリ、ハイパーバイザーの復旧に取り組みます。 詳しくは、 IBM Cloud 製品を使用する際の責任の分担を ご覧ください。

IBM 地域の失敗からどう回復するか

地域全体で障害が発生した場合、 IBM は再び、施設やデータセンター、物理ネットワークやデバイス、物理ストレージ、 物理サーバーやメモリ、およびハイパーバイザーの復旧に取り組みます。 詳細については、 IBM Cloud 製品を使用する際の責任の分担、および災害復旧に関する FAQ をご覧ください。 および 災害復旧に関するFAQを 参照してください。

IBM、サービス・インスタンスをリストアできない場合は、 ディザスタ・リカバリ・アーキテクチャの 説明に従ってサービスをリストアする必要があります。