Mise en Haute-Disponibilité avec RSF-1 ZFS

Introduction

RSF-1 ZFS est disponible pour FreeBSD, Debian (et d'autres Linux), OmniOSce ...
Sa licence pour une utilisation domestique est de l'ordre de 200€, beaucoup plus pour du commercial.
Il ne fonctionne qu'avec 2 serveurs. Son but est de mettre en place une haute disponibilité avec réplication des données périodique.

But

Monter 2 serveurs (s1 et s2) en un cluster de stockage avec réplication des données automatique entre les serveurs à l'intervalle voulu.
Il faut également pouvoir gérer le nombre maximal de snapshots accumulés.

Nous allons :

Pré-requis

Préparation des serveurs

Installer les serveurs, faire les MAJ sur chacun.
Se loguer en root puis faire les MAJ : 

pkg ins -y ; pkg update

Repérer l'adresse IP de chaque serveur : 

ifconfig

Sur chaque noeud, y compris sur l'ordinateur hôte pour faciliter la gestion (notamment si les noeuds sont des VMs), ajouter les correspondances nom-IP dans le fichier /etc/hosts : 

192.168.0.47 s1
192.168.0.48 s2

Préparation des connexions SSH entre serveurs par clef

Sur s1 et s2 : dans le fichier /etc/ssh/sshd_config, autoriser la connexion au compte root comme ceci : 

PermitRootLogin yes

Relancer ssh : 

service sshd restart

Sur s1, créer la paire de clefs SSH en étant root

Se loguer en tant que root puis : 

ssh-keygen -t ed25519

(ne pas créer de passphrase !!)

Envoyer la clef publique à l'autre serveur (exemple ici depuis s1) : 

ssh-copy-id -i /root/.ssh/id_ed25519.pub root@s2

Initier une première connexion de test depuis s1 vers s2 

ssh root@s2
exit

Refaire la manip depuis s2 (et envoyer la publique à s1)

Installer RSF-1 ZFS sur chaque serveur

Télécharger le soft sur chaque serveur directement : 

fetch https://packages2.high-availability.com/offline-packages/rsf-1-offline-latest-freebsd140.pkg -o /tmp

Installer le logiciel : 

pkg install -y /tmp/rsf-1-offline-latest-freebsd140.pkg

Redémarrer le serveur (impératif) : 

reboot

Configuration de RSF-1 depuis la console web

Depuis un ordinateur client (ou depuis votre hôte), se connecter à l'interface web de s1 

https://s1:8330

Créer l'utilisateur administrateur :

(Il n'y a pas besoin de faire cette manip (créer cet utilisateur administrateur de la console web RSF) sur le noeud s2. Lorsque le cluster des 2 noeuds sera créé depuis la console web RSF de s1, l'utilisateur administrateur deviendra automatiquement celui de s2 aussi.)

Création du cluster

Une fois authentifié sur la console web de RSF sur s1, cliquer sur Create/Destroy cluster

Activer les heartbeats encryptés

Il est fondamental d'effectuer cette opération AVANT la mise en ligne d'un service de clustering !! Galère assurée autrement.

Aller dans le menu 'Settings', 'General', 'Encrypted Heartbeats' sur 'on'. Sauvegardez le changement puis retourner dans le Dashboard pour démarrer le service.

Création des pools ZFS

Une fois le cluster créé, il nous faut créer le service de stockage.
Nous allons donc créer les pools sur s1 et s2, composés de nos 2 supports de stockage sur chaque serveur prévus à cet effet.

Note importante sur l'encryption

RSF ne permet pas, à ce jour, la création de pools et de datasets encryptés. C'est une énorme lacune du logiciel à mon sens !! (même si son objectif premier, rappelons-le, c'est la Haute Disponibilité.. pas la création des pool et datasets)

Les besoins en sécurité de ce type aujourd'hui sont fondamentaux, et cela m'a beaucoup interrogé lorsque j'ai testé ce logiciel. Il faut implémenter cette solution ! Impérativement.

Il est néanmoins tout à fait possible de réaliser les 2 étapes suivantes (création du pool et des datasets) directement en ligne de commande sur chaque serveur afin de créer ces pools encryptés puis de mettre en cluster le pool créé, c'est même la meilleure option.

Néanmoins, c'est toujours la même consigne : même nom de pool, et mêmes noms pour les datasets sur chaque serveur. Les caractéristiques doivent être rigoureusement identiques !!

Il faudra néanmoins bien réfléchir aux conséquences de l'encryption du pool et/ou des datasets lors d'un crash. Je n'ai pas pu tester cette caractéristique avec RSF, mais il est connu que les pool et datasets ZFS encryptés posent des problèmes plus particuliers lors des send/receive !
Je ferai d'ailleurs un article à ce sujet car ça n'a rien d'évident.

Création du pool sur s1

Toujours depuis la console web RSF de s1, Aller dans le menu ZFS, +Create.

Création du pool sur s2

Il faut à présent créer le second pool ZFS 'SFTP' (sur s2).
Se connecter à la console web RSF de s2, et faire la même manip pour créer le pool.

Attention, le nom du pool doit être IDENTIQUE (SFTP ici), le mode de pool (mirror) aussi, le type (DATA) aussi.

Une fois ce second pool créé, le pool SFTP devient soudainement 'CLUSTERABLE' en bleu. (depuis la console web RSF de s1, rafraîchissez la page web pour la console de s1 et la ligne qui était rouge devient bleue !)

(Vous pouvez fermer la console de s2, on en a plus besoin. On va faire le reste sur la console de s1)

Mise en cluster du pool ZFS 'SFTP'

Sur la console web RSF de s1, aller dans le menu 'Volumes' puis cliquer sur Actions (notre pool SFTP apparaît en bleu), 'Cluster this pool'.

Choisir le noeud préféré (s1), si vous ajoutez une VIP, attention à ne pas la nommer avec des majuscules !!! Elle ne fonctionnera pas autrement et vous allez tout faire foirer !!!! Donnez-lui un nom en minuscule et plutôt court.

Une fois créé, le pool ZFS 'SFTP' va démarrer sur chaque noeud puis afficher 'Running on s1'.

Création des datasets sur le cluster de pools

Aller dans le menu ZFS, Datasets, Cliquer sur 'CREATE DATASET'

Remplissez les champs. (Par exemple, vous pourriez dédier un dataset à un utilisateur et donc le nommer comme le nom de l'utilisateur...). Prenons USER1 par exemple

Configuration des intervalles de snapshots

Par défaut, elle est fixée à 15min pour le noeud actif. C'est souvent suffisant, inutile de le descendre d'avantage. Pour changer ce réglage, aller dans 'Settings', 'Shared Nothing'.

Vous pouvez également régler le nombre de snapshots à conserver (ce qui peut être pratique si vous avez besoin de restaurer à une date précise).

Attention aux pare-feux !

Ouvrir les ports :

Comment faire pour updater dynamiquement le nom de domaine si l'un des serveurs tombe ?

Plusieurs solutions :

... ce sont les solutions pas chères ça ! Mais ça fonctionne.
Sinon, il y a la grosse artillerie avec AWS & co !

↑ Haut de page