マルチリージョン デプロイ

Version 1.13 (latest)

サポート対象のバージョン:

• v1.13（最新）
• v1.12
• v1.11
• サポート対象バージョンのリスト

サポートされていないバージョン:

• v1.10
• v1.9
• v1.8
• v1.7
• v1.6
• v1.5
• v1.4
• v1.3
• v1.2
• v1.1

このトピックでは、GKE 上の Apigee ハイブリッド、オンプレミスにデプロイされた Anthos GKE、Microsoft® Azure Kubernetes Service（AKS）、Amazon Elastic Kubernetes Service（EKS）、および RedHat OpenShift のマルチリージョン デプロイについて説明します。前提条件と手順では、ご使用のプラットフォームを選択してください。

マルチリージョン デプロイのトポロジには次のものがあります。

• アクティブ - アクティブ: 複数の地理的ロケーションにアプリケーションをデプロイし、それらのデプロイで API レスポンスのレイテンシを低く抑える必要がある場合。クライアントに最も近い複数の地理的ロケーションにハイブリッドをデプロイすることもできます。例: 米国西海岸、米国東海岸、ヨーロッパ、APAC。
• アクティブ - パッシブ: プライマリ リージョンとフェイルオーバー リージョンまたは障害復旧リージョンがある場合。

次の図に示すように、マルチリージョン ハイブリッド デプロイのリージョンは Cassandra を介して通信します。

前提条件

複数リージョンにハイブリッドを構成する前に、次の前提条件を満たす必要があります。

GKE

• 異なるネットワーク（異なるクラウド プロバイダ、異なる VPC ネットワーク、クラウドとオンプレミスなど）間でマルチリージョンの Apigee デプロイをインストールする場合は、Cassandra がノード間の通信に使用できるようにネットワーク間の内部接続を提供する必要があります。これは、VPN またはクラウド固有の接続ソリューションで実現できます。
• 1 つのクラスタで Workload Identity を使用してサービス アカウントを認証している場合は、拡張するクラスタごとに Workload Identity を使用することを強くおすすめします。GKE で Workload Identity を有効にするまたは AKS と EKS で Workload Identity 連携を有効にするをご覧ください。
• 異なる CIDR ブロックを持つ複数のリージョンに Kubernetes クラスタを設定します。
• 各クラスタに cert-manager がインストールされていることを確認します。
• リージョン間通信を設定します。
• すべての Cassandra Pod が自身のホスト名を解決できることを確認します。hostNetwork が false に設定されている場合、ホスト名は Cassandra Pod の名前です。hostNetwork が true に設定されている場合、ホスト名は Cassandra Pod を実行している Kubernetes ノードのホスト名になります。
  ヒント: ホスト名の解決が機能しているかどうかを確認するには、次のコマンドを使用します。
  
  hostNetwork が false に設定されている場合は、コマンド 1 を使用します。hostNetwork が true に設定されている場合は、コマンド 2 を使用します。
  
  ホスト名の解決が機能している場合は、出力に IP アドレスが表示されます。ホスト名の解決に失敗した場合、出力には「Host not found」が含まれます。
  
  コマンド 1:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i

  
  コマンド 2:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i

• Cassandra マルチリージョンの要件:
  • Pod ネットワークの Namespace が、ファイアウォール、VPN、VPC ピアリング、vNet ピアリングなどのリージョン間で接続されていることを確認します。この処理は、ほとんどの GKE インストールについて実施する必要があります。
  • Pod ネットワークの Namespace がクラスタ間の接続を持たない場合（クラスタがアイランド ネットワーク モードで実行されている場合）、オーバーライド ファイルで cassandra.hostNetwork: true を設定することで、Apigee ハイブリッド マルチリージョン インストールの全リージョンで Kubernetes の hostNetwork 機能を有効にします。

    hostNetwork の必要性について詳しくは、以下のアイランド モードのクラスタと hostNetwork をご覧ください。

  • マルチリージョン構成を新しいリージョンに拡張する前に、既存のクラスタで hostNetwork を有効にします。
  • hostNetwork が有効になっている場合は、ワーカーノードがホスト名のフォワード DNS ルックアップを実行できることを確認してください。Apigee Cassandra は、起動時にフォワード DNS ルックアップを使用してホスト IP を取得します。
    ヒント: DNS 解決が機能しない場合は、以下の回避策をお試しください。

    各 Cassandra ワーカーノードの /etc/hosts ファイルに次のような静的ホストエントリを追加します。

    echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"

    または

    "\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"

  • すべてのリージョンの Kubernetes クラスタ間で TCP ポート 7001 を開き、リージョン間とデータセンター間でワーカーノードが通信できるようにします。Cassandra のポート番号については、ポートの構成をご覧ください。

詳細については、Kubernetes のドキュメントをご覧ください。

注: サーバーの時刻を同期させることをおすすめします。

有効期限やトークンの取り消しなどの機能では、正確なシステム時刻が必要になります。異なるデータセンターでランタイム コンポーネントをホストする場合、システム時刻が同期されていることを確認してください。

ntpdate などのツールを使用すると、サーバー時刻が同期されていることを確認できます。

GKE On-Prem

• 異なるネットワーク（異なるクラウド プロバイダ、異なる VPC ネットワーク、クラウドとオンプレミスなど）間でマルチリージョンの Apigee デプロイをインストールする場合は、Cassandra がノード間の通信に使用できるようにネットワーク間の内部接続を提供する必要があります。これは、VPN またはクラウド固有の接続ソリューションで実現できます。
• 異なる CIDR ブロックを持つ複数のリージョンに Kubernetes クラスタを設定します。
• 各クラスタに cert-manager がインストールされていることを確認します。
• リージョン間通信を設定します。
• すべての Cassandra Pod が自身のホスト名を解決できることを確認します。hostNetwork が false に設定されている場合、ホスト名は Cassandra Pod の名前です。hostNetwork が true に設定されている場合、ホスト名は Cassandra Pod を実行している Kubernetes ノードのホスト名になります。
  ヒント: ホスト名の解決が機能しているかどうかを確認するには、次のコマンドを使用します。
  
  hostNetwork が false に設定されている場合は、コマンド 1 を使用します。hostNetwork が true に設定されている場合は、コマンド 2 を使用します。
  
  ホスト名の解決が機能している場合は、出力に IP アドレスが表示されます。ホスト名の解決に失敗した場合、出力には「Host not found」が含まれます。
  
  コマンド 1:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i

  
  コマンド 2:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i

• Cassandra マルチリージョンの要件:
  • Pod ネットワークの Namespace が異なるクラスタ内のクラスタ間で接続できない場合（クラスタが GKE On-Prem のインストールにおいてアイランド ネットワーク モードで実行されている場合など）は、オーバーライド ファイルで cassandra.hostNetwork: true を設定することで、Apigee ハイブリッド マルチリージョン インストールの全リージョンで Kubernetes の hostNetwork 機能を有効にします。

    hostNetwork の必要性について詳しくは、以下のアイランド モードのクラスタと hostNetwork をご覧ください。

  • マルチリージョン構成を新しいリージョンに拡張する前に、既存のクラスタで hostNetwork を有効にします。
  • hostNetwork が有効になっている場合は、ワーカーノードがホスト名のフォワード DNS ルックアップを実行できることを確認してください。Apigee Cassandra は、起動時にフォワード DNS ルックアップを使用してホスト IP を取得します。
    ヒント: DNS 解決が機能しない場合は、以下の回避策をお試しください。

    各 Cassandra ワーカーノードの /etc/hosts ファイルに次のような静的ホストエントリを追加します。

    echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"

    または

    "\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"

  • すべてのリージョンの Kubernetes クラスタ間で Cassandra ポートを開き、リージョン間とデータセンター間でワーカーノードが通信できるようにします。Cassandra のポート番号については、ポートの構成をご覧ください。

詳細については、Kubernetes のドキュメントをご覧ください。

注: サーバーの時刻を同期させることをおすすめします。

有効期限やトークンの取り消しなどの機能では、正確なシステム時刻が必要になります。異なるデータセンターでランタイム コンポーネントをホストする場合、システム時刻が同期されていることを確認してください。

ntpdate などのツールを使用すると、サーバー時刻が同期されていることを確認できます。

AKS

