LVM et reprise après sinistre


13

Je comprends ce qu'est LVM et ce qu'elle accomplit, mais j'ai l'impression de manquer certaines choses.

Disons que nous avons deux disques physiques, sda et sdb. Les deux font 100 Megs. Je les mets dans VolumeGroup1 et crée un LogicalVolume1 de 200 mégaoctets.

Que se passerait-il si je créais un fichier de 150 mégaoctets? 100 mégaoctets seraient-ils physiquement sur sda et 50 sur sdb? Dans l'affirmative, qu'est-ce qui indique au système d'exploitation qu'une partie du fichier se trouve sur un lecteur et une autre sur l'autre?

Qu'en est-il de la panne de disque? En supposant qu'aucun RAID, si sdb échoue, toutes les données sur sda seront-elles perdues? Est-il possible de contrôler quels fichiers se trouvent sur quels disques physiques?

Comment gérez-vous généralement LVM? Créez-vous un ou deux grands groupes de volumes puis créez-vous des partitions comme cela a du sens? D'autres conseils?


1
Si vous voulez éviter la redondance d'un raid, d'un grand média et que vous pouvez vivre avec des pannes de disque unique, cela pourrait fonctionner pour vous: serverfault.com/a/543684/165065
DennisH

Réponses:


15

Disons que nous avons deux disques physiques, sda et sdb. Les deux font 100 Megs. Je les mets dans VolumeGroup1 et crée un LogicalVolume1 de 200 mégaoctets.
Que se passerait-il si je créais un fichier de 150 mégaoctets? 100 mégaoctets seraient-ils physiquement sur sda et 50 sur sdb?

Correct (en supposant que le système de fichiers était vide avant la création du fichier).

Dans l'affirmative, qu'est-ce qui indique au système d'exploitation qu'une partie du fichier se trouve sur un lecteur et une autre sur l'autre?

