Fehlerbehebung: Cassandra-Wiederherstellung

Sie lesen gerade die Dokumentation zu Apigee und Apigee Hybrid.
Für dieses Thema gibt es keine entsprechende Apigee Edge-Dokumentation.

Symptom

Während der Cassandra-Wiederherstellung in Apigee Hybrid können Fehler in den Wiederherstellungslogs auftreten.

Fehlermeldung

Ihnen wird in den Logs eines der folgenden Elemente angezeigt:

java.net.ConnectException: Connection timed out (Connection timed out)
 
/tmp/tmp/schema.cql:662:OperationTimedOut: errors={'10.0.0.1': 'Client request timeout. See Session.execute[_async](timeout)'}, last_host=10.0.0.1
 
/tmp/tmp/schema.cql:6409:AlreadyExists: Table 'kvm_myorg.kvm_map_keys_descriptor' already exists

Mögliche Ursachen

Ursache Beschreibung Anleitungen zur Fehlerbehebung gelten für
Zeitüberschreitung der Verbindung Dieser Fehler ist ein Verbindungsfehler zwischen apigee-cassandra-restore-Pods und apigee-cassandra-default-*-Pods. Apigee hybrid
Zeitüberschreitung beim Vorgang Dieser Fehler tritt auf, wenn bei der Wiederherstellung nach mehr als 15 Minuten eine Zeitüberschreitung auftritt. Apigee hybrid
Bereits vorhanden Diese Fehlermeldung hängt nicht mit der Ursache des Problems zusammen und ist das Ergebnis des Wiederholungsvorgangs eines Wiederherstellungsjobs. Apigee hybrid

Ursache: Zeitüberschreitung der Verbindung

Der folgende Fehler ist ein Verbindungsfehler zwischen apigee-cassandra-restore- und apigee-cassandra-default-*-Pods: 

java.net.ConnectException: Connection timed out (Connection timed out)

Diagnose

  1. Wenn Ihr Hostnetzwerk nicht vom Pod-Netzwerk aus erreichbar ist, prüfen Sie, ob hostNetwork unter cassandra in overrides.yaml auf false gesetzt ist, wie in Region aus einer Sicherung wiederherstellen gezeigt.
  2. Melden Sie sich zum Testen der Verbindung beim apigee-mart- oder apigee-runtime-Pod an, der sich im selben Netzwerk wie der apigee-cassandra-restore-Job befindet. Sie können auch einen anderen Pod im Pod-Netzwerk verwenden.
    1. Rufen Sie den Namen des apigee-mart-Pods ab: 
      kubectl -n apigee get po --selector=app=apigee-mart --no-headers -o custom-columns=":metadata.name"
    2. Führen Sie eine Bash-Sitzung im Mart-Pod aus: 
      kubectl exec -it MART_POD_NAME -n apigee -- bash

      Ersetzen Sie MART_POD_NAME durch den Namen des MART-Pods. Beispiel: apigee-mart-myorg--9a8228a-191-t0xh1-qz5fl.

    3. Führen Sie Konnektivitätstests für Cassandra-Ports aus: 
      curl -v -m 5 telnet://apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local:9042
       
      curl -v -m 5 telnet://apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local:7001

    Wenn Sie einen Connection timed out-Fehler in der Ausgabe erhalten, bedeutet dies, dass es Verbindungsprobleme gibt. Wenn Sie jedoch die Connected to-Meldung sehen, die eine erfolgreiche Verbindung meldet, nutzen Sie die Tastenkombination Strg + C, um die Verbindung zu schließen und fortzufahren.

Lösung

Achten Sie darauf, dass die HostNetwork-Einstellung in der overrides.yaml-Datei, die für die Wiederherstellung verwendet wird, auf false gesetzt ist, und wiederholen Sie den Wiederherstellungsprozess. Wenn die Einstellung bereits auf false gesetzt ist, aber dennoch Verbindungsfehler angezeigt werden, prüfen Sie mit folgendem Befehl, ob die Cassandra-Pods ausgeführt werden: 

kubectl get pods -n apigee -l app=apigee-cassandra

Ihre Ausgabe sollte in etwa so aussehen:

NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          14m
apigee-cassandra-default-1   1/1     Running   0          13m
apigee-cassandra-default-2   1/1     Running   0          11m
exampleuser@example hybrid-files %

Ursache: Zeitüberschreitung beim Vorgang

Der folgende Fehler tritt auf, wenn bei der Wiederherstellung nach mehr als 15 Minuten eine Zeitüberschreitung auftritt. Der Fehler weist auf E/A-Probleme mit Speicher oder Netzwerk hin, wobei unkomprimierte Inhalte der Sicherung nicht rechtzeitig übertragen werden konnten. 

