Pod di Cassandra non avviati nell'area geografica secondaria

Stai visualizzando la documentazione di Apigee e Apigee hybrid.
Visualizza la documentazione di Apigee Edge.

Nota: questo documento è applicabile solo agli utenti ibridi di Apigee.

Sintomo

I pod Cassandra non vengono avviati in una delle regioni in una configurazione ibrida di Apigee multiregionali. Durante l'applicazione del file overrides.yaml, i pod Cassandra non si avviano correttamente.

Messaggi di errore

1. Nei log del pod Cassandra verrà visualizzato il seguente messaggio di errore:

   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. Potresti vedere il seguente avviso nello stato del pod Cassandra:

   

Cause possibili

Questo problema si verifica in genere nel seguente scenario:

1. Il cluster di runtime Apigee viene eliminato in una delle regioni.
2. Nella regione viene eseguito un tentativo di reinstallazione del cluster di runtime Apigee nella regione con la configurazione dell'host di origine Cassandra nel file overrides.yaml, come descritto in Deployment multiregionale su GKE e GKE on-prem.
3. L'eliminazione del cluster di runtime Apigee non rimuove i riferimenti nel cluster Cassandra. Pertanto, i riferimenti inattivi dei pod Cassandra nel cluster eliminato verranno conservati. Per questo motivo, quando provi a reinstallare il cluster di runtime Apigee nella regione secondaria, i pod Cassandra lamentano già determinati indirizzi IP. Questo perché gli indirizzi IP possono essere assegnati dalla stessa subnet utilizzata in precedenza.

Nota: in questo playbook, il termine regione principale si riferisce al cluster di runtime Apigee integro, mentre il termine regione secondaria si riferisce al cluster di runtime Apigee che viene eliminato e si tenta di reinstallarlo con la configurazione del seed di Cassandra che fa riferimento alla regione principale.

Causa	Descrizione
Riferimenti inattivi ai pod delle regioni secondarie eliminati nel cluster Cassandra	L'eliminazione del cluster di runtime Apigee nella regione secondaria non rimuove i riferimenti agli indirizzi IP dei pod Cassandra nella regione secondaria.

Causa: riferimenti inattivi a pod delle regioni secondarie eliminati nel cluster Cassandra

Diagnosi

1. Il messaggio di errore nei log del pod Cassandra A node with address 10.52.18.40 already exists indica l'esistenza di un riferimento inattivo a uno dei pod Cassandra della regione secondaria con l'indirizzo IP 10.52.18.40. Convalidalo eseguendo il comando nodetool status nella regione principale.

   Esempio di output:

   

   L'esempio riportato sopra mostra che l'indirizzo IP 10.52.18.40 associato ai pod Cassandra della regione secondaria è ancora elencato nell'output.

2. Se l'output contiene riferimenti inattivi ai pod Cassandra nella regione secondaria, indica che la regione secondaria è stata eliminata, ma gli indirizzi IP dei pod Cassandra nella regione secondaria non vengono rimossi.

Risoluzione

Esegui i passaggi seguenti per rimuovere i riferimenti inattivi dei pod Cassandra del cluster eliminato:

1. Accedi al container e connettiti all'interfaccia a riga di comando di Cassandra seguendo i passaggi descritti in Creare il container client.
2. Dopo aver effettuato l'accesso al container e aver effettuato la connessione all'interfaccia cqlsh di Cassandra, esegui la seguente query SQL per elencare le definizioni di keyspace attuali:

   select * from system_schema.keyspaces;
   

   Output di esempio che mostra gli spazi dei tasti attuali:

   Nel seguente output, Primary-DC1 si riferisce alla regione principale e Secondary-DC2 alla regione secondaria.

   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)

   Come puoi vedere, keyspaces si riferisce sia a Primary-DC1 che a Secondary-DC2, anche se il cluster di runtime Apigee è stato eliminato nella regione secondaria.

   I riferimenti inattivi a Secondary-DC2 devono essere eliminati da ciascuna delle definizioni di keyspace.

3. Prima di eliminare i riferimenti inattivi nelle definizioni keyspace, utilizza il comando seguente per eliminare l'intera installazione di Apigee ibrida, tranne ASM (Istio) e cert-manager da Secondary-DC2. Per maggiori informazioni, consulta Disinstallare il runtime ibrido.

   apigeectl delete -f YOUR_OVERRIDES_FILE.yaml --all
   

4. Rimuovi i riferimenti inattivi a Secondary-DC2 da ciascuno degli keyspaces modificando la definizione di keyspace.

   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. Verifica che i riferimenti inattivi alla regione Secondary-DC2 siano stati rimossi da tutti gli keyspaces eseguendo questo comando:

   select * from system_schema.keyspaces;
   

6. Accedi a un pod Cassandra di Primary-DC1 e rimuovi i riferimenti agli UUID di tutti i pod Cassandra di Secondary-DC2. Gli UUID possono essere ottenuti dal comando nodetool status come descritto in precedenza nella diagnosi.

   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. Verifica che non siano presenti pod Cassandra di Secondary-DC2 eseguendo di nuovo il comando nodetool status.
8. Installa il cluster di runtime Apigee nella regione secondaria (Secondary-DC2) seguendo i passaggi in Deployment multiregionale su GKE e GKE On-Prem.

Deve raccogliere dati diagnostici

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni diagnostiche e contatta l'assistenza Apigee:

1. ID progetto Google Cloud
2. Il nome dell'organizzazione ibrida Apigee
3. I file overrides.yaml delle regioni principali e secondarie, che mascherano eventuali informazioni sensibili
4. Stato dei pod Kubernetes in tutti gli spazi dei nomi delle regioni principali e secondarie:

   kubectl get pods -A > kubectl-pod-status`date +%Y.%m.%d_%H.%M.%S`.txt
   

5. Un dump cluster-info di Kubernetes dalle regioni principali e secondarie:

   # 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. L'output dei comandi nodetool riportati di seguito dalla regione principale.

   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
         

Riferimenti

• Apigee ibrido Deployment multiregionale su GKE e GKE On-Prem
• Documentazione di Kubernetes
• Comando nodetool status Cassandra