Stockage en haute disponibilité

1. Problématique

Jusqu’à présent, lorsque le stockage était abordé, il s’agissait soit de volumes locaux, soit de montages, avec une note sur l’utilisation possible d’un partage réseau NFS pour partager des données entre les applications.

Depuis le début, un problème n’a pas été résolu : on sait comment rendre des serveurs, des adresses IP, des services résistants aux pannes, mais pour le stockage, nous nous sommes essentiellement appuyés sur des expédients qui n’ont fait que retarder l’arrivée d’un futur problème. Un partage NFS ? Certes, mais qui partage ? Un seul serveur ? Dans ce cas, le stockage est perdu (au moins temporairement) en cas de panne. Un NAS ? Si oui et si les disques sont en RAID, alors c’est déjà mieux, mais que se passe-t-il si le NAS est débranché ? Sommes-nous sûrs que le partage qui vous est proposé est bien redondant ?

Il y a donc ici un risque de point de défaillance unique (Single Point of Failure, SPOF). L’application et les bases de données peuvent dépendre d’une solution de stockage dont la disponibilité et la redondance ne peuvent être garanties.

Lorsque cela est possible, des entreprises utilisent des infrastructures de stockage dédiées, qu’on appelle des SAN (Storage Area Network). Mais tout le monde n’accède pas à un SAN, qui nécessite une infrastructure dédiée.

Les NAS, Network-Attached Storage, sont une solution présentant des volumes de données à un client via le réseau, en utilisant un protocole supporté par le système d’exploitation. Il s’agit généralement des protocoles NFS (Network File System) pour Unix, et CIFS (Common Internet File System, un dialecte de SMB) pour Windows. Ils peuvent parfois aussi proposer d’autres protocoles comme iSCSI. Des solution NAS redondées existent, comme celles proposées par la société NetApp, mais elles sont coûteuses. Ceci ne rentre pas dans le cadre de ce livre.

On peut aussi s’appuyer sur des services de stockage externes, dans le cloud par exemple. C’est une très bonne...

1. Principe

Le cluster permet la disponibilité des données en cas de perte, de panne ou de maintenance d’un des nœuds, mais il faut aussi penser à la disponibilité du stockage sur le nœud lui-même : que se passe-t-il si un disque physique tombe en panne ? Des solutions existent, tant matérielles que logicielles, exploitant une forme de virtualisation du stockage afin d’augmenter la fiabilité du stockage des données : le RAID (Redundant Array of Independent Disks, regroupement redondant de disques indépendants ; à l’origine, la lettre I signifiait Inexpensive, mais le coût du stockage ayant fortement baissé, le mot a été modifié). 

Le RAID permet d’agréger plusieurs disques physiques en un seul disque logique, en améliorant la fiabilité et la disponibilité globale, et parfois en augmentant les performances. Il existe plusieurs algorithmes et plusieurs gestions possibles. Le RAID peut être logiciel, matériel (avec une carte contrôleur dédiée) ou un mélange des deux, comme certaines fonctionnalités proposées par quelques BIOS et UEFI.

2. RAID matériel vs RAID logiciel

Le choix entre RAID matériel ou logiciel est souvent assez simple, notamment en entreprise. Les serveurs de type lame intègrent souvent des baies disques en façade raccordées à des contrôleurs SCSI ou SATA spécifiques très performants, mais aussi très chers, intégrant un processeur puissant, de la mémoire cache et même une petite batterie chargée d’assurer les transactions et l’alimentation des disques le temps de finaliser les écritures en cas de coupure de courant. Elles permettent aussi le hot swap, c’est-à-dire le remplacement à chaud des disques en cas de défaillance. C’est le cas par exemple des cartes HP Smart Array sur des serveurs HP Proliant. Du côté de Linux, le volume RAID est vu comme un unique périphérique /dev/sdX de type bloc. Un module et des commandes en espace utilisateur permettent de gérer les disques et les volumes RAID. Une carte RAID de qualité est coûteuse, sans compter les disques nécessaires, d’une...

1. Installation des packages

Les packages suivants doivent être installés, 420 packages en tout pourront être installés, occupant 1 Go d’espace supplémentaire :

# apt install net-tools corosync pacemaker resource-agents  
resource-agents-extra fence-agents crmsh pcs haveged drbd-utils 
nfs-kernel-server xfsprogs xfsdump units lsscsi 

Un problème a été rencontré avec multipath lors du paramétrage du cluster, aussi vous pouvez le désinstaller :

# apt remove multipath-tools 

Ou alors modifier sa configuration en conséquence dans /etc/multipath.conf :

blacklist { 
    devnode "^sd[a-z]" 
    devnode "^drbd[0-9]" 
} 

2. Configuration du réseau

Bien que l’on puisse s’appuyer sur le DNS, il est préférable de modifier le fichier /etc/hosts et d’y ajouter les entrées pour les deux nœuds. Profitez-en pour supprimer les éventuelles entrées 127.0.1.1 présentes :

192.168.56.10 nfsha01 
192.168.56.11 nfsha02 

Les composants nécessitent l’ouverture de plusieurs ports entre les deux membres du cluster pour fonctionner.

Ports à ouvrir :

Sur nfsha01 :

# ufw enable  
# ufw allow proto tcp from...

1. Ajout manuel

Maintenant que le cluster est en place, il faut créer des partages avec quotas. Sous XFS, les quotas se présentent sous plusieurs formes : celles, classiques, correspondant aux utilisateurs et groupes, et une autre, appelée quotas de projets. Un projet est tout simplement un répertoire. Vous pouvez donc limiter la quantité de données au sein d’un répertoire.

Voici comment faire avec deux répertoires. Les fichiers de configuration doivent être présents et identiques sur les deux nœuds. Par contre, les répertoires à créer et les commandes XFS à exécuter le sont forcément sur le nœud actif du cluster, là où est monté le système de fichiers XFS.

# mkdir -p /nfsha/exports/vol{1,2} 

Vous pouvez déjà monter ces deux répertoires depuis un autre serveur, mais la taille que vous verrez sera celle de la racine, et donc celle du système de fichiers complet. Il faut ajouter les quotas.

# cat /etc/projects 
1:/ nfsha/exports/vol1 
2:/ nfsha/exports/vol2 

Le fichier /etc/projid associe un label à l’identifiant de projet :

# cat /etc/projid 
vol1:1 
vol2:2 

Les informations de quotas sont sur le point de montage lui-même, elles basculeront avec le système de fichiers. Les quotas se gèrent avec la commande xfs_quota.

# xfs_quota -x -c 'project -s vol1' /nfsha 
Setting up project vol1 (path /nfsha/exports/vol1)... 
Processed 1 (/etc/projects and cmdline) paths for project vol1  
with recursion depth infinite (-1). 
# xfs_quota -x -c 'project -s vol2' /nfsha 
Setting up project vol2 (path /nfsha/exports/vol2)... 
Processed 1 (/etc/projects and cmdline) paths for project vol2  
with recursion depth infinite (-1). 

Voici...