Quelque soit le type de moteur, il y a toujours des opérations récurrentes à faire. De la simple sauvegarde au calcul de statistiques défini table par table, la complexité peut varier mais il est exceptionnel qu’une crontab de production reste vide (nous vous entendons dans le fond, cessez de crier. Oui : « on peut et on doit utiliser un ordonnanceur parce que c’est plus souple et plus sûr ». Nous sommes d’accord. Mais qu’est-ce qu’un ordonnanceur si ce n’est une crontab généralisée ?) .
Cassandra, NoSQL ou pas, ne déroge pas cette règle. La littérature insiste particulièrement sur deux opérations à faire régulièrement : les compactions (action sur les fichiers, pour la performance) et réparations (repair, action sur les données, pour la cohérence). Si nous ne rentrerons pas dans le détail de ces commandes aujourd’hui (il y a déjà une série d’articles sur le sujet), nous allons montrer comment dbSqware facilite la distribution des commandes entre les nœuds d’un cluster.
Pour cela, nous allons partir sur cet exemple : dans un cluster de douze nœuds répartis entre deux datacenters, nous voulons qu’une commande de compaction majeure soit lancée toutes les semaines.
Moïse : le premier exemple d’ordonnancement réussi.
En pré-requis, il faut que dbSqware soit déployée sur au moins une machine du cluster, laquelle sera considérée comme le point central. Un conseil toutefois : les machines devant rester interchangeables, il est conseillé d’installer dbSqware partout. Par exemple – soyons fous – en l’intégrant à votre procédure d’installation. Concrètement, peu importe la machine tant qu’elle peut voir tous ses partenaires.
Configuration
Après connexion, vérifiez que l’alias « cfg » est disponible dans votre environnement.
$ alias cfg alias cfg='cd /home/vous/NOM_DU_CLUSTER/sqwConfig; ls -al'
Si ce n’est pas le cas, votre installation n’est pas correcte. Ou pas faite. Bref: prenez le temps de lire la documentation officielle avant de poursuivre. Sinon, un simple
cfg
vous amène au bon endroit : le répertoire vers lequel pointe la variable $gvsqw_RootCfg (Par exemple: $HOME/$nom_instance/sqwConfig).
Dans ce répertoire, une poignée de fichiers :
LocalDC.cfg NOM_DU_CLUSTER.clucfg sqwcas_Jobs.cfg
Les deux premiers sont générés automatiquement lorsque dbSqware est parvenu à se connecter à une machine au moins. « LocalDC.cfg » contient le nom du datacenter local, ce qui montre que son nom est particulièrement bien choisi. « NOM_DU_CLUSTER.clucfg » contient la liste des nœuds découverts, sous la forme de lignes comme celles-ci :
NOM_DU_CLUSTER;PROD1;B1D;machine1;21;2.1.9 NOM_DU_CLUSTER;PROD1;B1D;machine2;21;2.1.9 NOM_DU_CLUSTER;PROD1;B1D;machine3;21;2.1.9
Mais c’est le troisième qui nous intéresse pour le moment : « sqwcas_Jobs.cfg ». Il est au même format que pour les autres moteurs supportés (« sqwora_Jobs.cfg » pour Oracle, « sqwsyb_Jobs.cfg » pour Sybase, etc).
La commande est de la forme :
#NodetoolCompact: run "nodetool compact" on all nodes NodetoolCompact:$gvsqw_CasBin/sqwcas_CentralisedNodetool.ksh -I NOM_DU_CLUSTER -C 'compact' -S DC_DC1 -Dynamic -Exec
- Le premier champ est le descripteur qui sera appelé par le script générique « sqwcas_RunJob.ksh ».
- Le second est le script à exécuter. Ici : « sqwcas_CentralisedNodetool.ksh ». Celui-ci se charge des commandes Cassandra qui lui sont précisées par « -C ». Ici: une compaction majeure sans paramètre. Le nom de cluster visé est obligatoire. « -S » est le périmètre d’action : un datacenter, plusieurs datacenters, un seul nœud, un sous-ensemble ou tous en même temps.
Pour obtenir de l’aide : « sqwcas_CentralisedNodetool.ksh -h ».
Usage: sqwcas_CentralisedNodetool.ksh [-h] -I <instance> -C <command options> [+ options] DESCRIPTION sqwcas_CentralisedNodetool.ksh Run 'nodetool' command on selected nodes SUPPORT Cassandra supported versions: 2.0 <= v <= 3.0 PARAMETERS -I instance : Target instance. -C command : Options for the nodetool command (ex: 'version', 'compact keyspace column_family' or other). OPTIONS -h help : Display the full usage. -s : Display samples of usage. -S scope : Scope of the execution (default: Local) Local => only on the local node LocalNode => only on the local node Node_$NodeName => only on the node '$NodeName' LocalDC => all nodes on the local datacenter DC_$DCName => all nodes on the datacenter '$DCName' All => all nodes on the cluster(all datacenters) AllNodes => all nodes on the cluster(all datacenters) AllDC => all nodes on the cluster(all datacenters) -AGR Nb sec : Nb of seconds between two run (by default 1s). -AGE Nb sec : Nb of seconds between two check of end (by default 5s). -FRT return_code : Force return code value on error. -AddMail email : Email Address to add at 'votre_adresse@votre_domaine.fr'. -Timeout Nb_sec : Timeout before kill off ssh session. -SendReport : Send execution log report. -Dynamic : Strength discover of nodes (by default, search in $gvsqw_RootCfg/NOM_DU_CLUSTER.clucfg generated by sqwcas_GenNodesConf.ksh). -NoMail : Desactivate sendmail on error votre_adresse@votre_domaine.fr (by default, send on error). -Exec : Execute commands (default, display generated commands)
Au passage: l’aide intégrée a le bon goût d’afficher les paramètres avec les valeurs qu’elle connaît. Ici, le texte a été édité mais sachez que vous verriez vos adresses, vos noms de machines… Pratique.
Une fois les informations définies, il ne reste plus qu’à planifier suivant la méthode utilisée chez vous. L’important étant la commande appelée :
ksh -c '. $HOME/.profile NOM_DU_CLUSTER;$gvsqw_CasBin/sqwcas_RunJob.ksh -I NOM_DU_CLUSTER -A NodetoolCompact'
Le plus difficile est fait. Voyons comment se passe une exécution.
Premier lancement
A l’heure dite, le traitement se déclenche. Le log se trouve dans le répertoire correspondant à l’alias « log » (dbSqware fait un usage abondant de ce type de raccourcis qui, une fois connus, font gagner beaucoup de temps. Prenez la peine de les mémoriser: à l’usage, c’est du temps bien utilisé).
A cet endroit, plusieurs répertoires :
CentralisedNodetool GatherIndicators GenNodesConf RollingRestart RunJob TestSendmail
En cas de problème dès le lancement du job planifié, vous trouverez les informations dans « RunJob ». Mais celui qui nous intéresse est « CentralisedNodetool ».
Dans ce dernier, vous trouverez les logs d’exécutions de tous les jobs planifiés par dbSqware. Ils portent le nom du script générique plus l’horodatage.
Exemple : sqwcas_CentralisedNodetool_20170215_210006_13177.log
Note: que les fichiers portent le nom du script lanceur est logique. Par contre, si vous êtes un collectionneur de plans de maintenance (nous ne jugeons pas; nous respectons les préférences de chacun), vous devrez sans doute recourir à « grep » pour retrouver le script qui vous intéresse. Ça, c’est valable si vous êtes connecté directement sur la machine. Sinon, avec l’interface Web de dbSqware, dans l’onglet « Cassandra » puis « Technical » et enfin « Batches », vous trouverez non seulement les heures d’exécution et le statut des scripts mais également les fichiers de log. Et même les messages envoyés.
Architecture dbSqware (allégorie)
Et enfin (vous touchez au but !), dans le fichier de log, vous trouverez toutes les informations sur le déroulement du script :
- Un en-tête résumant le contexte de lancement : heure, version de dbSqware, paramètres passés à la commande.
- Un récapitulatif des paramètres, y compris les implicites. Exemple :
Major version of NOM_DU_CLUSTER, 21, 2.1.13 Node: machine131 Datacenter: DC1 Cluster: PROD1 Summary of parameters : Exec = Enable Scope = LocalDC Dynamic = Enable NodeToolCommand = 'nodetool compact' AggressivenessRun = 1 AggressivenessCheckEnd = 5
- Ensuite vient la liste des machines découvertes dynamiquement:
Generate dynamic conf for NOM_DU_CLUSTER: gfsqw_SearchNodeInfos machine131 15/02/2017 21:00:18 gfsqw_SearchNodeInfos machine132 15/02/2017 21:00:19 gfsqw_SearchNodeInfos machine133 15/02/2017 21:00:20...
- Suivi du test de connexion, un par membre :
Node version, ... for machine131 15/02/2017 21:00:18 : key | cluster_name | data_center -------+--------------+------------- local | PROD1 | DC1 (1 rows) lvsqw_CasVersionMajTmp=ReleaseVersion: 2.1.13 END_TRT Code: 0 --> Connect on node machine131 PROD1 DC1 21 2.1.13 executed successfully.
- Et enfin, après un long moment (pour vous donner un point de référence, il y a une trentaine de machines dans ce cluster) :
Treatment Run 'nodetool compact' command on 'LocalDC' for NOM_DU_CLUSTER proceeded successfully Begining : 15/02/2017 21:00:01 End : 17/02/2017 04:51:02 Duration : 31:51:01 Insert end of script sqwcas_CentralisedNodetool.ksh for 'NOM_DU_CLUSTER' 17/02/2017 04:51:02
Si vous êtes pressés (et qui ne le serait pas ?), vous pouvez sauter directement à cette section pour voir en un coup d’œil si l’opération est un succès et combien de temps elle a duré.
Conclusion
Dans le monde Cassandra, il y a peu d’outils gratuits qui permettent un suivi des opérations de maintenance. Si vous utilisez déjà dbSqware, son module dédié à cette technologie peut vous rendre de grands services. Sachez également qu’une fois la rudesse du premier contact dépassé (c’est un produit complexe de part le nombre de technologies supportées, et qui permet de surcharger les comportements par défaut. L’image des matryoshka n’était qu’à moitié une plaisanterie ), tous les scripts suivent la même logique : une aide intégrée, contextualisée si possible, avec des logs regroupés derrière le même alias et suivant le même format. Logiquement, une personne normale (c’est à dire ni nous ni vous) trouvera l’essentiel des informations sur l’interface Web. Mais les Power-Users, les L33T-Rox0r, les érudits du clavier (c’est à dire, pour le coup, vous et nous) trouvent encore plus d’informations en étant directement sur les machines.
Et pour une fois, cet aspect de l’analyse a été pris en compte dans le produit. C’est plutôt rare : ne vous en privez pas !
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 : wikicommon, wikicommon ,
