Guide de dépannage Cassandra

Vous consultez la documentation d'Apigee et d'Apigee hybrid.
Il n'existe pas de documentation Apigee Edge équivalente pour ce sujet.

Cette rubrique décrit les étapes à suivre pour résoudre les problèmes liés au datastore Cassandra. Cassandra est un magasin de données persistant qui s'exécute dans le composant cassandra de l 'architecture d'exécution hybride. Consultez également la présentation de la configuration du service d'exécution.

Les pods Cassandra sont bloqués dans l'état "En attente"

Symptôme

Au démarrage, les pods Cassandra restent à l'état En attente.

Message d'erreur

Lorsque vous utilisez kubectl pour afficher les états des pods, vous constatez qu'un ou plusieurs pods Cassandra sont bloqués dans l'état Pending. L'état Pending indique que Kubernetes ne peut pas planifier le pod sur un nœud : le pod ne peut pas être créé. Exemple :

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

Causes possibles

Un pod bloqué dans l'état "Pending" (En attente) peut avoir plusieurs causes. Exemple :

Cause	Description
Ressources insuffisantes	Le processeur ou la mémoire sont insuffisants pour créer le pod.
Volume non créé	Le pod attend que le volume persistant soit créé.
Pilote CSI Amazon EBS manquant	Pour les installations EKS, le pilote CSI Amazon EBS requis n'est pas installé.

Diagnostic

Utilisez kubectl pour décrire le pod afin de déterminer la source de l'erreur. Exemple :

kubectl -n NAMESPACE describe pods POD_NAME

Exemple :

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

Le résultat peut présenter l'un des problèmes suivants :

Si le problème est dû à des ressources insuffisantes, un message d'avertissement indique un processeur ou une mémoire insuffisants.
Si le message d'erreur indique que le pod a une requête PersistentVolumeClaim (PVC) immédiate non liée, cela signifie qu'il ne peut pas créer son volume persistant.

Solution

Ressources insuffisantes

Modifiez le pool de nœuds Cassandra afin qu'il dispose de suffisamment de ressources processeur et de mémoire. Pour en savoir plus, consultez la section Redimensionner un pool de nœuds.

Volume persistant non créé

Si vous déterminez un problème de volume persistant, décrivez la PersistentVolumeClaim (PVC) pour déterminer la raison de son absence de création :

Répertoriez les PVC du 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
...

Décrivez la PVC du pod qui échoue. Par exemple, la commande suivante décrit la PVC liée au 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

Notez que dans cet exemple, la ressource StorageClass nommée apigee-sc n'existe pas. Pour résoudre ce problème, créez la ressource StorageClass manquante dans le cluster, comme expliqué dans la section Modifier la ressource StorageClass par défaut.

Consultez également la section Déboguer des pods.

Pilote CSI Amazon EBS manquant

Si l'instance hybride s'exécute sur un cluster EKS, assurez-vous que le cluster EKS utilise le pilote CSI (Container Storage Interface) Amazon EBS. Pour en savoir plus, consultez les questions fréquentes sur la migration CSI Amazon EBS.

Les pods Cassandra sont bloqués dans l'état CrashLoopBackoff

Symptôme

Lors du démarrage, les pods Cassandra restent à l'état CrashLoopBackoff.

Message d'erreur

Lorsque vous utilisez kubectl pour afficher l'état des pods, vous constatez qu'un ou plusieurs pods Cassandra sont à l'état CrashLoopBackoff. Cet état indique que Kubernetes n'est pas en mesure de créer le pod. Exemple :

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

Causes possibles

Un pod bloqué dans l'état CrashLoopBackoff peut avoir plusieurs causes. Exemple :

Cause	Description
Le centre de données est différent du centre de données précédent	Cette erreur indique que le pod Cassandra possède un volume persistant contenant les données d'un cluster précédent et que les nouveaux pods ne peuvent pas rejoindre l'ancien cluster. Cela se produit généralement lorsque des volumes persistants obsolètes persistent du cluster Cassandra précédent sur le même nœud Kubernetes. Ce problème peut se produire si vous supprimez et recréez l'environnement Cassandra dans le cluster.
Mise à niveau de Kubernetes	Une mise à niveau de Kubernetes peut affecter le cluster Cassandra. Cela peut se produire si les nœuds de calcul Anthos hébergeant les pods Cassandra sont mis à niveau vers une nouvelle version d'OS.

Cause

Description

Le centre de données est différent du centre de données précédent

Cette erreur indique que le pod Cassandra possède un volume persistant contenant les données d'un cluster précédent et que les nouveaux pods ne peuvent pas rejoindre l'ancien cluster. Cela se produit généralement lorsque des volumes persistants obsolètes persistent du cluster Cassandra précédent sur le même nœud Kubernetes. Ce problème peut se produire si vous supprimez et recréez l'environnement Cassandra dans le cluster.

Mise à niveau de Kubernetes

Une mise à niveau de Kubernetes peut affecter le cluster Cassandra. Cela peut se produire si les nœuds de calcul Anthos hébergeant les pods Cassandra sont mis à niveau vers une nouvelle version d'OS.

Diagnostic

Consultez le journal d'erreurs Cassandra pour déterminer la cause du problème.

Répertoriez les pods pour obtenir l'ID du pod Cassandra qui échoue :
```
kubectl get pods -n NAMESPACE
```
Vérifiez le journal du pod défaillant :
```
kubectl logs POD_ID -n NAMESPACE
```

Solution

Recherchez les indices suivants dans le journal du pod :

Le centre de données est différent du centre de données précédent

Si vous voyez ce message de journal :

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

