1. Home
  2. Cloud
  3. Cluster Linking

重要

このページの日本語コンテンツは古くなっている可能性があります。最新の英語版コンテンツをご覧になるには、こちらをクリックしてください。

Cluster Linking の構成、コマンド、管理

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

You can create, view, manage, and delete cluster links using the unified Confluent CLI and the Confluent Cloud Cluster Linking (v3) REST API.

送信元クラスターから送信先クラスターへの ACL の同期

Cluster Linking は、送信元クラスターの一部または全部の ACL を送信先クラスターに同期できます。これはディザスターリカバリ（DR）アーキテクチャにとって重要です。クライアントアプリケーションが DR クラスターにフェイルオーバーするときに、元のクラスターで持っていたアクセス権限と同じアクセス権限を持つことになるからです。クラスターリンクを作成するときは、同期する ACL をリソース名、プリンシパル（サービスアカウント）、運用および/またはアクセス許可で絞り込んで指定できます。この設定はクラスターリンクでいつでも更新できます。一致する ACL の初期セットはクラスターリンクによりコピーされ、一致する ACL に変更や追加、削除があった場合は送信元クラスターから送信先クラスターに継続的に同期されます。

ちなみに

また、コンシューマーグループオフセットをソースから送信先クラスターに移行する こともできます。

前提条件

適切な認可を持っている必要があります。

  • 送信元クラスターに対する DESCRIBE Cluster ACL（DescribeAcls API）
  • 送信先クラスターに対する ALTER Cluster ACL（CreateAcls/DeleteAcls API）

ACL 同期の構成

クラスターリンクで ACL 同期を有効にするには、次のプロパティを指定します。

acl.sync.enable=true

これにより、ACL 同期が有効になります。この構成を false に更新すると、ACL 同期が無効になります。

これを設定して Cluster Linking を実行し、その後で無効にすると、フィルターがクラスターリンクからクリア（削除）されます。

acl.filters
1 つのプロパティ aclFilters を持つ JSON オブジェクト。同期する特定の ACL を含めるためのフィルターの配列が含まれます。以下に例を示します。
acl.sync.ms（省略可）
ACL を同期する頻度。デフォルトは 5000（5 秒）です。最小値は 1000 です。

ACL は、クラスターリンクを作成するときか、または既存の構成のアップデートとして構成できます。

以下に、クラスターリンクを作成するときに ACL 移行とともにクラスターリンクをセットアップする例を示します。リンク構成（ACL 移行プロパティを含む）は直接、コマンドラインで指定するのではなく、link-configs.properties ファイルに定義されます。

confluent kafka link create from-aws-basic \
    --source-cluster-id lkc-12345 \
    --source-bootstrap-server SASL_SSL://pkc-abcde.us-west1.gcp.confluent.cloud:9092 \
    --source-api-key 1L1NK2RUL3TH3M4LL \
    --source-api-secret ******* \
    --config-file link-configs.properties

以下に、link-configs.properties の内容の例を示します。

acl.sync.enable=true
acl.sync.ms=1000
acl.filters={ "aclFilters": [ { "resourceFilter": { "resourceType": "any", "patternType": "any" }, "accessFilter": { "operation": "any", "permissionType": "any" } } ] }

以下のセクションでは、実際の ACL を acls.filters に定義する方法の例を示します。

サンプル

以下の例では、さまざまなタイプの ACL 移行（トピックやリソースを対象とした移行、および混在する ACL の移行）用の JSON を構成する方法を示します。

すべての ACL を送信元から送信先クラスターに移行

すべての ACL を送信元クラスターから送信先クラスターに移行するには、acl.filters に以下を指定します。

acl.filters={                   \
  "aclFilters": [               \
    {                           \
      "resourceFilter": {       \
        "resourceType": "any",  \
        "patternType": "any"    \
      },                        \
      "accessFilter": {         \
        "operation": "any",     \
        "permissionType": "any" \
      }                         \
    }                           \
  ]                             \
}

JSON の各フィールドには、以下のオプションがあります。

  • resourceType: ANY （任意の種類のリソース）または topic、cluster、group、または transactionalID （Confluent Cloud のアクセス制御リスト（ACL）の使用 に指定されるリソース）。
  • patternType: ANY、LITERAL、PREFIXED、または MATCH のいずれか。
  • name: リソースの名前。
    • 空白のままにした場合、デフォルトとしてワイルドカード * が使用されます。これは、指定された resourceType のすべての名前と一致することを意味します。
    • patternType が "LITERAL" の場合、この名前と完全に一致するすべてのリソースが含められます。
    • patternType が "PREFIXED" の場合、この名前をプレフィックスとして持つすべてのリソースが含められます。
    • patternType が "MATCH" の場合、指定されたパターンと一致するすべてのリソースが含められます。たとえば、同じ名前とタイプのリテラル、ワイルドカード（*）、またはプレフィックスの付いたパターンです。
  • principal:（省略可）ACL に指定されたプリンシパルの名前。空白のままにした場合、デフォルトとしてワイルドカード * が使用されます。これは、指定された operation と permissionType を持つすべてのプリンシパルと一致することを意味します。
    • たとえば、ID 12345 のサービスアカウントのプリンシパルは User:sa-12345 です。
  • operation: any、または Operations の "Operation" 列に指定されている値のいずれか 1 つ。
  • permissionType: any、allow、または deny のどちらか

