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 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 (SPOF). L’application et les bases de données peuvent dépendre d’une solution de stockage qui n’est pas pérenne.

Là où c’est possible, des entreprises utilisent des infrastructures de stockage dédiées, qu’on appelle des SAN (Storage Area Network). Le livre Linux, Solutions de Haute Disponibilité présentait cette solution, avec le zoning, le masking, iSCSI (Internet Small Computer System Interface), le multipathing, etc. Mais tout le monde n’accède pas à un SAN, qui nécessite une infrastructure dédiée.

On peut aussi s’appuyer sur des services de stockage externes, dans le cloud par exemple. C’est une très bonne idée de placer des éléments ou des pages statiques sur du S3 par exemple, quitte à les placer derrière des proxies pour en masquer la présence au public.

Depuis le début de cet ouvrage, les moyens matériels mis en œuvre ne sont pas excessifs, on pourrait même dire qu’ils sont économiques. Alors, pourquoi ne pas continuer et proposer une solution facilement utilisable sur des serveurs peu puissants ou des machines virtuelles, mais avec...

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. 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.

Un RAID logiciel permet de créer des volumes même si le BIOS, l’UEFI ou la carte contrôleur ne le permettent...

1. Installation des packages

Les packages suivants doivent être installés :

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

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

# apt remove mutlipath-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 :

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 allow proto tcp from 192.168.56.11 to 192.168.56.10 port 2224 
# ufw allow proto tcp from 192.168.56.11 to 192.168.56.10 port 3121 
# ufw allow proto tcp from 192.168.56.11 to 192.168.56.10 port 7788 
# ufw allow proto tcp from 192.168.56.11 to 192.168.56.10...

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.

Créez deux projets XFS qui pourront être montés en NFS depuis un autre serveur. Les répertoires doivent être créés dans l’export racine NFS /nfsha/exports :

# 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.

Le fichier /etc/projects définit la liste des projets sous le format id:chemin. L’identifiant est numérique. Ajoutez les deux lignes qui correspondent aux projets :

# 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 

Sur le nœud primaire (qui dispose du point de montage), initialisez les quotas. 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 le rapport associé. Le projet...