Vérifiez s'il existe des anciennes versions du PVC dans le cluster et supprimez-les.
S'il s'agit d'une nouvelle installation, supprimez toutes les PVC et relancez la configuration. Par exemple :
```
kubectl -n NAMESPACE get pvc
kubectl -n NAMESPACE delete pvc cassandra-data-apigee-cassandra-default-0
```

La mise à niveau d'Anthos modifie les paramètres de sécurité

Vérifiez si le message d'erreur suivant figure dans les journaux Cassandra :

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

Si l'instance Hybrid est multirégionale, mettez hors service l'instance Hybrid concernée et redéveloppez l'installation dans la région concernée.
Si l'instance Hybrid est associée à une région unique, effectuez un redémarrage progressif sur chaque pod Cassandra de l'instance Hybrid.

Créer un conteneur client pour le débogage

Cette section explique comment créer un conteneur client à partir duquel vous pouvez accéder aux utilitaires de débogage Cassandra tels que cqlsh. Ces utilitaires vous permettent d'interroger les tables Cassandra et peuvent être utiles à des fins de débogage.

Créer le conteneur client

Pour créer le conteneur client, procédez comme suit :

Le conteneur doit utiliser le certificat TLS du pod apigee-cassandra-user-setup. Cet identifiant est stocké en tant que secret Kubernetes. Récupérez le nom du secret qui stocke ce certificat :
```
kubectl get secrets -n apigee --field-selector type=kubernetes.io/tls | grep apigee-cassandra-user-setup | awk '{print $1}'
```
Cette commande renvoie le nom du secret. Exemple : apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls. Vous l'utiliserez ci-dessous dans le champ secretName du fichier YAML.

Ouvrez un nouveau fichier et collez-y la spécification de pod suivante :

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

Enregistrez le fichier avec l'extension .yaml. Exemple : my-spec.yaml.
Appliquez les spécifications à votre cluster comme suit :
```
kubectl apply -f YOUR_SPEC_FILE.yaml -n apigee
```

Connectez-vous au conteneur :

kubectl exec -n apigee CASSANDRA_CLIENT_NAME -it -- bash

Connectez-vous à l'interface Cassandra cqlsh à l'aide de la commande suivante. Saisissez la commande exactement comme indiqué ci-dessous :
```
cqlsh ${CASSANDRA_SEEDS} -u ${APIGEE_DML_USER} -p ${APIGEE_DML_PASSWORD} --ssl
```

Supprimer le pod client

Utilisez la commande suivante pour supprimer le pod client Cassandra :

kubectl delete pods -n apigee cassandra-client

Mauvaise configuration de l'extension de région : tous les nœuds Cassandra dans un centre de données

Cette situation se produit dans un emplacement multirégional sur les plates-formes GKE et GKE On-Prem (Anthos). Évitez d'essayer de créer tous vos nœuds Cassandra dans le même centre de données.

Symptôme

Les nœuds Cassandra ne sont pas créés dans le centre de données de la deuxième région.

Message d'erreur

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

Solution

Réparez l'expansion de la région mal configurée en procédant comme suit :

Mettez à jour la base de données Cassandra de replicaCount vers 1 dans le fichier overrides.yaml du deuxième centre de données. Exemple :
```
cassandra:
  . . .
  replicaCount: 1
```
Appliquez le paramètre à l'aide de apigeectl apply :
```
$APIGEECTL_HOME/apigeectl apply -f 2ND_DATACENTER_OVERRIDES.yaml
```
Utilisez kubectl exec pour accéder au pod Cassandra restant à l'aide de la commande suivante :
```
kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
```
Mettez hors service le pod Cassandra restant à l'aide de la commande suivante :
```
nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD decommission
```
Supprimez les pods Cassandra du deuxième centre de données à l'aide de apigeectl delete avec l'argument --datastore. Exemple :
```
$APIGEECTL_HOME/apigeectl delete -f 2ND_DATACENTER_OVERRIDES.yaml --datastore
```
Remplacez le contexte Kubernetes par le cluster de votre premier centre de données :
```
kubectl config use-context FIRST_DATACENTER_CLUSTER
```
Vérifiez qu'aucun nœud Cassandra n'est indisponible dans le premier centre de données.
```
nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status
```

Vérifiez que les nœuds Cassandra configurés pour le deuxième centre de données ont été supprimés du premier centre de données. Assurez-vous que les adresses IP affichées dans le résultat de l'état de nodetool sont uniquement les adresses IP des pods Cassandra destinés à votre premier centre de données. Par exemple, dans le résultat suivant, l'adresse IP 10.100.0.39 doit correspondre à un pod de votre premier centre de données.

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

Vérifiez que le fichier overrides.yaml du deuxième centre de données contient le paramètre de nom du centre de données dans la section Cassandra. Exemple :
```
cassandra:
  datacenter: DATA_CENTER_2
  rack: "RACK_NAME" # "ra-1" is the default value.
  . . .
```
Mettez à jour le paramètre cassandra:replicaCount dans le fichier overrides.yaml du deuxième centre de données sur le nombre souhaité. Exemple :
```
cassandra:
  datacenter: DATA_CENTER_2
  . . .
  replicaCount: 3
```
Remarque : La valeur de cassandra:replicaCount doit être un multiple de 3. Utilisez pour replicaCount la même valeur que celle spécifiée pour votre premier centre de données.
Appliquez le fichier overrides.yaml pour le deuxième centre de données avec l'argument --datastore. Exemple :
```
$APIGEECTL_HOME/apigeectl apply -f 2ND_DATACENTER_OVERRIDES.yaml --datastore
```
Utilisez kubectl exec pour accéder à l'un des nouveaux pods Cassandra du deuxième centre de données et vérifiez qu'il existe deux centres de données :
```
 "nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status"
```

Autres ressources

Consultez la page Présentation des playbooks Apigee X et Apigee hybrides