Organisation zu einem anderen Cluster migrieren

Auf dieser Seite wird beschrieben, wie Sie eine Apigee Hybrid-Organisation von einem Kubernetes-Cluster zu einem anderen migrieren. In folgenden Fällen müssen Sie eine Organisation möglicherweise zu einem anderen Cluster migrieren:

Das Rechenzentrum, in dem der vorhandene Cluster gehostet wird, hat keine Kapazität mehr oder wird außer Betrieb genommen.
Der Cluster führt eine alte Infrastruktur oder eine alte Version von Kubernetes aus und Sie möchten zu einem Cluster mit neuerer Infrastruktur migrieren.
Sie möchten Organisationen aus Multi-Organisations-Clustern in separate Cluster verschieben.

Beachten Sie, dass bei der Migration einer Organisation in einen anderen Hybridcluster Risiken und Einschränkungen bestehen. Lesen Sie die Details im Abschnitt Einschränkungen, bevor Sie eine Migration ausführen.

Beschränkungen

Die folgenden Einschränkungen gelten bei der Migration einer Hybridorganisation zu einem anderen Kubernetes-Cluster:

Wenn Sie Organisationsdaten in einen neuen Kubernetes-Cluster verschieben, besteht das Risiko eines Datenverlusts. Sie sollten die Daten für alle Organisationen im Kubernetes-Cluster sichern. Verwenden Sie dazu die Anleitung zur Hybridsicherung, bevor Sie eine Organisation migrieren.
Die maximale Datengröße, die für die Organisationsmigration unterstützt wird, beträgt 5 GB für alle Schlüsselbereiche einer Organisation, ohne Cache und Kontingent.
Cache-Daten werden nicht migriert. Hybrid erstellt Cache-Daten neu.
Kontingentdaten werden nicht migriert. Hybrid setzt Kontingentdaten zurück.
Sie können Organisationen nur zu einem Kubernetes-Cluster migrieren, der keine vorhandene Hybridbereitstellung enthält. Die Migration zu einem Cluster mit einer vorhandenen Hybridbereitstellung wird nicht unterstützt.
Die zu migrierende Organisation kann nur in einen neuen Cluster mit einer einzigen Regionsbereitstellung verschoben werden. Nachdem die Bereitstellung für eine einzelne Region abgeschlossen ist, können Sie den Vorgang der Regionserweiterung ausführen, wie unter Multiregionale Bereitstellung beschrieben, um auf andere Regionen zu erweitern.
Der Cassandra-Cluster sollte in allen Regionen fehlerfrei funktionieren.

Organisation migrieren

Folgen Sie der Anleitung unten, um eine Hybridorganisation von einem Kubernetes-Cluster in einen anderen zu migrieren:

Wenn nicht bereits aktiviert, aktivieren Sie Sicherungen im Kubernetes-Cluster mit der zu migrierenden Hybridorganisation. Weitere Informationen zu Hybridsicherungen finden Sie unter Cassandra-Sicherungsübersicht.
Starten Sie den Hybrid-Sicherungsjob mit dem folgenden Befehl:
```
kubectl create job -n APIGEE_NAMESPACE --from=cronjob/apigee-cassandra-backup <backup job name>
```
<backup job name> kann ein beliebiger gültiger Containername sein.
Nachdem der Sicherungsjob abgeschlossen ist, prüfen Sie anhand der Anleitung in den folgenden Abschnitten unter Sicherungen überwachen, ob die Sicherung erfolgreich abgeschlossen wurde:
- „Status des Sicherungsjobs prüfen“
- „Sicherungslogs prüfen“
Nachdem Sie überprüft haben, ob die Sicherung erfolgreich war, notieren Sie sich die ID-Nummer am Ende des Sicherungslogs. Ein erfolgreiches Sicherungslog sollte beispielsweise eine Zeile wie die folgende enthalten:
```
INFO: completed upload for 20230207004250
```
Notieren Sie sich die mehrstellige Nummer am Zeilenende. Sie benötigen diese Nummer später.
Wechseln Sie den Kubernetes-Kontext zum Kubernetes-Zielcluster:
```
kubectl config use-context <destination cluster name> # <destination cluster name>
```
Dabei ist <destination cluster name> der Name des Kubernetes-Zielclusters.
Stellen Sie die Sicherungsdaten gemäß der Anleitung unter In einer einzelnen Region wiederherstellen im Kubernetes-Zielcluster wieder her.
- Verwenden Sie die Datei overrides.yaml für die Organisation, die zur Bereitstellung in der Ziel-Hybrid migriert wird.
- Denken Sie daran, den Wert restore:snapshotTimestamp auf die mehrstellige Zahl zu setzen, die im Sicherungslog in Schritt 4 angezeigt wird. Siehe In einer einzelnen Region wiederherstellen.
Löschen Sie nach Abschluss der Wiederherstellung alle Organisationsdaten mit Ausnahme der Daten für die Organisation, die migriert wird, aus dem Kubernetes-Zielcluster. Hybrid-Sicherungsdateien enthalten die Daten für alle Organisationen, einschließlich derjenigen, die Sie möglicherweise nicht migrieren möchten. Nachdem die Ziel-Hybridbereitstellung wiederhergestellt wurde, müssen Sie alle zusätzlichen Organisationsdaten entfernen, die in die Bereitstellung kopiert wurden. Gehen Sie dazu so vor:
1. Prüfen Sie, ob der aktuelle Kontext der richtige Kontext für den Kubernetes-Zielcluster ist:
```
kubectl config current-context
```
2. Führen Sie den Pod apigee-cassandra-default-0 aus:
```
kubectl exec -it -n APIGEE_NAMESPACE apigee-cassandra-default-0 -- /bin/bash
```
3. Führen Sie diesen Befehl aus:
```
find /opt/apigee/data/apigee-cassandra/ -iname '*_hybrid' -not -iname '*<migrated org name>*' -type d -maxdepth 2 -printf "%f\n"
```
  Eine Anleitung zum Suchen von <migrated org name> finden Sie unter Name der migrierten Organisation abrufen.
  
  Kopieren Sie die Liste aller Namen, die in der Ausgabe angezeigt werden. Diese Liste benötigen Sie in Schritt 7. f.
