Questa pagina è stata tradotta dall'API Cloud Translation.

Guida alla risoluzione dei problemi di Cassandra

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

Questo argomento illustra i passaggi che puoi seguire per risolvere i problemi relativi al datastore Cassandra. Cassandra è un datastore permanente eseguito nel componente cassandra dell'architettura di runtime ibrida. Vedi anche Panoramica della configurazione del servizio di runtime.

I pod Cassandra sono bloccati nello stato di rilascio

Sintomo

Dopo aver tentato di eseguire un aggiornamento ai pod Cassandra, il datastore segnala che è bloccato in stato di rilascio.

Messaggio di errore

Quando utilizzi kubectl per visualizzare gli stati dei pod, vedrai che 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 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 hanno avuto effetto.

Modifiche alla capacità di archiviazione

Diagnosi

Utilizza kubectl per visualizzare lo stato attuale del pod del datastore apigee:
```
kubectl get apigeeds -n apigee
```
```
NAME STATE AGE
default releasing 122d
```
Controlla se sono state apportate modifiche al file override.yaml:

Utilizzando il tuo sistema di controllo della versione, confronta la versione precedente del file override.yaml con quella corrente:
```
diff OVERRIDES_BEFORE.yaml OVERRIDES_AFTER.yaml
```
L'output di un diff in override.yaml potrebbe mostrare il possibile problema con la dimensione della capacità 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 nel punto in cui i passaggi sono stati saltati e sia stato applicato direttamente un nuovo override.yaml, il datastore potrebbe essere in stato di rilascio.

Controlla statefulset per assicurarti che ne sia presente uno per apigee-cassandra-default:

kubectl describe sts -n apigee

L'output avrà un aspetto simile al seguente:

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

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 esecuzione di Cassandra, segui questi passaggi:

Disattiva apigee-controller:

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

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'

Riapplica il file override.yaml originale:

./apigeectl apply --datastore -f overrides.yaml

Attiva apigee-controller:

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

Attendi il ripristino del datastore ed esegui la convalida utilizzando quanto segue:
```
kubectl get apigeeds --namespace apigee
```

Verifica che i deployment e i pod Apigee siano in esecuzione e che apigeeds non sia 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

Gli aggiornamenti apportati alle proprietà cassandra in override.yaml e le modifiche non hanno avuto effetto. Potrebbe trattarsi di una 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.

Raccogliere dati diagnostici

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

Overrides.yaml per ogni cluster nell'installazione.

Un dump delle informazioni del cluster Kubernetes dall'installazione ibrida:

Genera Kubernetes cluster-info dump:

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

Comprimi con 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 in stato In attesa.

Messaggio di errore

Quando utilizzi kubectl per visualizzare gli stati dei pod, puoi vedere che uno o più pod Cassandra sono bloccati nello stato Pending. Lo stato Pending indica che Kubernetes non è in grado di pianificare il pod su un nodo: non è possibile 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     Pending     0          10m
...

Cause possibili

Un pod bloccato nello stato In attesa può avere diverse 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 Amazon EBS CSI richiesto non è installato.

Diagnosi

Utilizza kubectl per descrivere il pod e 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 è costituito da risorse insufficienti, verrà visualizzato un messaggio di avviso che indica CPU o memoria insufficiente.
Se il messaggio di errore indica che il pod ha oggetti PersistentVolumeClaim (PVC) immediati non associati, significa che il pod non è in grado di creare il suo volume permanente.

Risoluzione

Risorse insufficienti

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

Volume permanente non creato

Se rilevi un problema di volume permanente, descrivi l'oggetto PersistentVolumeClaim (PVC) per determinare il motivo per cui non viene creato:

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

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 non esiste un oggetto StorageClass denominato apigee-sc. Per risolvere questo problema, crea il valore di StorageClass mancante nel cluster, come spiegato in Modificare il valore predefinito di StorageClass.

Vedi anche Debug dei pod.

Driver CSI Amazon EBS mancante

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

I pod Cassandra sono bloccati nello stato CrashLoopBackoff

Sintomo

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

Messaggio di errore

Quando utilizzi kubectl per visualizzare gli stati dei pod, puoi vedere che uno o più pod Cassandra si trovano 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 un cluster precedente e che i nuovi pod non sono in grado di unire il cluster precedente. Questo di solito accade quando volumi permanenti inattivi persistono dal cluster Cassandra precedente 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.

Elenca i pod per ottenere l'ID del pod Cassandra in errore:
```
kubectl get pods -n NAMESPACE
```
Controlla il log del pod con problemi:
```
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

Se l'istanza ibrida ha più regioni, dismetti l'istanza ibrida interessata e espandila nuovamente nella regione interessata.
Se l'istanza ibrida è una singola regione, esegui un riavvio in sequenza su ciascun pod Cassandra nell'istanza ibrida.

Crea un contenitore client per il debug

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

Crea il container client

Per creare il contenitore client:

Il container deve utilizzare il certificato TLS del pod apigee-cassandra-user-setup. Questo viene archiviato come secret di Kubernetes. Recupera il nome del secret in cui è archiviato 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.

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

Salva il file con l'estensione .yaml. Ad esempio: my-spec.yaml.

Applica la specifica al cluster:

kubectl apply -f YOUR_SPEC_FILE.yaml -n apigee

Accedi al container:

kubectl exec -n apigee CASSANDRA_CLIENT_NAME -it -- bash

Connettiti all'interfaccia cqlsh di Cassandra con il seguente comando. Inserisci il comando 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 data center

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

Sintomo

Impossibile creare i nodi Cassandra nel data center per la seconda regione.

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:

Aggiorna il replicaCount di Cassandra in 1 nel file 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
```
Utilizza kubectl exec per accedere al pod Cassandra rimanente con il seguente comando:
```
kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
```

Dismetti il pod Cassandra rimanente con il seguente comando:

nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD decommission

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
```
Cambia il contesto di Kubernetes con il cluster per il tuo primo data center:
```
kubectl config use-context FIRST_DATACENTER_CLUSTER
```
Verifica che non esistano nodi Cassandra in stato inattivo nel primo data center.
```
nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status
```

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 nell'output dello stato nodetool siano solo gli indirizzi IP dei pod Cassandra destinati al tuo primo data center. Ad esempio, nel seguente output l'indirizzo IP 10.100.0.39 dovrebbe essere relativo a 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

Verifica che il file overrides.yaml del 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.
  . . .
```
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
```
Nota: il valore di cassandra:replicaCount deve essere un multiplo di 3. Utilizza per replicaCount lo stesso valore specificato per il primo data center.
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
```
Utilizza kubectl exec per accedere a uno dei nuovi pod Cassandra nel secondo data center e verifica che esistano due data center:
```
 "nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status"
```

Risorse aggiuntive

Consulta l' introduzione ai playbook ibridi di Apigee X e Apigee.