Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

第6章 複数のデータセンターをまたぐクラスターのガイダンス

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 for Kubernetes (ACM) などのツールを使用してこれらのクラスターとデプロイメントを管理します。

一部の OpenShift Container Platform プラットフォームには、多くのデータセンターデプロイメントに対する特別なサポートがあります。詳細は、プラットフォーム固有の製品ドキュメントとリリースノートを確認してください。その他のプラットフォームは、ノード間のネットワーク接続の品質に応じて、データセンターをまたぐことができます。詳細は、etcd とパフォーマンスに影響を与える調整可能なパラメーター/条件について を参照してください。

多数のデータセンターをまたぐクラスターデプロイメントを実装する場合は、Red Hat OpenShift Container Platform の高可用性および推奨されるプラクティス に詳しく記載されているプラクティスを実装するように努める必要があります。マルチサイトデプロイメントの代替として、サイトごとに 1 つの OpenShift Container Platform クラスターをデプロイすることもできます。これは、ACM によって管理されます。

6.1. 複数をまたぐクラスターのデプロイメントに関する注意事項
リンクのコピー

このドキュメントで提供されるガイダンスは、複数のデータセンターをまたぐクラスターデプロイメントの一般的な側面に重点を置いています。覚えておくべき注意事項:

  • 複数のデータセンターをまたぐデプロイメントの設計に特別なサポート要件はありません。しかし、標準的なシングルサイトクラスターと比較すると、これらのクラスターには追加の考慮事項やサポート (問題の特定、修復、解決に要する時間) が必要となる固有の複雑さが伴います。
  • Kube API のレイテンシーが高い、またはトランザクションレートが低いクラスターでは、アプリケーションが適切に動作しないか、まったく動作しない可能性があります。
  • ストレージプロバイダーなどのレイヤード製品では、レイテンシー要件が低くなります。このような場合、レイテンシーの制限は、レイヤード製品でサポートされているアーキテクチャーによって決まります。

  • 障害シナリオはストレッチコントロールプレーンによって増幅され、その影響の受け方はデプロイメントによって異なります。このため、実稼働環境で複数のデータセンターをまたぐデプロイメントを使用する前に、組織は次のような中断時のクラスターの動作をテストして文書化する必要があります。

    • ネットワークパーティションが発生し、1 つ、2 つ、またはすべてのコントロールプレーンノードが分離された場合
    • コントロールプレーンノード間のトランスポートネットワーク上で MTU の不一致がある場合
    • Day 2 イベントとして、1 つ以上のコントロールプレーンノードに対するレイテンシーが持続的に急増した場合
    • ネットワークの輻輳、誤設定、QoS の欠如、中間ネットワークデバイスによるパケットエラーなどによりジッターに大きな変化が生じた場合
  • 多数のサイト、ネットワークインフラストラクチャー、ストレージインフラストラクチャー、またはその他のコンポーネントをまたいでデプロイされたクラスターには、その性質上、障害点の数が多くなります。ネットワークの中断や分割は特にこのようなクラスターにとって大きな脅威となり、ノードが相互の接続を失うリスクが生じます。このようなマルチサイトクラスターは、このような障害の可能性を考慮して設計する必要があります。マルチサイトクラスターをデプロイする組織は、障害シナリオを徹底的にテストし、クラスターがすべての障害点から保護されているか検討する必要があります。耐障害性のある高可用性クラスター設計の重要な側面を検討する場合は、Red Hat サポートにご相談ください。
  • 場合によっては、GEO 認識は、レイテンシーを最小限に抑えるために解決する必要がある要件または問題であるため、Global Service Load Balancing (GSLB) メソッドの適切な実装を利用できなければなりません。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat