Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

4.4.3. Création de volumes en miroir

Note

Créer un volume logique LVM en miroir au sein d'un cluster requiert les mêmes commandes et procédures que la création d'un volume logique LVM en miroir sur un noeud unique. Cependant, afin de créer un volume LVM en miroir dans un cluster, le cluster et l'infrastructure du miroir du cluster doivent être en cours d'exécution, le cluster doit avoir atteint le quorum, et le type de verrouillage dans le fichier lvm.conf doit être configuré correctement afin de permettre le verrouillage du cluster. Pour un exemple de création d'un volume en miroir au sein d'un cluster, reportez-vous à la Section 5.5, « Création d'un volume logique LVM miroir dans un cluster ».
Tenter d'exécuter de multiples commandes de création et de conversions de miroirs LVM en succession rapide depuis de multiples noeuds dans un cluster peut provoquer une file d'attente de ces commandes. Cela peut faire expirer certaines des opérations requises, et les faire échouer. Pour éviter ce problème, il est recommandé d'exécuter les commandes de création de miroirs en cluster depuis un seul noeud du cluster.
Lorsque vous créez un volume en miroir, vous spécifiez le nombre de copies de données à effectuer avec l'argument -m de la commande lvcreate. Si vous spécifiez l'argument -m1, vous créez un miroir qui produira deux copies du système de fichiers : un volume logique linéaire plus une copie. De façon similaire, spécifiez l'argument -m2 pour créer deux miroirs qui produiront trois copies du système de fichiers.
La commande suivante crée un volume logique en miroir avec un seul miroir. Le volume a une taille de 50 giga-octets, s'appelle mirrorlv et est issu du groupe de volumes vg0 :
lvcreate -L 50G -m1 -n mirrorlv vg0
Un miroir LVM divise le périphérique en train d'être copié en régions faisant une taille de 512 Ko par défaut. Vous pouvez utiliser l'argument -R de la commande lvcreate pour spécifier la taille des régions en Mo. Vous pouvez aussi changer la taille des régions par défaut en modifiant le paramètre mirror_region_size dans le fichier lvm.conf.

Note

En raison des limitations dans l'infrastructure du cluster, les miroirs de clusters de plus de 1,5 To ne peuvent pas être créés avec une taille de région par défaut de 512 Ko. Les utilisateurs nécessitant de plus grands miroirs devraient augmenter la taille des régions par défaut. L'omission d'effectuer cette augmentation de taille des régions aura pour résultat de suspendre la création LVM et pourrait aussi suspendre d'autres commandes LVM.
En règle générale pour spécifier la taille des régions pour des miroirs faisant plus de 1,5 To, vous pouvez prendre la taille de votre miroir en téraoctets et arrondir ce nombre à la puissance de 2 suivante, en utilisant ce nombre en tant qu'argument -R de la commande lvcreate. Par exemple, si la taille de votre miroir est de 1,5 To, vous pourriez spécifier -R 2. Si la taille de votre miroir est de 3 To, vous pourriez spécifier -R 4. Si votre miroir fait 5 To, vous pourriez spécifier -R 8
La commande suivante crée un volume logique en miroir avec une taille de région de 2 Mo :
lvcreate -m1 -L 2T -R 2 -n mirror vol_group
LVM maintient un petit fichier journal afin de garder une trace des régions synchronisées avec le ou les miroirs. Par défaut, ce fichier journal est stocké sur le disque, il est donc persistant à travers les redémarrages et assure ainsi que le miroir ne doit pas être resynchronisé à chaque fois qu'une machine redémarre ou se bloque. Au lieu de cela, vous pouvez spécifier que ce fichier journal soit stocké en mémoire avec l'argument --mirrorlog core ; ceci élimine le besoin de posséder un périphérique de fichiers journaux supplémentaire, mais le miroir entier devra être resynchronisé à chaque redémarrage.
La commande suivante crée un volume logique en miroir à partir du groupe de volumes bigvg. Le volume logique est appelé ondiskmirvol et a un seul miroir. Le volume a une taille de 12Mo et garde le fichier journal du miroir en mémoire.
# lvcreate -L 12MB -m1 --mirrorlog core -n ondiskmirvol bigvg
  Logical volume "ondiskmirvol" created
