高可用性アーキテクチャ

Red Hat OpenShift on IBM Cloud アーキテクチャは、地域、ゾーン、クラスタの各レベルで高い可用性を実現します。

使用可能な地域

すべてのリージョンに、そのリージョンに固有の API エンドポイントからアクセスできる高可用性ロード・バランサーがセットアップされています。 このロード・バランサーが、着信要求と発信要求を、そのリージョンの各ゾーンにある複数のクラスターにルーティングします。 あるリージョン全体で障害が発生する可能性はごくわずかです。 それでも、このような障害に備えるには、複数のクラスターを別々のリージョンにセットアップし、それらを外部ロード・バランサーを使用して接続します。 リージョン全体に障害が発生した場合、他のリージョンのクラスタがワークロードを引き継ぐことができる。

クラスタとゾーンの可用性

ゾーンの障害は、すべての物理コンピュート・ホストおよび NFS ストレージに影響します。 この障害には、電力、冷却、ネットワーキング、ストレージの故障と自然災害 (洪水、地震、ハリケーンなど) が含まれます。 ゾーンの障害から保護するには、2 つの異なるゾーンにクラスターを作成し、それらを外部ロード・バランサーでロード・バランシングする必要があります。 マルチゾーンにクラスタを作成し、マスターをゾーンに分散させます。 または、別のゾーンに2つ目のクラスタをセットアップすることを検討してください。

マルチゾーン利用可能

マルチゾーンクラスタは、複数のワーカーノードとゾーンに負荷を分散し、ゾーンの故障に対する追加の保護機能を提供します。 ワーカーノードは、3つのレプリカが複数のゾーンにまたがって自動的に展開されます。 ゾーン全体がダウンした場合、お客様の作業負荷は他のゾーンのワーカーノードに割り当てられ、お客様のアプリケーションをダウンから保護します。

グローバル・ロード・バランシング

マスターの障害からアプリを保護するため、またはサポートされているマルチゾーン・リージョンの1つに常駐しなければならない古典的なクラスタのために、リージョン内の異なるゾーンに複数のクラスタを作成し、それらをグローバルなロードバランサで接続することができます。

高可用性を実現するためのリソースの分散。

アプリを複数のワーカー・ノード、ゾーン、クラスターに分散させると、ユーザーがダウン時間を経験する可能性が低くなります。 ロード・バランシングや負荷の分離などの組み込み機能により、ホスト、ネットワーク、アプリで想定される障害に対する回復力を強化できます。 クラスターのセットアップ方法を以下にまとめます。下に行くほど可用性が高くなります。 IBM Cloud のリソースが地理的ゾーンおよび地域にどのように分散されているかについての詳細は、 ロケーションに関するドキュメント をご覧ください。

単一ゾーン・クラスター

クラシックのみ

シングルゾーンクラスタは、同じゾーン内の個別の物理ホストに分散されたワーカーノードで構成されています。 このオプションは、マスター更新時などの特定の停止から保護し、管理もより簡単です。 しかし、ゾーン全体がサービス停止に陥った場合は、お客様のアプリケーションは保護されません。

マルチゾーンクラスタ

クラシック VPC

マルチゾーンクラスタでは、複数のゾーンにまたがる3つのレプリカとともに、ワーカーノードが自動的に展開されます。 ゾーン全体がダウンした場合、お客様の作業負荷は他のゾーンのワーカーノードに割り当てられ、お客様のアプリケーションをダウンから保護します。

ロードバランサーにリンクされた複数のクラスター

クラシック VPC

複数のクラスタを同一ゾーンまたは異なるゾーンに設定し、グローバルロードバランサー経由で接続することができます。 このオプションは、単一のゾーン地域でクラスタをプロビジョニングする必要があるものの、マルチゾーンの可用性のメリットも得たい場合に便利です。

高可用性機能

アプリケーションやサービスに高い可用性を提供するために利用できる機能を確認してください。

災害復旧機能

災害復旧の一般的な戦略は、 Portworx などのソリューションを使用して、データのストレージとバックアップを設定することです。

Kubernetes Service 以下の災害復旧機能をサポートしています

rclone や OADP など、 データのエクスポートに関する追加オプション を確認してください。

目標復旧時間（RTO）と目標復旧時点（RPO）

IBM® がどのように災害復旧を確実にしているか

