組織を別のクラスタに移行する

このページでは、Apigee ハイブリッド組織を Kubernetes クラスタ間で移行する方法について説明します。以下のように、組織を別のクラスタに移行することが必要になる場合があります。

既存のクラスタをホストするデータセンターの容量が不足しているか、データセンターが廃止される。
クラスタで古いインフラストラクチャまたは古いバージョンの Kubernetes が実行されているため、新しいインフラストラクチャを持つクラスタに移行する必要がある。
組織を複数の組織で構成されるクラスタから個別のクラスタに移行する必要がある。

組織を別のハイブリッドクラスタに移行する場合、リスクと制限事項があります。移行する前に、制限事項セクションの詳細をご確認ください。

制限事項

ハイブリッド組織を別の Kubernetes クラスタに移行する場合は、以下の制限事項が適用されます。

組織のデータを新しい Kubernetes クラスタに移動する場合は、データ損失のリスクがあります。組織を移行する前に、ハイブリッドバックアップ手順に沿って Kubernetes クラスタ内のすべての組織のデータをバックアップしてください。
組織の移行でサポートされる最大データサイズは、組織のすべてのキースペースで 5 GB です（キャッシュと割り当てを除く）。
キャッシュデータは移行されません。ハイブリッドでは、キャッシュデータは再構築されます。
割り当てデータは移行されません。ハイブリッドでは、割り当てデータはリセットされます。
組織は、既存のハイブリッドデプロイを含まない Kubernetes クラスタにのみ移行できます。既存のハイブリッドデプロイによるクラスタへの移行はサポート対象外です。
移行対象の組織は、単一のリージョンデプロイで新しいクラスタにのみ移動できます。単一のリージョンデプロイが実行されたら、マルチリージョンデプロイで説明されているリージョン拡張プロセスに従って他のリージョンに拡張できます。
Cassandra クラスタは、すべてのリージョンで正常に動作している必要があります。

組織の移行

以下の手順で、ハイブリッド組織を Kubernetes クラスタ間で移行します。

有効になっていない場合は、移行するハイブリッド組織を含む Kubernetes クラスタでバックアップを有効にします。ハイブリッドバックアップについては、Cassandra のバックアップの概要をご覧ください。
次のコマンドを使用して、ハイブリッドバックアップジョブを開始します。
```
kubectl create job -n APIGEE_NAMESPACE --from=cronjob/apigee-cassandra-backup <backup job name>
```
<backup job name> は、任意の有効なコンテナの名前です。
バックアップジョブが完了したら、バックアップのモニタリングの以下のセクションに示された手順に沿って、バックアップが正常に完了したことを確認します。
- 「バックアップジョブのステータスを確認する」
- 「バックアップログを確認する」
バックアップが正常に完了したことを確認したら、バックアップログの末尾にある ID 番号をメモします。たとえば、正常なバックアップログには次のような行が表示されます。
```
INFO: completed upload for 20230207004250
```
行の末尾にある複数桁の番号をメモしておきます。この番号は後で必要になります。
Kubernetes コンテキストを移行先の Kubernetes クラスタに切り替えます。
```
kubectl config use-context <destination cluster name> # <destination cluster name>
```
ここで、<destination cluster name> は移行先の Kubernetes クラスタの名前です。
単一リージョンでの復元の手順に沿って、バックアップデータを移行先の Kubernetes クラスタに復元します。
- 移行する組織の overrides.yaml ファイルを移行先のハイブリッドデプロイに使用します。
- restore:snapshotTimestamp の値を、手順 4 でバックアップログに表示された複数桁の番号に設定します。単一リージョンでの復元をご覧ください。
復元が完了したら、移行する組織以外のデータを移行先の Kubernetes クラスタから削除します。ハイブリッドバックアップファイルには、移行する必要がない組織を含むすべての組織のデータが含まれています。移行先のハイブリッドデプロイが復元されたら、デプロイにコピーされた余分な組織のデータを次の手順に沿って削除する必要があります。
1. 現在のコンテキストが、移行先の Kubernetes クラスタの正しいコンテキストであることを確認します。
```
kubectl config current-context
```
2. apigee-cassandra-default-0 Pod を実行します。
```
kubectl exec -it -n APIGEE_NAMESPACE apigee-cassandra-default-0 -- /bin/bash
```
3. 次のコマンドを実行します。
```
find /opt/apigee/data/apigee-cassandra/ -iname '*_hybrid' -not -iname '*<migrated org name>*' -type d -maxdepth 2 -printf "%f\n"
```
  <migrated org name> を確認する手順については、移行した組織の名前を取得するをご覧ください。
  
  出力に表示されるすべての名前のリストをコピーします。このリストは手順 7 の f で必要になります。
4. apigee-cassandra-default-0 Pod を終了します。
5. デバッグ用のクライアントコンテナを作成する手順に沿って、Cassandra のデバッグクライアント Pod を作成します。cqlsh プロンプトが表示されたら、次の手順に進みます。
6. cqlsh プロンプトで次のコマンドを実行します。
  - ```
  desc keyspaces;
```
  このコマンドがエラーを返さないことを確認します。
