Guida alla risoluzione dei problemi di Cassandra

Stai visualizzando la documentazione relativa a Apigee e Apigee ibrido.
Non esiste una equivalente Documentazione di Apigee Edge per questo argomento.

Questo argomento illustra i passaggi che puoi seguire per risolvere i problemi relativi al datastore Cassandra. Cassandra è un datastore permanente in esecuzione nel componente cassandra dell' architettura di runtime ibrida. Consulta anche Panoramica della configurazione dei servizi di runtime.

I pod Cassandra sono bloccati nello stato di rilascio

Sintomo

Dopo aver provato ad aggiornare i pod Cassandra, il datastore segnala che è bloccato nello stato di rilascio.

Messaggio di errore

Quando usi kubectl per visualizzare gli stati dei pod, ne viene visualizzato uno o più pod Cassandra sono bloccati nello stato di rilascio:

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

Cause possibili

Un pod bloccato in stato di rilascio può essere causato da quanto segue:

Causa Descrizione
Modifiche alla capacità di archiviazione Sono stati eseguiti i passaggi per modificare la capacità di archiviazione nel file override.yaml.
Altre modifiche alla configurazione Sono stati apportati aggiornamenti alle proprietà Cassandra nel file override.yaml; tuttavia, le modifiche non sono state applicate.

Modifiche alla capacità di archiviazione

Diagnosi

  1. Usa kubectl per visualizzare lo stato attuale di apigee pod datastore:
    kubectl get apigeeds -n apigee
    NAME STATE AGE
    default releasing 122d
  2. Controlla se sono state apportate modifiche al file override.yaml:
    1. Utilizzando il sistema di controllo della versione, confronta la versione precedente del override.yaml file con la versione corrente:
      diff OVERRIDES_BEFORE.yaml OVERRIDES_AFTER.yaml
    2. L'output di una diff in override.yaml potrebbe mostrare un possibile problema con le dimensioni della capacità dello spazio di archiviazione. Ad esempio:
      # Overrides.yaml  before:
      cassandra:
         storage:
            capacity: 500Gi
      
      # Overrides.yaml after:
      cassandra:
         storage:
            capacity: 100Gi

      Se è stata eseguita un'operazione per modificare la capacità di archiviazione in cui sono stati saltati dei passaggi e un nuovo override.yaml è stato applicato direttamente, il datastore potrebbe essere nello stato di rilascio.

  3. Controlla statefulset per assicurarti che sia presente per apigee-cassandra-default:
    kubectl describe sts -n apigee

    L'output dovrebbe avere il seguente aspetto:

    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. Verifica la presenza di errori nel controller apigee:
    kubectl logs -f apigee-controller-manager-59cf595c77-wtwnr -n apigee-system -c manager | grep apigeedatastore
    

    Risultati:

    "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"

Risoluzione

Per ripristinare lo stato di Cassandra e tornare a uno stato di esecuzione, segui questi passaggi:

  1. Disattiva apigee-controller:
    kubectl -n apigee-system edit deployments and set --enable-controllers=true to --enable-controllers=false
    
  2. Ripristina lo stato di esecuzione del datastore utilizzando il comando PATCH:
    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. Applica di nuovo il file override.yaml originale:
    ./apigeectl apply --datastore -f overrides.yaml
    
  4. Attiva apigee-controller:
    kubectl -n apigee-system edit deployments and set --enable-controllers=false to --enable-controllers=true
    
  5. Attendi il ripristino del datastore e convalidalo utilizzando quanto segue:
    kubectl get apigeeds --namespace apigee
    
  6. Verifica che i deployment e i pod Apigee siano in esecuzione. apigeeds non è più in stato di rilascio:
    kubectl get ad -n apigee
    
    kubectl get pods -n apigee
    
    kubectl get apigeeds -n apigee
    
    NAME      STATE     AGE
    default   running   24d

Altre modifiche alla configurazione

Aggiornamenti apportati a cassandra proprietà in override.yaml e le modifiche non sono state applicate. Potrebbe trattarsi di un modifica della password o delle risorse in override.yaml. Oppure l'applicazione errata di override.yaml a un cluster.

Diagnosi

Vedi la procedura descritta in Diagnosi.

Risoluzione

Consulta la procedura descritta in Risoluzione.

Deve raccogliere informazioni di diagnostica

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

  • Overrides.yaml per ogni cluster nell'installazione.
  • Un dump delle informazioni sul cluster Kubernetes dall'installazione ibrida:

    Genera cluster-info dump Kubernetes:

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

    Comprimi utilizzando zip kubernetes cluster-info dump:

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

I pod Cassandra sono bloccati nello stato In attesa

Sintomo

All'avvio, i pod Cassandra rimangono nello stato Pending (In attesa).

