Cluster Linking¶

Looking for Confluent Cloud Cluster Linking docs? You are currently viewing Confluent Platform documentation. If you are looking for Confluent Cloud docs, check out Cluster Linking on Confluent Cloud.

重要

この機能はプレビュー機能として利用できます。プレビュー機能とは、開発者から早い段階でフィードバックを受けるために提供している Confluent Platform のコンポーネントのことです。この機能は、評価用、本稼働環境以外でのテスト用、あるいは Confluent にフィードバックを提供するために使用できます。

Cluster Linking とは¶

Cluster Linking を使用すると、直接クラスター間を接続して、一方のクラスターから他方のクラスターにトピックをミラーリングできます。Connect は必要ありません。Cluster Linking により、マルチデータセンター、マルチクラスター、およびハイブリッドクラウドのデプロイをはるかに簡単に構築できるようになります。

Replicator および MirrorMaker2 とは異なり、Cluster Linking では Connect を実行せずに一方のクラスターから他方のクラスターにメッセージを移動できるため、クラスター間でオフセットが確実に保持されます。これを、"バイト単位" のレプリケーションと呼びます。送信元上のどのようなデータも、送信先クラスターに正確にミラーリングされます。

Cluster Linking と Built-in Multi-Region Replication を組み合わせることで、可用性と耐久性が高い分散型のグローバルイベントファブリックを構築できます。Built-in Multi-Region Replication は、一部のトピックで自動クライアントフェイルオーバー（低 RTO）または RPO=0 が必要な場合に使用します。Cluster Linking は、ネットワークの品質に問題がある、データセンター間が非常に離れている、または RTO 目標でクライアントの再構成を許容できる場合に使用します。

注釈

送信先クラスターは Confluent Server を実行している必要があり、送信元クラスターには Confluent Server または Apache Kafka® 2.4 以降を使用できます。Cluster Linking は、プレビュー機能として Confluent Platform 6.0.0 に導入されています。

機能と比較¶

Cluster Linking には以下の機能があります。

クラスター間でオフセットを保持するため、システムのフェイルオーバーと合理化がより簡単になります。
再圧縮を回避することでレプリケーションを高速化します。
データセンター間のデータ移動を減らすことでレプリケーションコストが削減され、大陸間クラスターの構築が可能になるため、専用の Built-in Multi-Region Replication ソリューションを低コストで補完できます。
Confluent Cloud の操作を簡素化および円滑化します。
ハイブリッドクラウドアーキテクチャ（ライトワンス、リードメニー）をサポートしています。Kafka と Cluster Linking を使用してインフラストラクチャ環境をブリッジすることで、モニタリング可能でセキュアな単一のシステムを構築できます。これにより、オンプレミスデプロイ、Confluent Cloud およびクラウドプロバイダーに対応するコスト効率に優れたトランスポートレイヤーが実現されます。
Cluster Linking と標準または Built-in Multi-Region Replication クラスターの組み合わせにより、Kafka のグローバルメッシュが実現します。距離が非常に遠く、ネットワーク許容値が異なる場合でも、目標復旧時間（RTO）と目標復旧時点（RPO）を大幅に短縮できます。
集約クラスターの基礎を構築できます。

サポート対象¶

送信元	送信先
Confluent Platform 5.4 以降	Confluent Platform 6.0.0 以降
Confluent Platform 5.4 以降	Confluent Cloud
Confluent Cloud	Confluent Platform 6.0.0 以降
Confluent Cloud	Confluent Cloud

Confluent Server が必要です。具体的には、送信元クラスターには Confluent Platform 5.4 以降（Apache Kafka® 2.4）、送信先クラスターには Confluent Platform 6.0.0 以降が必要です。
Confluent Platform 7.0.0 では、送信元クラスターと送信先クラスターの両方で、2.7 以上のブローカー間プロトコル（IBP）が必要です。Confluent Platform 6.1.x および 6.2.x では、2.7 の IBP をお勧めしますが必須ではありません。こうした以前のバージョンでも、2.4 以降の IBP は使用できます。下位の IBP からアップグレードする必要がある場合は、これをブローカーの inter.broker.protocol.version の値として設定できます。
すべてのクライアントで正常に動作します。
Ansible および Kubernetes 用の Confluent と互換性があります。詳細については、「Cluster Linking と Ansible の使用」と「Cluster Linking と Confluent for Kubernetes の使用」を参照してください。
認証と認可をサポートしています（「Cluster Linking のセキュリティ」を参照）。ただし、既知の制限がいくつかあります。
送信元クラスターには Kafka または Confluent Server を使用でき、送信先クラスターは Confluent Enterprise にバンドルされている Confluent Server である必要があります。
送信元クラスターが Confluent Server の場合、Confluent Platform 5.4 以降である必要があります。送信元クラスターが Kafka の場合、Apache Kafka® 2.4 以降である必要があります（前述のように、どちらの場合も、Confluent Platform 7.0.0 より前のデプロイでは 2.4 以降の IBP が、また、Confluent Platform デプロイ 7.0.0 以降では 2.7 以降の IBP が必須となります）。
Confluent Platform 上のセルフマネージド型デプロイに加え、Cluster Linking は Confluent Cloud およびハイブリッドクラウドアーキテクチャのマネージド型サービスとしても使用できます。

