Tout d’abord, toutes nos excuses pour l’anglicisme du titre mais « Cassandra : prise de pouls » ou « Cassandra : ça va bien ou bien ? » ne sonnaient pas correctement. Il faut parfois faire taire ses principes lorsque l’efficacité l’exige. Et puis, un titre anglais, c’est accrocheur.
En anglais ou en français, nous allons parler aujourd’hui de Cassandra et des vérifications nécessaires pour estimer le fonctionnement de votre cluster.
Une analyse rapide de l’état de santé de Cassandra est semblable à celle que vous feriez pour d’autres types de bases avec cependant une complication supplémentaire : l’aspect distribué demande d’avoir un moyen de passer une commande shell simultanément sur toutes les machines, ou sur un sous-ensemble. Heureusement, Cassandra fournit des outils qui prennent en compte cet aspect. Il faut tout de même être attentif à leur portée : est-ce local ou global ? Et bien sûr comprendre ce qu’ils nous répondent.
Nous allons donc voir, dans l’ordre, les possibilités d’envoyer une commande identique à tous les nœuds d’un cluster, les indicateurs systèmes à surveiller puis les principales options de l’outil intégré à Cassandra : nodetool.
Quel beau programme ! Ne perdez pas de temps et lisez donc la suite !
Première partie : les commandes systèmes et les moyens de les rendre globales
La Curiosité Escortant l’Ignorance (Allégorie)
En 2015, l’excellent Brendan Gregg publiait cet article : Linux performances analysis in 60,000 milliseconds, un le blog concurrent mais néanmoins de qualité : Netflix TechBlog. Il nous montrait comment faire le tour de la question performance système grâce à une dizaine de commandes de base : uptime (qui doit être votre premier réflexe en cas de problème de performance mais ne pas être le seul), dmesg, sar,etc. Nous vous encourageons à lire l’article et même, si vous être trèèèèèès courageux, son livre Systems Performance. Une somme, en anglais, qui fait le tour de la question. Vous noterez, lecteurs attentifs, que « systems » est au pluriel car le livre couvre à la fois Linux et Solaris, Brendan Gregg ayant co-écrit ZFS pour ce dernier (ainsi que « dtrace« , qui lui donne une autorité certaine).
Bref, fin de la parenthèse et revenons à notre sujet… Ces commandes font partie des paquets de base sur tout Unix et dérivés. Si vous n’avez pas l’habitude de les utiliser, prenez le temps : elles vous rendront chaque minutes passées avec des intérêts. Pas de piège dans le cas de Cassandra : quelle est la charge (uptime, vmstat 1 10) ? Reste-t-il de la mémoire libre (free -m, vmstat encore…) ? Les disques sont-ils saturés (iostat 1 10) ? Le seul piège étant que les processus Cassandra peuvent être longs dans leur description, surtout si vous ajoutez des fonctionnalités sous forme de Jar, et qu’un :
ps aux | grep -i CassandraDaemon
Peut ne rien vous retourner (et donc remonter une erreur dans une sonde de surveillance). Il faut penser à utiliser la description longue :
ps auxwww | grep -i CassandraDaemon
Ceci étant précisé, comment passer une commande (par exemple « uptime ») sur toutes les machines ? il y a plusieurs méthodes. Nous partirons du principe que toutes les machines se voient sur le réseau et qu’une connexion SSH sans mot de passe, par échange de clés, est possible.
- Première méthode : boucle SSH
Dans un fichier texte, listez les machines cibles et lancez la commande dans une boucle lisant les lignes les unes après les autres. Exemple :
while read host; do ssh -q -n ${host} uptime ; done < machines_cibles.txt
« -n » est nécessaire car ssh est exécuté dans une boucle, donc considéré comme en arrière plan. Sans lui, ssh sort après le traitement de la première ligne car il reçoit le signal « fin de communication ».
« -q » pour ne pas voir défiler les messages d’information. Il faut savoir ne pas se laisser distraire par les bavardages lorsque l’on travaille.
C’est une méthode simple et rapide mais attention aux « grep » et aux « | » qui se feront sur la machine de départ et non sur la cible. C’est trompeur.
- Deuxième méthode : les Shells distribués
Il existe plusieurs solutions de Shell distribués : DSH, PSSH voire – la grosse artillerie mais il faut le mentionner – Ansible, Chef, Puppet…
Comme exemple, voici un exemple avec DSH (Distributed Shell ou Dancer’s Shell, selon votre humeur). Avant toutes choses, créez un groupe avec les machines cibles dans le répertoire $DSH_HOME/etc/group sous la forme d’un simple fichier texte avec le nom ou l’adresse IP des cibles. Ensuite, la syntaxe est la suivante :
dsh -g NOM_DU_GROUPE -o'OPTION' -- COMMANDE_A_DIFFUSER
« -o » sera l’endroit où vous préciserez les paramètres tels que le compte à utiliser.
« — » est une séparation permettant d’indiquer les options de la commande distribuée.
Un exemple :
dsh -g PRODUCTION_CASSANDRA -o'-l cassandra_user' -- uptime Machine1: 16:03:00 up 148 days, 5:55, 0 users, load average: 9.68, 7.57, 6.53 Machine2: 16:03:00 up 148 days, 6:10, 0 users, load average: 8.28, 7.17, 6.01 Machine3: 16:03:01 up 148 days, 1:47, 0 users, load average: 6.36, 4.74, 4.03 Machine4: 16:03:02 up 148 days, 2:21, 0 users, load average: 7.08, 6.02, 5.03
Un des avantages de dsh est qu’il préfixe toutes les lignes retournées par le nom de la machine d’où elles proviennent. Cela permet une exploration plus aisée des résultats lorsqu’ils sont très verbeux.
- Regarder, oui, mais regarder quoi ?
Maintenant que vous pouvez passer vos commandes partout, que faut-il surveiller ?
Sur une machine hébergeant Cassandra, les deux premières causes de ralentissements sont la consommation CPU par des processus Java reflétant l’activité des différents threads (« top -H » , « prstat » ou « vmstat » vous donneront des informations sur la consommation. « sar -q » sur les files de traitements) et l’activité disque surtout en écriture (« iostat -d id_du_disque » et regarder les temps d’attente pour détecter la saturation).
Il y a de nombreuses commandes pour analyser les performances systèmes et il est parfois fastidieux de passer de l’une à l’autre, surtout si vous cherchez à suivre l’évolution de tous les critères simultanément. Heureusement pour vous existe la commande « dstat« , qui regroupe toutes les autres sur une seule ligne. Elle ne fait pas partie des paquets de base mais sachez que sur Linux elle se compile facilement et que le binaire peut être copié d’une machine à une autre sans problème.
Exemple d’utilisation : pour suivre l’évolution de la charge CPU, des IO, de la file de processus, de la mémoire et du trafic réseau, toutes les secondes pendant une minute, il suffit de saisir une quinzaine de caractères :
$ dstat -tlrvn 1 60 ----system---- ---load-avg--- --io/total- ---procs--- ------memory-usage----- ---paging-- -dsk/total- ---system-- --total-cpu-usage-- -net/total- time | 1m 5m 15m | read writ|run blk new| used free buff cach| in out | read writ| int csw |usr sys idl wai stl| recv send 02-02 16:34:55|0.99 0.78 0.72|3.95 2.33 | 0 0 0.4|3105M 284M 23.8M 418M|7838B 18k| 67k 97k| 648 2121 | 5 1 94 1 0| 0 0 02-02 16:34:56|1.07 0.80 0.73| 0 2.00 |1.0 0 0|3101M 288M 23.8M 418M| 0 0 | 0 420k|1415 5772 | 14 1 85 0 0| 853B 0 02-02 16:34:57|1.07 0.80 0.73| 0 0 | 0 0 1.0|3077M 312M 23.8M 418M| 0 0 | 0 0 |6940 7896 | 15 2 82 1 0| 693B 0 02-02 16:34:58|1.07 0.80 0.73| 0 4.00 |1.0 0 0|3077M 312M 23.8M 418M| 0 0 | 0 248k|1694 8148 | 8 1 89 2 0| 757B 0 02-02 16:34:59|1.07 0.80 0.73| 0 0 | 0 0 0|3080M 309M 23.8M 418M| 0 0 | 0 0 |2336 8321 | 21 1 78 0 0| 757B 0 02-02 16:35:00|1.07 0.80 0.73| 0 0 | 0 0 0|3080M 309M 23.8M 418M| 0 0 | 0 0 |1937 9754 | 9 1 89 1 0|1071B 241B
Pratique, n’est-ce pas ?
Voilà pour l’aspect système. Cet article étant déjà long, nous vous proposons de faire une pause et nous retrouver la semaine prochaine pour la partie Cassandra.
Note: pour être vraiment complet, nous nous devons de préciser que la « connexion SSH sans mot de passe » n’est même pas obligatoire si vous faites une boucle en shell et utilisez « expect« . C’est un moyen pratique et méconnu qui fera l’objet d’un article plus tard.
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.com
Crédit photo: wikimedia common