IBM Cloud VPC の高可用性と災害復旧について
高可用性サービスまたは作業負荷が障害に耐え、事前に定義されたサービスレベルに従って処理能力を提供し続ける能力。 サービスについては、可用性はサービスレベル契約で定義されています。 可用性には、計画されたイベントと計画外のイベントの両方が含まれます。計画外のイベントには、メンテナンス、故障、災害などが含まれます。 (HA) とは、予期しない障害が発生した場合でもサービスが稼働し続け、アクセス可能になる能力です。 ディザスタリカバリとはサービスの中断などの稀な重大なインシデントや広範囲にわたる障害から、サービスや作業負荷が回復する能力。 これには、地域全体に影響を及ぼす物理的な災害、データベースの破損、作業負荷に寄与するサービスの損失などが含まれます。 その影響は、高可用性設計の処理能力を超えている。、サービスインスタンスを稼動状態に回復させるプロセスである。
IBM Cloud® Virtual Private Cloud は、 サービス・レベル目標(SLO)を 満たすように設計された可用性の高いサービスである。 ゾーンサービスとリージョナルサービスの両方で構成されている。
利用可能な地域とデータセンターのロケーションの詳細については、 ロケーション別のサービスとインフラの可用性を ご覧ください。
高可用性アーキテクチャ
VPCリソースはコントロールプレーンとデータプレーンのサービスに分かれており、顧客はVPC上に可用性の高いアプリケーションを構築できる。 コントロール・プレーンは、VPCリソースのプロビジョニングと管理(作成、更新、削除)、および制御機能を提供するために存在する。 データプレーンは、仮想サーバーインスタンス、フローティングIPアドレス、セキュリティグループ、ブロックストレージなど、プロビジョニングされたVPCリソースの集合体です。
制御プレーンは、ゾーン間で冗長化されたハードウェア上にホストされ、ハードウェアやゾーンの障害に対する回復力を提供する。 コントロールプレーンとデータプレーンは異なる障害ドメインにある。 例えば、制御プレーンが停止しても、データプレーンの可用性には影響しない。 既存の顧客リソースはすべて、何の影響もなく稼動し続ける。 耐障害性を高めるために、ユーザーは冗長データプレーンリソースからアプリケーションを構築することができます。
VPCリソースは、その範囲に基づいてゾーンリソースとリージョナルリソースに分類される。 VPCなど一部のリソースは複数のゾーンにまたがっており、地域リソースとみなされる。 ほとんどの資源はゾーン・スコープがあり、特定のゾーンで利用できる。 例えば、サブネット、アクセス・コントロール・リスト、セキュリティ・グループ、ルーティング・テーブル、パブリック・ゲートウェイ、および仮想プライベート・エンドポイント・ゲートウェイは、それらが作成されたゾーンに存在する。
制御プレーンの障害からのデータプレーンの保護、ゾーンサービスの独立性、地域サービスの冗長性の詳細については、 高可用性と回復力のための IBM Cloud サービスアーキテクチャを 参照してください。
ゾーン障害
完全なゾーン障害が発生した場合、コントロールプレーンとデータプレーンの両方がそのゾーンに影響を受ける。 影響を受けたゾーンの制御機能は利用できず、すべてのゾーンのリソースがダウンしている。 たとえば、影響を受けたゾーンの仮想サーバーインスタンスは利用できず、健全な別のゾーンに移動されません。 リージョナルリソースに加えられた変更は、そのゾーンが回復するまで 失敗したゾーンには反映されない。
他のゾーンのデータプレーンは影響を受けず、影響を受けていないゾーンのすべてのゾーン・リソースは何の混乱もなく機能し続ける。 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 は以下の高可用性機能をサポートしている:
特長 | 説明 | 考慮事項 |
---|---|---|
アプリケーション・ロード・バランサー | ALBはゾーン間の負荷をIPアドレスに分散する。 | ワークロードはスケーラブルでなければならない。 |
ネットワーク・ロード・バランサー | NLBはゾーン内のIPアドレスに負荷を分散する。 | ワークロードはスケーラブルでなければならない。 |
Auto scale for VPC | お客様の環境に応じて動的に仮想サーバーインスタンスを作成することで、パフォーマンスとコストを改善します。 | ワークロードはスケーラブルでなければならない。 |
ロードバランサーとインスタンスグループ | ロードバランサーによってフロント処理されるスケーラブルなワークロードは、ゾーン間の複数のインスタンスに負荷を分散する。 | ワークロードはスケーラブルでなければならない。 |
顧客として、HAを作り、サポートすることができる:
特長 | 説明 | 考慮事項 |
---|---|---|
スケーラブルなワークロード | 仮想サーバーまたはベアメタルサーバーベースのワークロードを作成し、サーバーを増やして水平に拡張することができます。 | すべてのワークロードが水平方向に拡張できるわけではない。 |
スケーラブルなワークロード
スケーラブルなワークロードは、同じイメージを実行するサーバーを追加することで、需要の増加に対応できる。 スケーラブルなワークロードは、ロードバランサーとAuto Scale for VPCを使用することで実装できる。
災害復旧アーキテクチャ
ディザスタリカバリの戦略は、VPCワークロードをリカバリロケーションにリストアするためのスクリプト自動化を提供することです。 例えば、リージョンが利用できなくなった場合、ワークロードと関連データを利用可能なリージョンに移行するのは顧客の責任である。 IBM はTerraform infrastructure as code systemをサポートしており、パラメータ化されたロケーションとパフォーマンスを持つワークロードを定義するのに使用できる。 VPC API、SDK、CLIは、災害時に利用可能な場所にあるリソースを復旧させるスクリプトを作成するために、顧客が使用することができます。 詳しくは、 災害復旧の計画を 参照。
IBM Cloud Object Storage、Terraform-as-a-Serviceを提供する IBM Cloud Schematics、デプロイ可能なアーキテクチャの使用については、 Using IBM Cloud services in your disaster recoveryで 詳しく説明されている。
ディザスターリカバリー機能
IBM Cloud VPC は、以下のディザスタリカバリ機能をサポートしている:
特長 | 説明 | 考慮事項 |
---|---|---|
シングルボリュームのスナップショット | スナップショットは、ブートボリュームまたはデータボリュームのポイントインタイムコピーです。 Block Storage スナップショットは地域の インスタンスに保存される。 Cloud Object Storage | スナップショットはソースボリュームから独立しています。 ソースボリュームのゾーンが利用できない場合、スナップショットを使用して、リージョン内の別のゾーンに新しいボリュームを作成できます。 スナップショットはコンソール、CLI、API、Terraformからオンデマンドで作成できます。 また、Backup for VPCサービスを使用してスケジュールすることもできます。 |
地域横断スナップショット・コピー | 新しいボリュームを作成するために、ソーススナップショットから独立したクロスリージョンスナップショットコピーを使用することができます。 | スナップショットは、コンソールやCLIから手動で、あるいはAPIやTerraformを使ってプログラムで別のリージョンにコピーすることができます。 また、バックアップポリシーに他の地域でのコピーの作成を含めることもできる。 |
一貫性グループのスナップショット | スナップショット一貫性グループには、同じ仮想サーバーインスタンスにアタッチされている複数の Block Storage ボリュームのスナップショットが含まれます。 | 一貫性グループのスナップショットを要求すると、仮想サーバーインスタンスにアタッチされているすべてのタグ付き Block Storage ボリュームのスナップショットが同時に生成されます。 ブートボリュームを含めることも除外することもできる。 インスタンス・ストレージは含まれない。 |
高速リストアスナップショット | 高速リストアスナップショットは、親ブロックボリュームがあるゾーンにキャッシュされるスナップショットです。 ブート可能な高速リストアスナップショットを使用して仮想サーバーを作成すると、通常のスナップショットからブートボリュームをプロビジョニングする場合と比較して、サーバーがより早く完全に動作するようになります。 | |
ファイル共有レプリケーション | ソース共有が利用できなくなった場合、レプリカ共有への レプリケーション・フェイルオーバーを 開始できます。 | 同じリージョンの別のゾーンにレプリカ共有を作成できる。 同じ地域内の別のリージョンにレプリカを作成することもできます。 15分ごとにデータをレプリケートできる。 |
スナップショットからのボリュームまたは共有の復元は、時間がかかる手動操作です。 ディザスタリカバリのために、より高いレベルのサービスが必要な場合は、 IBM 「 クラウド型ディザスタリカバリソリューション 」をご覧ください。
お客様として、追加の災害復旧オプションを作成し、サポートすることができます:
特長 | 説明 | 考慮事項 |
---|---|---|
VPC設定の外部真実情報源 | Terraformスクリプト、シェルスクリプト、プログラムなど、お客様が管理する設定ファイルに取り込まれたVPC、ネットワーク、サーバーの構築。 | 顧客は、スクリプトを作成し、潜在的な災害時に使用できるように構成を永続化する必要があります。 |
ファイル・ストレージのバックアップとコピーのためにお客様が作成したスクリプト | ファイル共有の内容をコピーして、別の場所で利用できるようにする。 | お客様がスクリプトを作成するか、お客様が管理する継続的バックアップおよび復元を使用する必要があります。 |
ブロックボリュームとファイルストレージの顧客管理による継続的なバックアップとリストア | 顧客は、 Veeamの ようなバックアップ&リカバリーシステムと統合するサーバーに、 3rd-party エージェントとOSドライバーをインストールすることができる。 | お客様は、 3rd パーティーのバックアップおよびリカバリソリューションをインストールし、管理する必要があります。 |
災害復旧の計画
災害復旧の手順は、定期的に実践されなければならない。 計画を立てる際には、次のような失敗のシナリオと解決策を検討してください。
失敗 | 解決方法 |
---|---|
ブートボリューム障害 | ボリュームから作成したカスタムイメージから 新しいボリュームを作成できます。 また、コンソール、CLI、API、Terraform、または顧客管理の継続的バックアップ・リストアソリューションを使用して、 スナップショットからボリュームをリストア することもできます。 スナップショットからブートボリュームをリストアする場合、スナップショットからブートボリュームにデータがコピーされる間にパフォーマンスが低下することが予想されます。 高速リストアスナップショットを 使用すると、すべてのデータが利用可能でパフォーマンスに影響がないため、通常のスナップショットからリストアするよりも早く 復旧時間目標災害復旧計画において、災害後にビジネスプロセスが復旧するまでの時間。 (RTO)を達成できます。 |
データボリュームの故障またはデータの破損 | コンソール、CLI、API、Terraform、またはお客様が管理する継続的バックアップ・リストアソリューションを使用して、 スナップショットからボリュームをリストア します。 高速リストアスナップショットは、データボリュームでも利用できる。 |
ファイル共有データの破損 | ファイル共有スナップショットを作成して、ファイル共有上のデータを特定の時点で保存することができます。 ファイル共有のコンテンツが誤って削除されたり上書きされたりしても、 ファイル共有スナップショットからデータを復元 できる。 |
ファイル共有の失敗 | 別のゾーンにある既存のレプリカへのフェイルオーバーを開始することで緩和される。 フェイルオーバー・プロセスをテストし、所要時間を確認する。 |
仮想サーバー障害 | ロードバランサーの高可用性機能とAuto Scale for VPCを使用し、スケーラブルなワークロードを作成することで軽減。 仮想サーバーの再起動が必要な場合があります。 ブロックボリュームの障害解決が必要になるかもしれない。 |
ベアメタルサーバーの障害 | 顧客管理のバックアップ・リストアソリューション。 |
ゾーン障害 | ロードバランサーの高可用性機能とAuto Scale for VPCを使用し、スケーラブルなワークロードを作成することで軽減。 VPCゾーン構成に外部真理源を使用し、サーバー障害解決とブロックボリューム障害解決を使用して、利用可能なゾーンにリソースを作成する。 |
地域的な失敗 | 利用可能なリージョンにリソースを作成するために、VPCリージョン構成に外部の真実のソースを使用する。 サーバーの障害解決を使用して、ボリュームとファイルストレージを以前の値に復元します。 |
高可用性とディザスタリカバリの責任
背景については、 仮想プライベート・クラウドを使用する際の責任を理解するを 参照してください。 HAとDRのプランを継続的にテストするのは、あなたの責任です。 詳細は、 災害復旧テストを 参照。
ネットワーク接続の中断や短時間のサービス利用不能が発生する可能性があります。 アプリケーションの高可用性を維持するために、アプリケーションのソースコードに クライアント可用性再試行ロジックが 含まれていることを確認するのは、あなたの責任です。
以下のチェックリストは、計画の作成と実践に役立ちます。
-
ブロックボリュームのスナップショット
-
ファイル・ストレージのレプリケーション
-
VPC設定の外部真実情報源
変更管理
変更管理には、アップグレード、構成変更、削除などのタスクが含まれる。
ユーザーとプロセスに、業務に必要な最小限の権限を持つ IAM ロールとアクションを付与する。 詳細については、 「誤ってサービスを削除しないようにするにはどうすればよいですか?
インフラ構成を変更する前に、手動でバックアップを作成することを検討してください。
IBM®、災害復旧計画をどのようにサポートするか
IBM® 災害が発生した場合、。 IBM Cloud VPC
単一のホストに予期せぬ障害が発生した場合、障害が発生したホスト上の仮想サーバーを健全なホスト上で自動的に再起動することができます。 IBM、インフラストラクチャを監視し、ホストの障害に対応する方法の詳細については、 ホストの障害回復 ポリシーを参照してください。
IBM ゾーン障害からの復旧方法
ゾーンの障害は、自然災害、停電のようなインフラの問題、情報を削除する偶発的または悪意のある行為、またはバグやエラーを含むソフトウェアの更新によって発生する可能性があります。 バグやエラーを含むソフトウェアの更新 ゾーンに障害が発生した場合、 IBM、施設やデータセンター、物理ネットワークやデバイスの復旧にあたります、 物理ストレージ、物理サーバーとメモリー、ハイパーバイザーを復旧させる。 詳しくは、 IBM Cloud 製品を使用する際の責任の分担を ご覧ください。
IBM 地域の失敗からどう回復するか
地域全体が障害に見舞われた場合、 IBM、施設やデータセンター、物理ネットワークやデバイス、物理ストレージ、物理サーバーやメモリー、ハイパーバイザーを復旧させる、 物理サーバーとメモリー、ハイパーバイザーを復旧させる。 詳細については、 IBM Cloud 製品を使用する際の責任の分担、および災害復旧に関する FAQ をご覧ください。 および 災害復旧に関するFAQを 参照してください。
IBM、サービス・インスタンスをリストアできない場合は、 ディザスタ・リカバリ・アーキテクチャの 説明に従ってサービスをリストアする必要があります。
IBM サービスの維持方法
仮想サーバー、ホスト、データセンターで定期的なメンテナンスが行われる場合は、定期的なプロトコルに従う。 詳しくは、クラウドの保守操作についてを参照してください。
すべてのアップグレードは、リカバリプランとロールバックプロセスを含む、 IBM サービスのベストプラクティスに従います。 定期的なメンテナンスにより短時間の中断が発生する可能性があるが、 クライアントの可用性再試行ロジックにより 緩和される。 IBM は、不具合の最初の兆候でアップデートを元に戻します。
複雑な変更は、露出をコントロールする機能フラグで有効・無効にする。
顧客のワークロードに影響を与える変更は、 IBM Cloud 通知で詳述される。 このサービスに影響する計画的なメンテナンス、アナウンスメント、リリースノートの詳細については、 通知とステータスの監視を 参照してください。