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

このトピックでは、Microsoft® Azure Kubernetes Service（AKS）で Apigee ハイブリッドに対してマルチリージョンデプロイを設定する方法について説明します。

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

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

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

前提条件

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

クラスタの設定手順に進む前に、ハイブリッドインストールガイドで Google Cloud や組織構成などの前提条件を確認してください。

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

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

マルチリージョンデプロイ用の仮想ネットワークを作成します。たとえば、次のコマンドでは米国中部リージョンと米国東部リージョンにネットワークを作成します。

次のコマンドを実行して、米国東部リージョンに my-hybrid-rg-vnet という名前の仮想ネットワークを作成します。

az network vnet create \
 --name my-hybrid-rg-vnet \
 --location eastus \
 --resource-group my-hybrid-rg \
 --address-prefixes 120.38.1.0/24 \
 --subnet-name my-hybrid-rg-vnet-subnet \
 --subnet-prefix 120.38.1.0/26

次のコマンドを実行して、米国中部リージョンに my-hybrid-rg-vnet-ext01 という名前の仮想ネットワークを作成します。

az network vnet create \
 --name my-hybrid-rg-vnet-ext01 \
 --location centralus \
 --resource-group my-hybrid-rg \
 --address-prefixes 192.138.0.0/24 \
 --subnet-name my-hybrid-rg-vnet-ext01-subnet \
 --subnet-prefix 192.138.0.0/26

ネットワークピアリングを作成する

仮想ネットワーク間にネットワークピアリングを作成します。

仮想ネットワーク ID を取得する

仮想ネットワーク ID 間のピアリングが確立されます。az network vnet show コマンドを使用して各仮想ネットワークの ID を取得し、その ID を変数に格納します。

最初の仮想ネットワーク（my-hybrid-rg-vnet）の ID を取得します。

vNet1Id=$(az network vnet show \
 --resource-group my-hybrid-rg \
 --name my-hybrid-rg-vnet \
 --query id --out tsv)

2 番目の仮想ネットワーク（my-hybrid-rg-vnet-ext01）の ID を取得します。

vNet2Id=$(az network vnet show \
 --resource-group my-hybrid-rg \
 --name my-hybrid-rg-vnet-ext01 \
 --query id \
 --out tsv)

最初の仮想ネットワークから 2 番目の仮想ネットワークへのピアリングを作成する

仮想ネットワーク ID を使用すると、次の例に示すように、最初の仮想ネットワーク（my-hybrid-rg-vnet）から 2 番目の仮想ネットワーク（my-hybrid-rg-vnet-ext01）へのピアリングを作成できます。

--allow-vnet-access パラメータを指定しなくてもピアリングは確立されますが、通信はできません。

az network vnet peering create \
 --name my-hybrid-rg-vnet1-peering \     # The name of the virtual network peering.
 --resource-group my-hybrid-rg \
 --vnet-name my-hybrid-rg-vnet \         # The virtual network name.
 --remote-vnet $vNet2Id \                # Resource ID of the remote virtual network.
 --allow-vnet-access

コマンドの出力で、peeringState が nitiated 状態になっていることに注意してください。I2 番目の仮想ネットワークから最初の仮想ネットワークへのピアリングを作成するまで、ピアリングは Initiated 状態のままです。

{
  ...
  "peeringState": "Initiated",
  ...
}

2 番目の仮想ネットワークから最初の仮想ネットワークへのピアリングを作成する

コマンドの例:

az network vnet peering create \
 --name my-hybrid-rg-vnet2-peering \        # The name of the virtual network peering.
 --resource-group my-hybrid-rg \
 --vnet-name my-hybrid-rg-vnet-ext01 \      # The virtual network name.
 --remote-vnet $vNet1Id \                   # Resource ID of the remote virtual network.
 --allow-vnet-access

コマンドの出力で、peeringState が Connected 状態になっていることに注意してください。また、Azure で、最初と 2 番目の仮想ネットワークのピアリングのピアリング状態が Connected に変更されます。

{
  ...
  "peeringState": "Connected",
  ...
}

次のコマンドでも、my-hybrid-rg-vnet1-peering から my-hybrid-rg-vnet2-peering へのピアリング状態が Connected に変更されていることを確認できます。

