Configurer Cassandra en cluster

La force de cette base de donnée, c’est d’être taillée pour encaisser une énorme quantité de requêtes en s’équilibrant entre de nombreux noeuds. Quelques points de configuration sont à comprendre pour ajouter un node à un cluster.

Publié le

Le ring

C’est l’ensemble des nodes qui stockent et gèrent les keyspaces.

Les nodes se répartissent les clés des keyspaces entre eux, de façon automatique (et équilibré entre les nodes par défaut) : c’est le partitioner. Celui qui est actif par défaut est le Murmur3 qui utilise des algorithmes de hachage du nom des clés pour assurer une répartition pseudo aléatoire, mais organisée et rapide.

Autrement dit, un ring c’est genre de RAID0 qui étale les données entre tous les nodes qui le composent. Toute la mathématique qui le compose est configurable, et est détaillée dans la documentation.

Les datacentres

Si vous voulez que votre ring soit dupliqué entre plusieurs ensembles d’instances de Cassandra, il faudra les organiser en datacentres – DC.

C’est un genre de RAID1 entre les nodes. L’ensemble de tous les nodes essayera de dupliquer toutes les données envoyés sur tous les datacenter.

On peut bien évidement jouer avec les configurations de ring et de DC. D’ailleurs, il existe une notion de rack, comme un sous datacenter.

Les commandes nodetool status et nodetool ring informent de la topologie du cluster.

Les stratégies

L’intelligence qui gère le stockage d’un keyspace s’appelle une stratégie (strategy). Il y a deux types de strategies qui sont possible dans un keyspace : le SimpleStrategy et le NetworkTopologyStrategy. Le SimpleStrategy assure un stockage au mieux dans un ring, et le NetworkTopologyStrategy garanti le stockage des clés a travers plusieurs datacentres de façon homogène entre les racks.

Le replication_factor est le paramètre de configuration d’une stratégie. Il indique le nombre de copie de chaque clé dans le cas d’un SimpleStrategy et le  nombre de copie de chaque clé pour chaque datacenter pour le  NetworkTopologyStrategy.

C’est le client Cassandra, au moment de la création du keyspace, qui doit définir sa stratégie. Elle peut être changée avec le client Cassandra CLI :

cassandra-cli -h unserveurcassandraducluster
update keyspace MonKeySpace with strategy_options = {replication_factor:3};

Ici on souhaite 3 copies.

Configuration

Cassandra est capable de trouver d’autres noeuds autour de lui (via un broadcast IP et un autodiscover) avec les options de snitch.

Pour l’exemple qui sera pris, on choisi d’avoir deux serveurs en miroir pour avoir une tolérance à la panne. Tous les clients Thrifs pour Cassandra gèrent très bien ces notions de partitioner et de multiples instances. Certains sont capables de trouver tout seuls des nodes Cassandra.

A faire pour les deux nodes

Dans cassandra-rackdc.properties, on défini le nom du DC, et le nom du rack. Dans ce cas de figure, le nom du rack n’a pas d’importance. Le nom du DC doit être différent pour chaque node (pour notre exemple) :

dc=DC1
rack=RAC1

Dans cassandra.yaml, on active le endpoint_snitch qui nous permet d’utiliser le fichier cassandra-rackdc.properties :

endpoint_snitch: GossipingPropertyFileSnitch

Puis on liste les nodes cassandra à contacter. Pour une grosse installation (dans le cas ou il est impossible de garder a jour ce genre de liste… il faut lire la doc). Toujours dans le fichier cassandra.yaml :

seed_provider:
[...]
- seeds: "ipmoi,ipserveur2,..."

Attention ipmoi doit être l’ip du serveur que vous paramétrez, et cette IP doit être la même que celle qui est indiquée dans listen_address. Evidement, tous les serveurs doivent pouvoir être contractés entre eux et par les clients.

Vous pouvez parfaitement mettre deux instances de Cassandra sur le même serveur. Avec les ip 127.0.0.1 et 127.0.0.2 par exemple si vous avez une installation mono serveur. Par contre les configurations doivent bien être différentes.

Relancez les deux serveurs. Un message tel que « Handshaking version with /ipautreserveur«  doit apparaitre dans les logs des deux serveurs.

Sur un des deux serveur, activez le clone des données sur les deux nodes avec un replication_factor de 2 (on est en SimpleStrategy) :

cassandra-cli -h ipmoi
update keyspace MonKeySpace with strategy_options = {replication_factor:2};

La commande nodetool ring doit vous afficher la configuration active :

Datacenter: DC1
==========
Address       Rack        Status State   Load            Owns                Token     
ipserveur1  RAC1        Up     Normal  60,16 KB        100%              -6972691373456915396

Datacenter: DC2
==========
Address       Rack        Status State   Load            Owns                Token
ipserveur2  RAC2        Up     Normal  60,15 KB        100%              7056292121392065869

Si un node est trop longtemps hors ligne l’autre prendra le relai de façon transparente. Quand il reviendra en ligne, il se peut qu’il décide de se re-synchroniser en totalité par rapport à l’autre noeud. C’est configurable par ColumnFamily (notamment la valeur de gc grace period). Si la pause est suffisamment courte, il se mettra juste à jour par rapport à l’autre. C’est bon à savoir si vous avez des To de données dans vos nodes.

Après, les synchronisations sont faites au fil de l’eau, et sont bien évidement très rapides.

C’est toujours une bonne idée d’avoir au moins deux nodes, même petits, dans une installation Cassandra. Et c’est l’idéal en virtualisation.

Pour aller plus loin : Cassandra Wiki – Operations

Mise à jour du 29/01/2014

  • Ajout de précisions sur les stratégies.