• 異なるネットワーク（異なるクラウド プロバイダ、異なる VPC ネットワーク、クラウドとオンプレミスなど）間でマルチリージョンの Apigee デプロイをインストールする場合は、Cassandra がノード間の通信に使用できるようにネットワーク間の内部接続を提供する必要があります。これは、VPN またはクラウド固有の接続ソリューションで実現できます。
• クラスタの設定手順に進む前に、Google Cloud や組織の構成などの前提条件について、ハイブリッド インストール ガイドに従ってください。
• 各クラスタに cert-manager がインストールされていることを確認します。
• すべての Cassandra Pod が自身のホスト名を解決できることを確認します。hostNetwork が false に設定されている場合、ホスト名は Cassandra Pod の名前です。hostNetwork が true に設定されている場合、ホスト名は Cassandra Pod を実行している Kubernetes ノードのホスト名になります。
  ヒント: ホスト名の解決が機能しているかどうかを確認するには、次のコマンドを使用します。
  
  hostNetwork が false に設定されている場合は、コマンド 1 を使用します。hostNetwork が true に設定されている場合は、コマンド 2 を使用します。
  
  ホスト名の解決が機能している場合は、出力に IP アドレスが表示されます。ホスト名の解決に失敗した場合、出力には「Host not found」が含まれます。
  
  コマンド 1:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i

  
  コマンド 2:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i

• Cassandra マルチリージョンの要件:
  • Pod ネットワークの Namespace がクラスタ間の接続を持たない場合（AKS インストールのデフォルトの場合、クラスタはアイランド ネットワーク モードで稼働します）、オーバーライド ファイルで cassandra.hostNetwork: true を設定することで、Apigee ハイブリッド マルチリージョン インストールの全リージョンで Kubernetes の hostNetwork 機能を有効にします。

    hostNetwork の必要性について詳しくは、以下のアイランド モードのクラスタと hostNetwork をご覧ください。

  • マルチリージョン構成を新しいリージョンに拡張する前に、既存のクラスタで hostNetwork を有効にします。
  • hostNetwork が有効になっている場合は、ワーカーノードがホスト名のフォワード DNS ルックアップを実行できることを確認してください。Apigee Cassandra は、起動時にフォワード DNS ルックアップを使用してホスト IP を取得します。
    ヒント: DNS 解決が機能しない場合は、以下の回避策をお試しください。

    各 Cassandra ワーカーノードの /etc/hosts ファイルに次のような静的ホストエントリを追加します。

    echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"

    または

    "\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"

  • すべてのリージョンの Kubernetes クラスタ間で Cassandra ポートを開き、リージョン間とデータセンター間でワーカーノードが通信できるようにします。Cassandra のポート番号については、ポートの構成をご覧ください。

詳細については、Kubernetes のドキュメントをご覧ください。

注: サーバーの時刻を同期させることをおすすめします。

有効期限やトークンの取り消しなどの機能では、正確なシステム時刻が必要になります。異なるデータセンターでランタイム コンポーネントをホストする場合、システム時刻が同期されていることを確認してください。

ntpdate などのツールを使用すると、サーバー時刻が同期されていることを確認できます。

EKS

• 異なるネットワーク（異なるクラウド プロバイダ、異なる VPC ネットワーク、クラウドとオンプレミスなど）間でマルチリージョンの Apigee デプロイをインストールする場合は、Cassandra がノード間の通信に使用できるようにネットワーク間の内部接続を提供する必要があります。これは、VPN またはクラウド固有の接続ソリューションで実現できます。
• クラスタの設定手順に進む前に、Google Cloud や組織の構成などの前提条件について、ハイブリッド インストール ガイドに従ってください。
• 各クラスタに cert-manager がインストールされていることを確認します。
• すべての Cassandra Pod が自身のホスト名を解決できることを確認します。hostNetwork が false に設定されている場合、ホスト名は Cassandra Pod の名前です。hostNetwork が true に設定されている場合、ホスト名は Cassandra Pod を実行している Kubernetes ノードのホスト名になります。
  ヒント: ホスト名の解決が機能しているかどうかを確認するには、次のコマンドを使用します。
  
  hostNetwork が false に設定されている場合は、コマンド 1 を使用します。hostNetwork が true に設定されている場合は、コマンド 2 を使用します。
  
  ホスト名の解決が機能している場合は、出力に IP アドレスが表示されます。ホスト名の解決に失敗した場合、出力には「Host not found」が含まれます。
  
  コマンド 1:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i

  
  コマンド 2:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i

• Cassandra マルチリージョンの要件:
  • Pod ネットワークの Namespace がクラスタ間の接続を持たない場合（クラスタがアイランド ネットワーク モードで実行されている場合）、オーバーライド ファイルで cassandra.hostNetwork: true を設定することで、Apigee ハイブリッド マルチリージョン インストールの全リージョンで Kubernetes の hostNetwork 機能を有効にします。Amazon EKS は、デフォルトで完全統合ネットワーク モデルを使用します。

    hostNetwork の必要性について詳しくは、以下のアイランド モードのクラスタと hostNetwork をご覧ください。

  • マルチリージョン構成を新しいリージョンに拡張する前に、既存のクラスタで hostNetwork を有効にします。
  • hostNetwork が有効になっている場合は、ワーカーノードがホスト名のフォワード DNS ルックアップを実行できることを確認してください。Apigee Cassandra は、起動時にフォワード DNS ルックアップを使用してホスト IP を取得します。
    ヒント: DNS 解決が機能しない場合は、以下の回避策をお試しください。

    各 Cassandra ワーカーノードの /etc/hosts ファイルに次のような静的ホストエントリを追加します。

    echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"

    または

    "\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"

  • すべてのリージョンの Kubernetes クラスタ間で Cassandra ポートを開き、リージョン間とデータセンター間でワーカーノードが通信できるようにします。Cassandra のポート番号については、ポートの構成をご覧ください。

詳細については、Kubernetes のドキュメントをご覧ください。

注: サーバーの時刻を同期させることをおすすめします。

有効期限やトークンの取り消しなどの機能では、正確なシステム時刻が必要になります。異なるデータセンターでランタイム コンポーネントをホストする場合、システム時刻が同期されていることを確認してください。

ntpdate などのツールを使用すると、サーバー時刻が同期されていることを確認できます。

OpenShift

• 異なるネットワーク（異なるクラウド プロバイダ、異なる VPC ネットワーク、クラウドとオンプレミスなど）間でマルチリージョンの Apigee デプロイをインストールする場合は、Cassandra がノード間の通信に使用できるようにネットワーク間の内部接続を提供する必要があります。これは、VPN またはクラウド固有の接続ソリューションで実現できます。
• クラスタの設定手順に進む前に、Google Cloud や組織の構成などの前提条件について、ハイブリッド インストール ガイドに従ってください。
• 各クラスタに cert-manager がインストールされていることを確認します。
• すべての Cassandra Pod が自身のホスト名を解決できることを確認します。hostNetwork が false に設定されている場合、ホスト名は Cassandra Pod の名前です。hostNetwork が true に設定されている場合、ホスト名は Cassandra Pod を実行している Kubernetes ノードのホスト名になります。
  ヒント: ホスト名の解決が機能しているかどうかを確認するには、次のコマンドを使用します。
  
  hostNetwork が false に設定されている場合は、コマンド 1 を使用します。hostNetwork が true に設定されている場合は、コマンド 2 を使用します。
  
  ホスト名の解決が機能している場合は、出力に IP アドレスが表示されます。ホスト名の解決に失敗した場合、出力には「Host not found」が含まれます。
  
  コマンド 1:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i

  
  コマンド 2:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i

• Cassandra マルチリージョンの要件:
  • Pod ネットワークの Namespace がクラスタ間の接続を持たない場合（OpenShift インストールのデフォルトの場合、クラスタはアイランド ネットワーク モードで稼働します）は、オーバーライド ファイルで cassandra.hostNetwork: true を設定することで、Apigee ハイブリッド マルチリージョン インストールの全リージョンで Kubernetes の hostNetwork 機能を有効にします。

    hostNetwork の必要性について詳しくは、以下のアイランド モードのクラスタと hostNetwork をご覧ください。

  • マルチリージョン構成を新しいリージョンに拡張する前に、既存のクラスタで hostNetwork を有効にします。
  • hostNetwork が有効になっている場合は、ワーカーノードがホスト名のフォワード DNS ルックアップを実行できることを確認してください。Apigee Cassandra は、起動時にフォワード DNS ルックアップを使用してホスト IP を取得します。
    ヒント: DNS 解決が機能しない場合は、以下の回避策をお試しください。

    各 Cassandra ワーカーノードの /etc/hosts ファイルに次のような静的ホストエントリを追加します。

    echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"

    または

    "\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"

  • すべてのリージョンの Kubernetes クラスタ間で Cassandra ポートを開き、リージョン間とデータセンター間でワーカーノードが通信できるようにします。Cassandra のポート番号については、ポートの構成をご覧ください。

