• Call us: 1(704) - 858 - 0065
  • Email us: dmngaya@dmnbigdata.com
  • Working Hours: 8am - 6pm

Mise hors service d’un ancien noeud Cassandra et intégration d’un nouveau dans un Datacenter existant

Mise hors service de l’ancien noeud Cassandra

J’ai récemment entrepris la tâche passionnante de mettre hors service un ancien noeud, puis de rejoindre un nouveau noeud Cassandra dans un datacenter existant. Bien que la documentation sur le Web soit assez bonne pour cela, je pensais que cela valait la peine de poster un article sur quelques points techniques et sur les questions «à quoi s’attendre» que j’avais avant de commencer le processus. Nous utilisons DataStax enterprise 4.8.8 avec Cassandra 2.1. Les étapes de base pour la mise hors service d’un nœud d’un datacenter sont décrites dans la documentation de Cassandra 2.1.
Notre cas était de mettre hors service un nœud puis d’ajouter un nouveau en production sans effectuer les étapes de base suivantes:

  1. Désactivez tous les clients écrivant dans le Datacenter (n’oubliez pas les agents Datastax)
  2. Effectuez l’opération Repair pour vous assurer que vos données sont répliquées
  3. Modifier tous les keyspaces afin qu’ils ne référencent pas le Datacenter

mais nous n’avons fait que:

  • Exécutez la commande nodetool pour la mise hors service sur chaque nœud un par un, puis une fois l’opération terminée, nous avons ajouté un nœud.

Les étapes de base pour joindre un nœud dans un Datacenter sont décrites dans la documentation Cassandra 2.1.

À noter. Le processus de mise hors service n’a pas été assez rapide car nous l’avons fait dans un environnement de production sans arrêter tous les clients, le service Opscenter Repair était en cours d’exécution et planifié sous opscenter 5.2.4 et les keyspaces n’avaient pas été modifiés. Sur la base de la documentation de mise hors service, le nœud «transmettra ses données en continu au nœud suivant sur ring Cassandra». En pratique, il y avait beaucoup de données à diffuser, car nous n’avions pas effectué l’étape 3 et des keyspaces avaient déjà été attribués à ce Datacenter. La commande pour la mise hors service a pris environ 2 heures à exécuter et à joindre 40 minutes pour moi.

Une chose à noter est que la mise hors service crée une charge considérable sur les autres Datacenter du cluster, car nous en avons quatre. Il n’était pas suffisant de modifier sensiblement les temps de réponse en lecture / écriture, mais c’était suffisant pour que je ne fasse pas un tas de nœuds en même temps. Je les ai mis en boucle avec une pause de 10 minutes entre la mise hors service d’un ancien noeud et joindre un nouveau noeud à l’aide du token ring de l’ancien noeud, puis une pause de 30 minutes entre l’ajout d’un nouveau noeud et la mise hors service de l’ancien noeud. Bien sûr, le script prend environ 3,5 heures, mais la sécurité avant tout en production.

Enfin, une petite information intéressante, si vous voulez voir ce que vous aviez fait, vous pouvez le vérifier en utilisant la commande nodetool gossipinfo. Elle montrera tous vos noeuds supprimés et également la différence dans quelle méthode ils ont été supprimés.

Nous avons également utilisé la commande nodetool netstats pour vérifier le nombre de fichiers en cours de mise hors service en transit sur d’autres nœuds.

Ci-dessous le script shell que j’ai utilisé:

#!/bin/bash
NODETOOL=/usr/bin/nodetool for i in 10.252.72.46,10.252.72.134 10.252.72.49,10.252.72.138 10.252.72.47,10.252.72.142 do oldnode=$(echo $i|cut -d',' -f1) newnode=$(echo $i|cut -d',' -f2) echo "Decommissioning node "$oldnode" from the datacenter CDC at `date +%Y.%m.%d-%H.%M.%S`" ssh -t $oldnode $NODETOOL decommission while [ true ];do echo "Checking to see if $oldnode has finished decommissionning yet at `date +%Y.%m.%d-%H.%M.%S`" STATUS=$(ssh -t $oldnode $NODETOOL status|grep ^"$oldnode" |awk '{print $1}') # break the loop when we achieve UN status, the extra
# x char is there so the conditional # won't fail if $STATUS is null if [ "x${STATUS}" = "x" ];then # wait 10 mins between decommissionning old node and
# joinning a new node sleep 600 echo "joining new node "$newnode" to the datacenter CDC at `date +%Y.%m.%d-%H.%M.%S`" ssh -t $newnode sudo service dse start ssh -t $newnode sudo service datastax-agent start # sleeping for 5 mins because the command above
# returns before the server is #actually started! if we get some grep usage errors # after this 5 minute period, it's not a big deal, it
# just means we entered the # while loop prematurely. it will work itself out. sleep 300 ssh -t $newnode sudo service datastax-agent start while [ true ];do echo "Checking to see if $newnode has finished joining yet" STATUS1=$(ssh -t $newnode $NODETOOL status|grep "$newnode"|awk '{print $1}') # break the loop when we achieve UN status,
# the extra x char is there so the # conditional won't fail if $STATUS1 is null if [ "x${STATUS1}" = "xUN" ]; then break fi echo "Still joining $newnode, sleeping for next 60 seconds" sleep 60 done break fi echo "Still decommissionning $oldnode, sleeping for next 60 seconds" sleep 60 # break done echo "End of decommissionning $oldnode and joining $newnode to the datacenter CDC at `date +%Y.%m.%d-%H.%M.%S`" ssh -t $oldnode sudo service dse stop ssh -t $newnode sudo service datastax-agent stop # kill switch for this process, just touch
# /tmp/stop-migration to stop # this process gracefully if [ -f /tmp/stop-migration ];then echo "/tmp/stop-migration found, stopping migration" exit 0 fi # wait 30 mins between decommissionning nodes echo "sleeping 30 mins before decommissionning next old node" sleep 1800 done

et voilà, vous avez fini de tout faire !

Laisser un commentaire

Fermer le menu
×
×

Panier