4. Beenden Sie den apigee-cassandra-default-0-Pod.
5. Erstellen Sie einen Cassandra-Debugging-Client-Pod mithilfe der Anleitung unter Client-Container zur Fehlerbehebung erstellen. Fahren Sie mit dem nächsten Schritt fort, nachdem Sie eine cqlsh-Eingabeaufforderung erhalten haben.
6. Führen Sie die folgenden Befehle in der Eingabeaufforderung cqlsh aus:
  - ```
  desc keyspaces;
```
  Achten Sie darauf, dass dieser Befehl keine Fehler zurückgibt.
- Führen Sie für jeden Namen in der in Schritt 7 erstellten Liste den folgenden Befehl aus:
```
  drop keyspace <name>
```
7. Beenden Sie den Cassandra-Debugging-Client-Pod.
8. Führen Sie nach der Ausführung der cqlsh-Befehle die folgenden Befehle auf allen Cassandra-Pods im Kubernetes-Zielcluster aus:
  - ```
  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
```
    Eine Anleitung zum Suchen von <migrated org name> finden Sie unter Name der migrierten Organisation abrufen.
  - ```
  find /opt/apigee/data/apigee-cassandra/ -iname '*_hybrid' -not -iname '**' -type d -maxdepth 2 -exec rm -rf {} +
```
9. Beenden Sie den Cassandra-Pod.
Wechseln Sie den Kubernetes-Kontext zum Kubernetes-Quellcluster:
```
kubectl config use-context <source cluster name>
```
Dabei ist <source cluster name> der Name des Kubernetes-Quellclusters.
Löschen Sie die migrierte Organisation aus dem Kubernetes-Quellcluster. Achten Sie darauf, für die Organisation die Datei overrides.yaml im Löschbefehl zu verwenden:
1. Prüfen Sie, ob der aktuelle Kontext der richtige Kontext für den Kubernetes-Quellcluster ist:
```
kubectl config current-context
```
  Legen Sie bei Bedarf die Kubernetes-Kontexte für den Cluster fest und die Organisation muss außer Betrieb genommen werden.
  
  Listen Sie Ihre aktuellen Kontexte auf, um den Kontextnamen für jeden Cluster anzuzeigen:
```
kubectl config get-contexts
```
  Legen Sie den Kontext auf den Cluster und die Region fest, die Sie außer Betrieb nehmen möchten:
```
kubectl config use-context CONTEXT_NAME
```
  Dabei ist CONTEXT_NAME der Kontextname für den Cluster und die Region.
  
  Beispiel:
```
    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. Löschen Sie den Virtualhost. Wiederholen Sie das für jede Umgebungsgruppe:
```
helm -n APIGEE_NAMESPACE delete ENV_GROUP_NAME
```
3. Löschen Sie die Umgebungen. Wiederholen Sie diesen Vorgang für jede Umgebung:
```
helm -n APIGEE_NAMESPACE delete ENV_NAME
```
4. Löschen Sie die Apigee-Organisation.
```
helm -n APIGEE_NAMESPACE delete ORG_NAME
```
5. Führen Sie den Pod "apigee-cassandra-default-0" aus:
```
kubectl exec -it -n APIGEE_NAMESPACE apigee-cassandra-default-0 -- /bin/bash
```
6. Führen Sie diesen Befehl aus:
```
find /opt/apigee/data/apigee-cassandra/ -iname '*<migrated org name>_hybrid' -type d -maxdepth 2 -printf "%f\n"
```
  Eine Anleitung zum Suchen von <migrated org name> finden Sie unter Name der migrierten Organisation abrufen.
  
  Kopieren Sie die Liste aller Namen, die in der Ausgabe angezeigt werden. Sie benötigen diese Liste in Schritt 9. j.
7. Beenden Sie den apigee-cassandra-default-0-Pod.
8. Erstellen Sie einen Cassandra-Debugging-Client-Pod mithilfe der Anleitung unter Client-Container zur Fehlerbehebung erstellen. Fahren Sie mit dem nächsten Schritt fort, nachdem Sie eine cqlsh-Eingabeaufforderung erhalten haben.
9. Führen Sie die folgenden Befehle an der cqlsh-Eingabeaufforderung aus:
```
desc keyspaces;
```
  Achten Sie darauf, dass dieser Befehl keine Fehler zurückgibt.
10. Führen Sie für jeden Namen in der Liste, die in Schritt 10. f erstellt wurde, diesen Befehl aus:
```
drop keyspace <name>;
```
11. Beenden Sie den Cassandra-Debugging-Client-Pod.
12. Beenden Sie den Cassandra-Pod.

Namen der migrierten Organisation abrufen

Einige der im vorherigen Abschnitt beschriebenen Schritte erfordern den Namen der migrierten Organisation. So rufen Sie den Namen der migrierten Organisation ab:

Rufen Sie den Namen der Organisation aus der Datei overrides.yaml der Organisation ab. Prüfen Sie die Datei overrides.yaml für die zu migrierende Organisation.
Wenn der Organisationsname Bindestriche „-“ enthält, ersetzen Sie alle Bindestriche „-“ durch Unterstriche „_“.