Tipps zur Fehlerbehebung für Cassandra

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

Hinweis: Dieses Dokument gilt nur für Nutzer von Apigee Hybrid.

In diesem Thema werden Schritte erläutert, mit denen Sie Probleme mit dem Cassandra-Datenspeicher beheben können. Cassandra ist ein nichtflüchtiger Datenspeicher, der in der Komponente cassandra der Hybridlaufzeitarchitektur ausgeführt wird. Weitere Informationen finden Sie unter Laufzeitdienst-Konfiguration – Übersicht.

Cassandra-Pods verbleiben im Release-Status

Symptom

Nachdem Sie versucht haben, die Cassandra-Pods zu aktualisieren, wird für den Datenspeicher gemeldet, dass er im Release-Status verbleibt.

Fehlermeldung

Wenn Sie den Pod-Status mit kubectl aufrufen, sehen Sie, dass ein oder mehrere Cassandra-Pods im Release-Status verbleiben:

Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Ack 57s (x7 over 24h) apigee-datastore release started

Mögliche Ursachen

Ein Pod, der im Release-Status verbleibt, kann folgende Ursachen haben:

Ursache	Beschreibung
Änderungen der Speicherkapazität	Es wurden Schritte ausgeführt, um die Speicherkapazität in der Datei override.yaml zu ändern.
Weitere Konfigurationsänderungen	Die Cassandra-Eigenschaften in der Datei override.yaml wurden aktualisiert, die Änderungen wurden jedoch nicht übernommen.

Änderungen der Speicherkapazität

Diagnose

1. Verwenden Sie kubectl, um den aktuellen Status des apigee-Datenspeicher-Pods aufzurufen:

   kubectl get apigeeds -n apigee

   NAME STATE AGE
   default releasing 122d

2. Prüfen Sie, ob Änderungen an der Datei override.yaml vorgenommen wurden:
1. Vergleichen Sie mit Ihrem Versionsverwaltungssystem die vorherige Version der Datei override.yaml mit der aktuellen Version:

   diff OVERRIDES_BEFORE.yaml OVERRIDES_AFTER.yaml

2. Die Ausgabe eines Diff in override.yaml kann das mögliche Problem mit der Größe der Speicherkapazität zeigen. Beispiel:

   # Overrides.yaml  before:
   cassandra:
      storage:
         capacity: 500Gi
   
   # Overrides.yaml after:
   cassandra:
      storage:
         capacity: 100Gi

   Wenn bei einem Vorgang zum Ändern der Speicherkapazität Schritte übersprungen wurden, und wenn eine neue override.yaml direkt angewendet wurde, kann dies dazu führen, dass der Datenspeicher im Release-Status bleibt.