/tmp/tmp/schema.cql:662:OperationTimedOut: errors={'10.0.0.1': 'Client
request timeout. See Session.execute[_async](timeout)'}, last_host=10.0.0.1

Diagnose

  1. Prüfen Sie die apigee-cassandra-default-0-Logs und notieren Sie sich den Zeitstempel des Beginns der Wiederherstellung: 

    kubectl logs apigee-cassandra-default-0 -n apigee | grep 'MigrationManager.java' | head -n 1

  2. Vergleichen Sie den Zeitstempel mit dem letzten Protokoll zur Tabellenerstellung:

    kubectl logs apigee-cassandra-default-0 -n apigee | grep 'Create new table' | tail -n 1

    Die Ergebnisse dieses Vergleichs sollten zeigen, dass der Cassandra-Pod nach der Überschreitung des Zeitlimits noch Tabellen erstellt hat.

  3. Testen Sie die Speicherbandbreite mit folgenden Befehlen:

    kubectl -n apigee exec -it apigee-cassandra-default-0 -- bash -c 'dd if=/dev/zero of=/opt/apigee/data/test.img bs=200M count=1 ; rm /opt/apigee/data/test.img'
     
    kubectl -n apigee exec -it apigee-cassandra-default-1 -- bash -c 'dd if=/dev/zero of=/opt/apigee/data/test.img bs=200M count=1 ; rm /opt/apigee/data/test.img'
     
    kubectl -n apigee exec -it apigee-cassandra-default-2 -- bash -c 'dd if=/dev/zero of=/opt/apigee/data/test.img bs=200M count=1 ; rm /opt/apigee/data/test.img'

    Wenn die Schreibgeschwindigkeit weniger als 100 Mbit/s beträgt, kann dies darauf hindeuten, dass nicht die geeignete StorageClass (SSD) verwendet wird.

  4. Netzwerkbandbreite testen:

    1. Führen Sie netcat auf dem Cassandra-Pod aus, um den Port zu überwachen: 

      kubectl -n apigee exec -it apigee-cassandra-default-0 -- bash -c 'nc -l -p 3456 > /dev/null'

    2. Rufen Sie in einer separaten Shell-Sitzung den Namen des apigee-mart-Pods ab: 

      kubectl -n apigee get po --selector=app=apigee-mart --no-headers -o custom-columns=":metadata.name"

    3. Führen Sie eine Bash-Sitzung im apigee-mart-Pod aus. Sie können auch einen anderen Pod im Pod-Netzwerk verwenden: 

      kubectl exec -it MART_POD_NAME -n apigee -- bash

      Ersetzen Sie MART_POD_NAME durch den Namen des MART-Pods. Beispiel: apigee-mart-myorg--9a8228a-191-t0xh1-qz5fl.

    4. Führen Sie einen Netzwerkbandbreitentest für den Cassandra-Pod aus, auf dem noch die netcat ausgeführt wird: 

      dd if=/dev/zero bs=50M count=1 | nc apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local 3456

    Sie können den Vorgang für andere Cassandra-Pods wiederholen. Beträgt die resultierende Geschwindigkeit weniger als 10 Mio./s, ist die Netzwerkbandbreite wahrscheinlich die Ursache des Problems.

Lösung

Sobald eine langsame E/A-Geschwindigkeit mit den obigen Schritten bestätigt wurde, prüfen Sie, ob Ihr Cluster den Minimalanforderungen an Netzwerk und Speicherkapazität entspricht. Testen Sie die Bandbreite danach noch einmal.

Ursache: Bereits vorhanden

Diagnose

Möglicherweise erhalten Sie eine Fehlermeldung wie die folgende: 

/tmp/tmp/schema.cql:6409:AlreadyExists: Table 'kvm_myorg.kvm_map_keys_descriptor' already exists

Lösung

Diese Fehlermeldung hängt nicht mit der Ursache des Problems zusammen und ist das Ergebnis des Wiederholungsvorgangs eines Wiederherstellungsjobs. Die tatsächliche Fehlermeldung sollte in den Protokollen des ersten Pods angezeigt werden, der fehlgeschlagen ist.

Rufen Sie die Logs des ersten Fehlers ab, um das Problem zu diagnostizieren.

Wenn das Problem weiterhin besteht, gehen Sie zu Erfassen von Diagnoseinformationen erforderlich.

Problemumgehung für das bekannte Problem 391861216

Diagnose

Der Cassandra-Pod mit der höchsten Nummer befindet sich nach der Wiederherstellung im Status CrashLoopBackoff. Das kann aufgrund des bekannten Problems 391861216 auftreten. Im Cassandra-Pod-Log wird ein Fehler angezeigt, der in etwa so aussieht: 

Cannot change the number of tokens from 512 to 256

Lösung

Führen Sie die folgenden Schritte aus, um das zugrunde liegende Problem zu beheben. So kann Cassandra normal gestartet werden und die Daten bleiben erhalten.

  1. Starten Sie das Löschen des PVC für den Cassandra-Pod, der sich im Status CrashLoopBackoff befindet. Legen Sie POD_NAME auf den Namen des Pods im Status CrashLoopBackoff fest. Legen Sie APIGEE_NAMESPACE auf den Namespace des Clusters fest, in dem Apigee installiert ist. 

    kubectl delete pvc cassandra-data-POD_NAME -n APIGEE_NAMESPACE --wait=false

  2. Löschen Sie den Pod im Status CrashLoopBackoff. 

    kubectl delete pod POD_NAME -n APIGEE_NAMESPACE

  3. Ändern Sie den Seed-Host für Cassandra manuell in den Pod mit der höchsten Nummer. Wenn Sie beispielsweise drei Replikate haben, sollte SEED_POD_NAME apigee-cassandra-default-2 sein. Dies ist nur einmal erforderlich und kann für nachfolgende Pods übersprungen werden. 

    kubectl patch apigeeds/default -n APIGEE_NAMESPACE --type='merge' -p '{"spec": {"components": {"cassandra": {"properties": {"externalSeedHost":"SEED_POD_NAME.apigee-cassandra-default.APIGEE_NAMESPACE.svc.cluster.local"}}}}}'

  4. Entfernen Sie den Knoten mit 512 Token aus dem Cassandra-Ring. 

    kubectl exec -n APIGEE_NAMESPACE -t sts/apigee-cassandra-default -c apigee-cassandra -- bash -c 'nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD status' | awk '/^DN .*\?.* 512 / {print $6; exit}; /^DN .* [KMG]iB.* 512 / {print $7; exit}' | xargs -I {} kubectl exec -n APIGEE_NAMESPACE -t sts/apigee-cassandra-default -c apigee-cassandra -- bash -c 'nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD removenode {}'

  5. Warten Sie, bis der Cassandra-Pod wiederhergestellt ist, starten Sie ihn gegebenenfalls mehrmals neu und erreichen Sie den Status 2/2.Ready Der nächsthöhere Pod erhält dann den Status CrashLoopBackoff. 

    kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra -w

  6. Aktualisieren Sie POD_NAME und wiederholen Sie die vorherigen Schritte für die verbleibenden Pods einzeln, sobald sie den Status CrashLoopBackoff erreichen, bis alle Pods den Status Ready von 2/2 und den Status Running haben.

  7. Prüfen Sie, ob alle Pods dem Cassandra-Ring beigetreten sind. 

    kubectl exec -n APIGEE_NAMESPACE -t sts/apigee-cassandra-default -c apigee-cassandra -- bash -c 'nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD status'

    Alle Cassandra-Knoten sollten den Status UN und 256 Token haben.

  8. Setzen Sie die Änderung am Seed-Host für Cassandra rückgängig. 

    kubectl patch apigeeds/default -n APIGEE_NAMESPACE --type='merge' -p '{"spec": {"components": {"cassandra": {"properties": {"externalSeedHost":""}}}}}'

    Der Apigee Datastore-Controller startet die Cassandra-Pods neu, da die Änderung des Starthosts rückgängig gemacht wird.

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 den Google Cloud Customer Care:

  1. Erfassen Sie mit folgendem Befehl die Diagnosedaten von den Cassandra-Pods, die eventuell zusätzlich zu den üblichen Daten bereitgestellt werden müssen: 

    for p in $(kubectl -n apigee get pods -l app=apigee-cassandra --no-headers -o custom-columns=":metadata.name") ; do \
        for com in info describecluster failuredetector version status ring info gossipinfo compactionstats tpstats netstats cfstats proxyhistograms gcstats ; do kubectl \
        -n apigee exec ${p} -- bash -c 'nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD '"$com"' 2>&1 '\
        | tee /tmp/k_cassandra_nodetool_${com}_${p}_$(date +%Y.%m.%d_%H.%M.%S).txt | head -n 40 ; echo '...' ; done; done

  2. Komprimieren Sie sie und stellen Sie sie im Supportfall bereit:

    tar -cvzf /tmp/cassandra_data_$(date +%Y.%m.%d_%H.%M.%S).tar.gz /tmp/k_cassandra_nodetool*
  3. Erfassen Sie Logs aus dem Wiederherstellungs-Pod und stellen Sie diese bereit. Beachten Sie, dass Logs kurzlebig sind. Daher sollten sie direkt nach Auftreten eines Fehlers erfasst werden.
  4. Wenn Sie die obigen Schritte zur Diagnose ausgeführt haben, erfassen Sie alle Konsolenausgaben, kopieren Sie sie in eine Datei und hängen Sie die Datei an den Supportfall an.