Cassandra – Configurer un cluster à 5 nœuds et stockage SAN

Dans cet article sera discutée la création d’un cluster Cassandra complet. La répartition de charge (load-balancing) permettant la connexion indifféremment à n’importe quel nœud de cluster, ainsi que la haute-disponibilité (high-availibility) seront abordés dans un article ultérieur.

Il est considéré que les bases de manipulation d’un shell comme bash ou ksh sont acquises, ainsi que les bases de fonctionnement du système d’exploitation Linux (UNIX-like).

Pré-requis

Stockage SAN

Le stockage SAN doit avoir été configuré pour accueillir les fichiers de bases de données de chacun des nœuds. L’article « Linux – Connecter un serveur SAN (iSCSI) » donne les explications nécessaires à la réalisation de cette étape. Dans l’ensemble de cet article, l’arborescence /data présente sur chaque serveur est une LUN de stockage iSCSI.

Configuration réseau

Nous considérons un système installé sur un hardware ou dans une machine virtuelle disposant d’au moins 3 cartes réseau connectées chacune à un réseau isolé des autres :

1. Carte dédiée au SAN
2. Carte dédiée à la communication entre les nœuds de cluster
3. Carte dédiée à la communication client/serveur

Ainsi, chaque flux spécifique n’interfère pas avec les autres, évitant les goulets d’étranglement réseau.

Exemple de configuration sur le nœud 1 de cette configuration :

Le réseau 192.168.56.xxx sert à l’interconnexion entre les nœuds du cluster Cassandra.

Le réseau 192.168.1.xxx sert aux connexions des clients.

Le réseau 10.0.0.xxx quant à lui sert à la connexion avec le SAN. Il s’agit du réseau dédié au stockage. Dans une configuration d’entreprise, il y aurait en réalité au moins deux cartes rapides ( >= 10 Gb/s ) à très faible latence en redondance d’accès au SAN.

Chacun des cinq serveurs est configuré de la même manière.

La classe d’adresse qui va le plus nous intéresser dans le cadre de cet article est la 192.168.56.xxx qui va permettre la communication entre les nœuds (membres) du cluster.

Configuration firewall

Le sujet est très vaste. Il est important que le réseau de communication entre les nœuds de cluster soit isolé des autres réseaux et sans accès possible vers l’extérieur. Cassandra nécessite l’ouverture de plusieurs ports de communication entre les serveurs.

Les ports à ouvrir à minima en UDP et TCP sont les suivants :

1. 7000
2. 7001
3. 7199
4. 9042
5. 9160

Installation et configuration de Cassandra

Création d’un utilisateur dédié

Créer un groupe « cassandra » et un utilisateur « cassandra » sur chaque serveur.

Cet utilisateur peut faire partie du groupe « wheel » pour permettre « su » et d’autre part peut aussi être déclaré « sudoer » afin de faciliter les tâches d’installation et configuration.

IMPORTANT ! Une fois la configuration faite, supprimer l’utilisateur « cassandra » tant du groupe « wheel » que des « sudoer » pour des raisons évidentes de sécurité.

Echange de clés publiques/privées entre tous les utilisateurs « cassandra »

Comme le travail se fait sur un cluster, il est vivement conseillé de générer une clé SSL et la partager entre tous les utilisateurs « cassandra » du cluster afin de faciliter les tâches d’installation et configuration.

Installation de Cassandra

Les sources sont disponibles sur le site de l’Apache Foundation en version 3.9 à date du 26 octobre 2016.

L’installation sur Linux se fait en décompressant le fichier tar.gz. Placer l’arborescence décompressée dans /usr/local et en créant un lien symbolique afin de s’affranchir par la suite des modifications liées aux futurs changements de version et assigner le répertoire ainsi que tout son contenu à « cassandra:cassandra » :

Création des répertoires nécessaires à Cassandra

Cassandra nécessite au moins la création de 3 répertoires pour le stockage de la base de données, des journaux de transaction et des hints.

Créer ces trois répertoires à l’endroit de stockage désiré, le même pour chaque nœud de cluster de préférence :

Ma configuration considère l’arborescence suivante :

1. /data/cassandra/data, pour les données
2. /data/cassandra/commitlog pour les journaux de transactions
3. /data/cassandra/hints pour les hints

Les répertoires doivent être accessibles à l’utilisateur cassandra et au groupe cassandra tant en parcours, lecture et écriture (rwx) :

Configuration de Cassandra