詳細については、Kubernetes のドキュメントをご覧ください。

注: サーバーの時刻を同期させることをおすすめします。

有効期限やトークンの取り消しなどの機能では、正確なシステム時刻が必要になります。異なるデータセンターでランタイム コンポーネントをホストする場合、システム時刻が同期されていることを確認してください。

ntpdate などのツールを使用すると、サーバー時刻が同期されていることを確認できます。

アイランド モードのクラスタと hostNetwork

Kubernetes クラスタには、完全統合（またはフラット）モードとアイランド モードという 2 つの主要なネットワーク モデルがあります。マルチリージョン Cassandra 接続を簡素化するため、可能であればフラット ネットワーク モデルを使用することをおすすめします。Kubernetes クラスタがアイランドモードで構成されると、Pod ネットワークは分離されます。Pod が IP アドレスを使って他のクラスタ内の Pod と直接通信することはできません。この 2 つのネットワーク モデルの違いの詳細とそれぞれの例については、一般的なネットワーク モデルの実装をご覧ください。

アイランド モード ネットワーキング モデルを使用して Apigee ハイブリッドを 2 つ以上の Kubernetes クラスタで実行する場合は、cassandra.hostNetwork プロパティを使って Cassandra の hostNetwork 設定を有効にする必要があります。デフォルトでは、Kubernetes の Pod は個々のネットワークの Namespace に分離されるため、Kubernetes ワーカーノード IP を使用できません。hostNetwork が true に設定されている場合、Pod は独自のネットワークの Namespace に分離される代わりに、自身がスケジュールされている Kubernetes ワーカーノードの IP アドレスとホスト名を使用します。これにより、Cassandra は Kubernetes ワーカーノードの IP を自身の IP としてネイティブに使用でき、アイランド モードで実行されている複数のクラスタ内のすべての Cassandra Pod 間でフルメッシュを確立できるようになります。

Cassandra のホスト名の解決

Cassandra Pod は他の Cassandra Pod をホスト名で解決しませんが、Cassandra は起動時に自身のホスト名が DNS で解決できることを確認します。hostNetwork が true に設定されている場合、Pod のホスト名は Kubernetes ワーカーノードのホスト名と同じであるため、クラスタの DNS サービスを介してワーカーノードのホスト名を IP アドレスに解決できる状態になっている必要があります。Kubernetes ワーカーノードのホスト名を解決できない場合、Cassandra Pod を完全に開始することはできません。このため、hostNetwork を true に設定する場合は、Kubernetes ワーカーノードのホスト名をクラスタ内の Pod で解決できることが重要です。

Apigee ハイブリッドをマルチリージョン用に構成する

このセクションでは、Apigee ハイブリッドをマルチリージョン用に構成する方法について説明します。

GKE

重要: Apigee ハイブリッドを新しいリージョン データセンターに拡張する場合は、既存のデータセンターと同じバージョンのハイブリッドをインストールしてください。複数のデータセンターで異なるバージョンのハイブリッドを実行しないでください。

警告: 新しいリージョンでインストールが失敗した場合は、リージョンのインストールを続行しないでください。代わりに、障害が発生したリージョンのハイブリッド インストールを削除して再作成してください。

マルチリージョン シードホストを構成する

このセクションでは、既存の Cassandra クラスタを新しいリージョンに拡張する方法について説明します。この設定によって、新しいリージョンがクラスタをブートストラップし、既存のデータセンターに参加できるようになります。この構成がないと、マルチリージョンの Kubernetes クラスタが相互に認識できません。

1. 最初に作成したリージョンのために、Apigee Namespace で Pod を取得します。

   kubectl get pods -o wide -n APIGEE_NAMESPACE
   

2. このリージョン内の Cassandra のマルチリージョン シードホスト アドレス（たとえば、10.0.0.11）を特定します。

3. 2 番目のリージョン用の overrides.yaml ファイルを準備し、次のようにシードホストの IP アドレスを追加します。

   cassandra:
     multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
     datacenter: "DATACENTER_NAME"
     rack: "RACK_NAME"
     hostNetwork: false
     clusterName: CLUSTER_NAME

   次のように置き換えます。

   • SEED_HOST_IP_ADDRESS と、シードホスト IP アドレス（例: 10.0.0.11）。
   • DATACENTER_NAME と、データセンター名（例: dc-2）。
   • RACK_NAME は、ラック名で置き換えます。例: ra-1。
   • CLUSTER_NAME は、Cassandra クラスタの名前に置き換えます。デフォルトでは、値は apigeecluster です。別のクラスタ名を使用する場合は、cassandra.clusterName の値を指定する必要があります。独自の値を自由に選択できますが、すべてのリージョンで同じ値にする必要があります。

2 番目のリージョンを構成する

新しいリージョンを設定するには:

1. 2 番目のリージョンに cert-manager をインストールします。

2. 証明書を既存のクラスタから新しいクラスタにコピーします。新しい CA ルートは、Cassandra などのハイブリッド コンポーネントによって mTLS に使用されます。したがって、クラスタ全体で一貫した証明書を使用することが不可欠です。

   1. コンテキストを元の Namespace に設定します。

      kubectl config use-context ORIGINAL_CLUSTER_NAME
      

   2. 現在の Namespace の構成をファイルにエクスポートします。

      kubectl get namespace APIGEE_NAMESPACE -o yaml > apigee-namespace.yaml
      

   3. apigee-ca Secret をファイルにエクスポートします。

      kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
      

   4. コンテキストを新しいリージョンのクラスタ名に設定します。

      kubectl config use-context NEW_CLUSTER_NAME
      

   5. 新しいクラスタに Namespace の構成をインポートします。新しいリージョンで別の Namespace を使用する場合は、ファイル内の Namespace を必ず更新してください。

      kubectl apply -f apigee-namespace.yaml
      

   6. 新しいクラスタに Secret をインポートします。

      kubectl -n cert-manager apply -f apigee-ca.yaml
      

3. 手順に沿って、新しいリージョンに Apigee ハイブリッド CRD をインストールします。

4. ここで、Helm チャートを使用して、次の Helm チャート コマンド（リージョン 1 と同様）で、Apigee ハイブリッドを新しいリージョンにインストールします。

   注: チャートをダウンロードした同じフォルダを使用して、同じ CRD を使用できます。オーバーライドを overrides-region_name.yaml などの一意のもので名付けることによって、オーバーライド ファイルをリージョン 1 と 2 で一意に維持することもできます。

   helm upgrade operator apigee-operator \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade datastore apigee-datastore \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade telemetry apigee-telemetry \
     --install \
     --namespace APIGEE_NAMESPACE> \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade redis apigee-redis \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ingress-manager apigee-ingress-manager \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ORG_NAME apigee-org \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env mentioned on the overrides
   helm upgrade ENV_NAME apigee-env/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     --set env=ENV_NAME \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env group mentioned on the overrides
   helm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     --set envgroup=ENV_GROUP_NAME \
     -f overrides-DATACENTER_NAME.yaml
   

5. 次のコマンドを実行して、Cassandra クラスタの設定を確認します。出力には、既存のデータセンターと新しいデータセンターの両方が表示されるはずです。
   警告: このコマンドの出力に既存のデータセンターと新しいデータセンターの両方が表示されていない場合は、設定に失敗しています。その場合は、続行しないでください。

   この問題を解決するには、新しいリージョンのハイブリッド インストールを削除してから再作成する必要があります。ハイブリッド ランタイムをアンインストールするをご覧ください。設定に失敗した場合は、続行もクラスタへの参加も行わないでください。

   kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  \
   -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   成功した設定を示す例:

   Datacenter: dc-1
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
   UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
   UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d
   
   Datacenter: dc-2
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
   UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
   UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b

