Cassandra : exclure un nœud défectueux

de | 2017-04-21

Les accidents, ça n’arrive pas qu’aux autres.

Aujourd’hui, dans notre série « Le Malheur Frappe Dès Le Matin », une histoire vraie.

Dans un cluster Cassandra assez volumineux, construit sur des machines physiques, un des membres se bloque. C’était un noeud comme les autres, sans histoire, arrivé depuis peu dans le voisinage, toujours poli et souriant. Apprécié de tous. Mais rien à faire : il était bloqué – bien que la connexion en cqlsh passât toujours –  et il y a fallu l’intervention d’un « kill -9 » pour le maîtriser.

Alors pourquoi ? Et que faire ? Envoyez vos témoignages !

Envoyez Vos Témoignages (et vos sous) !

Envoyez Vos Témoignages (et vos sous) !

Quant à nous, agissons !

1) L’erreur initiale

Nagios : la sonde surveillant le commitlog est en erreur.

Sur la machine : Cassandra est toujours joignable. Dans son journal d’évènement, des erreurs de connexion et sur le SharedPoolThread, ce qui est mauvais signe.

Dans le journal linux :

sd 2:0:0:0: [sda] Add. Sense: Unrecovered read error
sd 2:0:0:0: [sda] CDB: Read(10): 28 00 10 ca 60 00 00 01 00 00
end_request: critical medium error, dev sda, sector 281698304

C’est une bonne et une mauvaise nouvelle. La mauvaise, pour commencer, étant que le disque sur lequel est écrit le commitlog est en panne. La bonne étant que c’est un problème système, pas le votre.

Néanmoins, sauf récupération rapide de la machine, vous ferez aussi bien d’éjecter le nœud : il faut souvent un certain délais avant qu’un technicien puisse intervenir, diagnostiquer. A celui-ci s’ajoute le délais de remplacement du disque, de restauration… Bref, nous n’allons pas nous embêter : il reste 10 machines dans ce datacenter (au sens Cassandra et physiquement).

2) Action !

Premièrement, arrêtez Cassandra (un « kill -9 » fera l’affaire puisque l’on va l’exclure).

Ensuite, connectez vous sur une autre machine, dans le même datacenter. Elle fera office de coordinateur pour l’opération.

Maintenant, il faut identifier le noeud fautif. ce sera grâce à « nodetool status » :

SHELL> nodetool status --resolve-ip 

Cherchez la ligne commençant par « DN » (« Down and Normal ») et repérez son « HostID » :

Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address                              Load       Tokens  Owns    Host ID                       Rack
DN  machine5                     436,29 GB  256     ?       7ac8aa08-e850-4457-9ab7-28576cf84600  RAC1
UN  machine4                     492,56 GB  256     ?       6032aba3-9fae-4259-aefe-5dceb029bf2b  RAC1
UN  machine1                     390,61 GB  256     ?       801e0038-b5b1-4d21-a8d5-527adad6c377  RAC1

« Host ID » va nous servir à cibler la commande suivante : « nodetool removenode » :

SHELL> nohup nodetool removenode HostID &

Note: le « nohup » est probablement superflu mais c’est une habitude.

Les données vont être redistribuées entre les membres restant. Comme il y en à 10, c’est relativement rapide mais comptez quelques heures pour 500 Go.

Vous pouvez suivre la progression avec « nodetool removenode status » : elle affiche une liste des partenaires affectés par la redistribution des données.

Lorsque « nodetool removenode status » ne retourne plus rien et que le « nodetool status –resolve-ip » ne liste plus la machine en erreur, l’opération est terminée. Vous avez le temps de réparer puis de ré-introduire la machine sans que cela n’affecte le service. Un très gros avantage de cette architecture.

3) Conclusion

Un disque qui tombe en panne, ça arrive. Surtout que les projets de type Cassandra, MongoDB ou Elasticsearch sont bien souvent construit sur du matériel au rabais. Ce que nous appelons « des POC ayant tragiquement bien tournés ». Hélas, une fois la preuve apportée de son utilité, il est très rare que l’existant soit remis en question et que son évolution soit financée. D’où un taux de pannes matérielles logiquement plus élevées que sur des châssis payés affreusement chers.

Moralité : soignez vos prototypes ! Ils risquent de passer en production plus vite que vous ne l’auriez pensé !

Des problèmes ? des questions ? Exprimez-vous ! Les commentaires sont ouverts. Coquilles et fautes de grammaires sont notre lot quotidien : signalez-les nous à m.capello@dbsqware.c

 

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*