cassandra.yaml

Afin de définir le cluster, il est nécessaire dans un premier temps de configurer le premier nœud du cluster.

Le fichier de configuration se trouve dans le répertoire conf de l’installation et se nomme cassandra.yaml

Plusieurs paramètres doivent être définis afin de permettre la constitution du futur cluster :

1. hints_directory : Répertoire dont la fonction est d’accueillir toutes les opérations à rejouer sur un (ou plusieurs) nœud(s) de cluster perdu(s) lors de son (leur) retour dans le cluster
2. data_file_directories : Liste de répertoires où sont stockés les objets de la base de données
3. commitlog_directory : Répertoire contenant les journaux de logs (« transactions », qui ne sont pas tout à fait des transactions au sens SGBDR mais y ressemblent beaucoup)
4. seeds dans la rubrique seed_provider : Nœuds de cluster contenant les informations d’architecture du cluster, à savoir quels nœuds participent au cluster
5. listen_address : Adresse d’écoute du nœud, entre autres adresse de communication entre nœuds
6. auto_bootstrap : Paramètre nécessaire une seule fois à l’initialisation du cluster. Il doit être mis à « false » sur le nœud 1 uniquement au premier démarrage et doit ensuite être supprimé
7. start_rpc : Permet la connexion de clients au serveur
8. rpc_address : Adresse permettant la connexion d’un client au serveur
9. endpoint_snitch : Mode de fonctionnement du cluster

Les paramètres du cluster sont les suivants pour tous les nœuds :

Les paramètres du cluster spécifiques par nœud sont les suivants :

cassandra-rackdc.properties

Ce fichier présent aussi dans le répertoire conf comporte deux paramètres. Il doit être configuré strictement de la même manière pour chaque nœud participant au cluster :

1.  dc : Nom du datacenter
2. rack : Nom du rack dans le datacenter

A cette occasion on voit que Cassandra propose une gestion centralisée des racks (clusters) au sein de datacenters.

Les paramètres de base peuvent être configurés ainsi (configuration par défaut proposée par Apache Foundation) :

1. dc=dc1
2. rack=rack1

Initialisation du cluster à partir du nœud 1

En tant qu’utilisateur cassandra sur le nœud 1, exécuter cassandra (présent dans /usr/local/cassandra/bin)

Se connecter au serveur pour vérifier qu’il est bien en fonction :

[cassandra@cassandra01 conf]$ cqlsh 192.168.1.101
Connected to CassandraRAC at 192.168.1.101:9042.
[cqlsh 5.0.1 | Cassandra 3.9 | CQL spec 3.4.2 | Native protocol v4]
Use HELP for help.
cqlsh> exit

Arrêter le serveur en repérant le numéro de son process et en procédant à un kill de celui-ci.

Constitution du cluster

Constituer le cluster est très simple une fois tout correctement configuré.

Il suffit sur chaque nœud de lancer cassandra en tant qu’utilisateur cassandra, dans l’ordre numérique des nœuds, avec le lancement en priorité des nœuds déclarés seed. Dans ma configuration ce sont les nœuds 1 et 2 qui sont les seeds, ce qui fait que le démarrage des nœuds dans l’ordre 1 à 5 suffit à constituer le cluster.

Vérification du fonctionnement nominal du cluster

L’instruction nodetool status permet de voir si le cluster est en fonctionnement nominal (Cette image montre 6 nœuds, entretemps j’ai testé l’intégration d’un nœud supplémentaire. Sujet abordé plus loin) :

Intégration de production

Il faut ensuite prévoir un démarrage de Cassandra au niveau de systemd et éventuellement créer des scripts de démarrage et d’arrêt du cluster pour maintenance. Ceci dépasse le cadre de cet article

Ajout d’un nœud au cluster

Le cluster étant en fonctionnement nominal, il est tout à fait possible d’ajouter à la volée un nœud supplémentaire au cluster.

Les étapes sont les suivantes :

1. Créer un serveur Linux configuré strictement comme les autres nœuds du cluster avec ses nouvelles IP
2. Configurer une nouvelle LUN de stockage
3. Déployer les binaires de Cassandra
4. Configurer cassandra.yaml en fonction des IP disponibles sur le serveur (chez moi, finissant en 106), donc touchant uniquement les paramètres listen_address et rpc_address
5. Démarrer Cassandra

A ce point, le cluster dispose d’un nœud supplémentaire qui a au final été ajouté dynamiquement.