Messaggio di errore

Quando utilizzi kubectl per visualizzare gli stati dei pod, vedi che uno o più I pod Cassandra sono bloccati nello stato Pending. Lo stato Pending indica che Kubernetes non è in grado di pianificare il pod su un nodo: il pod non può essere creato. Ad esempio:

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

Cause possibili

Un pod bloccato nello stato In attesa può avere più cause. Ad esempio:

Causa Descrizione
Risorse insufficienti La CPU o la memoria disponibili non sono sufficienti per creare il pod.
Volume non creato Il pod è in attesa della creazione del volume permanente.
Driver CSI Amazon EBS mancante Per le installazioni EKS, il driver CSI Amazon EBS richiesto non è installato.

Diagnosi

Utilizza kubectl per descrivere il pod al fine di determinare l'origine dell'errore. Ad esempio:

kubectl -n NAMESPACE describe pods POD_NAME

Ad esempio:

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

L'output potrebbe mostrare uno di questi possibili problemi:

  • Se il problema è dovuto a risorse insufficienti, viene visualizzato un messaggio di avviso che indica la CPU o la memoria insufficienti.
  • Se il messaggio di errore indica che il pod ha richieste di volumi permanenti (PVC) immediate non associate, significa che il pod non è in grado di creare il proprio Volume permanente.

Risoluzione

Risorse insufficienti

Modifica il pool di nodi Cassandra in modo che disponga di risorse CPU e memoria sufficienti. Vedi Ridimensionamento di un pool di nodi per maggiori dettagli.

Volume permanente non creato

Se rilevi un problema con il volume permanente, descrivi il PersistentVolumeClaim (PVC) per determinare perché non viene creato:

  1. Elenca le PVC nel cluster:
    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. Descrivi la PVC del pod che presenta errori. Ad esempio, il seguente comando descrive la PVC associata al pod apigee-cassandra-default-0:
    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

    Tieni presente che in questo esempio l'oggetto StorageClass denominato apigee-sc non esiste. A risolvere il problema, creare l'oggetto StorageClass mancante nel cluster, come spiegato in Modificare il valore predefinito del campo StorageClass.

Vedi anche Eseguire il debug dei pod.

Driver CSI Amazon EBS mancante

Se l'istanza ibrida è in esecuzione su un cluster EKS, assicurati che il cluster EKS utilizzi il driver CSI (Container Storage Interface) di Amazon EBS. Per maggiori dettagli, consulta le domande frequenti sulla migrazione di Amazon EBS CSI.

I pod Cassandra sono bloccati nello stato CrashLoopBackoff

Sintomo

All'avvio, i pod Cassandra rimangono nello stato CrashLoopBackoff.

Messaggio di errore

Quando utilizzi kubectl per visualizzare gli stati dei pod, noti che uno o più pod Cassandra sono nello stato CrashLoopBackoff. Questo stato indica che Kubernetes non è in grado di creare il pod. Ad esempio:

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

Cause possibili

Un pod bloccato nello stato CrashLoopBackoff può avere diverse cause. Ad esempio:

Causa Descrizione
Il data center è diverso da quello precedente Questo errore indica che il pod Cassandra ha un volume permanente con dati di una e i nuovi pod non potranno unirsi al cluster precedente. Questo di solito si verifica quando rimangono volumi permanenti inattivi dalla versione precedente di Cassandra di un cluster Kubernetes sullo stesso nodo Kubernetes. Questo problema può verificarsi se elimini e ricrei Cassandra nel cluster.
Upgrade di Kubernetes Un upgrade di Kubernetes potrebbe influire sul cluster Cassandra. Questo può accadere quando viene eseguito l'upgrade dei nodi worker Anthos che ospitano i pod Cassandra a una nuova versione del sistema operativo.

Diagnosi

Controlla il log degli errori di Cassandra per determinare la causa del problema.

  1. Elenca i pod per ottenere l'ID del pod Cassandra in errore:
    kubectl get pods -n NAMESPACE
  2. Controlla il log del pod con errori:
    kubectl logs POD_ID -n NAMESPACE

Risoluzione

Cerca i seguenti indizi nel log del pod:

Il data center è diverso da quello precedente

Se viene visualizzato questo messaggio di log:

Cannot start node if snitch's data center (us-east1) differs from previous data center
  • Controlla se nel cluster sono presenti PVC obsolete o obsolete ed eliminale.
  • Se si tratta di una nuova installazione, elimina tutte le PVC e riprova a eseguire la configurazione. Ad esempio:
    kubectl -n NAMESPACE get pvc
    kubectl -n NAMESPACE delete pvc cassandra-data-apigee-cassandra-default-0

L'upgrade di Anthos cambia le impostazioni di sicurezza

