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

第6章 データセンターにまたがるクラスターのガイダンス

Red Hat は、OpenShift Container Platform クラスターがデータセンター内にデプロイされるデプロイメントモデルを強く推奨しています。ただし、プロバイダーがデータセンター全体にまたがるデプロイメントモデルを使用できるシナリオも認識しています。本書では、多くのデータセンターにまたがるクラスターデプロイメントの使用を検討し、このようなデプロイメントのサポート性に影響を与える重要なメトリクスを説明します。このようなデプロイメントの設計は、製品が最適に機能し、適切な製品サポートサブスクリプションで最高品質のサポートを保証するために、これらのガイドラインに従う必要があります。

警告

多くのデータセンターにまたがるクラスターデプロイメントは、クラスターをロケーション全体で単一の障害ドメインとして拡張するため、障害復旧計画の代替とは見なすべきではありません。

多くのデータセンターにまたがるクラスターデプロイメントがあるクラスターは、標準の 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 について および パフォーマンスに影響を与える tunables/conditions を参照してください。

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

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