トピックに固有なすべての ACL の同期

1 つのトピック（この場合、トピック pineapple）に固有のすべての ACL を同期するには、acl.filters を以下のように構成します。

acl.filters={                     \
  "aclFilters": [                 \
    {                             \
      "resourceFilter": {         \
        "resourceType": "topic",  \
        "patternType": "literal", \
        "name": "pineapple”       \
      },                          \
      "accessFilter": {           \
        "operation": "any",       \
        "permissionType": "any"   \
      }                           \
    }                             \
   ]                              \
 }

プリンシパルまたは権限に固有のすべての ACL の同期

ID が 12345 のサービスアカウントに固有なすべての ACL と、クラスターへのアクセスを拒否するすべての ACL を同期するには、acls.filters に以下の構成を指定します。

acl.filters={                         \
  "aclFilters": [                     \
    {                                 \
      "resourceFilter": {             \
        "resourceType": "any",        \
        "patternType": "any"          \
      },                              \
      "accessFilter": {               \
        “principal”: “User:sa-12345”, \
        "operation": "any",           \
        "permissionType": "any"       \
      }                               \
    },                                \
    {                                 \
      "resourceFilter": {             \
        "resourceType": "any",        \
        "patternType": "any"          \
      },                              \
      "accessFilter": {               \
        "operation": "any",           \
        "permissionType": "deny"      \
      }                               \
     }                                \
   ]                                  \
 }

セキュリティ認証情報の構成

クラスターリンクを作成する際は、送信元クラスターへの認証に使用する認証情報をクラスターリンクに与える必要があります。必要な ACL を含め、Cluster Linking のセキュリティ要件について詳しくは、Cluster Linking のセキュリティの概要を参照 してください。

Confluent Cloud 送信元クラスターに対するセキュリティ認証情報の構成

送信元クラスターが Confluent Cloud クラスターである場合、クラスターリンクのプロパティが次のように構成されている必要があります。

  • security.protocol が SASL_SSL に設定されていること
  • sasl.mechanism が PLAIN に設定されていること
  • sasl.jaas.config が org.apache.kafka.common.security.plain.PlainLoginModule required username="<source-api-key>" password="<source-api-secret>"; に設定されていること
    • <source-api-key> と <source-api-secret> は、送信元クラスターで使用する API キーに置き換えてください。
    • " 文字と末尾の ; を忘れずに入力してください。

Confluent Platform と Kafka の送信元クラスターに対するセキュリティ認証情報の構成

Since cluster links consume from the source cluster using the same mechanism as a regular Kafka consumer, the cluster link's authentication configuration is identical to the one needed by Kafka consumers.

注釈

For Confluent Cloud cluster links, if your source cluster uses SSL (also known as TLS) and you need to pass a keystore and truststore; you must do so in-line, rather than with a keystore and truststore location. To learn more, see the security section on Mutual TLS (mTLS).

Confluent 送信先クラスターへのクラスターリンクでは、次のプロパティがサポートされます。

  • sasl.client.callback.handler.class
  • sasl.jaas.config
  • sasl.kerberos.kinit.cmd
  • sasl.kerberos.min.time.before.relogin
  • sasl.kerberos.service.name
  • sasl.kerberos.ticket.renew.jitter
  • sasl.kerberos.ticket.renew.window.factor
  • sasl.login.callback.handler.class
  • sasl.login.class
  • sasl.login.refresh.buffer.seconds
  • sasl.login.refresh.min.period.seconds
  • sasl.login.refresh.window.factor
  • sasl.login.refresh.window.jitter
  • sasl.mechanism
  • security.protocol
  • ssl.cipher.suites
  • ssl.enabled.protocols
  • ssl.endpoint.identification.algorithm
  • ssl.engine.factory.class
  • ssl.key.password
  • ssl.keymanager.algorithm
  • ssl.keystore.location
  • ssl.keystore.password
  • ssl.keystore.type
  • ssl.keystore.certificate.chain
  • ssl.protocol
  • ssl.provider
  • ssl.truststore.certificates