3. Prüfen Sie statefulset, um sicherzugehen, dass ein Exemplar für apigee-cassandra-default vorhanden ist:

   kubectl describe sts -n apigee

   Die Ausgabe sieht in etwa so aus:

   Name:               apigee-cassandra-default
   Namespace:          apigee
   CreationTimestamp:  Tue, 18 Jul 2023 00:40:57 +0000
   Selector:           app=apigee-cassandra,name=default
   Labels:             apigee.cloud.google.com.revision=v1-2cc098050836c6b4
                       apigee.cloud.google.com.version=v1
                       apigee.cloud.google.com/platform=apigee
                       app=apigee-cassandra
                       name=default
   Annotations:        <none>
   Replicas:           3 desired | 3 total
   Update Strategy:    RollingUpdate
     Partition:        0
   Pods Status:        3 Running / 0 Waiting / 0 Succeeded / 0 Failed
   Pod Template:
     Labels:       apigee.cloud.google.com/apigee_servicename=production
                   apigee.cloud.google.com/billing_type=subscription
                   apigee.cloud.google.com/platform=apigee
                   app=apigee-cassandra
                   name=default
                   revision=v1
                   runtime_type=hybrid
     Annotations:  apigee.cloud.google.com/pod-template-spec-hash: 2cc098050836c6b4
                   prometheus.io/path: /metrics
                   prometheus.io/port: 7070
                   prometheus.io/scheme: https
                   prometheus.io/scrape: true
     Containers:
      apigee-cassandra:
       Image:       gcr.io/apigee-release/hybrid/apigee-hybrid-cassandra:1.10.1
       Ports:       7000/TCP, 7001/TCP, 7199/TCP, 9042/TCP, 8778/TCP
       Host Ports:  7000/TCP, 7001/TCP, 7199/TCP, 9042/TCP, 8778/TCP
       Requests:
         cpu:      500m
         memory:   1Gi
       Readiness:  exec [/bin/bash -c /opt/apigee/ready-probe.sh] delay=0s timeout=5s period=10s #success=1 #failure=2
       Environment:
         POD_NAME:                  (v1:metadata.name)
         POD_IP:                    (v1:status.podIP)
         MAX_HEAP_SIZE:            512M
         HEAP_NEWSIZE:             100M
         CASSANDRA_SEEDS:          apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local
         CASSANDRA_CLUSTER_NAME:   apigeecluster
         CASSANDRA_DC:             dc-1
         CASSANDRA_RACK:           ra-1
         CASSANDRA_OPEN_JMX:       true
         CPS_ADMIN_USER:           <set to the key 'admin.user' in secret 'apigee-datastore-default-creds'>        Optional: false
         CPS_ADMIN_PASSWORD:       <set to the key 'admin.password' in secret 'apigee-datastore-default-creds'>    Optional: false
         APIGEE_JMX_USER:          <set to the key 'jmx.user' in secret 'apigee-datastore-default-creds'>          Optional: false
         APIGEE_JMX_PASSWORD:      <set to the key 'jmx.password' in secret 'apigee-datastore-default-creds'>      Optional: false
         CASS_PASSWORD:            <set to the key 'default.password' in secret 'apigee-datastore-default-creds'>  Optional: false
         APIGEE_JOLOKIA_USER:      <set to the key 'jolokia.user' in secret 'apigee-datastore-default-creds'>      Optional: false
         APIGEE_JOLOKIA_PASSWORD:  <set to the key 'jolokia.password' in secret 'apigee-datastore-default-creds'>  Optional: false
       Mounts:
         /opt/apigee/apigee-cassandra/conf from appsfs (rw)
         /opt/apigee/customer from cwc-volume (ro)
         /opt/apigee/data from cassandra-data (rw)
         /opt/apigee/ssl from tls-volume (ro)
         /var/secrets/google from apigee-cassandra-backup (rw)
         /var/secrets/keys from apigee-cassandra-backup-key-file (rw)
     Volumes:
      cwc-volume:
       Type:        Secret (a volume populated by a Secret)
       SecretName:  config-cassandra-default
       Optional:    false
      tls-volume:
       Type:        Secret (a volume populated by a Secret)
       SecretName:  apigee-cassandra-default-tls
       Optional:    false
      appsfs:
       Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
       Medium:
       SizeLimit:  <unset>
      apigee-cassandra-backup:
       Type:        Secret (a volume populated by a Secret)
       SecretName:  apigee-cassandra-backup-svc-account
       Optional:    true
      apigee-cassandra-backup-key-file:
       Type:        Secret (a volume populated by a Secret)
       SecretName:  apigee-cassandra-backup-key-file
       Optional:    true
   Volume Claims:
     Name:          cassandra-data
     StorageClass:
     Labels:        <none>
     Annotations:   <none>
     Capacity:      10Gi
     Access Modes:  [ReadWriteOnce]
   Events:
     Type    Reason            Age   From                    Message
     ----    ------            ----  ----                    -------
     Normal  SuccessfulCreate  47m   statefulset-controller  create Pod apigee-cassandra-default-2 in StatefulSet apigee-cassandra-default successful

4. Prüfen Sie den Apigee-Controller auf Fehler:

   kubectl logs -f apigee-controller-manager-59cf595c77-wtwnr -n apigee-system -c manager | grep apigeedatastore
   

   Ergebnisse:

   "error creating
   apigee-cassandra object: failed to update resource
   apigee/apigee-cassandra-default: StatefulSet.apps \"apigee-cassandra-default\"
   is invalid: spec: Forbidden: updates to statefulset spec for fields other than
   'replicas', 'template', 'updateStrategy', 'persistentVolumeClaimRetentionPolicy'
   and 'minReadySeconds' are forbiddenerror creating apigee-cassandra object:
   failed to update resource apigee/apigee-cassandra-default: StatefulSet.apps
   \"apigee-cassandra-default\" is invalid: spec: Forbidden: updates to statefulset
   spec for fields other than 'replicas', 'template', 'updateStrategy',
   'persistentVolumeClaimRetentionPolicy' and 'minReadySeconds' are forbidden"

Lösung

Der Status für Cassandra kann mit den folgenden Schritten zurückgesetzt werden, um ihn wieder in den Status „Wird ausgeführt“ zu versetzen:

1. Deaktivieren Sie den apigee-controller:

   kubectl -n apigee-system edit deployments and set --enable-controllers=true to --enable-controllers=false
   

