IBM Cloud Monitoring の高可用性と災害復旧について
高い可用性サービスまたは作業負荷が障害に耐え、事前に定義されたサービスレベルに従って処理能力を提供し続ける能力。 サービスについては、可用性はサービスレベル契約で定義されています。 可用性には、計画されたイベントと計画外のイベントの両方が含まれます。計画外のイベントには、メンテナンス、故障、災害などが含まれます。 （HA）とは、予期せぬ障害が発生しても、サービスが稼働し、アクセスし続ける能力のことである。 ディザスタリカバリサービスの中断などの稀な重大なインシデントや広範囲にわたる障害から、サービスや作業負荷が回復する能力。 これには、地域全体に影響を及ぼす物理的な災害、データベースの破損、作業負荷に寄与するサービスの損失などが含まれます。 その影響は、高可用性設計の処理能力を超えている。とは、サービスインスタンスを稼動状態に回復させるプロセスである。
IBM Cloud® Monitoring は、アプリケーション、プラットフォーム・リソース、およびインフラストラクチャーをモニターするための、高可用性でマルチテナントのリージョン別サービスです。 このトピックでは、 IBM Cloud Monitoringの可用性と災害復旧の戦略について詳しく説明します。
アベイラビリティー・ゾーン
アベイラビリティー・ゾーンとは、1 つの IBM Cloud リージョン内で論理的かつ物理的に分離された場所のことであり、データが処理され、ホストされる場所です。
- アベイラビリティー・ゾーンをまたぐ単一障害点をなくして耐障害性を強化するために、ゾーンごとに、他のゾーンから切り離された電源、冷却装置、ネットワーク・インフラストラクチャーがあります。
- 同じリージョン内では、高帯域幅かつ低遅延のアベイラビリティー・ゾーン間通信を利用できます。
リージョン (ロケーション) とは、地理的および物理的に分けられたグループであり、各グループには 1 つ以上のアベイラビリティー・ゾーンが含まれます。リージョンごとに、他のリージョンから切り離された電気インフラストラクチャーとネットワーク・インフラストラクチャーがあります。
- リージョンは、他のリージョンとの単一障害点の共有をなくし、かつ、リージョン内での低遅延のゾーン間通信が保証されるように設計されています。
- 冗長化のために、リージョンごとに 3 つの異なるデータ・センター (DC) があります。
以下の表に、IBM Cloud Monitoring サービスを提供しているリージョン (ロケーション) の高可用性 (HA) 状況をリストします。
| 地域 | リージョン | HA 状況 |
|---|---|---|
Asia Pacific |
Sydney (au-syd) |
MZR |
Asia Pacific |
Tokyo (jp-tok) |
MZR |
Asia Pacific |
Osaka (jp-osa) |
MZR |
Europe |
Frankfurt (eu-de) |
MZR |
Europe |
London (eu-gb) |
MZR |
Europe |
Madrid (eu-es) |
MZR |
North America |
Dallas (us-south) |
MZR |
North America |
Washington (us-east) |
MZR |
North America |
Toronto (ca-tor) |
MZR |
South America |
São-Paulo (br-sao) |
MZR |
説明
-
ジオグラフィーとは、1 つ以上のリージョンを持つ地理的領域または広域の国家の集合体を指します。
-
リージョンとは、定義された地理的な領域です。
リージョンとなり得るのは、特定の郵便番号区域、町、市、州、州のグループ、さらには国のグループです。
ローカル・アクセス、低遅延、およびリージョンに応じたセキュリティー要件を満たせるように、リージョンごとに複数のアベイラビリティー・ゾーンがあります。
-
N/Aは、そのジオグラフィーでは適用外の機能であることを示しています。 -
MZRは、マルチゾーン・リージョンを意味します。 詳細はこちら。
モニタリング・インスタンスの可用性
モニタリング・インスタンスをプロビジョンするときに、インスタンスを作成する MZR (ロケーション) を選択します。 そのリージョンによって、モニター・データが処理され、データがホストされる場所が決まります。
1 つのマルチゾーン・リージョン (MZR) は 3 つ以上のアベイラビリティー・ゾーンで構成されます。各ゾーンは互いから独立しているので、1 つの障害イベントは 1 つのゾーンにしか影響を与えないようになっています。
デフォルトでは、各モニタリング・インスタンスは、3 つのゾーン (1 次ゾーン 1 つと 2 次ゾーン 2 つ) で構成されます。
- 各ゾーンは、該当するリージョンの別々のデータ・センターに置かれます。
- 1 次ゾーンのデータは、自動的に 2 次ゾーンに低遅延で複製されます。 ユーザーは、複製を使用可能にするために何もする必要はありません。
- 1 次ゾーンに障害が発生すると、サービス・インスタンスが影響を受けないように、2 次ゾーンの 1 つが 1 次ゾーンとして選択されます。
- 2 つのゾーンで同時に障害が発生すると、サービスは停止します。
MZR アーキテクチャーは、1 つのリージョンの中で、モニタリング・インスタンスの 2 ゾーン間の自動フェイルオーバーと高可用性を実現します。
1 リージョンでのモニタリング・サービスの災害復旧 (DR)
災害復旧とは、単一ロケーションでの壊滅的な障害または可用性の消失が発生しても存続できるよう対処することに関する内容です。
IBM Cloud Monitoring IBM Cloud の要件に従い 、 は高い可用性と冗長性を確保しています IBM Cloud。
地域的な災害が発生した場合は、以下の情報を考慮してください。
- リージョン・サイトを再構築して別のロケーションでサービスを復元するためにかかる推定復旧時間は 24 時間です。
- お客様が、新しいロケーションの取り込みエンドポイントを指すように、アプリケーションとモニタリング・エージェントのエンドポイントを更新する必要があります。
- お客様が、バックアップから、サービス・インスタンスのメタデータ (ダッシュボードとアラートの定義) を復元する必要があります。
災害時に履歴データが失われる可能性があります。 監査の目的で履歴メトリックが必要な場合は、サービスで照会したメトリックをリモート・バックアップ・サイトに保管することで、メトリックを定期的にバックアップしてください。 詳しくは、 API を使用した Monitoring インスタンスからのメトリックの抽出 を参照してください。
手動によるサービスの復旧
地域的な災害が発生した場合、サービスの復旧時間はそのリージョンの復旧時間に左右されます。 サービスのダウン時間とビジネスへの影響を最小限に抑えるために、リージョンの復元中に、お客様が手動でフェイルオーバーを実施して別のリージョンに切り替えることもできます。 新しいロケーションで稼働するまでにかかる時間を短縮するために、サービスの操作権限をアクセス・グループを使用して管理することを検討してください。また、各インスタンスのモニター・メタデータをバックアップしてください。 アラート、通知、ダッシュボード、およびチーム定義を定期的にバックアップする必要があります。
DR サイトの再構築中に稼働を継続する方法
モニタリング・インスタンスでモニターしているアプリケーションとサービスがすべて同じリージョンにある場合は、そのリージョンが再びビジネスに使用できる状態になるまで待つ必要があります。
モニタリング・エージェントを既にデプロイしたシステムがあり、それらのシステムが地域的な障害の影響を受けていない場合は、別のリージョンにある他のモニタリング・インスタンスにメトリックをリダイレクトすることもできます。 メトリック・データをリダイレクトするには、以下の手順を実行します。
-
各システムのモニタリング・エージェントを再構成します。エージェント構成内のアクセス・キーと取り込みエンドポイントを変更します。
-
新しいモニタリング・インスタンスを操作するための IAM 権限を定義します。
モニタリング・インスタンスの操作権限の管理にアクセス・グループを使用すると、新しいインスタンスを操作するために適切なポリシーとユーザーを設定する作業の量を削減できます。 アクセス・グループに関する情報は、リージョン別ではなく、グローバルな情報です。
-
モニタリング・インスタンスを起動し、アラート、通知、チーム、およびダッシュボードをインポートして、アプリケーションとシステムをモニターします。
DR 復旧時間
DR 状態が発生した場合の推定復旧時間を以下の表にまとめます。
| DR の復旧目標 | 推定時間 |
|---|---|
| 最大許容ダウン時間 (MTD) / 目標復旧時間 (RTO) | 最大 24 時間 |
| 目標復旧目標 (RPO) | 最大 24 時間 |