LVM indique au système d'exploitation qu'il existe un seul disque de 200 Mo. La partie LVM du noyau (elle se compose de deux parties, des outils de gestion de l'espace utilisateur et des pilotes du noyau) mappera ensuite ce que le système d'exploitation voit aux emplacements / blocs physiques sur les disques.

Qu'en est-il de la panne de disque? En supposant qu'aucun RAID, si sdb échoue, toutes les données sur sda seront-elles perdues? Est-il possible de contrôler quels fichiers se trouvent sur quels disques physiques?

Oui, considérez les données perdues.

Si vous créez des volumes logiques plus petits, vous pouvez utiliser la pvmovecommande pour les déplacer d'un disque à l'autre.

Comment gérez-vous généralement LVM? Créez-vous un ou deux grands groupes de volumes puis créez-vous des partitions comme cela a du sens? D'autres conseils?

J'ai tendance à créer de grands groupes de volumes, puis à créer des volumes logiques selon les besoins. Il n'est pas nécessaire d'allouer entièrement tout l'espace dans un groupe de volumes; allouez-le quand il est nécessaire. Il est facile d'augmenter la taille d'un volume logique, et à peu près tous les systèmes de fichiers modernes peuvent également être facilement développés.


Vous êtes sûr de ce premier? Je pensais que LVM par défaut était le striping, de sorte que le fichier de 150 mégaoctets aurait probablement environ 75 mégaoctets sur chaque disque
freiheit

2
Les bandes ne sont pas créées sauf si vous spécifiez --stripes <num>(court -i <num>) lorsque vous créez le volume logique.
pgs

PS, ma réponse ici contient un script qui vous montrera quels PV chaque LV utilise: serverfault.com/questions/28592/…
pgs

@freiheit, pgs a raison, la valeur par défaut est d'étendre, et non de rayer, le volume.
Avery Payne, le

en ce qui concerne la gestion, je suis prêt à créer un groupe lvm sur mes 3 disques durs, mais uniquement à créer des volumes logiques limités aux volumes physiques, puis à n'utiliser que les espaces disponibles pour créer des instantanés; pensez-vous que c'est le plus sûr pour un utilisateur à domicile (qui n'a pas de raid ni d'argent pour remplacer rapidement les choses)?
Aquarius Power

4

La chose sous-jacente qui permet à LVM et aux raids logiciels sous Linux est la partie mappeur de périphériques du noyau. C'est ce qui résume les adresses de bloc des périphériques physiques aux périphériques de bloc virtuels que vous utilisez.

Lorsque vous utilisez LVM comme pour tout ce qui concerne les données, vous devez être conscient des répercussions sur la disponibilité des données. Cela ne veut pas dire que LVM est dangereux en fait lorsque les bonnes pratiques sont utilisées, son impact sur la disponibilité est minime.

Dans le scénario que vous suggérez dans votre question, la disponibilité de vos données serait la même que pour un RAID0 où si un disque tombe en panne, cela entraînerait une perte de données.

En pratique, je n'utiliserais pas LVM sans l'exécuter sur une sorte de RAID. J'ai utilisé LVM sur un serveur de fichiers de 30 To qui avait environ 20 volumes Hardware RAID5 dans un VG. Mais si vous avez suffisamment d'extensions gratuites, vous pouvez utiliser pvmove pour migrer les données d'un ou plusieurs PV si cela commence à vous poser des problèmes.

Mais ayez toujours une stratégie de sauvegarde en place qui est testée de temps en temps.


3

Comment gérez-vous généralement LVM? Créez-vous un ou deux grands groupes de volumes puis créez-vous des partitions comme cela a du sens?

Ma stratégie générale consiste à mettre dans un groupe de volumes séparé les volumes physiques qui pourraient éventuellement être migrés (dans leur ensemble) vers un autre système.

Si vous disposez d'un stockage externe, il est judicieux de le placer dans un groupe de volumes séparé. Il est physiquement facile de le déconnecter de cet ordinateur et de se connecter à un autre, il devrait donc être logiquement facile de l'exporter / l'importer dans LVM, en conservant les données intactes.

Si vous avez déjà un vg00 sur le (s) disque (s) interne (s) et que vous achetez ensuite un autre disque interne pour votre machine, posez-vous une question: les données du nouveau disque seront-elles liées à vg00, et il n'y aurait aucun sens à déplacer les données vers un autre système? Dans ce cas, il doit faire partie de vg00. Sinon, je créerais vg01, car il peut être facilement exporté / importé seul.


0

Si vous avez deux disques en tant que volumes physiques dans un groupe comme celui-ci, alors vous avez un tableau JBOD (Just a Bunch Of Disks). Si l'un des disques tombe en panne, vous ne serez pas mieux protégé que si les disques étaient disposés dans une matrice RAID0.

Vous ne pouvez pas contrôler directement ce qui se passe sur les deux disques si vous avez un volume logique dans le groupe de volumes (car cela sera contrôlé par le système de fichiers dans le volume, pas LVM), mais si vous divisez le groupe de volumes en plusieurs volumes logiques, vous peut ordonner manuellement leur création de sorte qu'un volume logique donné se trouve sur un lecteur donné.

Je crois que chaque PV dans un VG a une copie de la disposition LV et que les données ne sont pas supprimées comme avec RAID0, vous avez donc plus de chances de récupérer quelque chose si l'un de vos disques tombe en panne, mais si la perte de données est un problème. Je n'envisagerais pas du tout d'utiliser deux disques de cette façon (via LVM ou RAID0).


0

Que se passerait-il si je créais un fichier de 150 mégaoctets? 100 mégaoctets seraient-ils physiquement sur sda et 50 sur sdb? Dans l'affirmative, qu'est-ce qui indique au système d'exploitation qu'une partie du fichier se trouve sur un lecteur et une autre sur l'autre?

Le LVM (Logical Volume Manager) collecte les volumes physiques en groupes de volumes. Chaque volume physique (le lecteur lui-même) a de petits morceaux appelés extensions physiques. Ces extensions ont un identifiant uniq sur le disque. En fait, ils sont numérotés séquentiellement. Lorsque vous créez un volume logique, il a été créé à partir d'extensions logiques qui sont associées aux extensions physiques. Les extensions logiques ont un ID uniq dans le volume logique. Dans HP-UX, vous pouvez vérifier quelle étendue logique est associée à quelle étendue physique. Dans SLES11, je ne sais pas comment le vérifier. lvdisplay --mapsdevrait être bon mais pas parfait (pour moi).

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.