Catégorie : Réseaux

Cette article est la traduction de https://galeracluster.com/library/documentation/arbitrator.html

Arbitre Galera

Lors du déploiement d’un cluster Galera, il est recommandé d’utiliser au moins trois instances: trois nœuds, trois centres de données, etc.

Si le coût de l’ajout de ressources (par exemple, un troisième centre de données) est trop élevé, vous pouvez utiliser Galera Arbitrator. Galera Arbitrator est membre d’un cluster qui participe au vote, mais pas à la réplication réelle.

avertissement

Bien que Galera Arbitrator ne participe pas à la réplication, il reçoit les mêmes données que tous les autres nœuds. Vous devez sécuriser sa connexion réseau.

L’arbitre Galera sert deux objectifs: lorsque vous avez un nombre pair de nœuds, il fonctionne comme un nœud impair, pour éviter les situations de split-brain. Il peut également demander un instantané cohérent de l’état de l’application, ce qui est utile pour effectuer des sauvegardes.

Un split-brain se produit lorsque deux parties d’un cluster d’ordinateurs sont déconnectées, chaque partie croyant que l’autre ne fonctionne plus. Le terme est une analogie médicale du syndrome split-brain.

Les clusters à haute disponibilité utilisent le réseau afin de surveiller l’état des nœuds le composant. Une des fonctionnalités les plus critiques qu’un logiciel de clustering doit pouvoir gérer est le split-brain. En effet, si le lien réseau entre les nœuds vient à tomber, mais que ces nœuds sont toujours en fonctionnement, ceux-ci vont croire que les autres nœuds ne fonctionnent plus et vont essayer de démarrer des services qui en réalité tournent toujours. Ceci peut occasionner des duplications de services, voire de la corruption de données dans certains cas. Les données peuvent ainsi se trouver dans un état incohérent.

Pour prévenir ce phénomène, les machines doivent utiliser des liens redondants, être équipées d’un mode gérant le split-brain et pouvoir se mettre en état d’auto-fencing – c’est-à-dire de pouvoir s’isoler par elle-même de la grappe – lorsque des nœuds semblent hors-ligne.

Arbitre Galera

Si un centre de données échoue ou perd sa connexion WAN , le nœud qui voit l’arbitre – et par extension voit les clients – continue de fonctionner.

Remarque

Même si Galera Arbitrator ne stocke pas de données, il doit voir tout le trafic de réplication. Le fait de placer Galera Arbitrator dans un emplacement avec une mauvaise connectivité réseau au reste du cluster peut entraîner de mauvaises performances du cluster.

En cas de défaillance de Galera Arbitrator, cela n’affectera pas le fonctionnement du cluster. Vous pouvez attacher une nouvelle instance au cluster à tout moment et plusieurs instances peuvent être exécutées dans le cluster.

Le but ici étant de faire du load balacing avec Haproxy, Apache et MySQL

Installation des serveurs Proxmox

La documentation Online est très bien faite : https://documentation.online.net/fr/dedicated-server/tutorials/administration/proxmox-first-step
Pour terminer l’installation, vous aurez besoin de plusieurs outils :Ajouter vim, sudo et openssh-server

apt-get install vim 
apt-get install sudo 
apt-get install openssh-server    

Vous aurez besoin de vous connecter en ssh avec votre utilisateur proxmox

 vim /etc/sudoers  

Puis jouter votre utilisateur sous

# User privilege specification 
root    ALL=(ALL:ALL) ALL  

Installation des serveurs

Récupérer votre iso ubuntu 18 server https://www.ubuntu.com/download/server dans /var/lib/vz/template/iso/ (défini dans stockage dans Datacenter)

Créer une nouvelle VM en sélectionnant votre Iso

Créer un RPN V2

Ajouter une carte sur chaque Proxmox

Paramétrer les cartes réseaux

 vim /etc/network/interfaces  

Les machines virtuelles devront être sur le même réseau que la carte vmbr1. Si vous choisissez un réseau en 10.0.0.x ens18 devra aussi être en 10.0.0.x

Préparer les connexions ssh

Générer une clé SSH

Avec OpenSSH, une clé SSH est créée à l’aide de ssh-keygen.
Dans la forme la plus simple, lancez ssh-keygen et répondez aux questions. L’exemple suivant illustre cela.

 ssh-keygen  

Génération d’une paire de clés rsa publique / privée. Entrez le fichier dans lequel enregistrer la clé (/home/ylo/.ssh/id_rsa): myid_rsa
Entrez la phrase secrète (vide pour aucune phrase secrète):
Entrez à nouveau le même mot de passe:
Votre identification a été sauvegardée dans ma clé.

Votre clé publique a été enregistrée dans mykey.pub.
L’empreinte digitale clé est: SHA256: xxxxx L’image randomart de la clé est: + — [RSA 2048] —- + xxxxxx + —- [SHA256] —– +

La création d’une paire de clés (clé publique et clé privée) ne prend qu’une minute. Les fichiers de clés sont généralement stockés dans le répertoire ~ / .ssh.
Copier la clé sur un serveur

Une fois qu’une clé SSH a été créée, la commande ssh-copy-id peut être utilisée pour l’installer en tant que clé autorisée sur le serveur.
Une fois que la clé a été autorisée pour SSH, elle autorise l’accès au serveur sans mot de passe.

Utilisez une commande comme celle ci-dessous pour copier la clé SSH

 
ssh-copy-id -i ~/ .ssh/myid_rsa $user$@$addressIP$     

Cela se connecte à l’hôte du serveur, copie les clés sur le serveur et les configure pour autoriser l’accès en les ajoutant au fichier allowed_keys.
La copie peut demander un mot de passe ou une autre authentification pour le serveur.

Seule la clé publique est copiée sur le serveur. La clé privée ne doit jamais être copiée sur une autre machine.