- 手順 7 の c で作成したリストの名前ごとに、次のコマンドを実行します。
```
  drop keyspace <name>
```
7. Cassandra デバッグクライアント Pod を終了します。
8. cqlsh コマンドの実行後、移行先の Kubernetes クラスタ内のすべての Cassandra Pod で次のコマンドを実行します。
  - ```
  kubectl exec -it -n APIGEE_NAMESPACE  -- /bin/bash
```
- ```
find /opt/apigee/data/apigee-cassandra/ -iname '*_hybrid' -not -iname '*<migrated org name>*' -type d -maxdepth 2
```
    <migrated org name> を確認する手順については、移行した組織の名前を取得するをご覧ください。
  - ```
  find /opt/apigee/data/apigee-cassandra/ -iname '*_hybrid' -not -iname '**' -type d -maxdepth 2 -exec rm -rf {} +
```
9. Cassandra Pod を終了します。
Kubernetes コンテキストを移行元の Kubernetes クラスタに切り替えます。
```
kubectl config use-context <source cluster name>
```
ここで、<source cluster name> は移行元の Kubernetes クラスタの名前です。
移行した組織を移行元の Kubernetes クラスタから削除します。削除コマンドでは、必ず組織の overrides.yaml ファイルを使用してください。
1. 現在のコンテキストが移行元の Kubernetes クラスタの正しいコンテキストであることを確認します。
```
kubectl config current-context
```
  必要に応じて、Kubernetes コンテキストをクラスタに設定し、組織を廃止する必要があります。
  
  現在のコンテキストを一覧取得して、各クラスタのコンテキスト名を確認します。
```
kubectl config get-contexts
```
  廃止するクラスタとリージョンにコンテキストを設定します。
```
kubectl config use-context CONTEXT_NAME
```
  ここで、CONTEXT_NAME はクラスタとリージョンのコンテキスト名です。
  
  例:
```
    kubectl config get-contexts
    CURRENT   NAME                                                   CLUSTER                                                AUTHINFO                                               NAMESPACE
              gke_example-org-1_us-central1_example-cluster-1        gke_example-org-1_us-central1_example-cluster-1        gke_example-org-1_us-central1_example-cluster-1        apigee
    *         gke_example-org-1_us-central1_example-cluster-2        gke_example-org-1_us-central1_example-cluster-2        gke_example-org-1_us-central1_example-cluster-2        apigee
              gke_example-org-1_us-west1_example-cluster-2           gke_example-org-1_us-west1_example-cluster-2           gke_example-org-1_us-west1_example-cluster-2           apigee

    kubectl config use-context gke_example-org-1_us-west1_example-cluster-2
```
2. 仮想ホストを削除します。この手順を環境グループごとに繰り返します。
```
helm -n APIGEE_NAMESPACE delete ENV_GROUP_NAME
```
3. 環境を削除します。この手順を環境ごとに繰り返します。
```
helm -n APIGEE_NAMESPACE delete ENV_NAME
```
4. Apigee 組織を削除します。
```
helm -n APIGEE_NAMESPACE delete ORG_NAME
```
5. apigee-cassandra-default-0 Pod に次のコマンドを実行します。
```
kubectl exec -it -n APIGEE_NAMESPACE apigee-cassandra-default-0 -- /bin/bash
```
6. 次のコマンドを実行します。
```
find /opt/apigee/data/apigee-cassandra/ -iname '*<migrated org name>_hybrid' -type d -maxdepth 2 -printf "%f\n"
```
  <migrated org name> を確認する手順については、移行した組織の名前を取得するをご覧ください。
  
  出力に表示されるすべての名前のリストをコピーします。このリストは、手順 9 の j で必要になります。
7. apigee-cassandra-default-0 Pod を終了します。
8. デバッグ用のクライアントコンテナを作成する手順に沿って、Cassandra のデバッグクライアント Pod を作成します。cqlsh プロンプトが表示されたら、次の手順に進みます。
9. cqlsh プロンプトで次のコマンドを実行します。
```
desc keyspaces;
```
  このコマンドがエラーを返さないことを確認します。
10. 手順 10 の f で作成したリストの名前ごとに、次のコマンドを実行します。
```
drop keyspace <name>;
```
11. Cassandra デバッグクライアント Pod を終了します。
12. Cassandra Pod を終了します。

移行した組織の名前を取得する

前のセクションで説明した手順の一部では、移行した組織の名前が必要です。移行した組織の名前を取得するには、次の操作を行います。

組織の overrides.yaml ファイルから組織名を取得します。移行する組織の overrides.yaml ファイルを必ず確認してください。
組織名にダッシュ「-」が含まれている場合は、すべてのダッシュ「-」をアンダースコア「_」に置き換えます。