Controlla se nei log di Cassandra è presente questo messaggio di errore:

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

Creare un contenitore client per il debug

Questa sezione spiega come creare un contenitore client da cui puoi accedere alle utility di debug di Cassandra come cqlsh. Queste utilità ti consentono di eseguire query sulle tabelle Cassandra e possono essere utili per il debug.

Crea il contenitore del client

Per creare il contenitore client:

  1. Il contenitore deve utilizzare il certificato TLS del pod apigee-cassandra-user-setup. Viene archiviato come secret Kubernetes. Recupera il nome del secret che memorizza questo certificato:
    kubectl get secrets -n apigee --field-selector type=kubernetes.io/tls | grep apigee-cassandra-user-setup | awk '{print $1}'

    Questo comando restituisce il nome del secret. Ad esempio: apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls. Lo utilizzerai di seguito nel campo secretName del file YAML.

  2. Apri un nuovo file e incolla al suo interno la seguente specifica del pod:
    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. Salva il file con un'estensione .yaml. Ad esempio: my-spec.yaml.
  4. Applica la specifica al cluster:
    kubectl apply -f YOUR_SPEC_FILE.yaml -n apigee
  5. Accedi al contenitore:
    kubectl exec -n apigee CASSANDRA_CLIENT_NAME -it -- bash
  6. Connettiti all'interfaccia cqlsh di Cassandra con il seguente comando. Inserisci il esattamente come mostrato:
    cqlsh ${CASSANDRA_SEEDS} -u ${APIGEE_DML_USER} -p ${APIGEE_DML_PASSWORD} --ssl

Eliminazione del pod client

Utilizza questo comando per eliminare il pod del client Cassandra:

kubectl delete pods -n apigee cassandra-client

Espansione della regione configurata in modo errato: tutti i nodi Cassandra in un unico data center

Questa situazione si verifica in un'espansione multiregionale su piattaforme GKE e GKE On-Prem (Anthos). Cerca di evitare di creare tutti i tuoi Nodi Cassandra nello stesso data center.

Sintomo

La creazione dei nodi Cassandra nel data center per la seconda regione non riesce.

Messaggio di errore

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

Risoluzione

Correggi l'espansione della regione configurata in modo errato seguendo questa procedura:

  1. Aggiorna il replicaCount di Cassandra in 1 nel overrides.yaml per il secondo data center. Ad esempio:
    cassandra:
      . . .
      replicaCount: 1

    Applica l'impostazione con apigeectl apply:

    $APIGEECTL_HOME/apigeectl apply -f 2ND_DATACENTER_OVERRIDES.yaml
  2. Usa kubectl exec per accedere al pod Cassandra rimanente con il seguente comando:
    kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
  3. Esegui il ritiro del pod Cassandra rimanente con il seguente comando:
    nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD decommission
  4. Elimina i pod Cassandra dal secondo data center utilizzando apigeectl delete con l'argomento --datastore. Ad esempio:
    $APIGEECTL_HOME/apigeectl delete -f 2ND_DATACENTER_OVERRIDES.yaml --datastore
  5. Modifica il contesto Kubernetes nel cluster per il primo data center:
    kubectl config use-context FIRST_DATACENTER_CLUSTER
  6. Verifica che non siano presenti nodi Cassandra in stato di riposo nel primo data center.
    nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status
  7. Verifica che i nodi Cassandra configurati in modo errato (destinati al secondo data center) siano stati rimossi dal primo data center. Assicurati che gli indirizzi IP visualizzati L'output dello stato nodetool è costituito solo dagli indirizzi IP dei pod Cassandra destinati il primo data center. Ad esempio, nel seguente output l'indirizzo IP 10.100.0.39 dovrebbe essere per un pod nel tuo primo data center.
    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. Verifica che il file overrides.yaml per il secondo data center contenga l'impostazione del nome del data center nella sezione cassandra. Ad esempio:
    cassandra:
      datacenter: DATA_CENTER_2
      rack: "RACK_NAME" # "ra-1" is the default value.
      . . .
  9. Aggiorna l'impostazione cassandra:replicaCount nel file overrides.yaml per il secondo data center con il numero desiderato. Ad esempio:
    cassandra:
      datacenter: DATA_CENTER_2
      . . .
      replicaCount: 3
  10. Applica il file overrides.yaml per il secondo data center con l'argomento --datastore. Ad esempio:
    $APIGEECTL_HOME/apigeectl apply -f 2ND_DATACENTER_OVERRIDES.yaml --datastore
  11. Utilizza kubectl exec per accedere a uno dei nuovi pod Cassandra nel secondo e verificare che esistano due data center:
     "nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status"

Risorse aggiuntive

Consulta Introduzione alle guide pratiche di Apigee X e Apigee hybrid.