2. Bringen Sie den Datenspeicher mit dem Befehl PATCH wieder in den Status „Wird ausgeführt“:

   curl -XPATCH \-H "Accept: application/json" -H "Content-Type: application/json-patch+json" --data '[{"op": "replace", "path": "/status/nestedState", "value": ""},{"op": "replace", "path": "/status/state", "value": "running"}]' 'http://127.0.0.1:8001/apis/apigee.cloud.google.com/v1alpha1/namespaces/apigee/apigeedatastores/default/status'
   

3. Wenden Sie die ursprüngliche Datei override.yaml mit Helm noch einmal an:

   helm upgrade datastore apigee-datastore/ \
   --namespace APIGEE_NAMESPACE \
   --atomic \
   -f OVERRIDES_FILE \
   --dry-run=server

   Achten Sie darauf, dass alle gezeigten Einstellungen enthalten sind, einschließlich --atomic, damit die Aktion bei einem Fehler rückgängig gemacht wird.

   Installation des Diagramms:

   helm upgrade datastore apigee-datastore/ \
   --namespace APIGEE_NAMESPACE \
   --atomic \
   -f OVERRIDES_FILE

4. Aktivieren Sie den apigee-controller:

   kubectl -n apigee-system edit deployments and set --enable-controllers=false to --enable-controllers=true
   

5. Warten Sie, bis der Datenspeicher wieder aktiviert ist, und validieren Sie ihn mit:

   kubectl get apigeeds --namespace apigee
   

6. Prüfen Sie, ob Apigee-Bereitstellungen und -Pods den Status „Wird ausgeführt“ haben und apigeeds nicht mehr den Release-Status hat:

   kubectl get ad -n apigee
   

   kubectl get pods -n apigee
   

   kubectl get apigeeds -n apigee
   

   NAME      STATE     AGE
   default   running   24d

Andere Konfigurationsänderungen

Aktualisierungen der cassandra-Properties in override.yaml wurden nicht übernommen. Das kann eine Passwortänderung oder eine Änderung an Ressourcen im override.yaml sein. Oder es wurde fälschlicherweise die falsche override.yaml auf einen Cluster angewendet.

Diagnose

Hier finden Sie die einzelnen Schritte.

Lösung

Folgen Sie der Anleitung unter Lösung.

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-Support:

• Overrides.yaml für jeden Cluster in der Installation.