Le fichier journal du miroir est créé sur un périphérique séparé à partir des périphériques sur lesquels n'importe quelle branche du miroir peut être créée. Il est cependant possible de créer un fichier journal sur le même périphérique que celui des branches du miroir à l'aide de l'argument --alloc anywhere de la commande vgcreate. Ceci peut dégrader la performance, mais vous permet aussi de créer un miroir, même si vous ne possédez que deux périphériques sous-jacents.
La commande suivante crée un volume logique en miroir avec un seul miroir dans lequel le fichier journal du miroir se trouve sur le même périphérique que l'une des branches du miroir. Dans cet exemple, le groupe de volumes vg0 est composé de deux périphériques. Cette commande crée un volume de 500 méga-octets nommé mirrorlv dans le groupe de volumes vg0.
lvcreate -L 500M -m1 -n mirrorlv -alloc anywhere vg0

Note

Avec des miroirs de clusters, la gestion du journal des miroirs est sous l'entière responsabilité du noeud du cluster avec l'ID actuel du cluster le plus bas. Ainsi, lorsque le périphérique possédant le journal des miroirs de cluster se retrouve indisponible sur un sous-ensemble du cluster, le miroir clusterisé peut continuer à fonctionner sans le moindre impact tant que le noeud du cluster avec l'ID le plus bas conserve l'accès au journal miroir. Comme le miroir n'est pas perturbé, aucune action corrective automatique (réparation) n'est effectuée. Lorsque le noeud de cluster avec l'ID le plus bas perd son accès au journal miroir , une action automatique sera alors lancée (peu importe le niveau d'accessibilité du journal depuis d'autres noeuds).
Pour créer un fichier journal miroir qui est lui-même mis en miroir, vous pouvez spécifier l'argument --mirrorlog mirrored. La commande suivante crée un volume logique en miroir à partir du groupe de volumes bigvg. Le volume logique est appelé twologvol et a un seul miroir. Le volume a une taille de 12Mo et le fichier journal du miroir est en miroir, avec chaque journal stocké sur un périphérique séparé.
# lvcreate -L 12MB -m1 --mirrorlog mirrored -n twologvol bigvg
  Logical volume "twologvol" created
Tout comme avec un fichier journal de miroir standard, il est possibler de créer les fichiers journaux de miroirs redondants sur le même périphérique que les branches du miroir en utilisant l'argument --alloc anywhere de la commande vgcreate. Ceci peut dégrader la performance, mais vous permet de créer un fichier journal de miroir redondant même si vous ne possédez pas suffisament de périphériques sous-jacents pour que chaque fichier journal soit stocké sur un périphérique autre que celui des branches du miroir.
Lorsqu'un miroir est créé, les régions du miroir sont synchronisées. Pour les composants miroir volumineux, le processus de synchronisation peut prendre un moment. Lorsque vous créez un nouveau miroir qui n'a pas besoin d'être réactivé, vous pouvez spécifier l'argument nosync pour indiquer qu'une synchronisation initiale à partir du premier périphérique n'est pas requise.
Vous pouvez spécifier les périphériques à utiliser pour les fichiers journaux et les branches du miroir, ainsi que les extensions des périphériques à utiliser. Pour forcer un fichier journal sur un disque particulier, spécifiez une seule extension sur le disque où il sera placé. LVM ne respecte pas forcément l'ordre dans lequel les périphériques sont listés dans la ligne de commande. Si des volumes physiques sont listés, il s'agit du seul emplacement sur lequel l'allocation aura lieu. Toute extension physique inclue dans la liste qui est déjà allouée sera ignorée.
La commande suivante crée un volume logique en miroir avec un seul miroir et un seul fichier journal qui n'est pas en miroir. Le volume a une taille de 500 méga-octets, il s'appelle mirrorlv et est issu du groupe de volumes vg0. La première branche du miroir se trouve sur le périphérique /dev/sda1, la seconde sur /dev/sdb1 et le fichier journal du miroir se trouve sur /dev/sdc1.
lvcreate -L 500M -m1 -n mirrorlv vg0 /dev/sda1 /dev/sdb1 /dev/sdc1
La commande suivante crée un volume logique en miroir avec un seul miroir. Le volume a une taille de 500 méga-octets, il s'appelle mirrorlv et est issu du groupe de volumes vg0. La première branche du miroir se trouve sur les extensions 0-499 du périphérique /dev/sda1, la seconde sur les extensions 0-499 du périphérique /dev/sdb1, et le fichier journal du miroir commence à l'extension 0 du périphérique /dev/sdc1. Il y a 1Mo d'extensions. Si une des extensions spécifiées a déjà été allouée, elle sera ignorée.
lvcreate -L 500M -m1 -n mirrorlv vg0 /dev/sda1:0-499 /dev/sdb1:0-499 /dev/sdc1:0

