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 neuesten Log der 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 Pod apigee-mart aus. Sie können auch einen beliebigen 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 mit dem Cassandra-Pod aus, auf dem noch 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

Es kann ein Fehler wie dieser angezeigt werden: 

/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.

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 Diagnoseschritte ausgeführt haben, erfassen Sie alle Konsolenausgaben, kopieren Sie sie in eine Datei und hängen Sie die Datei an die Supportanfrage an.