Table of Contents
Introduction
Monter un même disque iSCSI sur plusieurs serveurs peut entraîner des risques de corruption des données si les systèmes de fichiers et les configurations adéquates ne sont pas utilisés. Cet article détaille un cas spécifique où deux serveurs ont monté le même disque iSCSI, entraînant des problèmes de corruption du système de fichiers XFS. Nous examinerons les étapes d’analyse et de résolution du problème, puis proposerons des solutions pour éviter de telles situations à l’avenir.
Problème
L’utilisation simultanée d’un disque iSCSI partagé par plusieurs serveurs sans un système de fichiers en cluster peut entraîner une corruption des données. Dans notre cas, deux serveurs montaient le même volume iSCSI, ce qui a causé des problèmes avec le journal du système de fichiers XFS, rendant nécessaires des interventions pour réparer le système de fichiers corrompu.
Analyse du Problème
- Identification du Volume : Utiliser
lsblk
pour identifier les volumes montés sur les serveurs.lsblk
- Vérification du Type de Système de Fichiers : Utiliser
blkid
pour confirmer le type de système de fichiers sur la partition problématique.sudo blkid /dev/mapper/ARCH-MOUNT1
Étapes de Résolution
- Montage en Lecture Seule : Monter le système de fichiers en lecture seule pour rejouer le journal sans modifier les données.
sudo mount -o ro /dev/mapper/ARCH-MOUNT1 /mnt/data
- Utilisation de
xfs_logprint
: Vérifier l’état du journal avecxfs_logprint
.sudo xfs_logprint -t /dev/mapper/ARCH-MOUNT1
- Démonter et Réparer : Si le journal est propre, démonter et exécuter
xfs_repair
.sudo umount /mnt/data sudo xfs_repair /dev/mapper/ARCH-MOUNT1
- Forcer la Réparation en dernier recours : utiliser
xfs_repair -L
pour forcer la suppression du journal et réparer le système de fichiers. Attention : cette opération peut entraîner une perte de données !sudo xfs_repair -L /dev/mapper/ARCH-MOUNT1
Bonus : Réparation Générale des Systèmes de Fichiers avec fsck
et touch /forcefsck
Forcer une Vérification de Système de Fichiers au Démarrage
Vous pouvez utiliser touch /forcefsck
pour forcer une vérification du système de fichiers au prochain démarrage du système. Cette méthode est généralement utilisée pour les systèmes de fichiers ext4, mais peut être utile pour vérifier l’intégrité de la table des partitions et d’autres métadonnées.
Créer un fichier pour forcer fsck au démarrage :sudo touch /forcefsck
sudo reboot
Utilisation de fsck
Manuellement
fsck
est utilisé pour vérifier et réparer les systèmes de fichiers. Bien que fsck
ne soit pas directement compatible avec XFS, il peut être utilisé pour vérifier d’autres types de systèmes de fichiers ou la table de partitions.
Vérification et réparation manuelles avec fsck
:sudo fsck /dev/mapper/ARCH-MOUNT1
Prévention et Solutions Améliorées
- Utilisation de Systèmes de Fichiers en Cluster : Pour éviter la corruption des données, utilisez des systèmes de fichiers en cluster comme GFS2 ou OCFS2, conçus pour gérer les accès concurrents.
sudo mkfs.gfs2 -p lock_dlm -t mycluster:mygfs2 -j 2 /dev/mapper/ARCH-MOUNT
sudo mount -t gfs2 /dev/mapper/ARCH-MOUNT /mnt/data
- Partage via NFS ou CIFS : Montez le volume iSCSI sur un seul serveur et partagez-le via NFS ou CIFS pour permettre un accès depuis plusieurs serveurs sans risquer de corruption.
- Utilisation de CLVM : Utilisez le gestionnaire de volumes logiques en cluster (CLVM) pour coordonner l’accès aux volumes logiques entre plusieurs nœuds.
- Configuration de Haute Disponibilité : Pour des environnements critiques, configurez une solution de haute disponibilité avec réplicas pour éviter un point de défaillance unique.
Conclusion
Monter un même disque iSCSI sur plusieurs serveurs sans une infrastructure appropriée peut entraîner des corruptions de données sévères. En suivant les bonnes pratiques et en utilisant les systèmes de fichiers et outils adaptés, il est possible de minimiser ces risques et de garantir une gestion sécurisée des données. Pour toute implémentation, assurez-vous de tester rigoureusement les configurations dans un environnement contrôlé avant de les déployer en production.