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 multiregionalen Clustern in separate Cluster verschieben.

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

Beschränkungen

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

Wenn Sie Organisationsdaten in einen neuen Kubernetes-Cluster verschieben, können Daten verloren gehen. Sie sollten die Daten für alle Organisationen im Kubernetes-Cluster sichern. Lesen Sie dazu die Anleitung zur Hybrid-Sicherung, 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 Hybrid-Bereitstellung enthält. Die Migration zu einem Cluster mit einer vorhandenen Hybrid-Bereitstellung 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 eine 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 Hybrid-Organisation von einem Kubernetes-Cluster in einen anderen zu migrieren:

Sofern noch nicht geschehen, aktivieren Sie Sicherungen im Kubernetes-Cluster mit der zu migrierenden Hybrid-Organisation. Weitere Informationen zu Hybrid-Sicherungen finden Sie unter Cassandra-Sicherungsübersicht.
Starten Sie die Hybrid-Sicherung mit folgendem 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 Monitoring von Sicherungen, ob die Sicherung erfolgreich abgeschlossen wurde:
- „Status des Sicherungsjobs prüfen“
- „Sicherungslogs prüfen“
Nachdem Sie geprüft haben, ob die Sicherung erfolgreich war, notieren Sie sich die ID-Nummer am Ende des Sicherungslogs. Beispiel: Ein erfolgreiches Sicherungslog sollte eine Zeile wie die folgende enthalten:
```
INFO: completed upload for 20230207004250
```
Notieren Sie sich die mehrstellige Zahl am Zeilenende. Sie benötigen diese Zahl 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 Ziel-Hybrid-Bereitstellung 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-Hybrid-Bereitstellung 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 folgenden 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 Pod apigee-cassandra-default-0.
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 die Eingabeaufforderung cqlsh erhalten haben.
6. Führen Sie in der Eingabeaufforderung cqlsh die folgenden Befehle 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. c. 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 und die Organisation fest, die außer Betrieb genommen werden soll.
  
  Listen Sie Ihre aktuellen Kontexte auf, um den Kontextnamen für jeden Cluster anzeigen zu lassen:
```
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 diesen Vorgang 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 folgenden 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 Pod apigee-cassandra-default-0.
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 nach der cqlsh-Eingabeaufforderung die folgenden Befehle 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, den folgenden 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 „_“.

Organisation zu einem anderen Cluster migrieren Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Beschränkungen

Organisation migrieren

Namen der migrierten Organisation abrufen

Organisation zu einem anderen Cluster migrieren