6. 新しいデータセンターのすべての Pod で Cassandra を設定します。
   1. 次のコマンドを使用して、クラスタから apigeeorg を取得します。

      kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
      

      次に例を示します。

      Ex: kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
      "rg-hybrid-b7d3b9c"
      

   2. cassandra データ レプリケーションのカスタム リソース（YAML）ファイルを作成します。ファイルには任意の名前を付けることができます。以下の例では、datareplication.yaml というファイル名を使用しています。

      このファイルには、次のものが含まれている必要があります。

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
      name: REGION_EXPANSION
      namespace: NAMESPACE
      spec:
      organizationRef: APIGEEORG_VALUE
      force: false
      source:
      region: SOURCE_REGION

      ここで

      • REGION_EXPANSION は、このメタデータに付ける名前です。任意の名前を使用できます。
      • NAMESPACE は、overrides.yaml で定義されている名前空間です。通常は apigee です。
      • APIGEEORG_VALUE は、前のステップの kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name" コマンドの出力値です。例: rg-hybrid-b7d3b9c
      • SOURCE_REGION は、ソース リージョン（ソース リージョンの overrides.yaml の cassandra セクションの下にあるデータセンターの値）です。

      次に例を示します。

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
      name: region-expansion
      namespace: apigee
      spec:
      organizationRef: rg-hybrid-b7d3b9c
      force: false
      source:
      region: "dc-1"

   3. 次のコマンドを使用して CassandraDataReplication を適用します。

      kubectl apply -f datareplication.yaml

7. 次のコマンドを使用して、再ビルドのステータスを確認します。
   注: データサイズによっては、再ビルド オペレーションに数時間かかることがあります。

   kubectl -n APIGEE_NAMESPACE get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

   結果は次のようになります。

   {
   "rebuildDetails": {
   "apigee-cassandra-default-0": {
   "state": "complete",
   "updated": 1623105760
   },
   "apigee-cassandra-default-1": {
   "state": "complete",
   "updated": 1623105765
   },
   "apigee-cassandra-default-2": {
   "state": "complete",
   "updated": 1623105770
   }
   },
   "state": "complete",
   "updated": 1623105770
   }

8. データ レプリケーションが完了し、検証されたら、シードホストを更新します。
   1. multiRegionSeedHost: 10.0.0.11 を overrides-DATACENTER_NAME.yaml から削除してください。

   2. 変更を再適用して、Apigee Datastore CR を更新します。

      helm upgrade datastore apigee-datastore/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f overrides-DATACENTER_NAME.yaml
      

9. ログで再ビルドプロセスを確認します。また、nodetool status コマンドを使用してデータサイズを確認します。
   注: 再ビルド オペレーションが完了の状態を示し、再ビルドプロセスのログに「すべてのセッションが完了」と表示される場合は、すべてのデータが新しいリージョンに正常にコピーされています。

   kubectl logs apigee-cassandra-default-0 -f -n APIGEE_NAMESPACE

   kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   ヒント: APIGEE_JMX_USER と APIGEE_JMX_PASSWORD は通常、環境変数 $APIGEE_JMX_USER と $APIGEE_JMX_PASSWORD で定義されます。

   次に、ログエントリの例を示します。

   INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

Cassandra クラスタのステータスを確認する

次のコマンドは、2 つのデータセンターでクラスタが正常に設定されているかどうかを確認するのに役立ちます。このコマンドを実行すると、2 つのリージョンの nodetool ステータスがチェックされます。

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status


Datacenter: dc-1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.12.1.45  112.09 KiB  256          100.0%            3c98c816-3f4d-48f0-9717-03d0c998637f  ra-1
UN  10.12.4.36  95.27 KiB  256          100.0%            0a36383d-1d9e-41e2-924c-7b62be12d6cc  ra-1
UN  10.12.5.22  88.7 KiB   256          100.0%            3561f4fa-af3d-4ea4-93b2-79ac7e938201  ra-1
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.4.33   78.69 KiB  256          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

GKE On-Prem

重要: Apigee ハイブリッドを新しいリージョン データセンターに拡張する場合は、既存のデータセンターと同じバージョンのハイブリッドをインストールしてください。複数のデータセンターで異なるバージョンのハイブリッドを実行しないでください。

警告: 新しいリージョンでインストールが失敗した場合は、リージョンのインストールを続行しないでください。代わりに、障害が発生したリージョンのハイブリッド インストールを削除して再作成してください。

マルチリージョン シードホストを構成する

このセクションでは、既存の Cassandra クラスタを新しいリージョンに拡張する方法について説明します。この設定によって、新しいリージョンがクラスタをブートストラップし、既存のデータセンターに参加できるようになります。この構成がないと、マルチリージョンの Kubernetes クラスタが相互に認識できません。

1. 最初に作成したリージョンのために、Apigee Namespace で Pod を取得します。

   kubectl get pods -o wide -n APIGEE_NAMESPACE
   

2. このリージョン内の Cassandra のマルチリージョン シードホスト アドレス（たとえば、10.0.0.11）を特定します。

3. 2 番目のリージョン用の overrides.yaml ファイルを準備し、次のようにシードホストの IP アドレスを追加します。

   cassandra:
     multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
     datacenter: "DATACENTER_NAME"
     rack: "RACK_NAME"
     hostNetwork: false
     clusterName: CLUSTER_NAME

   次のように置き換えます。

   • SEED_HOST_IP_ADDRESS と、シードホスト IP アドレス（例: 10.0.0.11）。
   • DATACENTER_NAME と、データセンター名（例: dc-2）。
   • RACK_NAME は、ラック名で置き換えます。例: ra-1。
   • CLUSTER_NAME は、Cassandra クラスタの名前に置き換えます。デフォルトでは、値は apigeecluster です。別のクラスタ名を使用する場合は、cassandra.clusterName の値を指定する必要があります。独自の値を自由に選択できますが、すべてのリージョンで同じ値にする必要があります。

2 番目のリージョンを構成する

新しいリージョンを設定するには:

1. 2 番目のリージョンに cert-manager をインストールします。

2. 証明書を既存のクラスタから新しいクラスタにコピーします。新しい CA ルートは、Cassandra などのハイブリッド コンポーネントによって mTLS に使用されます。したがって、クラスタ全体で一貫した証明書を使用することが不可欠です。

   1. コンテキストを元の Namespace に設定します。

      kubectl config use-context ORIGINAL_CLUSTER_NAME
      

   2. 現在の Namespace の構成をファイルにエクスポートします。

      kubectl get namespace APIGEE_NAMESPACE -o yaml > apigee-namespace.yaml
      

   3. apigee-ca Secret をファイルにエクスポートします。

      kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
      

   4. コンテキストを新しいリージョンのクラスタ名に設定します。

      kubectl config use-context NEW_CLUSTER_NAME
      

   5. 新しいクラスタに Namespace の構成をインポートします。新しいリージョンで別の Namespace を使用する場合は、ファイル内の Namespace を必ず更新してください。

      kubectl apply -f apigee-namespace.yaml
      

   6. 新しいクラスタに Secret をインポートします。

      kubectl -n cert-manager apply -f apigee-ca.yaml
      

3. 手順に沿って、新しいリージョンに Apigee ハイブリッド CRD をインストールします。

4. ここで、Helm チャートを使用して、次の Helm チャート コマンド（リージョン 1 と同様）で、Apigee ハイブリッドを新しいリージョンにインストールします。

   注: チャートをダウンロードした同じフォルダを使用して、同じ CRD を使用できます。オーバーライドを overrides-region_name.yaml などの一意のもので名付けることによって、オーバーライド ファイルをリージョン 1 と 2 で一意に維持することもできます。

   helm upgrade operator apigee-operator \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade datastore apigee-datastore \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade telemetry apigee-telemetry \
     --install \
     --namespace APIGEE_NAMESPACE> \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade redis apigee-redis \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ingress-manager apigee-ingress-manager \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ORG_NAME apigee-org \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env mentioned on the overrides
   helm upgrade ENV_NAME apigee-env/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     --set env=ENV_NAME \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env group mentioned on the overrides
   helm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     --set envgroup=ENV_GROUP_NAME \
     -f overrides-DATACENTER_NAME.yaml
   

