Cassandra-Pods werden in der sekundären Region nicht gestartet

Sie lesen gerade die Dokumentation zu Apigee und Apigee Hybrid.
Apigee Edge-Dokumentation aufrufen.

Symptom

Cassandra-Pods starten in einer der Regionen in einer multiregionalen Apigee Hybrid-Konfiguration nicht. Wenn Sie die Datei overrides.yaml anwenden, werden die Cassandra-Pods nicht erfolgreich gestartet.

Fehlermeldungen

  1. In den Cassandra-Pod-Logs wird die folgende Fehlermeldung angezeigt:
    Exception (java.lang.RuntimeException) encountered during startup:
    A node with address 10.52.18.40 already exists, cancelling join.
    use cassandra.replace_addrees if you want to replace this node.
    
  2. Im Cassandra-Pod-Status können Sie möglicherweise folgende Warnung sehen:

Mögliche Ursachen

Dieses Problem tritt normalerweise im folgenden Szenario auf:

  1. Der Apigee-Laufzeitcluster ist in einer der Regionen gelöscht.
  2. Ein Versuch der Neuinstallation des Apigee-Laufzeitclusters wird in der Region mit der Cassandra-Seed-Hostkonfiguration in der overrides.yaml-Datei unternommen, wie in Multiregionale Bereitstellung in GKE und GKE On-Prem beschrieben.
  3. Durch das Löschen des Apigee-Laufzeitclusters werden die Verweise im Cassandra-Cluster nicht entfernt. Daher werden die veralteten Referenzen der Cassandra-Pods im gelöschten Cluster beibehalten. Aus diesem Grund melden die Cassandra-Pods bei der Neuinstallation des Apigee-Laufzeitclusters in der sekundären Region, dass bestimmte IP-Adressen bereits vorhanden sind. Das liegt daran, dass die IP-Adressen möglicherweise aus demselben Subnetz zugewiesen werden, das zuvor verwendet wurde.
Ursache Beschreibung
Veraltete Verweise auf gelöschte Pods aus sekundären Regionen im Cassandra-Cluster Durch das Löschen des Apigee-Laufzeitclusters in der sekundären Region werden die Verweise auf IP-Adressen von Cassandra-Pods in der sekundären Region nicht entfernt.

Ursache: Veraltete Verweise auf gelöschte Pods aus sekundären Regionen im Cassandra-Cluster

Diagnose

  1. Die Fehlermeldung in den Cassandra-Pod-Logs A node with address 10.52.18.40 already exists gibt an, dass ein veralteter Verweis auf einen der sekundären Region-Cassandra-Pods mit der IP-Adresse 10.52.18.40 vorhanden ist. Führen Sie den Befehl nodetool status in der primären Region aus, um dies zu prüfen.

    Beispielausgabe:

    Das obige Beispiel zeigt, dass die IP-Adresse 10.52.18.40, die mit Cassandra-Pods der sekundären Region verknüpft ist, weiterhin in der Ausgabe aufgeführt wird.

  2. Wenn die Ausgabe die veralteten Verweise auf Cassandra-Pods in der sekundären Region enthält, gibt dies an, dass die sekundäre Region gelöscht wurde, aber die IP-Adressen der Cassandra-Pods in der sekundären Region nicht entfernt wurden.

Lösung

