このページは Cloud Translation API によって翻訳されました。

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

このページでは、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 ファイルを必ず確認してください。
組織名にダッシュ「-」が含まれている場合は、すべてのダッシュ「-」をアンダースコア「_」に置き換えます。