5. 次のコマンドを実行して、Cassandra クラスタの設定を確認します。出力には、既存のデータセンターと新しいデータセンターの両方が表示されるはずです。
   警告: このコマンドの出力に既存のデータセンターと新しいデータセンターの両方が表示されていない場合は、設定に失敗しています。その場合は、続行しないでください。

   この問題を解決するには、新しいリージョンのハイブリッド インストールを削除してから再作成する必要があります。ハイブリッド ランタイムをアンインストールするをご覧ください。設定に失敗した場合は、続行もクラスタへの参加も行わないでください。

   kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  \
   -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   成功した設定を示す例:

   Datacenter: dc-1
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
   UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
   UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d
   
   Datacenter: dc-2
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
   UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
   UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b

6. 新しいデータセンターのすべての Pod で Cassandra を設定します。
   1. 次のコマンドを使用して、クラスタから apigeeorg を取得します。

      kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
      

      次に例を示します。

      Ex: kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
      "rg-hybrid-b7d3b9c"
      

   2. cassandra データ レプリケーションのカスタム リソース（YAML）ファイルを作成します。ファイルには任意の名前を付けることができます。以下の例では、datareplication.yaml というファイル名を使用しています。

      このファイルには、次のものが含まれている必要があります。

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
      name: REGION_EXPANSION
      namespace: NAMESPACE
      spec:
      organizationRef: APIGEEORG_VALUE
      force: false
      source:
      region: SOURCE_REGION

      ここで

      • REGION_EXPANSION は、このメタデータに付ける名前です。任意の名前を使用できます。
      • NAMESPACE は、overrides.yaml で定義されている名前空間です。通常は apigee です。
      • APIGEEORG_VALUE は、前のステップの kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name" コマンドの出力値です。例: rg-hybrid-b7d3b9c
      • SOURCE_REGION は、ソース リージョン（ソース リージョンの overrides.yaml の cassandra セクションの下にあるデータセンターの値）です。

      次に例を示します。

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
      name: region-expansion
      namespace: apigee
      spec:
      organizationRef: rg-hybrid-b7d3b9c
      force: false
      source:
      region: "dc-1"

   3. 次のコマンドを使用して CassandraDataReplication を適用します。

      kubectl apply -f datareplication.yaml

7. 次のコマンドを使用して、再ビルドのステータスを確認します。
   注: データサイズによっては、再ビルド オペレーションに数時間かかることがあります。

   kubectl -n APIGEE_NAMESPACE get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

   結果は次のようになります。

   {
   "rebuildDetails": {
   "apigee-cassandra-default-0": {
   "state": "complete",
   "updated": 1623105760
   },
   "apigee-cassandra-default-1": {
   "state": "complete",
   "updated": 1623105765
   },
   "apigee-cassandra-default-2": {
   "state": "complete",
   "updated": 1623105770
   }
   },
   "state": "complete",
   "updated": 1623105770
   }

8. データ レプリケーションが完了し、検証されたら、シードホストを更新します。
   1. multiRegionSeedHost: 10.0.0.11 を overrides-DATACENTER_NAME.yaml から削除してください。

   2. 変更を再適用して、Apigee Datastore CR を更新します。

      helm upgrade datastore apigee-datastore/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f overrides-DATACENTER_NAME.yaml
      

9. ログで再ビルドプロセスを確認します。また、nodetool status コマンドを使用してデータサイズを確認します。
   注: 再ビルド オペレーションが完了の状態を示し、再ビルドプロセスのログに「すべてのセッションが完了」と表示される場合は、すべてのデータが新しいリージョンに正常にコピーされています。

   kubectl logs apigee-cassandra-default-0 -f -n APIGEE_NAMESPACE

   kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   ヒント: APIGEE_JMX_USER と APIGEE_JMX_PASSWORD は通常、環境変数 $APIGEE_JMX_USER と $APIGEE_JMX_PASSWORD で定義されます。

   次に、ログエントリの例を示します。

   INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

Cassandra クラスタのステータスを確認する

次のコマンドは、2 つのデータセンターでクラスタが正常に設定されているかどうかを確認するのに役立ちます。このコマンドを実行すると、2 つのリージョンの nodetool ステータスがチェックされます。

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status


Datacenter: dc-1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.12.1.45  112.09 KiB  256          100.0%            3c98c816-3f4d-48f0-9717-03d0c998637f  ra-1
UN  10.12.4.36  95.27 KiB  256          100.0%            0a36383d-1d9e-41e2-924c-7b62be12d6cc  ra-1
UN  10.12.5.22  88.7 KiB   256          100.0%            3561f4fa-af3d-4ea4-93b2-79ac7e938201  ra-1
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.4.33   78.69 KiB  256          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

AKS

重要: Apigee ハイブリッドを新しいリージョン データセンターに拡張する場合は、既存のデータセンターと同じバージョンのハイブリッドをインストールしてください。複数のデータセンターで異なるバージョンのハイブリッドを実行しないでください。

警告: 新しいリージョンでインストールが失敗した場合は、リージョンのインストールを続行しないでください。代わりに、障害が発生したリージョンのハイブリッド インストールを削除して再作成してください。

各リージョンに仮想ネットワークを作成する

Azure の推奨事項に従ってクロスリージョン通信を確立します。具体的には、VNet-to-VNet: 異なるリージョン間での Azure 仮想ネットワークの接続をご覧ください。

マルチリージョン クラスタを作成する

異なる CIDR ブロックを持つ複数のリージョンに Kubernetes クラスタを設定します。ステップ 1: クラスタを作成するもご覧ください。以前に作成したロケーションと仮想ネットワーク名を使用します。

すべてのリージョンの Kubernetes クラスタ間で Cassandra ポートを開き、リージョン間とデータセンター間でワーカーノードが通信できるようにします。Cassandra のポート番号については、ポートの構成をご覧ください。

マルチリージョン シードホストを構成する

このセクションでは、既存の Cassandra クラスタを新しいリージョンに拡張する方法について説明します。この設定によって、新しいリージョンがクラスタをブートストラップし、既存のデータセンターに参加できるようになります。この構成がないと、マルチリージョンの Kubernetes クラスタが相互に認識できません。

1. 最初に作成したリージョンのために、Apigee Namespace で Pod を取得します。

   kubectl get pods -o wide -n APIGEE_NAMESPACE
   

2. このリージョン内の Cassandra のマルチリージョン シードホスト アドレス（たとえば、10.0.0.11）を特定します。

3. 2 番目のリージョン用の overrides.yaml ファイルを準備し、次のようにシードホストの IP アドレスを追加します。

   cassandra:
     multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
     datacenter: "DATACENTER_NAME"
     rack: "RACK_NAME"
     hostNetwork: false
     clusterName: CLUSTER_NAME

   次のように置き換えます。

   • SEED_HOST_IP_ADDRESS と、シードホスト IP アドレス（例: 10.0.0.11）。
   • DATACENTER_NAME と、データセンター名（例: dc-2）。
   • RACK_NAME は、ラック名で置き換えます。例: ra-1。
   • CLUSTER_NAME は、Cassandra クラスタの名前に置き換えます。デフォルトでは、値は apigeecluster です。別のクラスタ名を使用する場合は、cassandra.clusterName の値を指定する必要があります。独自の値を自由に選択できますが、すべてのリージョンで同じ値にする必要があります。

2 番目のリージョンを構成する

新しいリージョンを設定するには:

1. 2 番目のリージョンに cert-manager をインストールします。

2. 証明書を既存のクラスタから新しいクラスタにコピーします。新しい CA ルートは、Cassandra などのハイブリッド コンポーネントによって mTLS に使用されます。したがって、クラスタ全体で一貫した証明書を使用することが不可欠です。

   1. コンテキストを元の Namespace に設定します。

      kubectl config use-context ORIGINAL_CLUSTER_NAME
      

   2. 現在の Namespace の構成をファイルにエクスポートします。

      kubectl get namespace APIGEE_NAMESPACE -o yaml > apigee-namespace.yaml
      

   3. apigee-ca Secret をファイルにエクスポートします。

      kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
      

   4. コンテキストを新しいリージョンのクラスタ名に設定します。

      kubectl config use-context NEW_CLUSTER_NAME
      

   5. 新しいクラスタに Namespace の構成をインポートします。新しいリージョンで別の Namespace を使用する場合は、ファイル内の Namespace を必ず更新してください。

      kubectl apply -f apigee-namespace.yaml
      

   6. 新しいクラスタに Secret をインポートします。

      kubectl -n cert-manager apply -f apigee-ca.yaml
      