az network vnet peering show \
 --name my-hybrid-rg-vnet1-peering \
 --resource-group my-hybrid-rg \
 --vnet-name my-hybrid-rg-vnet \
 --query peeringState

予想される出力:

Connected

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

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

すべてのリージョンの Kubernetes クラスタ間で Cassandra ポート 7000 と 7001 を開きます（トラブルシューティング中にバックアップオプションとして 7000 を使用できます）。

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

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

シード名を取得する前に、kubectl コンテキストを元のクラスタに設定します。
```
kubectl config use-context original-cluster-name
```
次の kubectl コマンドを実行して、現在のリージョンの Cassandra のシードホストアドレスを特定します。

シードホストアドレスによって、新しいリージョンインスタンスは最初の起動時に元のクラスタを検索し、クラスタのトポロジを学習できます。シードホストアドレスは、クラスタ内のコンタクトポイントとなります。
```
kubectl get pods -o wide -n apigee | grep apigee-cassandra

apigee-cassandra-default-0  1/1   Running   0   4d17h   120.38.1.9  aks-agentpool-21207753-vmss000000
```
前のコマンドで返された IP の中からマルチリージョンシードホストにするものを決めます。この例では、単一ノードの Cassandra クラスタのみが動作しており、シードホストは 120.38.1.9 です。
データセンター 2 で、オーバーライドファイルのコピーを作成します。新しいファイルの名前にはクラスタ名を含めます。例: overrides_your_cluster_name.yaml。
データセンター 2 の overrides_your_cluster_name.yaml で、cassandra.multiRegionSeedHost と cassandra.datacenter を構成します。ここで multiRegionSeedHost は、前のコマンドで返された IP の一つです。
```
cassandra:
  multiRegionSeedHost: seed_host_IP
  datacenter: data_center_name
  rack: rack_name
```
次に例を示します。
```
cassandra:
  multiRegionSeedHost: 120.38.1.9
  datacenter: "centralus"
  rack: "ra-1"
```
新しいデータセンター / リージョンで、ハイブリッドをインストールする前に、最初のリージョンで設定したものと同じ TLS 証明書と認証情報を overrides_your_cluster_name.yaml で設定します。
注: 元のデータセンターで指定した Cassandra の TLS 証明書と認証情報を 2 番目のデータセンターでも使用してください。最初のデータセンターのオーバーライドファイルで設定した認証情報と 2 番目のデータセンターのオーバーライドファイルで指定する認証情報は一致している必要があります。詳細については、Cassandra 用の TLS の構成をご覧ください。

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

シードホストを構成したら、新しいリージョンを設定できます。

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

証明書を既存のクラスタから新しいクラスタにコピーします。新しい CA ルートは、Cassandra などのハイブリッドコンポーネントによって mTLS に使用されます。したがって、クラスタ全体で一貫した証明書を使用することが不可欠です。
1. コンテキストを元の Namespace に設定します。
```
kubectl config use-context original-cluster-name
```
2. 現在の名前空間の構成をファイルにエクスポートします。
```
$ kubectl get namespace 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」を必ず更新してください。
```
kubectl apply -f apigee-namespace.yaml
```
6. 新しいクラスタに Secret をインポートします。
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
新しいリージョンにハイブリッドをインストールします。前のセクションで説明したように、overrides_your_cluster_name.yaml ファイルでは、最初のリージョンで構成したものと同じ TLS 証明書を指定してください。
次の 2 つのコマンドを実行して、ハイブリッドを新しいリージョンにインストールします。
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
新しいデータセンターのすべてのノードで nodetool rebuild を順次実行します。データサイズに応じて数分から数時間かかることがあります。
```
kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password rebuild -- dc-1
```
ここで、JMX_user と JMX_password は Cassandra JMX ユーザーのユーザー名とパスワードです。

ログで再ビルドプロセスを確認します。また、nodetool status コマンドを使用してデータサイズを確認します。

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

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status

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

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

シードホストを更新します。overrides-DC_name.yaml から multiRegionSeedHost: 10.0.0.11 を削除してから再度適用します。
シードホストはローカルクラスタのメンバーです。新しいリージョンを起動するには、外部シードホストが必要になります。リージョンが起動したら、overrides.yaml でシードホストをローカルクラスタに戻してから構成を再度適用する必要があります。
```
apigeectl apply -f overrides-DC_name.yaml
```