IBM® 災害が発生した場合、 に対して特定の復旧措置を講じます。 Red Hat OpenShift on IBM Cloud

IBM がサービスを維持する方法

すべてのアップグレードは、 IBM のサービスにおけるベストプラクティスに従っており、リカバリ計画やロールバックプロセスも含まれています。 定期的なメンテナンスにより、短時間のサービス中断が発生する場合がありますが、 クライアントの可用性再試行ロジック により緩和されます。 変更は、地域ごとに、地域内のゾーンごとに順次展開されます。 IBM は、不具合が見つかった場合は、更新を元に戻します。

複雑な変更は、機能フラグによって有効化または無効化され、公開を制御します。

お客様側の作業負荷に影響する変更については、 IBM Cloud の通知に詳細が記載されています。 このサービスに影響するメンテナンスの予定、アナウンス、リリースノートに関する詳細については 、「通知とステータスの監視」 を参照してください。

高可用性とディザスタリカバリの責任

HAおよびDRのための計画を継続的にテストすることは、お客様の責任です。

ネットワーク接続の中断や、サービスが短時間利用できなくなる場合があります。 アプリケーションの高可用性を維持するために、アプリケーションのソースコードに クライアントの可用性再試行ロジック が含まれていることを確認することは、お客様の責任となります。

お客様のアプリケーションおよびサービスに適切なレベルの可用性を実現するために、クラスタを構成する責任はお客様にあります。 クラスターにセットアップする可用性のレベルは、IBM Cloud HA サービス・レベル・アグリーメントのご利用条件の実現可能なレベルに影響を与えます。 例えば、SLA の条件に基づいて HA の範囲を完全にカバーするには、合計 6 つ以上のワーカー・ノードを持つ複数ゾーン・クラスターをセットアップする必要があります。各ゾーンに 2 つのワーカー・ノードがあり、それらは 3 つのゾーンに均等に分散されます。

クラスターで実行されるワークロードおよびアプリケーション・データの復旧は、お客様の責任です。 災害復旧に関するお客様の責任の詳細については 、 IBM Cloud Kubernetes Service をご参照ください。

変更管理

変更管理には、アップグレード、構成変更、削除などのタスクが含まれる。 以下の点を念頭に置いて、作業負荷によるダウンタイムやデータ損失を減らしましょう。

• ユーザーおよびプロセスには、業務に必要な最小限の特権でIAMの役割と権限を付与することをお勧めします。 例えば、生産リソースを削除する機能を制限する。

• API、CLI、またはコンソールツールを使用して、オペレーティングシステムのパッチを含む提供されたワーカーノードのアップデートを適用したり、ワーカーノードの再起動、再ロード、または交換を要求したりします。

• API、CLI、またはコンソールツールを使用して、提供されたメジャーおよびマイナーの Kubernetes マスターアップデートと、メジャー、マイナー、および パッチのワーカーノードアップデートを 適用します。 問題やダウンタイムを防ぐため、各バージョンのアップデートに関する情報や要件を必ず確認してください。

• クラスタのワーカーノードが最新バージョンで動作していることを確認してください。 Ubuntu バージョンであることを確認してください。

• クラスタで実行するアドオンの リリーススケジュール を必ず確認してください。

アプリとサービスの展開における考慮事項

クラスタをどのように構成するかによって、アプリケーションやサービスの可用性のレベルが決まります。 セットアップ時に複数のワーカー・ノードとクラスターを分散させる範囲を広くすればするほど、各ユーザーがアプリのダウン時間を経験する可能性は低くなります。

アプリのセットアップ方法を以下にまとめます。下に行くほど可用性が高くなります。

1. 単一ノード上のレプリカセットによって管理される、 n+2 ポッドによるデプロイメント。
2. n+2 個のポッドをレプリカ・セットによって管理し、単一のゾーン・クラスター内の複数のノードに分散させる (アンチアフィニティー) デプロイメント。
3. n+2 個のポッドをレプリカ・セットによって管理し、複数のゾーンにまたがる複数ゾーン・クラスター内の複数のノードに分散させる (アンチアフィニティー) デプロイメント。

高可用性ワークロードの作成については、以下のドキュメントを参照してください。

• 可用性の高いデプロイメントの計画
• クラスタ高可用性戦略
• 使用におけるお客様の責任 IBM Cloud Kubernetes Service