3. 手順に沿って、新しいリージョンに Apigee ハイブリッド CRD をインストールします。

4. ここで、Helm チャートを使用して、次の Helm チャート コマンド（リージョン 1 と同様）で、Apigee ハイブリッドを新しいリージョンにインストールします。

   注: チャートをダウンロードした同じフォルダを使用して、同じ CRD を使用できます。オーバーライドを overrides-region_name.yaml などの一意のもので名付けることによって、オーバーライド ファイルをリージョン 1 と 2 で一意に維持することもできます。

   helm upgrade operator apigee-operator \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade datastore apigee-datastore \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade telemetry apigee-telemetry \
     --install \
     --namespace APIGEE_NAMESPACE> \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade redis apigee-redis \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ingress-manager apigee-ingress-manager \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ORG_NAME apigee-org \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env mentioned on the overrides
   helm upgrade ENV_NAME apigee-env/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     --set env=ENV_NAME \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env group mentioned on the overrides
   helm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     --set envgroup=ENV_GROUP_NAME \
     -f overrides-DATACENTER_NAME.yaml
   

5. 次のコマンドを実行して、Cassandra クラスタの設定を確認します。出力には、既存のデータセンターと新しいデータセンターの両方が表示されるはずです。
   警告: このコマンドの出力に既存のデータセンターと新しいデータセンターの両方が表示されていない場合は、設定に失敗しています。その場合は、続行しないでください。

   この問題を解決するには、新しいリージョンのハイブリッド インストールを削除してから再作成する必要があります。ハイブリッド ランタイムをアンインストールするをご覧ください。設定に失敗した場合は、続行もクラスタへの参加も行わないでください。

   kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  \
   -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   成功した設定を示す例:

   Datacenter: dc-1
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
   UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
   UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d
   
   Datacenter: dc-2
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
   UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
   UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b

6. 新しいデータセンターのすべての Pod で Cassandra を設定します。
   1. 次のコマンドを使用して、クラスタから apigeeorg を取得します。

      kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
      

      次に例を示します。

      Ex: kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
      "rg-hybrid-b7d3b9c"
      

   2. cassandra データ レプリケーションのカスタム リソース（YAML）ファイルを作成します。ファイルには任意の名前を付けることができます。以下の例では、datareplication.yaml というファイル名を使用しています。

      このファイルには、次のものが含まれている必要があります。

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
      name: REGION_EXPANSION
      namespace: NAMESPACE
      spec:
      organizationRef: APIGEEORG_VALUE
      force: false
      source:
      region: SOURCE_REGION

      ここで

      • REGION_EXPANSION は、このメタデータに付ける名前です。任意の名前を使用できます。
      • NAMESPACE は、overrides.yaml で定義されている名前空間です。通常は apigee です。
      • APIGEEORG_VALUE は、前のステップの kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name" コマンドの出力値です。例: rg-hybrid-b7d3b9c
      • SOURCE_REGION は、ソース リージョン（ソース リージョンの overrides.yaml の cassandra セクションの下にあるデータセンターの値）です。

      次に例を示します。

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
      name: region-expansion
      namespace: apigee
      spec:
      organizationRef: rg-hybrid-b7d3b9c
      force: false
      source:
      region: "dc-1"

   3. 次のコマンドを使用して CassandraDataReplication を適用します。

      kubectl apply -f datareplication.yaml

7. 次のコマンドを使用して、再ビルドのステータスを確認します。
   注: データサイズによっては、再ビルド オペレーションに数時間かかることがあります。

   kubectl -n APIGEE_NAMESPACE get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

   結果は次のようになります。

   {
   "rebuildDetails": {
   "apigee-cassandra-default-0": {
   "state": "complete",
   "updated": 1623105760
   },
   "apigee-cassandra-default-1": {
   "state": "complete",
   "updated": 1623105765
   },
   "apigee-cassandra-default-2": {
   "state": "complete",
   "updated": 1623105770
   }
   },
   "state": "complete",
   "updated": 1623105770
   }

8. データ レプリケーションが完了し、検証されたら、シードホストを更新します。
   1. multiRegionSeedHost: 10.0.0.11 を overrides-DATACENTER_NAME.yaml から削除してください。

   2. 変更を再適用して、Apigee Datastore CR を更新します。

      helm upgrade datastore apigee-datastore/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f overrides-DATACENTER_NAME.yaml
      

9. ログで再ビルドプロセスを確認します。また、nodetool status コマンドを使用してデータサイズを確認します。
   注: 再ビルド オペレーションが完了の状態を示し、再ビルドプロセスのログに「すべてのセッションが完了」と表示される場合は、すべてのデータが新しいリージョンに正常にコピーされています。

   kubectl logs apigee-cassandra-default-0 -f -n APIGEE_NAMESPACE

   kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   ヒント: APIGEE_JMX_USER と APIGEE_JMX_PASSWORD は通常、環境変数 $APIGEE_JMX_USER と $APIGEE_JMX_PASSWORD で定義されます。

   次に、ログエントリの例を示します。

   INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

Cassandra クラスタのステータスを確認する

次のコマンドは、2 つのデータセンターでクラスタが正常に設定されているかどうかを確認するのに役立ちます。このコマンドを実行すると、2 つのリージョンの nodetool ステータスがチェックされます。

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status


Datacenter: dc-1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.12.1.45  112.09 KiB  256          100.0%            3c98c816-3f4d-48f0-9717-03d0c998637f  ra-1
UN  10.12.4.36  95.27 KiB  256          100.0%            0a36383d-1d9e-41e2-924c-7b62be12d6cc  ra-1
UN  10.12.5.22  88.7 KiB   256          100.0%            3561f4fa-af3d-4ea4-93b2-79ac7e938201  ra-1
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.4.33   78.69 KiB  256          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

EKS

重要: Apigee ハイブリッドを新しいリージョン データセンターに拡張する場合は、既存のデータセンターと同じバージョンのハイブリッドをインストールしてください。複数のデータセンターで異なるバージョンのハイブリッドを実行しないでください。複数のデータセンターを新しいバージョンにアップグレードする場合、この制限は適用されません。

警告: 新しいリージョンでインストールが失敗した場合は、リージョンのインストールを続行しないでください。代わりに、障害が発生したリージョンのハイブリッド インストールを削除して再作成してください。

各リージョンに仮想ネットワークを作成する

VPC ピアリングとはで説明されているように、リージョン間の通信を確立するための AWS の推奨事項に従います。AWS では、異なるリージョンを使用することをリージョン間 VPC ピアリングと呼びます。

マルチリージョン クラスタを作成する

異なる CIDR ブロックを持つ複数のリージョンに Kubernetes クラスタを設定します。ステップ 1: クラスタを作成するもご覧ください。以前に作成したロケーションと仮想ネットワーク名を使用します。

すべてのリージョンの Kubernetes クラスタ間で Cassandra ポートを開き、リージョン間とデータセンター間でワーカーノードが通信できるようにします。Cassandra のポート番号については、ポートの構成をご覧ください。

マルチリージョン シードホストを構成する

このセクションでは、既存の Cassandra クラスタを新しいリージョンに拡張する方法について説明します。この設定によって、新しいリージョンがクラスタをブートストラップし、既存のデータセンターに参加できるようになります。この構成がないと、マルチリージョンの Kubernetes クラスタが相互に認識できません。

1. 最初に作成したリージョンのために、Apigee Namespace で Pod を取得します。

   kubectl get pods -o wide -n APIGEE_NAMESPACE
   

2. このリージョン内の Cassandra のマルチリージョン シードホスト アドレス（たとえば、10.0.0.11）を特定します。

3. 2 番目のリージョン用の overrides.yaml ファイルを準備し、次のようにシードホストの IP アドレスを追加します。

   cassandra:
     multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
     datacenter: "DATACENTER_NAME"
     rack: "RACK_NAME"
     hostNetwork: false
     clusterName: CLUSTER_NAME

   次のように置き換えます。

   • SEED_HOST_IP_ADDRESS と、シードホスト IP アドレス（例: 10.0.0.11）。
   • DATACENTER_NAME と、データセンター名（例: dc-2）。
   • RACK_NAME は、ラック名で置き換えます。例: ra-1。
   • CLUSTER_NAME は、Cassandra クラスタの名前に置き換えます。デフォルトでは、値は apigeecluster です。別のクラスタ名を使用する場合は、cassandra.clusterName の値を指定する必要があります。独自の値を自由に選択できますが、すべてのリージョンで同じ値にする必要があります。

