Résoudre les problèmes de restauration de Cassandra

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

Symptôme

Lors de la restauration Cassandra dans Apigee hybrid, vous pouvez rencontrer des erreurs dans les journaux de restauration.

Message d'erreur

L'un des éléments suivants s'affiche dans les journaux :

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

Causes possibles

Cause	Description	Instructions de dépannage applicables
Connexion expirée	Il s'agit d'une erreur de connectivité entre les pods `apigee-cassandra-restore` et `apigee-cassandra-default-*`.	Apigee hybrid
Opération arrivée à expiration	Cette erreur se produit si la restauration expire après 15 minutes.	Apigee hybrid
Existe déjà	Ce message d'erreur n'est pas lié à la cause du problème et résulte d'une nouvelle tentative d'un job de restauration.	Apigee hybrid

Cause : connexion expirée

Il s'agit d'une erreur de connectivité entre les pods apigee-cassandra-restore et les pods apigee-cassandra-default-* :

java.net.ConnectException: Connection timed out (Connection timed out)

Diagnostic

Si votre réseau hôte n'est pas accessible à partir du réseau du pod, assurez-vous que hostNetwork est défini sur false sous cassandra dans overrides.yaml, comme indiqué dans Restaurer une région à partir d'une sauvegarde.
Pour tester la connectivité, connectez-vous au pod apigee-mart ou apigee-runtime, qui se trouve sur le même réseau que le job apigee-cassandra-restore. Vous pouvez également utiliser n'importe quel autre pod dans le réseau du pod.
1. Obtenez le nom du pod apigee-mart :
```
kubectl -n apigee get po --selector=app=apigee-mart --no-headers -o custom-columns=":metadata.name"
```
2. Exécutez une session bash dans le pod mart :
```
kubectl exec -it MART_POD_NAME -n apigee -- bash
```
  Remplacez MART_POD_NAME par le nom du pod MART. Par exemple, apigee-mart-myorg--9a8228a-191-t0xh1-qz5fl.
3. Exécutez des tests de connectivité sur les ports Cassandra :
```
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
```
Si vous obtenez une erreur Connection timed out, cela signifie que vous rencontrez des problèmes de connectivité. Toutefois, si un message Connected to s'affiche, la connexion a bien été établie. Vous devez alors appuyer sur Ctrl+C pour fermer la connexion et continuer.

Solution

Assurez-vous que le paramètre HostNetwork est défini sur false dans le fichier overrides.yaml utilisé pour la restauration, puis répétez le processus de restauration. Si le paramètre est déjà défini sur false, mais que vous rencontrez des erreurs de connectivité, assurez-vous que les pods Cassandra sont opérationnels à l'aide de la commande suivante :

kubectl get pods -n apigee -l app=apigee-cassandra

La sortie doit se présenter sous la forme suivante :

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 %

Cause : l'opération a expiré

L'erreur suivante se produit si la restauration expire après 15 minutes. L'erreur indique des problèmes d'E/S, par exemple lorsque le stockage et le réseau ne permettent pas de transmettre à temps le contenu non compressé de la sauvegarde.

/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

Diagnostic

Consultez les journaux apigee-cassandra-default-0 pour noter l'horodatage du début de la restauration :
```
kubectl logs apigee-cassandra-default-0 -n apigee | grep 'MigrationManager.java' | head -n 1
```
Comparez l'horodatage avec la dernière de création de table dans les journaux :
```
kubectl logs apigee-cassandra-default-0 -n apigee | grep 'Create new table' | tail -n 1
```
Les résultats de cette comparaison doivent indiquer que le pod Cassandra était toujours en train de créer des tables après le dépassement du délai avant expiration.

Testez la bande passante de stockage à l'aide des commandes suivantes :

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'

Si la vitesse d'écriture est inférieure à 100 M/s, cela peut signifier l'absence de ressource StorageClass appropriée (SSD).

Testez la bande passante réseau :
1. Exécutez netcat sur le pod Cassandra pour écouter sur le port :
```
kubectl -n apigee exec -it apigee-cassandra-default-0 -- bash -c 'nc -l -p 3456 > /dev/null'
```
2. Dans une session shell distincte, obtenez le nom du pod apigee-mart :
```
kubectl -n apigee get po --selector=app=apigee-mart --no-headers -o custom-columns=":metadata.name"
```
3. Exécutez une session bash dans le pod apigee-mart. Vous pouvez également utiliser n'importe quel autre pod dans le réseau du pod :
```
kubectl exec -it MART_POD_NAME -n apigee -- bash
```
  Remplacez MART_POD_NAME par le nom du pod MART. Par exemple, apigee-mart-myorg--9a8228a-191-t0xh1-qz5fl.
4. Exécutez un test de bande passante réseau sur le pod Cassandra qui exécute toujours netcat :
```
dd if=/dev/zero bs=50M count=1 | nc apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local 3456
```
Vous pouvez répéter cette procédure pour d'autres pods Cassandra. Si la vitesse obtenue est inférieure à 10 M/s, la bande passante réseau est probablement la cause du problème.

Solution

Une fois que vous avez confirmé la vitesse d'E/S lente à l'aide des étapes ci-dessus, assurez-vous que votre cluster satisfait les besoins minimum en termes de réseau et de stockage. Testez à nouveau la bande passante.

Cause : existe déjà

Diagnostic

Une erreur semblable à celle-ci s'affiche :

/tmp/tmp/schema.cql:6409:AlreadyExists: Table 'kvm_myorg.kvm_map_keys_descriptor' already exists

Solution

Ce message d'erreur n'est pas lié à la cause du problème et résulte d'une nouvelle tentative d'un job de restauration. Le message d'erreur réel devrait apparaître dans les journaux du premier pod qui a échoué.

Obtenez les journaux de l'échec initial afin de diagnostiquer le problème.

Si le problème persiste, consultez la page Vous devez collecter des informations de diagnostic.

Vous devez collecter des informations de diagnostic

Si le problème persiste, même après avoir suivi les instructions ci-dessus, rassemblez les informations de diagnostic suivantes, puis contactez Google Cloud Customer Care :

Outre les données habituelles que vous pouvez être invité à fournir, collectez les données de diagnostic de tous les pods Cassandra à l'aide de la commande suivante :

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

Compressez-les et incluez-les dans la demande d'assistance :

tar -cvzf /tmp/cassandra_data_$(date +%Y.%m.%d_%H.%M.%S).tar.gz /tmp/k_cassandra_nodetool*

Collectez et incluez les journaux du pod de restauration. Notez que les journaux ne restent disponibles que peut de temps. Ils doivent donc être collectés juste après l'échec.
Si vous avez suivi les étapes de diagnostic ci-dessus, collectez tous les résultats de la console, copiez-les dans un fichier et incluez le fichier dans la demande d'assistance.