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
- 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.
Im Cassandra-Pod-Status können Sie möglicherweise folgende Warnung sehen:
Mögliche Ursachen
Dieses Problem tritt normalerweise im folgenden Szenario auf:
- Der Apigee-Laufzeitcluster ist in einer der Regionen gelöscht.
- 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. - 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
- 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-Adresse10.52.18.40
vorhanden ist. Führen Sie den Befehlnodetool 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. - 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:
- 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.
- 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 aktuellenkeyspace
-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 undSecondary-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
aufPrimary-DC1
undSecondary-DC2
, obwohl der Apigee-Laufzeitcluster in der sekundären Region gelöscht wurde.Die veralteten Verweise auf
Secondary-DC2
müssen aus jeder derkeyspace
-Definitionen gelöscht werden. - 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) undcert-manager
ausSecondary-DC2
zu löschen. Weitere Informationen finden Sie unter Hybridlaufzeit deinstallieren.apigeectl delete -f YOUR_OVERRIDES_FILE.yaml --all
- Entfernen Sie die veralteten Verweise auf
Secondary-DC2
aus jedem derkeyspaces
, indem Sie diekeyspace
-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'};
- Prüfen Sie mit dem folgenden Befehl, ob die veralteten Verweise auf die Region
Secondary-DC2
aus allenkeyspaces
entfernt wurden:select * from system_schema.keyspaces;
- Melden Sie sich in einem Cassandra-Pod der
Primary-DC1
an und entfernen Sie die Verweise auf UUIDs aller Cassandra-Pods vonSecondary-DC2
. Die UUIDs können mit dem Befehlnodetool 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
- Prüfen Sie, dass keine Cassandra-Pods von
Secondary-DC2
vorhanden sind, indem Sie den Befehlnodetool status
noch einmal ausführen. - 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:
- Die Google Cloud-Projekt-ID
- Der Name der Apigee Hybrid-Organisation
- Die
overrides.yaml
-Dateien aus der primären und der sekundären Region, wobei vertrauliche Informationen maskiert werden. - 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
- 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/*
- 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
- Multiregionale Bereitstellung in GKE und GKE On-Prem von Apigee Hybrid
- Kubernetes-Dokumentation
-
Cassandra
nodetool status
-Befehl