2 番目のリージョンを構成する

新しいリージョンを設定するには:

1. 2 番目のリージョンに cert-manager をインストールします。

2. 証明書を既存のクラスタから新しいクラスタにコピーします。新しい CA ルートは、Cassandra などのハイブリッド コンポーネントによって mTLS に使用されます。したがって、クラスタ全体で一貫した証明書を使用することが不可欠です。

   1. コンテキストを元の Namespace に設定します。

      kubectl config use-context ORIGINAL_CLUSTER_NAME
      

   2. 現在の Namespace の構成をファイルにエクスポートします。

      kubectl get namespace APIGEE_NAMESPACE -o yaml > apigee-namespace.yaml
      

   3. apigee-ca Secret をファイルにエクスポートします。

      kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
      

   4. コンテキストを新しいリージョンのクラスタ名に設定します。

      kubectl config use-context NEW_CLUSTER_NAME
      

   5. 新しいクラスタに Namespace の構成をインポートします。新しいリージョンで別の Namespace を使用する場合は、ファイル内の Namespace を必ず更新してください。

      kubectl apply -f apigee-namespace.yaml
      

   6. 新しいクラスタに Secret をインポートします。

      kubectl -n cert-manager apply -f apigee-ca.yaml
      

3. 手順に沿って、新しいリージョンに Apigee ハイブリッド CRD をインストールします。

4. ここで、Helm チャートを使用して、次の Helm チャート コマンド（リージョン 1 と同様）で、Apigee ハイブリッドを新しいリージョンにインストールします。

   注: チャートをダウンロードした同じフォルダを使用して、同じ CRD を使用できます。オーバーライドを overrides-region_name.yaml などの一意のもので名付けることによって、オーバーライド ファイルをリージョン 1 と 2 で一意に維持することもできます。

   helm upgrade operator apigee-operator \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade datastore apigee-datastore \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade telemetry apigee-telemetry \
     --install \
     --namespace APIGEE_NAMESPACE> \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade redis apigee-redis \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ingress-manager apigee-ingress-manager \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ORG_NAME apigee-org \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env mentioned on the overrides
   helm upgrade ENV_NAME apigee-env/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     --set env=ENV_NAME \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env group mentioned on the overrides
   helm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     --set envgroup=ENV_GROUP_NAME \
     -f overrides-DATACENTER_NAME.yaml
   

5. 次のコマンドを実行して、Cassandra クラスタの設定を確認します。出力には、既存のデータセンターと新しいデータセンターの両方が表示されるはずです。
   警告: このコマンドの出力に既存のデータセンターと新しいデータセンターの両方が表示されていない場合は、設定に失敗しています。その場合は、続行しないでください。

   この問題を解決するには、新しいリージョンのハイブリッド インストールを削除してから再作成する必要があります。ハイブリッド ランタイムをアンインストールするをご覧ください。設定に失敗した場合は、続行もクラスタへの参加も行わないでください。

   kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  \
   -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   成功した設定を示す例:

   Datacenter: dc-1
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
   UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
   UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d
   
   Datacenter: dc-2
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
   UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
   UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b

6. 新しいデータセンターのすべての Pod で Cassandra を設定します。
   1. 次のコマンドを使用して、クラスタから apigeeorg を取得します。

      kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
      

      次に例を示します。

      Ex: kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
      "rg-hybrid-b7d3b9c"
      

   2. cassandra データ レプリケーションのカスタム リソース（YAML）ファイルを作成します。ファイルには任意の名前を付けることができます。以下の例では、datareplication.yaml というファイル名を使用しています。

      このファイルには、次のものが含まれている必要があります。

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
      name: REGION_EXPANSION
      namespace: NAMESPACE
      spec:
      organizationRef: APIGEEORG_VALUE
      force: false
      source:
      region: SOURCE_REGION

      ここで

      • REGION_EXPANSION は、このメタデータに付ける名前です。任意の名前を使用できます。
      • NAMESPACE は、overrides.yaml で定義されている名前空間です。通常は apigee です。
      • APIGEEORG_VALUE は、前のステップの kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name" コマンドの出力値です。例: rg-hybrid-b7d3b9c
      • SOURCE_REGION は、ソース リージョン（ソース リージョンの overrides.yaml の cassandra セクションの下にあるデータセンターの値）です。

      次に例を示します。

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
      name: region-expansion
      namespace: apigee
      spec:
      organizationRef: rg-hybrid-b7d3b9c
      force: false
      source:
      region: "dc-1"

   3. 次のコマンドを使用して CassandraDataReplication を適用します。

      kubectl apply -f datareplication.yaml

7. 次のコマンドを使用して、再ビルドのステータスを確認します。
   注: データサイズによっては、再ビルド オペレーションに数時間かかることがあります。

   kubectl -n APIGEE_NAMESPACE get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

   結果は次のようになります。

   {
   "rebuildDetails": {
   "apigee-cassandra-default-0": {
   "state": "complete",
   "updated": 1623105760
   },
   "apigee-cassandra-default-1": {
   "state": "complete",
   "updated": 1623105765
   },
   "apigee-cassandra-default-2": {
   "state": "complete",
   "updated": 1623105770
   }
   },
   "state": "complete",
   "updated": 1623105770
   }

8. データ レプリケーションが完了し、検証されたら、シードホストを更新します。
   1. multiRegionSeedHost: 10.0.0.11 を overrides-DATACENTER_NAME.yaml から削除してください。

   2. 変更を再適用して、Apigee Datastore CR を更新します。

      helm upgrade datastore apigee-datastore/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f overrides-DATACENTER_NAME.yaml
      

9. ログで再ビルドプロセスを確認します。また、nodetool status コマンドを使用してデータサイズを確認します。
   注: 再ビルド オペレーションが完了の状態を示し、再ビルドプロセスのログに「すべてのセッションが完了」と表示される場合は、すべてのデータが新しいリージョンに正常にコピーされています。

   kubectl logs apigee-cassandra-default-0 -f -n APIGEE_NAMESPACE

   kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   ヒント: APIGEE_JMX_USER と APIGEE_JMX_PASSWORD は通常、環境変数 $APIGEE_JMX_USER と $APIGEE_JMX_PASSWORD で定義されます。

   次に、ログエントリの例を示します。

   INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

Cassandra クラスタのステータスを確認する

次のコマンドは、2 つのデータセンターでクラスタが正常に設定されているかどうかを確認するのに役立ちます。このコマンドを実行すると、2 つのリージョンの nodetool ステータスがチェックされます。

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status


Datacenter: dc-1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.12.1.45  112.09 KiB  256          100.0%            3c98c816-3f4d-48f0-9717-03d0c998637f  ra-1
UN  10.12.4.36  95.27 KiB  256          100.0%            0a36383d-1d9e-41e2-924c-7b62be12d6cc  ra-1
UN  10.12.5.22  88.7 KiB   256          100.0%            3561f4fa-af3d-4ea4-93b2-79ac7e938201  ra-1
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.4.33   78.69 KiB  256          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

OpenShift

重要: Apigee ハイブリッドを新しいリージョン データセンターに拡張する場合は、既存のデータセンターと同じバージョンのハイブリッドをインストールしてください。複数のデータセンターで異なるバージョンのハイブリッドを実行しないでください。

警告: 新しいリージョンでインストールが失敗した場合は、リージョンのインストールを続行しないでください。代わりに、障害が発生したリージョンのハイブリッド インストールを削除して再作成してください。

マルチリージョン シードホストを構成する

このセクションでは、既存の Cassandra クラスタを新しいリージョンに拡張する方法について説明します。この設定によって、新しいリージョンがクラスタをブートストラップし、既存のデータセンターに参加できるようになります。この構成がないと、マルチリージョンの Kubernetes クラスタが相互に認識できません。

1. 最初に作成したリージョンのために、Apigee Namespace で Pod を取得します。

   kubectl get pods -o wide -n APIGEE_NAMESPACE
   