• Ein Kubernetes-Cluster-Info-Dump aus der Apigee Hybrid-Installation:

  Kubernetes-cluster-info dump generieren:

  kubectl cluster-info dump -A --output-directory=/tmp/kubectl-cluster-info-dump
  

  Kubernetes-cluster-info dump mit ZIP komprimieren:

  zip -r kubectl-cluster-info-dump`date +%Y.%m.%d_%H.%M.%S`.zip /tmp/kubectl-cluster-info-dump/*
  

Cassandra-Pods verbleiben im Status "Ausstehend"

Symptom

Nach dem Start verbleiben die Cassandra-Pods im Status Ausstehend.

Fehlermeldung

Wenn Sie den Pod-Status mit kubectl aufrufen, sehen Sie, dass ein oder mehrere Cassandra-Pods im Status Pending verbleiben. Der Status Pending gibt an, dass Kubernetes den Pod auf einem Knoten nicht planen kann: Der Pod kann nicht erstellt werden. Beispiel:

kubectl get pods -n NAMESPACE

NAME                                     READY   STATUS      RESTARTS   AGE
adah-resources-install-4762w             0/4     Completed   0          10m
apigee-cassandra-default-0               0/1     Pending     0          10m
...

Mögliche Ursachen

Ein Pod, der im Status "Ausstehend" verbleibt, kann mehrere Ursachen haben. Beispiel:

Ursache	Beschreibung
Unzureichende Ressourcen	Es ist nicht genügend CPU oder Arbeitsspeicher zum Erstellen des Pods verfügbar.
Volume nicht erstellt	Der Pod wartet auf die Erstellung des nichtflüchtigen Volumes.
Amazon EBS-CSI-Treiber fehlt	Bei EKS-Installationen ist der erforderliche Amazon EBS CSI-Treiber nicht installiert.

Diagnose

Verwenden Sie kubectl, um den Pod zu beschreiben und die Ursache des Fehlers zu ermitteln. Beispiel:

kubectl -n NAMESPACE describe pods POD_NAME

Beispiel:

kubectl describe pods apigee-cassandra-default-0 -n apigee

Die Ausgabe kann eines der folgenden möglichen Probleme anzeigen:

• Wenn unzureichende Ressourcen das Problem sind, wird eine Warnmeldung angezeigt, dass die CPU oder der Arbeitsspeicher nicht ausreicht.
• Wenn in der Fehlermeldung darauf hingewiesen wird, dass der Pod ungebundene sofortige PersistentVolumeClaims (PVC) hat, kann der Pod kein nichtflüchtiges Volume erstellen.

Lösung

Unzureichende Ressourcen

Ändern Sie den Cassandra-Knotenpool so, dass er über ausreichende CPU- und Speicherressourcen verfügt. Weitere Informationen finden Sie unter Größe eines Knotenpools anpassen.

Kein nichtflüchtiges Volume erstellt

Wird ein Problem mit einem nichtflüchtigen Volume festgestellt, so beschreiben Sie den PVC (PersistentVolumeClaim), um festzustellen, warum er nicht erstellt wird:

1. Listen Sie die PVCs im Cluster auf:

   kubectl -n NAMESPACE get pvc
   
   NAME                                        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
   cassandra-data-apigee-cassandra-default-0   Bound    pvc-b247faae-0a2b-11ea-867b-42010a80006e   10Gi       RWO            standard       15m
   ...

2. Beschreiben Sie den PVC für den Pod, der fehlschlägt. Mit dem folgenden Befehl wird beispielsweise der PVC beschrieben, der an den Pod apigee-cassandra-default-0 gebunden ist:

   kubectl apigee describe pvc cassandra-data-apigee-cassandra-default-0
   
   Events:
     Type     Reason              Age                From                         Message
     ----     ------              ----               ----                         -------
     Warning  ProvisioningFailed  3m (x143 over 5h)  persistentvolume-controller  storageclass.storage.k8s.io "apigee-sc" not found

   Beachten Sie, dass in diesem Beispiel die StorageClass namens apigee-sc nicht vorhanden ist. Erstellen Sie zum Beheben dieses Problems die fehlende StorageClass im Cluster, wie unter Standard-StorageClass ändern beschrieben.

Weitere Informationen finden Sie unter Pods debuggen.

Amazon EBS-CSI-Treiber fehlt

Wenn die Hybrid-Instanz in einem EKS-Cluster ausgeführt wird, muss der EKS-Cluster den Amazon EBS-CSI-Treiber (Container Storage Interface) verwenden. Weitere Informationen finden Sie unter Häufig gestellte Fragen zur Amazon EBS CSI-Migration.

Cassandra-Pods verbleiben im CrashLoopBackoff-Status

Symptom

Während des Starts verbleiben die Cassandra-Pods im Status CrashLoopBackoff.

Fehlermeldung

Wenn Sie den Pod-Status mit kubectl aufrufen, sehen Sie, dass sich ein oder mehrere Cassandra-Pods im Status CrashLoopBackoff befinden. Dieser Status gibt an, dass Kubernetes den Pod nicht erstellen kann. Beispiel:

kubectl get pods -n NAMESPACE

NAME                                     READY   STATUS            RESTARTS   AGE
adah-resources-install-4762w             0/4     Completed         0          10m
apigee-cassandra-default-0               0/1     CrashLoopBackoff  0          10m
...

Mögliche Ursachen

Ein Pod, der im Status CrashLoopBackoff verbleibt, kann mehrere Ursachen haben. Beispiel:

Ursache	Beschreibung
Rechenzentrum unterscheidet sich vom vorherigen Rechenzentrum	Dieser Fehler weist darauf hin, dass der Cassandra-Pod ein nichtflüchtiges Volume mit Daten aus einem vorherigen Cluster hat und die neuen Pods dem alten Cluster nicht mehr beitreten können. Dies geschieht in der Regel, wenn veraltete nichtflüchtige Volumes vom vorherigen Cassandra-Cluster auf demselben Kubernetes-Knoten erhalten bleiben. Dieses Problem kann auftreten, wenn Sie Cassandra im Cluster löschen und neu erstellen.
Kubernetes-Upgrade	Ein Kubernetes-Upgrade kann sich auf den Cassandra-Cluster auswirken. Dies kann passieren, wenn die Anthos-Arbeitsknoten, auf denen die Cassandra-Pods gehostet werden, auf eine neue Betriebssystemversion aktualisiert werden.

Diagnose

Prüfen Sie das Cassandra-Fehlerlog, um die Ursache des Problems zu ermitteln.

1. Listen Sie die Pods auf, um die ID des Cassandra-Pods zu erhalten, der fehlschlägt:

   kubectl get pods -n NAMESPACE

2. Prüfen Sie das Log des fehlerhaften Pods:

   kubectl logs POD_ID -n NAMESPACE

Lösung

Suchen Sie die folgenden Hinweise im Log des Pods:

Rechenzentrum unterscheidet sich vom vorherigen Rechenzentrum

Wenn dieser Logeintrag angezeigt wird:

Cannot start node if snitch's data center (us-east1) differs from previous data center

• Prüfen Sie, ob der Cluster veraltete oder alte PVCs enthält und löschen Sie diese.
• Wenn es sich um eine Neuinstallation handelt, löschen Sie alle PVCs und wiederholen die Einrichtung. Beispiel:

  kubectl -n NAMESPACE get pvc
  kubectl -n NAMESPACE delete pvc cassandra-data-apigee-cassandra-default-0

Durch Anthos-Upgrade werden Sicherheitseinstellungen geändert

Prüfen Sie die Cassandra-Logs auf diese Fehlermeldung:

/opt/apigee/run.sh: line 68: ulimit: max locked memory:
  cannot modify limit: Operation not permitted

• Wenn die Hybrid-Instanz mehrere Regionen umfasst, deaktivieren Sie die betroffene Hybrid-Instanz und erweitern Sie sie wieder in die betroffene Region.
• Wenn die Hybrid-Instanz eine einzelne Region ist, führen Sie einen rollierenden Neustart für jeden Cassandra-Pod in der Hybrid-Instanz durch.

Client-Container zur Fehlerbehebung erstellen

In diesem Abschnitt wird erläutert, wie Sie einen Client-Container erstellen, über den Sie auf Cassandra-Debugging-Dienstprogramme wie cqlsh (die CQL-Shell) zugreifen können. Diese Dienstprogramme können zum Abfragen von Cassandra-Tabellen und für Fehlerbehebungszwecke nützlich sein.

Client-Container erstellen

So erstellen Sie den Client-Container:

1. Der Container muss das TLS-Zertifikat aus dem Pod apigee-cassandra-user-setup verwenden. Dies wird als Kubernetes-Secret gespeichert. Rufen Sie den Namen des Secrets ab, in dem dieses Zertifikat gespeichert ist:

   kubectl get secrets -n apigee --field-selector type=kubernetes.io/tls | grep apigee-cassandra-user-setup | awk '{print $1}'

   Dieser Befehl gibt den Namen des Secrets zurück. Beispiel: apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls. Sie benötigen ihn in der YAML-Datei im Feld secretName.

2. Öffnen Sie eine neue Datei und fügen Sie folgende Pod-Spezifikation in diese ein:

   apiVersion: v1
   kind: Pod
   metadata:
     labels:
     name: CASSANDRA_CLIENT_NAME   # For example: my-cassandra-client
     namespace: apigee
   spec:
     containers:
     - name: CASSANDRA_CLIENT_NAME
       image: "gcr.io/apigee-release/hybrid/apigee-hybrid-cassandra-client:YOUR_APIGEE_HYBRID_VERSION" # For example, 1.10.5.
       imagePullPolicy: Always
       command:
       - sleep
       - "3600"
       env:
       - name: CASSANDRA_SEEDS
         value: apigee-cassandra-default.apigee.svc.cluster.local
       - name: APIGEE_DML_USER
         valueFrom:
           secretKeyRef:
             key: dml.user
             name: apigee-datastore-default-creds
       - name: APIGEE_DML_PASSWORD
         valueFrom:
           secretKeyRef:
             key: dml.password
             name: apigee-datastore-default-creds
       volumeMounts:
       - mountPath: /opt/apigee/ssl
         name: tls-volume
         readOnly: true
     volumes:
     - name: tls-volume
       secret:
         defaultMode: 420
         secretName: YOUR_SECRET_NAME    # For example: apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls
     restartPolicy: Never

3. Speichern Sie die Datei mit der Erweiterung .yaml. Beispiel: my-spec.yaml
4. Wenden Sie die Spezifikation auf Ihren Cluster an:

   kubectl apply -f YOUR_SPEC_FILE.yaml -n apigee

5. Melden Sie sich beim Container an:

   kubectl exec -n apigee CASSANDRA_CLIENT_NAME -it -- bash

6. Stellen Sie mit dem folgenden Befehl eine Verbindung zur Cassandra-Schnittstelle cqlsh her. Geben Sie den Befehl genau so ein:

   cqlsh ${CASSANDRA_SEEDS} -u ${APIGEE_DML_USER} -p ${APIGEE_DML_PASSWORD} --ssl

Client-Pod löschen

Verwenden Sie diesen Befehl, um den Cassandra-Client-Pod zu löschen:

kubectl delete pods -n apigee cassandra-client

Falsch konfigurierte Regionserweiterung: alle Cassandra-Knoten unter einem Rechenzentrum

Diese Situation tritt bei einer multiregionalen Erweiterung auf GKE- und GKE On-Prem-Plattformen (Anthos) auf. Versuchen Sie nicht, alle Ihre Cassandra-Knoten im selben Rechenzentrum zu erstellen.

Symptom

Cassandra-Knoten werden im Rechenzentrum für die zweite Region nicht erstellt.

Fehlermeldung

failed to rebuild from dc-1: java.lang.RuntimeException : Error while rebuilding node: Stream failed

Lösung

Reparieren Sie die falsch konfigurierte Regionserweiterung mit den folgenden Schritten:

1. Aktualisieren Sie den Cassandra-replicaCount in der Datei overrides.yaml für das zweite Rechenzentrum auf 1. Beispiel:

   cassandra:
     . . .
     replicaCount: 1

   Wenden Sie die Einstellung mit Helm an:

   helm upgrade datastore apigee-datastore \
   --namespace APIGEE_NAMESPACE \
   --atomic \
   -f 2ND_DATACENTER_OVERRIDES_FILE \
   --dry-run=server

   Achten Sie darauf, dass alle gezeigten Einstellungen enthalten sind, einschließlich --atomic, damit die Aktion bei einem Fehler rückgängig gemacht wird.

   Installation des Diagramms:

   helm upgrade datastore apigee-datastore \
   --namespace APIGEE_NAMESPACE \
   --atomic \
   -f 2ND_DATACENTER_OVERRIDES_FILE

2. Verwenden Sie kubectl exec, um mit dem folgenden Befehl auf den verbleibenden Cassandra-Pod zuzugreifen:

   kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash

3. Nehmen Sie den verbleibenden Cassandra-Pod mit dem folgenden Befehl außer Betrieb:

   nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD decommission

4. Löschen Sie die Cassandra-Pods aus dem zweiten Rechenzentrum mit Helm:

   helm uninstall datastore -n APIGEE_NAMESPACE

5. Wechseln Sie mit dem Kubernetes-Kontext zum Cluster für Ihr erstes Rechenzentrum:

   kubectl config use-context FIRST_DATACENTER_CLUSTER

6. Achten Sie darauf, dass sich im ersten Rechenzentrum keine Cassandra-Knoten in einem inaktiven Zustand befinden.

   nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status

7. Prüfen Sie, ob die falsch konfigurierten Cassandra-Knoten (für das zweite Rechenzentrum) aus dem ersten Rechenzentrum entfernt wurden. Achten Sie darauf, dass die in der nodetool-Statusausgabe angezeigten IP-Adressen nur die IP-Adressen für die Cassandra-Pods sind, die für Ihr erstes Rechenzentrum vorgesehen sind. In der folgenden Ausgabe sollte beispielsweise die IP-Adresse 10.100.0.39 für einen Pod in Ihrem ersten Rechenzentrum vorgesehen sein.

   kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
   nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status
   
     Datacenter: dc-1
     ================
     Status=U/D (Up/Down) | State=N/L/J/M (Normal/Leaving/Joining/Moving)
     --  Address      Load      Tokens  Owns (effective)  Host ID                               Rack
     UN  10.100.0.39  4.21 MiB  256     100.0%            a0b1c2d3-e4f5-6a7b-8c9d-0e1f2a3b4c5d  ra-1

8. Prüfen Sie, ob die Datei overrides.yaml für das zweite Rechenzentrum die Einstellung für den Rechenzentrumsnamen im Abschnitt „cassandra“ enthält. Beispiel:

   cassandra:
     datacenter: DATA_CENTER_2
     rack: "RACK_NAME" # "ra-1" is the default value.
     . . .

9. Aktualisieren Sie die Einstellung cassandra:replicaCount in der Datei overrides.yaml für das zweite Rechenzentrum auf die gewünschte Zahl. Beispiel:

   cassandra:
     datacenter: DATA_CENTER_2
     . . .
     replicaCount: 3

   Hinweis: Der Wert von cassandra:replicaCount muss ein Vielfaches von 3 sein. Verwenden Sie für replicaCount den Wert, den Sie für Ihr erstes Rechenzentrum angegeben haben.
10. Wenden Sie die Datei overrides.yaml für das zweite Rechenzentrum mit dem Argument datastore an. Beispiel:

    helm upgrade datastore apigee-datastore \
    --namespace APIGEE_NAMESPACE \
    --atomic \
    -f 2ND_DATACENTER_OVERRIDES_FILE \
    --dry-run=server

    Achten Sie darauf, dass alle gezeigten Einstellungen enthalten sind, einschließlich --atomic, damit die Aktion bei einem Fehler rückgängig gemacht wird.

    Installation des Diagramms:

    helm upgrade datastore apigee-datastore \
    --namespace APIGEE_NAMESPACE \
    --atomic \
    -f 2ND_DATACENTER_OVERRIDES_FILE

11. Verwenden Sie kubectl exec, um auf einen der neuen Cassandra-Pods im zweiten Rechenzentrum zuzugreifen und zu prüfen, ob zwei Rechenzentren vorhanden sind:

     "nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status"

Problemumgehung für das bekannte Problem 388608440

In diesem Abschnitt wird erläutert, wie Sie prüfen, ob Ihre Installation vom bekannten Problem 388608440 betroffen ist, und wie Sie es beheben können.

Diagnose

Führen Sie den folgenden Befehl aus, um zu prüfen, ob Sie von diesem bekannten Problem betroffen sind:

kubectl -n APIGEE_NAMESPACE get pods -l app=apigee-cassandra -o name | \
  xargs -i -P0 kubectl -n APIGEE_NAMESPACE -c apigee-cassandra exec {} -- \
  bash -c 'echo "{}: Found $(nodetool -u cassandra -pw $CASS_PASSWORD listsnapshots | grep -c compaction_history) leftover snapshots"'

Beispiel:

kubectl -n apigee get pods -l app=apigee-cassandra -o name | xargs -i -P0 kubectl -n apigee -c apigee-cassandra exec {} -- bash -c 'echo "{}: Found $(nodetool -u cassandra -pw $CASS_PASSWORD listsnapshots | grep -c compaction_history) leftover snapshots"'

pod/apigee-cassandra-default-0: Found 0 leftover snapshots
pod/apigee-cassandra-default-1: Found 0 leftover snapshots
pod/apigee-cassandra-default-2: Found 0 leftover snapshots
    

Wenn die Anzahl der verbleibenden Snapshots für einen Ihrer Cassandra-Pods größer als 0 ist, ist Ihre Installation von diesem Problem betroffen.

Lösung

Gehen Sie so vor, um dieses Problem zu beheben. Wählen Sie dazu den Typ des Back-ups aus, das Sie verwenden, und Ihre Apigee Hybrid-Nebenversion:

Cloud Storage-Backup

1. Achten Sie darauf, dass Sie die richtige Konfiguration für die Cloud Storage-Sicherung verwenden. Zu den häufigsten Problemen zählen unter anderem:
   • Es wird das falsche Google-Dienstkonto verwendet.
   • Falscher Cloud Storage-Bucket-Name in cassandra.backup.dbStorageBucket angegeben.
   • Die Google API ist nicht über einen Proxy erreichbar (wenn cassandra.backup.httpproxy verwendet wird).

   Wenn Sie Probleme mit Ihrer Einrichtung feststellen, beheben Sie diese, bevor Sie fortfahren.

2. Löschen Sie verbleibende Snapshots manuell mit dem folgenden Befehl:

   Apigee Hybrid 1.12

   kubectl -n APIGEE_NAMESPACE get pods -l app=apigee-cassandra -o name | xargs -i -P0 kubectl -n APIGEE_NAMESPACE -c apigee-cassandra exec {} -- bash -c 'echo "{}: $(nodetool -u cassandra -pw $CASS_PASSWORD clearsnapshot --all)"'

   Beispiel:

   kubectl -n apigee get pods -l app=apigee-cassandra -o name | xargs -i -P0 kubectl -n apigee -c apigee-cassandra exec {} -- bash -c 'echo "{}: $(nodetool -u cassandra -pw $CASS_PASSWORD clearsnapshot --all)"'

   Apigee Hybrid 1.11

   kubectl -n APIGEE_NAMESPACE get pods -l app=apigee-cassandra -o name | xargs -i -P0 kubectl -n APIGEE_NAMESPACE -c apigee-cassandra exec {} -- bash -c 'echo "{}: $(nodetool -u cassandra -pw $CASS_PASSWORD clearsnapshot)"'

   Beispiel:

   kubectl -n apigee get pods -l app=apigee-cassandra -o name | xargs -i -P0 kubectl -n apigee -c apigee-cassandra exec {} -- bash -c 'echo "{}: $(nodetool -u cassandra -pw $CASS_PASSWORD clearsnapshot)"'

   pod/apigee-cassandra-default-1: Requested clearing snapshot(s) for [all keyspaces] with [all snapshots]
   pod/apigee-cassandra-default-2: Requested clearing snapshot(s) for [all keyspaces] with [all snapshots]
   pod/apigee-cassandra-default-0: Requested clearing snapshot(s) for [all keyspaces] with [all snapshots]
               

   Hinweis:

   • Mit dem Befehl clearsnapshot werden nur Snapshots gelöscht, ohne dass die gespeicherten Daten betroffen sind.
   • Wenn viele Snapshots übrig sind, kann der Vorgang einige Minuten dauern.
3. Lösen Sie einen manuellen Sicherungsjob aus und prüfen Sie, ob er erfolgreich abgeschlossen wird.
4. Prüfen Sie, ob das vom manuellen Sicherungsjob erstellte Sicherungsarchiv erfolgreich in den Cloud Storage-Bucket cassandra.backup.dbStorageBucket hochgeladen wurde, den Sie in Ihrer overrides.yaml-Datei angegeben haben.
5. Prüfen Sie mit dem Befehl, der weiter oben im Abschnitt Diagnose beschrieben wird, ob die Anzahl der verbleibenden Snapshots für alle Cassandra-Pods 0 ist.

Sicherung von Remote-Servern

1. Achten Sie darauf, dass der Remote-Sicherungsserver fehlerfrei und von den Cassandra-Pods aus erreichbar ist. Im Abschnitt Fehlerbehebung finden Sie Schritte zum Prüfen der SSH-Verbindung. Zu den häufigsten Problemen zählen unter anderem:
   • Die Netzwerkfirewall blockiert die Verbindung.
   • Der SSH-Schlüssel ist nicht richtig eingerichtet.
   • Der Remote-Sicherungsserver ist nicht erreichbar.
   • Auf dem Remoteserver für die Sicherung ist kein freier Speicherplatz mehr verfügbar.

   Wenn Sie Probleme mit dem Remote-Sicherungsserver finden, beheben Sie diese, bevor Sie fortfahren.

2. Löschen Sie verbleibende Snapshots manuell mit dem folgenden Befehl:

   Apigee Hybrid 1.12

   kubectl -n APIGEE_NAMESPACE get pods -l app=apigee-cassandra -o name | xargs -i -P0 kubectl -n APIGEE_NAMESPACE -c apigee-cassandra exec {} -- bash -c 'echo "{}: $(nodetool -u cassandra -pw $CASS_PASSWORD clearsnapshot --all)"'

   Beispiel:

   kubectl -n apigee get pods -l app=apigee-cassandra -o name | xargs -i -P0 kubectl -n apigee -c apigee-cassandra exec {} -- bash -c 'echo "{}: $(nodetool -u cassandra -pw $CASS_PASSWORD clearsnapshot --all)"'

   Apigee Hybrid 1.11

   kubectl -n APIGEE_NAMESPACE get pods -l app=apigee-cassandra -o name | xargs -i -P0 kubectl -n APIGEE_NAMESPACE -c apigee-cassandra exec {} -- bash -c 'echo "{}: $(nodetool -u cassandra -pw $CASS_PASSWORD clearsnapshot)"'

   Beispiel:

   kubectl -n apigee get pods -l app=apigee-cassandra -o name | xargs -i -P0 kubectl -n apigee -c apigee-cassandra exec {} -- bash -c 'echo "{}: $(nodetool -u cassandra -pw $CASS_PASSWORD clearsnapshot)"'

   pod/apigee-cassandra-default-1: Requested clearing snapshot(s) for [all keyspaces] with [all snapshots]
   pod/apigee-cassandra-default-2: Requested clearing snapshot(s) for [all keyspaces] with [all snapshots]
   pod/apigee-cassandra-default-0: Requested clearing snapshot(s) for [all keyspaces] with [all snapshots]
               

   Hinweis:

   • Mit dem Befehl clearsnapshot werden nur Snapshots gelöscht, ohne dass die gespeicherten Daten betroffen sind.
   • Wenn viele Snapshots übrig sind, kann der Vorgang einige Minuten dauern.
3. Lösen Sie einen manuellen Sicherungsjob aus und prüfen Sie, ob er erfolgreich abgeschlossen wird.
4. Prüfen Sie, ob das vom manuellen Sicherungsjob erstellte Sicherungsarchiv erfolgreich auf den Remote-Sicherungsserver hochgeladen wurde.
5. Prüfen Sie mit dem Befehl, der weiter oben im Abschnitt Diagnose beschrieben wird, ob die Anzahl der verbleibenden Snapshots für alle Cassandra-Pods 0 ist.

Zusätzliche Ressourcen

Einführung in Playbooks für Apigee X und Apigee Hybrid