LVM : le jeu en vaut-il la chandelle ?

[arapaho]

Mais néanmoins, je confirme que pour un système "simple serveur", il n'y a guère d'intérêt (puisque nous ne découpons plus en 10 arborescences type /boot, /, /home, /tmp, /var, /usr, /var/log, ...)

Avant que je me lance dans une diatribe envers cette affirmation, tu peux développer s'il te plait ?


Sinon Jibe, tu compares l'abstraction matérielle avec la VM Java, en finissant par dire que le code C tourne sur toutes les plate-formes. Je ne pense pas que ce soit le bon bout par lequel appréhender cela. Loin de moi l'idée de t'apprendre le C, mais tu sais pertinemment qu'un même code C un tant soit peu plus évolué que "Hello World" ne tournera pas automatiquement sur toutes les plate-formes matérielle. Sinon, on peut tout de même suivre ton raisonnement et faire en sorte que notre machine virtuelle Java soit écrite en C. Et donc tourne sur toutes les plate-formes. Bref.
Pour faire avancer un peu le sujet, tu devrais effectivement te pencher sur l'utilisation des snapshots, assez intéressante à mon avis. Ne pas oublier également que, suivant le système de fichiers choisi, tu peux également réduire la taille. Ou encore manipuler les PE en les déplaçant, d'un vieux disque à un disque plus récent, ou encore d'un disque mécanique vers un SSD, par exemple. Et quelques autres choses, comme les relations avec le RAID software (dont je ne suis pas fan, à part dans certains cas très précis)

Enfin, pour finir, les systèmes de fichiers ZFS, ou encore BTRFS, futur FS par défaut, te feront sûrement frissonner

[jdh]

Bonjour Arapaho. (hugh ?)