2. このリージョン内の Cassandra のマルチリージョン シードホスト アドレス（たとえば、10.0.0.11）を特定します。

3. 2 番目のリージョン用の overrides.yaml ファイルを準備し、次のようにシードホストの IP アドレスを追加します。

   cassandra:
     multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
     datacenter: "DATACENTER_NAME"
     rack: "RACK_NAME"
     hostNetwork: false
     clusterName: CLUSTER_NAME

   次のように置き換えます。

   • SEED_HOST_IP_ADDRESS と、シードホスト IP アドレス（例: 10.0.0.11）。
   • DATACENTER_NAME と、データセンター名（例: dc-2）。
   • RACK_NAME は、ラック名で置き換えます。例: ra-1。
   • CLUSTER_NAME は、Cassandra クラスタの名前に置き換えます。デフォルトでは、値は apigeecluster です。別のクラスタ名を使用する場合は、cassandra.clusterName の値を指定する必要があります。独自の値を自由に選択できますが、すべてのリージョンで同じ値にする必要があります。

2 番目のリージョンを構成する

新しいリージョンを設定するには:

1. 2 番目のリージョンに cert-manager をインストールします。

2. 証明書を既存のクラスタから新しいクラスタにコピーします。新しい CA ルートは、Cassandra などのハイブリッド コンポーネントによって mTLS に使用されます。したがって、クラスタ全体で一貫した証明書を使用することが不可欠です。

   1. コンテキストを元の Namespace に設定します。

      kubectl config use-context ORIGINAL_CLUSTER_NAME
      

   2. 現在の Namespace の構成をファイルにエクスポートします。

      kubectl get namespace APIGEE_NAMESPACE -o yaml > apigee-namespace.yaml
      

   3. apigee-ca Secret をファイルにエクスポートします。

      kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
      

   4. コンテキストを新しいリージョンのクラスタ名に設定します。

      kubectl config use-context NEW_CLUSTER_NAME
      

   5. 新しいクラスタに Namespace の構成をインポートします。新しいリージョンで別の Namespace を使用する場合は、ファイル内の Namespace を必ず更新してください。

      kubectl apply -f apigee-namespace.yaml
      

   6. 新しいクラスタに Secret をインポートします。

      kubectl -n cert-manager apply -f apigee-ca.yaml
      

3. 手順に沿って、新しいリージョンに Apigee ハイブリッド CRD をインストールします。

4. ここで、Helm チャートを使用して、次の Helm チャート コマンド（リージョン 1 と同様）で、Apigee ハイブリッドを新しいリージョンにインストールします。

   注: チャートをダウンロードした同じフォルダを使用して、同じ CRD を使用できます。オーバーライドを overrides-region_name.yaml などの一意のもので名付けることによって、オーバーライド ファイルをリージョン 1 と 2 で一意に維持することもできます。

   helm upgrade operator apigee-operator \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade datastore apigee-datastore \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade telemetry apigee-telemetry \
     --install \
     --namespace APIGEE_NAMESPACE> \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade redis apigee-redis \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ingress-manager apigee-ingress-manager \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ORG_NAME apigee-org \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env mentioned on the overrides
   helm upgrade ENV_NAME apigee-env/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     --set env=ENV_NAME \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env group mentioned on the overrides
   helm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --atomic \
     --set envgroup=ENV_GROUP_NAME \
     -f overrides-DATACENTER_NAME.yaml
   

5. 次のコマンドを実行して、Cassandra クラスタの設定を確認します。出力には、既存のデータセンターと新しいデータセンターの両方が表示されるはずです。
   警告: このコマンドの出力に既存のデータセンターと新しいデータセンターの両方が表示されていない場合は、設定に失敗しています。その場合は、続行しないでください。

   この問題を解決するには、新しいリージョンのハイブリッド インストールを削除してから再作成する必要があります。ハイブリッド ランタイムをアンインストールするをご覧ください。設定に失敗した場合は、続行もクラスタへの参加も行わないでください。

   kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  \
   -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   成功した設定を示す例:

   Datacenter: dc-1
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
   UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
   UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d
   
   Datacenter: dc-2
   ====================
   Status=Up/Down
   |/ State=Normal/Leaving/Joining/Moving
   --  Address        Load       Tokens  Owns  Host ID                               Rack
   UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
   UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
   UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b

6. 新しいデータセンターのすべての Pod で Cassandra を設定します。
   1. 次のコマンドを使用して、クラスタから apigeeorg を取得します。

      kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
      

      次に例を示します。

      Ex: kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
      "rg-hybrid-b7d3b9c"
      

   2. cassandra データ レプリケーションのカスタム リソース（YAML）ファイルを作成します。ファイルには任意の名前を付けることができます。以下の例では、datareplication.yaml というファイル名を使用しています。

      このファイルには、次のものが含まれている必要があります。

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
      name: REGION_EXPANSION
      namespace: NAMESPACE
      spec:
      organizationRef: APIGEEORG_VALUE
      force: false
      source:
      region: SOURCE_REGION

      ここで

      • REGION_EXPANSION は、このメタデータに付ける名前です。任意の名前を使用できます。
      • NAMESPACE は、overrides.yaml で定義されている名前空間です。通常は apigee です。
      • APIGEEORG_VALUE は、前のステップの kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name" コマンドの出力値です。例: rg-hybrid-b7d3b9c
      • SOURCE_REGION は、ソース リージョン（ソース リージョンの overrides.yaml の cassandra セクションの下にあるデータセンターの値）です。

      次に例を示します。

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
      name: region-expansion
      namespace: apigee
      spec:
      organizationRef: rg-hybrid-b7d3b9c
      force: false
      source:
      region: "dc-1"

   3. 次のコマンドを使用して CassandraDataReplication を適用します。

      kubectl apply -f datareplication.yaml

7. 次のコマンドを使用して、再ビルドのステータスを確認します。
   注: データサイズによっては、再ビルド オペレーションに数時間かかることがあります。

   kubectl -n APIGEE_NAMESPACE get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

   結果は次のようになります。

   {
   "rebuildDetails": {
   "apigee-cassandra-default-0": {
   "state": "complete",
   "updated": 1623105760
   },
   "apigee-cassandra-default-1": {
   "state": "complete",
   "updated": 1623105765
   },
   "apigee-cassandra-default-2": {
   "state": "complete",
   "updated": 1623105770
   }
   },
   "state": "complete",
   "updated": 1623105770
   }

8. データ レプリケーションが完了し、検証されたら、シードホストを更新します。
   1. multiRegionSeedHost: 10.0.0.11 を overrides-DATACENTER_NAME.yaml から削除してください。

   2. 変更を再適用して、Apigee Datastore CR を更新します。

      helm upgrade datastore apigee-datastore/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f overrides-DATACENTER_NAME.yaml
      

9. ログで再ビルドプロセスを確認します。また、nodetool status コマンドを使用してデータサイズを確認します。
   注: 再ビルド オペレーションが完了の状態を示し、再ビルドプロセスのログに「すべてのセッションが完了」と表示される場合は、すべてのデータが新しいリージョンに正常にコピーされています。

   kubectl logs apigee-cassandra-default-0 -f -n APIGEE_NAMESPACE

   kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   ヒント: APIGEE_JMX_USER と APIGEE_JMX_PASSWORD は通常、環境変数 $APIGEE_JMX_USER と $APIGEE_JMX_PASSWORD で定義されます。

   次に、ログエントリの例を示します。

   INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

Cassandra クラスタのステータスを確認する

次のコマンドは、2 つのデータセンターでクラスタが正常に設定されているかどうかを確認するのに役立ちます。このコマンドを実行すると、2 つのリージョンの nodetool ステータスがチェックされます。

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status


Datacenter: dc-1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.12.1.45  112.09 KiB  256          100.0%            3c98c816-3f4d-48f0-9717-03d0c998637f  ra-1
UN  10.12.4.36  95.27 KiB  256          100.0%            0a36383d-1d9e-41e2-924c-7b62be12d6cc  ra-1
UN  10.12.5.22  88.7 KiB   256          100.0%            3561f4fa-af3d-4ea4-93b2-79ac7e938201  ra-1
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.4.33   78.69 KiB  256          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

トラブルシューティング

Cassandra のデータ レプリケーション エラーをご覧ください。