Note

À partir de la version 6.1 de Red Hat Enterprise Linux, vous pouvez combiner RAID0 (striping) et RAID1 (mirroring) dans un seul volume logique. La création d'un volume logique tout en spécifiant le nombre de miroirs (--mirrors X) et le nombre de stripes (--stripes Y) résulte en un périphérique miroir dont les périphériques constituants sont en mode stripe.

4.4.3.1. Politique en cas d'échec des volumes logiques en miroir

Au cas où un échec de périphérique surviendrait, vous pouvez définir de quelle manière un volume logique en miroir se comporte avec les paramètres mirror_image_fault_policy et mirror_log_fault_policy dans la section activation du fichier lvm.conf. Lorsque ces paramètre sont définis sur remove, le système tente de supprimer le périphérique défectueux et de s'exécuter sans celui-ci. Lorsque ce paramètre est définit sur allocate, le système tente de supprimer le périphérique défectueux et essaie d'allouer de l'espace sur un nouveau périphérique afin de remplacer le périphérique défectueux ; cette politique fonctionne comme la politique remove s'il n'y a pas de périphérique ni d'espace convenable à allouer pour le remplacement.
Par défaut, le paramètre mirror_log_fault_policy est défini sur allocate. L'utilisation de cette politique pour le fichier journal est rapide et offre la possibilité de rester capable de se rappeler de l'état de la synchronisation à travers les pannes et les redémarrages. Si vous définissez cette politique sur remove, lorsqu'un périphérique de fichier journal échoue, le miroir se mettra à utiliser un journal se trouvant dans la mémoire et le miroir ne se rappellera pas de sont statut de synchronisation à travers les pannes et les redémarrages. Le miroir devra donc être entièrement resynchronisé.
Par défaut, le paramètre mirror_image_fault_policy est défini sur remove. Avec cette politique, si une image de miroir échoue, le miroir se convertira en périphérique sans miroir s'il ne reste qu'une seule copie correcte. Définir cette politique sur allocate pour un périphérique en miroir requiert que le miroir resynchronise les périphériques; ce processus est lent, mais préservera les caractéristiques de miroir du périphérique.

Note

Lorsqu'un miroir LVM souffre d'un échec de périphérique, une restauration en deux étapes s'effectue. La première étape implique la suppression des périphériques en échec. Ceci peut faire que le miroir soit réduit à l'état de périphérique linéaire. La deuxième étape, si le paramètre mirror_log_fault_policy est défini sur allocate, consiste à tenter de remplacer l'un des périphériques en échec. Remarquez cependant qu'il n'y a pas de garanties que la seconde étape choisira des périphériques qui étaient utilisés auparavant par le miroir qui ne faisait pas partie de l'échec si d'autres sont disponibles.
Pour plus d'informations sur la restauration manuelle d'échec de miroir LVM, voir Section 6.3, « Récupération suite à un échec miroir LVM ».