第7章 複数のデータセンターをまたぐクラスターのガイダンス
データセンターにまたがる OpenShift Container Platform クラスターの考慮事項とメトリクスを評価し、サポート対象の耐障害性に優れたマルチサイトデプロイメントを設計できるようにします。
Red Hat は、OpenShift Container Platform クラスターを 1 つのデータセンター内にデプロイするデプロイメントモデルを強く推奨していますが、クラスターを複数のデータセンターにまたがってデプロイするデプロイメントモデルをプロバイダーが使用できるシナリオがあることも認識しています。このガイダンスでは、多数のデータセンターにまたがるクラスターデプロイメントの使用を検討する際の考慮事項について概要を説明し、そのようなデプロイメントのサポート可能性に影響する重要なメトリクスについて説明します。そのようなデプロイメントの設計においては、製品が最適に機能し、適切な製品サポートサブスクリプションによる最高品質のサポートを確保するために、このガイドラインに準拠する必要があります。
多くのデータセンターにまたがるクラスターデプロイメントでは、クラスターが複数の場所をまたいで単一障害ドメインとして拡張されるため、障害復旧計画の代わりとはみなされません。
多くのデータセンターにまたがるクラスターは、標準の Red Hat OpenShift Container Platform サポートガイダンスに従います。詳細は、「Red Hat OpenShift Container Platform ライフサイクル」および「Red Hat 製品サポートの対象範囲」を参照してください。
多数のサイトにまたがる OpenShift Container Platform クラスターをデプロイしないでください。多数のデータセンターまたはリージョンにまたがる必要がある場合は、リージョンまたはサイトごとに 1 つのクラスターをデプロイし、Red Hat Advanced Cluster Management などのツールを使用してこれらのクラスターとデプロイメントを管理します。
一部の OpenShift Container Platform プラットフォームには、多くのデータセンターデプロイメントに対するサポートがあります。詳細は、プラットフォーム固有の製品ドキュメントとリリースノートを確認してください。その他のプラットフォームは、ノード間のネットワーク接続の品質に応じて、データセンターをまたぐことができます。詳細は、「etcd の信頼性の高いパフォーマンスとスケーラビリティーの確保」を参照してください。
多数のデータセンターにまたがるクラスターデプロイメントを実装する場合は、「Red Hat の高可用性と推奨プラクティス」の手順を実行してください。マルチサイトデプロイメントの代替として、サイトごとに 1 つの OpenShift Container Platform クラスターをデプロイすることもできます。これは、Red Hat Advanced Cluster Management によって管理されます。
7.1. 複数をまたぐクラスターのデプロイメントに関する注意事項 リンクのコピーリンクがクリップボードにコピーされました!
データセンターにまたがるクラスターデプロイメントの一般的な側面に関するガイダンスを確認します。
覚えておくべき注意事項:
- 複数のデータセンターをまたぐデプロイメントの設計に特別なサポート要件はありません。しかし、標準的なシングルサイトクラスターと比較すると、これらのクラスターには追加の考慮事項やサポート (問題の特定、修復、解決に要する時間) が必要となる固有の複雑さが伴います。
- Kube API のレイテンシーが高い、またはトランザクションレートが低いクラスターでは、アプリケーションが適切に動作しないか、まったく動作しない可能性があります。
- ストレージプロバイダーなどのレイヤード製品では、レイテンシー要件が低くなります。このような場合、レイテンシーの制限は、レイヤード製品でサポートされているアーキテクチャーによって決まります。
障害シナリオはストレッチコントロールプレーンによって増幅され、その影響の受け方はデプロイメントによって異なります。このため、実稼働環境で複数のデータセンターをまたぐデプロイメントを使用する前に、組織は次のような中断時のクラスターの動作をテストして文書化する必要があります。
- ネットワークパーティションが発生し、1 つ、2 つ、またはすべてのコントロールプレーンノードが分離された場合
- コントロールプレーンノード間のトランスポートネットワーク上で最大伝送ユニット (MTU) の不一致がある場合
- Day 2 イベントとして、1 つ以上のコントロールプレーンノードに対するレイテンシーが持続的に急増した場合
- ネットワークの輻輳、誤設定、QoS の欠如、中間ネットワークデバイスによるパケットエラーなどによりジッターに大きな変化が生じた場合
- 多数のサイト、ネットワークインフラストラクチャー、ストレージインフラストラクチャー、またはその他のコンポーネントをまたいでデプロイされたクラスターには、その性質上、障害点の数が多くなります。ネットワークの中断や分割は特にこのようなクラスターにとって大きな脅威となり、ノードが相互の接続を失うリスクが生じます。このようなマルチサイトクラスターは、このような障害の可能性を考慮して設計する必要があります。マルチサイトクラスターをデプロイする組織は、障害シナリオを徹底的にテストし、クラスターがすべての障害点から保護されているか検討する必要があります。耐障害性のある高可用性クラスター設計の重要な側面を検討する場合は、Red Hat サポートにご相談ください。
- 場合によっては、地理的 (GEO) 認識は、レイテンシーを最小限に抑えるために解決する必要がある要件または問題であるため、Global Service Load Balancing (GSLB) メソッドの適切な実装を利用できなければなりません。