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) !
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