Quand on installe un serveur Linux sur un serveur physique, on ne découpe plus en multiples partitions (/, /home, /usr, /var, /tmp, /boot, ...) comme autrefois (sur les Unix d'origine). Le minimum est un swap et /, et cela suffit pour un desktop. Mais on peut ajouter /home voire /boot.

A quoi peut servir LVM sur un tel système ?

Les 2 avantages net de LVM sont :
- la possibilité de créer rapidement une partition (création d'un volume logique + formatage + montage),
- l'extension d'une partition (volume logique) existante.

Le premier avantage est assez inutile puisque justement on ne créé que peu de partition.
Le second avantage suppose soit qu'il existe de la place disponible ... qu'on aurait pas utilisée dès le départ, soit qu'on ajoute un disque.

En général, on découpe totalement le disque dès le début donc pas besoin de LVM pour agrandir.
(Ce qui est fondamentalement une erreur : quand on manque d'espace disque, il y a urgence ! Et c'est toujours pratique de s'être gardé une petite marge)

Là où LVM peut avoir un intérêt net, pour un serveur physique, c'est lors de l'ajout d'un disque :
LVM peut permettre d'ajouter le nouveau disque au volume physique et d'étendre un volume logique directement.
Sans LVM, l'ajout de disque permettra de créer un dossier où la place supplémentaire sera dispo.
En détail, avec LVM, /home grandira de la taille du disque, alors que, sans LVM, on créera /home/newdisque/ avec la même place.

On pourrait arguer des possibilités de snapshot, il faut avoir de l'espace dispo et gérer snapshoot/remove à la main ?

On pourrait arguer des possibilités de raid (software), mais on peut déjà utiliser mdadm pour cela.
(D'ailleurs LVM s'appuie sur mdadm, me trompes-je ?)


Clairement, de mon point de vue, LVM est un atout énorme pour un hôte de virtualisation (Proxmox ou XEN), puisqu'il permet d'associer un volume logique à une VM et d'agrandir à volonté cet espace. La possibilité de snapshot permet une sauvegarde très rapide (pour l'interruption de service).
L'avantage de LVM pour un serveur physique est nettement moindre.

Est ce ton avis ?

[arapaho]

Salut jdh !

Quand on installe un serveur Linux sur un serveur physique, on ne découpe plus en multiples partitions (/, /home, /usr, /var, /tmp, /boot, ...) comme autrefois (sur les Unix d'origine). Le minimum est un swap et /, et cela suffit pour un desktop. Mais on peut ajouter /home voire /boot.

Serveur ou desktop finalement ? Bref.
En lisant l'affirmation "on ne découpe plus en multiples partitions", j'ai écarquillé les yeux. Et le "comme autrefois" m'a fait tomber la machoire.
Donc si je comprends bien, si on utilise pas LVM, ce n'est pas la peine de faire plusieurs partitions, que ce soit pour un "serveur simple" ou un desktop. Dans ce cas, je pense à un cas qui m'est arrivé la semaine dernière: un serveur, qui s'est vautré méchament. Au reboot, seule la partition contenant /var était dégueulasse. Donc la technique du "comme autrefois" m'a permis de:
* Booter en runlevel 1 et faire ma popote pour restaurer ma /var
* Restaurer *rapidement* et *uniquement* ma /var
Dans la même situation, avec une seule partition, je devais me taper une restauration complète.

Et puis d'autres cas d'utilisation sont impossibles avec une seule partition:
* formatage avec des tailles différentes de blocs (intéressant pour l'écriture de gros fichiers de logs par exemple)
* ou encore des montages avec des options spécifiques, comme des noexec ou des nosuid, ou des noatime (pour /tmp ou /home, entre autre)

Enfin, toujours hors LVM, concernant le problème de taille de partition, je te donne un exemple du partitionnement du portable sur lequel je suis actuellement, que j'ai depuis 2008 et qui n'a jamais été ré-installé depuis sa sortie du carton. Je pense que je suis à l'aise pendant encore quelque temps

Code : Tout sélectionner

Sys. fich.                    Type     Taille Util. Dispo Uti% Monté sur
rootfs                        rootfs     225M   80M  145M  36% /
/dev/root                     xfs        225M   80M  145M  36% /
devtmpfs                      devtmpfs   3,1G     0  3,1G   0% /dev
tmpfs                         tmpfs      618M  386k  618M   1% /run
tmpfs                         tmpfs      5,3M     0  5,3M   0% /run/lock
tmpfs                         tmpfs      995M   37M  958M   4% /tmp
tmpfs                         tmpfs      1,3G   13k  1,3G   1% /run/shm
/dev/sda1                     ext3        57M   37M   18M  68% /boot
/dev/sda7                     xfs        995M   37M  958M   4% /tmp
/dev/sda5                     xfs         10G  5,1G  5,0G  51% /usr
/dev/sda6                     xfs        2,0G  455M  1,6G  23% /var
/dev/mapper/vg.sda8-hompierre xfs        108G   84G   24G  78% /home


Tu noteras que ma home est sur sur LVM.

Au final, soit j'ai pas compris correctement ta phrase, soit je me dis qu'il y a deux ou trois oublis concernant l'emplois des partitions et des systèmes de fichiers 'comme autrefois'...

A quoi peut servir LVM sur un tel système ?
[...]
Est ce ton avis ?

Je suis convaincu des intérêts de LVM, et pas uniquement dans la virtualisation, loin de là. Après c'est comme tout, il faut l'utiliser quand c'est nécessaire.

[DmilZ]

Je suis plutôt d'accord avec l'avis de sibsib à la page précédente. Le couple LVM et SAN s'entend très bien.

Un exemple que je côtoie tous les jours :
Pour un grand compte les serveurs sont "mutualisés" c'est à dire qu'ils hébergent plusieurs applications. Chaque application est, si on peut dire, cloisonner et utilise son propre Volum Group et ses File Systems. L'utilisation des File Systems permet de limiter l'impact d'une application sur l'autre. LVM permet d'apporter une certaine souplesse d'administration : on dimensionne les partitions pour les besoins réels dès le départ et on modifie au fur et à mesure pour suivre les besoins sans interrompre le service (dans la majorité des cas). Le SAN fournit, lui, des disques aux différents VG avec ses avantages. Le client est donc facturé à ce qu'il consomme et on évite d'avoir des dizaines de téra-octets inutilisées en attente.

Tout ça pour dire, puisque cet argument n'avait pas été cité, qu'il peut aussi présenter un intérêt financier.

[jdh]

Bonsoir Arapaho.

Finalement, tu reprends (principalement) le découpage (du disque) en partitions.
Entre ce qui était préconisé à la fin des années 80 sur des Unix "classiques" et ce qu'on peut pratiquer aujourd'hui, il y a des écarts nets.

Par exemple, la taille de swap : on peut lire des préconisations "à l'ancienne" de 2 fois la taille de mémoire centrale.
J'ai connu une SM-90 équipé d'un processeur 68000 à 10Mhz (?) avec 2 Mo de mémoire : on pouvait mettre 4 Mo dans le swap.
Mais mon portable a 2 Go de mémoire : faut-il 4 Go de swap (qui ne seront jamais utilisé) ?

Les disques SCSI de l'époque assuraient la présence de secteurs de remplacement en cas de défaillance.
La taille des buffers, l'anticipation de lecture de secteurs successifs, l'alignement des file system essayaient d'améliorer la perf disque.
Je ne me souviens pas de la taille de disque d'un SM-90 mais je me souviens de mon premier disque ATA de 40 Mo.
On installe couramment dans un portable un disque de 500G à 7200t qui fournit aisément 40 Mo/s (soit mon 1er disque en 1 seconde).

Tu utilises des file system en xfs, et on pourrait évoquer ext3/4, jfs, reiserfs, le futur btrfs, ... et cela a de l'importance.
Et effectivement la taille des fichiers prévus peut aider à choisir un file system plutôt qu'un autre ...

Pour ce qui est de l'OS, j'utilise pour un serveur Linux "de base" souvent Debian qui place des fichiers de conf à peu près toujours dans /etc.
Donc on retrouve un /lib, /usr à peu près identique pour un serveur avec les mêmes paquets.
En restauration, une copie de ces arborescences à partir d'un serveur peut sans doute permettre de repartir.
Au pire, une copie de /etc (config), de /home (données), et de la liste des paquets peut aussi permettre la recréation d'une machine.

On peut distinguer des groupes de répertoires avec des rôles donnés :
- /boot : noyau
- /etc : l'essentiel de la config
- /lib, /usr, /opt : librairies, source (noyau), programmes
- /var : log, socket, fichiers de travail mais aussi emplacement de base pour certains logiciels
- /tmp, /mnt : temporaire, montage
- /home : fichiers utilisateurs

Il faut savoir changer l'emplacement de certains fichiers pour certains logiciels : mysql : /home/mysql au lieu de /var/lib/mysql p.e.

Je n'oublie pas que pour un serveur, l'OS et les logiciels, hors les données ne dépassent guère les 10G pour des disques de 300G ou bien plus.

[arapaho]

Bonsoir jdh

Finalement, tu reprends (principalement) le découpage (du disque) en partitions.
Entre ce qui était préconisé à la fin des années 80 sur des Unix "classiques" et ce qu'on peut pratiquer aujourd'hui, il y a des écarts nets.

Même si je me suis documenté dessus par le passé, je ne connais pas trop les années 80 ou celles d'avant. Les seuls Unices que j'ai pu manipuler ont été AIX, Sun OS et HP-UX. Je n'ai donc pas une parfaite maitrise des pratiques de 30 ans en arrière.

Par exemple, la taille de swap : on peut lire des préconisations "à l'ancienne" de 2 fois la taille de mémoire centrale.
J'ai connu une SM-90 équipé d'un processeur 68000 à 10Mhz (?) avec 2 Mo de mémoire : on pouvait mettre 4 Mo dans le swap.
Mais mon portable a 2 Go de mémoire : faut-il 4 Go de swap (qui ne seront jamais utilisé) ?

J'ai pas dit ça. Et je ne pratique pas non plus.

Les disques SCSI de l'époque assuraient la présence de secteurs de remplacement en cas de défaillance.
La taille des buffers, l'anticipation de lecture de secteurs successifs, l'alignement des file system essayaient d'améliorer la perf disque.
Je ne me souviens pas de la taille de disque d'un SM-90 mais je me souviens de mon premier disque ATA de 40 Mo.
On installe couramment dans un portable un disque de 500G à 7200t qui fournit aisément 40 Mo/s (soit mon 1er disque en 1 seconde).

Je n'ai malheureusement connu que du matériel plus récent.

Pour ce qui est de l'OS, j'utilise pour un serveur Linux "de base" souvent Debian qui place des fichiers de conf à peu près toujours dans /etc.
Donc on retrouve un /lib, /usr à peu près identique pour un serveur avec les mêmes paquets.
En restauration, une copie de ces arborescences à partir d'un serveur peut sans doute permettre de repartir.
Au pire, une copie de /etc (config), de /home (données), et de la liste des paquets peut aussi permettre la recréation d'une machine.

Je comprends tout à fait le point de vue.
Dans mon cas, je continuerai à éviter la copie d'un répertoire /etc d'un serveur à l'autre. Juste pour éviter que les centaines de groupes et d'utilisateurs passent de l'un à l'autre. Et je pense que je continuerai à restaurer ma / de quelques centaines de Mo.

Alors oui, on peut utiliser une seule partition et tout mettre dedans. J'ai jamais dit le contraire.
Le modèle mono-point de montage pour l'ensemble d'un système me convainc guère, m'enlevant beaucoup de ce que le "saucissonage" m'apporte. Je pense que je continuerai à pratiquer différemment, de monter mes partitions/lv avec noexec ou nosuid si besoin, d'en monter d'autre en lecture seule dans d'autre besoin. Evidemment, il est possible d'avoir ce même comportement avec plusieurs volumes logiques, tous étant situés sur une seule partition d'un seul disque physique ou logique (RAID)...

[jdh]

Bonjour Arapaho,

Je ne fais aucune préconisation excepté d'encourager la réflexion et le choix.

Si tu installes une Ubuntu sur un portable, l'install te proposera juste un swap et /. Pourquoi pas ?
Si tu créé un serveur pour ton entreprise, tu peux choisir ce que tu veux ou ce qui te conviens.
Encore faut-il savoir pourquoi et que cela prépare les accidents à venir ...

Le critère ancien pour le swap était "2 fois la mémoire", mais cela a de l'intérêt si les process peuvent amener à utiliser du swap !
Dans ma formation initiale (en maths), nous disposions d'un "mini système" avec des terminaux.
Un jour, un élève avaient programmé un calcul sur des matrices dimensionné en 10x10.
Le programme s'exécutait en un instant après saisie de la dimension =3 puis de la matrice 3x3.
Il lui vint l'idée de voir jusqu'où le programme pouvait aller : changement de dimension puis compil jusqu'à 1000x1000 (au delà c'était erreur).
Il lance alors le programme et saisie la même dimension 3 et la même matrice.
Il a fallu arrêter le programme car l'ordi est devenu "fou" : il swappait à mort car il avait créé des pages mémoire pour la matrice de taille maxi, et passait son temps à envoyer dans le swap le code puis les données, n'ayant pas au même moment le code et la donnée juste.
De mémoire (!), il a fallu 2 heures pour débloquer le mini ...

Un simple script bash avec une fonction récursive pour lire/copier un cd suffit pour saturer un unix qui tire 30 utilisateurs.
(Expérience vécue avec un Digital Unix en 1997 limité à 65000 process avec 256 Mo de mémoire ce qui était assez puissant à l'époque.)

Bien évidemment, on ne copie surtout jamais /etc d'un coup, mais on reconfigure paquet par paquet avec le/les fichiers de conf !
La base utilisateurs (passwd) et groupe pose évidemment problème (merci "find -uid -exec chown" !).