ユースケースとアーキテクチャ¶

以下のユースケースは、示されている構成とアーキテクチャによって実現できます。これらのデプロイのデモについては、「Cluster Linking のデモ（Docker）」と「チュートリアル: トピックデータ共有での Cluster Linking の使用」を参照してください。

クラスター移行¶

ユースケース : オンプレミス Kafka クラスターから Confluent Cloud Kafka クラスターに移行する、または古いバージョンから新しいバージョンに移行します。ブローカーの Confluent Server を活用することでネイティブオフセットが保持されるため、他の Connect ベースの方法より Cluster Linking を使用する方がはるかに簡単です。

ハイブリッドクラウドアーキテクチャ¶

ユースケース : 少数のトピック用に実行されているデータファネルをオンプレミス環境から Confluent Cloud にデプロイします。Cluster Linking は、これを適切にサポートするネットワーク分断耐性アーキテクチャを提供します（ネットワーク接続が瞬間的に失われても、特定のクラスター上のデータに大きな影響を与えません）。一方、ストレッチクラスターでこれを行おうとする場合は、信頼性が高く堅牢なネットワークが必要になります。

Cluster Linking におけるリスナーについて¶

フォワード接続では、どのリスナーが接続を受け付けるかはターゲットサーバーが把握しており、ターゲットサーバーによって、そのリスナーと接続とが関連付けられます。その接続にメタデータリクエストが到着すると、サーバーは、リスナーに対応するメタデータを返します。

たとえば Confluent Cloud で、外部リスナーのクライアントが topicA のリーダーを要求すると必ずリーダーの外部エンドポイントが返されます。クライアントに内部エンドポイントが返されることはありません。接続に基づいてリスナー名が認識されるためです。

リバース接続では、ターゲットサーバー（つまり、送信元クラスター）によって接続が確立されます。接続がリバースされた場合、そのリバース接続をどのリスナーに関連付けるか、たとえば、リーダーリクエストで送信先に返すべきエンドポイントをこのターゲットサーバーが把握している必要があります。

デフォルトでは、リンクが作成された送信元クラスターに基づいてリスナーが関連付けられます。使用される外部リスナーは通常 1 つであるため、ほとんどの場合、これで事足ります。Confluent Cloud では、このデフォルトが使用され、ユーザーがそれをオーバーライドすることはできません。

セルフマネージド型 Confluent Platform では、デフォルトのリスナー/接続の関連付けをユーザーが必要に応じてオーバーライドできます。こうして、内部リスナーに送信元リンクを作成しながらも、リバース接続に外部リスナーを関連付けるという柔軟性が実現されています。

local.listener.name 構成は、送信元クラスターのリスナー名を表します。デフォルトでは、送信元リンクの作成に使用されたリスナーになります。別のリスナーを使用する必要がある場合は、明示的にそれを構成する必要があります。Confluent Cloud が送信元である場合は、これが外部リスナー（デフォルト）となり、オーバーライドすることはできません。

送信先については、リスナーは、bootstrap.servers によって決定され、オーバーライドすることはできません。

既知の制限¶

Cluster Linking のプレビューを本稼働環境のユースケースに使用することは推奨されません。このプレビューでは一部の Kafka 機能がサポートされていません。
送信元クラスターは Confluent Platform 5.4 以降（Apache Kafka® 2.4）で、送信先クラスター Confluent Platform 6.0.0 以降である必要があります。
送信元のトピック名と送信先のミラートピック名は同じである必要があります。
リンクは一方向です。単一のリンクで双方向レプリケーションを実現するように構成することはできません。これには 2 つのリンクを使用する必要があります。
接続は送信先クラスターからのみ確立されます。送信元クラスターは送信先ブローカーからのインバウンド接続リクエストを受け付けるように構成されている必要があります。これにより、一部のセキュリティモデルに対応できます（すべてではありません）。
すべての SSL キーストア、トラストストア、および Kerberos キータブファイルは、特定のクラスター内の各ブローカー上の同じ場所に格納されている必要があります。そのように格納されていないと、クラスターリンクが失敗する場合があります。
これまで Confluent Platform 6.0.0 から 6.2.x で使用できた ACL 移行（ACL 同期）は、セキュリティ上の脆弱性があるため削除されました。デプロイで ACL 移行を使用している場合は、無効にする必要があります。詳細については、「認可（ACL）」を参照してください。