Führen Sie die folgenden Schritte aus, um die veralteten Verweise von Cassandra-Pods des gelöschten Clusters zu entfernen:

  1. Melden Sie sich im Container an und stellen Sie eine Verbindung zur Cassandra-Befehlszeile her. Führen Sie dazu die Schritte unter Client-Container erstellen aus.
  2. Nachdem Sie sich im Container angemeldet und eine Verbindung zur Cassandra-Schnittstelle cqlsh hergestellt haben, führen Sie die folgende SQL-Abfrage aus, um die aktuellen keyspace-Definitionen aufzulisten:
    select * from system_schema.keyspaces;
    

    Beispielausgabe mit aktuellen Schlüsselbereichen:

    In der folgenden Ausgabe bezieht sich Primary-DC1 auf die primäre Region und Secondary-DC2 auf die sekundäre Region.

    bash-4.4# cqlsh 10.50.112.194 -u admin_user -p ADMIN.PASSWORD --ssl
    Connected to apigeecluster at 10.50.112.194:9042.
    [cqlsh 5.0.1 | Cassandra 3.11.6 | CQL spec 3.4.4 | Native protocol v4]
    Use HELP for help.
    
    admin_user@cqlsh> Select * from system_schema.keyspaces;
    
    keyspace_name                        | durable_writes | replication
    -------------------------------------+----------------+--------------------------------------------------------------------------------------------------
    system_auth                          |           True | {'Primary-DC1': '3', 'Secondary-DC2': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'}
    kvm_tsg1_apigee_hybrid_prod_hybrid   |           True | {'Primary-DC1': '3', 'Secondary-DC2': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'}
    kms_tsg1_apigee_hybrid_prod_hybrid   |           True | {'Primary-DC1': '3', 'Secondary-DC2': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'}
    system_schema                        |           True |                                           {'class': 'org.apache.cassandra.locator.LocalStrategy'}
    system_distributed                   |           True | {'Primary-DC1': '3', 'Secondary-DC2': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'}
    system                               |           True |                                           {'class': 'org.apache.cassandra.locator.LocalStrategy'}
    perses                               |           True | {'Primary-DC1': '3', 'Secondary-DC2': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'}
    cache_tsg1_apigee_hybrid_prod_hybrid |           True | {'Primary-DC1': '3', 'Secondary-DC2': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'}
    rtc_tsg1_apigee_hybrid_prod_hybrid   |           True | {'Primary-DC1': '3', 'Secondary-DC2': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'}
    quota_tsg1_apigee_hybrid_prod_hybrid |           True | {'Primary-DC1': '3', 'Secondary-DC2': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'}
    system_traces                        |           True | {'Primary-DC1': '3', 'Secondary-DC2': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'}
    (11 rows)

    Wie Sie sehen, beziehen sich keyspaces auf Primary-DC1 und Secondary-DC2, obwohl der Apigee-Laufzeitcluster in der sekundären Region gelöscht wurde.

    Die veralteten Verweise auf Secondary-DC2 müssen aus jeder der keyspace-Definitionen gelöscht werden.

  3. Bevor Sie die veralteten Referenzen in den keyspace-Definitionen löschen, verwenden Sie den folgenden Befehl, um die gesamte Hybridinstallation von Apigee mit Ausnahme von ASM (Istio) und cert-manager aus Secondary-DC2 zu löschen. Weitere Informationen finden Sie unter Hybridlaufzeit deinstallieren.
    apigeectl delete -f YOUR_OVERRIDES_FILE.yaml --all
    
  4. Entfernen Sie die veralteten Verweise auf Secondary-DC2 aus jedem der keyspaces, indem Sie die keyspace-Definition ändern.
    ALTER KEYSPACE system_auth WITH replication = {'Primary-DC1': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'};
    ALTER KEYSPACE kvm_tsg1_apigee_hybrid_prod_hybrid WITH replication = {'Primary-DC1': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'};
    ALTER KEYSPACE kms_tsg1_apigee_hybrid_prod_hybrid WITH replication = {'Primary-DC1': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'};
    ALTER KEYSPACE system_distributed WITH replication = {'Primary-DC1': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'};
    ALTER KEYSPACE perses WITH replication = {'Primary-DC1': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'};
    ALTER KEYSPACE cache_tsg1_apigee_hybrid_prod_hybrid WITH replication = {'Primary-DC1': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'};
    ALTER KEYSPACE rtc_tsg1_apigee_hybrid_prod_hybrid WITH replication = {'Primary-DC1': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'};
    ALTER KEYSPACE quota_tsg1_apigee_hybrid_prod_hybrid WITH replication = {'Primary-DC1': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'};
    ALTER KEYSPACE system_traces WITH replication = {'Primary-DC1': '3', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'};
    
  5. Prüfen Sie mit dem folgenden Befehl, ob die veralteten Verweise auf die Region Secondary-DC2 aus allen keyspaces entfernt wurden:
    select * from system_schema.keyspaces;
    
  6. Melden Sie sich in einem Cassandra-Pod der Primary-DC1 an und entfernen Sie die Verweise auf UUIDs aller Cassandra-Pods von Secondary-DC2. Die UUIDs können mit dem Befehl nodetool status wie unter Diagnose beschrieben abgerufen werden.
    kubectl exec -it -n apigee apigee-cassandra-default-0 -- bash
    nodetool -u admin_user -pw ADMIN.PASSWORD removenode UUID_OF_CASSANDRA_POD_IN_SECONDARY_DC2
    
  7. Prüfen Sie, dass keine Cassandra-Pods von Secondary-DC2 vorhanden sind, indem Sie den Befehl nodetool status noch einmal ausführen.
  8. Installieren Sie den Apigee-Laufzeitcluster in der sekundären Region (Secondary-DC2), indem Sie die Schritte unter Multiregionale Bereitstellung in GKE und GKE On-Prem ausführen.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem auch nach Befolgen der obigen Anweisungen weiterhin besteht, sammeln Sie die folgenden Diagnoseinformationen und wenden Sie sich dann an Google Cloud Customer Care:

  1. Die Google Cloud-Projekt-ID
  2. Der Name der Apigee Hybrid-Organisation
  3. Die overrides.yaml-Dateien aus der primären und der sekundären Region, wobei vertrauliche Informationen maskiert werden.
  4. Kubernetes-Pod-Status in allen Namespaces der primären und sekundären Region:
    kubectl get pods -A > kubectl-pod-status`date +%Y.%m.%d_%H.%M.%S`.txt
    
  5. Ein Kubernetes-Dump cluster-info aus der primären und der sekundären Region:
    # generate kubernetes cluster-info dump
    kubectl cluster-info dump -A --output-directory=/tmp/kubectl-cluster-info-dump
    
    # zip kubernetes cluster-info dump
    zip -r kubectl-cluster-info-dump`date +%Y.%m.%d_%H.%M.%S`.zip /tmp/kubectl-cluster-info-dump/*
    
  6. Die Ausgabe der folgenden nodetool-Befehle aus der primären Region.
    export u=`kubectl -n apigee get secrets apigee-datastore-default-creds -o jsonpath='{.data.jmx\.user}' | base64 -d`
    export pw=`kubectl -n apigee get secrets apigee-datastore-default-creds -o jsonpath='{.data.jmx\.password}' | base64 -d`
    
    kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u $u -pw $pw info 2>&1 | tee /tmp/k_nodetool_info_$(date +%Y.%m.%d_%H.%M.%S).txt
    kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u $u -pw $pw describecluster 2>&1 | tee /tmp/k_nodetool_describecluster_$(date +%Y.%m.%d_%H.%M.%S).txt
    kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u $u -pw $pw failuredetector 2>&1 | tee /tmp/k_nodetool_failuredetector_$(date +%Y.%m.%d_%H.%M.%S).txt
    kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u $u -pw $pw status 2>&1 | tee /tmp/k_nodetool_status_$(date +%Y.%m.%d_%H.%M.%S).txt
    kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u $u -pw $pw gossipinfo 2>&1 | tee /tmp/k_nodetool_gossipinfo_$(date +%Y.%m.%d_%H.%M.%S).txt
    kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u $u -pw $pw netstats 2>&1 | tee /tmp/k_nodetool_netstats_$(date +%Y.%m.%d_%H.%M.%S).txt
    kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u $u -pw $pw proxyhistograms 2>&1 | tee /tmp/k_nodetool_proxyhistograms_$(date +%Y.%m.%d_%H.%M.%S).txt
    kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u $u -pw $pw tpstats 2>&1 | tee /tmp/k_nodetool_tpstats_$(date +%Y.%m.%d_%H.%M.%S).txt
    kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u $u -pw $pw gcstats 2>&1 | tee /tmp/k_nodetool_gcstats_$(date +%Y.%m.%d_%H.%M.%S).txt
    kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u $u -pw $pw version 2>&1 | tee /tmp/k_nodetool_version_$(date +%Y.%m.%d_%H.%M.%S).txt
    kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u $u -pw $pw ring 2>&1 | tee /tmp/k_nodetool_ring_$(date +%Y.%m.%d_%H.%M.%S).txt
          

Verweise