J'ai récemment commencé à utiliser LVM sur certains serveurs pour les disques durs de plus de 1 To. Ils sont utiles, extensibles et assez faciles à installer. Cependant, je n'ai pas trouvé de données sur les dangers et les mises en garde de LVM.
Quels sont les inconvénients de l'utilisation de LVM ?
Résumé
Risques liés à l'utilisation de LVM :
Les deux premiers problèmes de LVM se combinent : si la mise en cache en écriture ne fonctionne pas correctement et que vous avez une perte de puissance (par exemple, une panne de PSU ou d'UPS), vous pourriez bien devoir récupérer à partir de la sauvegarde, ce qui signifie un temps d'arrêt important. L'une des principales raisons d'utiliser LVM est l'amélioration de la disponibilité (lors de l'ajout de disques, du redimensionnement de systèmes de fichiers, etc.), mais il est important de configurer correctement la mise en cache en écriture pour éviter que LVM ne réduise réellement la disponibilité.
-- Mis à jour en décembre 2019 : mise à jour mineure sur btrfs et ZFS comme alternatives aux instantanés LVM.
Atténuer les risques
LVM peut toujours fonctionner correctement si vous :
Détails
J'ai fait de nombreuses recherches sur ce sujet dans le passé, ayant subi des pertes de données liées à LVM. Les principaux risques et problèmes liés à LVM dont je suis conscient sont les suivants :
Vulnérabilité à la mise en cache en écriture du disque dur due aux hyperviseurs VM, à la mise en cache du disque ou aux anciens noyaux Linux. et rend plus difficile la récupération des données en raison de structures plus complexes sur le disque - voir ci-dessous pour plus de détails. J'ai vu des configurations LVM complètes sur plusieurs disques être corrompues sans aucune chance de récupération, et LVM plus la mise en cache en écriture du disque dur est une combinaison dangereuse.
data=ordered (ou data=journal pour plus de sécurité), plus barrier=1 pour s'assurer que la mise en cache du noyau n'affecte pas l'intégrité. (Ou utilisez ext4 qui active les barrières par défaut .) C'est l'option la plus simple et elle fournit une bonne intégrité des données au prix de la performance. (Linux a modifié l'option ext3 par défaut au plus dangereux data=writeback il y a quelque temps, donc ne vous fiez pas aux paramètres par défaut du FS).hdparm -q -W0 /dev/sdX pour tous les lecteurs dans /etc/rc.local (pour SATA) ou utilisez sdparm pour SCSI/SAS. Cependant, selon cette entrée dans la FAQ XFS (qui est très bonne sur ce sujet), un disque SATA peut oublier ce paramètre après une reprise après une erreur de disque - vous devez donc utiliser SCSI/SAS, ou si vous devez utiliser SATA, mettez la commande hdparm dans une tâche cron exécutée toutes les minutes ou presque.Garder le cache en écriture activé pour les performances (et pour faire face aux lecteurs couchés)
Une option plus complexe mais plus performante consiste à garder la mise en cache en écriture des SSD / disques durs activée et à compter sur les barrières d'écriture du noyau qui fonctionnent avec LVM sur le noyau 2.6.33+ (vérifiez en recherchant les messages "barrier" dans les journaux).
Vous devez également vous assurer que la configuration RAID, la configuration de l'hyperviseur VM et le système de fichiers sont correctement configurés. utilise des barrières d'écriture (c'est-à-dire que le lecteur doit vider les écritures en attente avant et après les écritures de métadonnées/journaux clés). XFS utilise les barrières par défaut, mais ext3 ne le fait pas. donc avec ext3 vous devez utiliser barrier=1 dans les options de montage, et toujours utiliser data=ordered o data=journal comme ci-dessus.
SSDs sont problématiques car l'utilisation du cache en écriture est essentielle à la durée de vie du SSD. Il est préférable d'utiliser un SSD doté d'un supercondensateur (pour permettre le vidage du cache en cas de coupure de courant, et donc permettre au cache d'être en écriture inverse et non en écriture directe).
Format avancé configuration du disque - cache en écriture, alignement, RAID, GPT
pvcreate pour aligner les PVs. Ce fil de discussion de la liste d'emails LVM indique le travail effectué dans les noyaux en 2011 et le problème des écritures de blocs partiels lors du mélange de disques avec des secteurs de 512 octets et de 4 KiB dans un seul LV.Plus difficile de récupérer les données en raison de structures plus complexes sur le disque. :
/etc/lvm qui peut aider à restaurer la structure de base des LV, VG et PV, mais pas les métadonnées perdues du système de fichiers.Il est plus difficile de redimensionner correctement les systèmes de fichiers - Le redimensionnement facile des systèmes de fichiers est souvent donné comme un avantage de LVM, mais vous devez exécuter une demi-douzaine de commandes Shell pour redimensionner un FS basé sur LVM - cela peut être fait avec le serveur entier encore en place, et dans certains cas avec le FS monté, mais je ne risquerais jamais ce dernier sans sauvegardes à jour et en utilisant des commandes pré-testées sur un serveur équivalent (par exemple, un clone de reprise après sinistre du serveur de production).
Mise à jour : Des versions plus récentes de lvextend soutenir le -r ( --resizefs ) - si cette option est disponible, c'est un moyen plus sûr et plus rapide de redimensionner le LV et le système de fichiers, en particulier si vous réduisez le FS, et vous pouvez généralement sauter cette section.
La plupart des guides sur le redimensionnement des FS basés sur LVM ne tiennent pas compte du fait que le FS doit être un peu plus petit que la taille du LV : explication détaillée ici . Lors du rétrécissement d'un système de fichiers, vous devrez spécifier la nouvelle taille à l'outil de redimensionnement de FS, par ex. resize2fs pour ext3, et à lvextend o lvreduce . Sans grande précaution, les tailles peuvent être légèrement différentes en raison de la différence entre 1 Go (10^9) et 1 GiB (2^30), ou la façon dont les différents outils arrondissent les tailles vers le haut ou vers le bas.
Si vous ne faites pas les calculs exactement comme il faut (ou si vous utilisez des étapes supplémentaires en plus des plus évidentes), vous pouvez vous retrouver avec un FS trop grand pour le LV. Tout semblera aller bien pendant des mois ou des années, jusqu'à ce que vous remplissiez complètement le FS, à ce moment-là vous obtiendrez une corruption sérieuse - et à moins que vous ne soyez conscient de ce problème, il est difficile de trouver pourquoi, car vous pouvez aussi avoir de vraies erreurs de disque à ce moment-là qui obscurcissent la situation. (Il est possible que ce problème n'affecte que la réduction de la taille des systèmes de fichiers - cependant, il est clair que le redimensionnement des systèmes de fichiers dans un sens ou dans l'autre augmente le risque de perte de données, éventuellement en raison d'une erreur de l'utilisateur).
Il semble que la taille du LV doit être supérieure à celle du FS de 2 x la taille de l'étendue physique (PE) du LVM - mais vérifiez le lien ci-dessus pour plus de détails car la source de cette information ne fait pas autorité. Souvent, autoriser 8 MiB est suffisant, mais il peut être préférable d'autoriser plus, par exemple 100 MiB ou 1 GiB, juste pour être sûr. Pour vérifier la taille du PE, et la taille de votre volume logique+FS, en utilisant 4 KiB = 4096 blocs d'octets :
Indique la taille du PE en KiB :vgdisplay --units k myVGname | grep "PE Size"
Taille de tous les LVs :lvs --units 4096b
Taille du FS (ext3), suppose une taille de bloc de FS de 4 KiB :tune2fs -l /dev/myVGname/myLVname | grep 'Block count'
En revanche, une configuration non-LVM rend le redimensionnement du FS très fiable et facile - exécutez Gparted et redimensionner les FSs nécessaires, alors il fera tout pour vous. Sur les serveurs, vous pouvez utiliser parted à partir du Shell.
Il est souvent préférable d'utiliser le Gparted Live CD o Parted Magic J'ai déjà perdu tout un système de fichiers parce que le Gparted de la distribution ne mettait pas correctement à jour les partitions dans le noyau en cours d'exécution. Si vous utilisez le Gparted de la distribution, assurez-vous de redémarrer juste après avoir changé les partitions afin que la vue du noyau soit correcte.
Les instantanés sont difficiles à utiliser, lents et bogués. - si l'instantané n'a plus d'espace pré alloué, il est automatiquement abandonné . Chaque instantané d'un LV donné est un delta par rapport à ce LV (et non par rapport aux instantanés précédents), ce qui peut nécessiter beaucoup d'espace lors de l'instantanéisation de systèmes de fichiers avec une activité d'écriture importante (chaque instantané est plus grand que le précédent). Il est prudent de créer un instantané de LV de la même taille que le LV original, car l'instantané ne manquera jamais d'espace libre.
Les instantanés peuvent également être très lents (c'est-à-dire 3 à 6 fois plus lents que sans LVM pour ces tests MySQL ) - voir cette réponse couvrant divers problèmes d'instantanés . Cette lenteur s'explique en partie par les instantanés nécessitent de nombreuses écritures synchrones .
Les instantanés ont connu quelques bogues importants, par ex. dans certains cas ils peuvent rendre le démarrage très lent, voire le faire échouer complètement (parce que le système d'exploitation de l'entreprise ne fonctionne pas). le noyau peut s'arrêter attente du FS racine lorsqu'il s'agit d'un instantané LVM [corrigé dans Debian initramfs-tools mise à jour, mars 2015]).
Alternatives à Snapshot - systèmes de fichiers et hyperviseurs VM
Instantanés de VM/cloud :
Instantanés du système de fichiers :
Les instantanés au niveau du système de fichiers avec ZFS ou btrfs sont faciles à utiliser et généralement meilleurs que LVM, si vous êtes sur du métal nu (mais ZFS semble beaucoup plus mature, juste plus compliqué à installer) :
ZFS : il existe désormais un implémentation de ZFS dans le noyau ZFS, qui est utilisé depuis quelques années, et ZFS semble être de plus en plus adopté. Ubuntu propose désormais ZFS en tant qu'option "prête à l'emploi", y compris le ZFS expérimental à la racine. en 19.10 .
btrfs : toujours pas prêt pour une utilisation en production ( même sur openSUSE qui le fournit par défaut et dispose d'une équipe dédiée à btrfs), alors que RHEL a cessé de le prendre en charge). btrfs dispose désormais d'une fonction Outil fsck (FAQ) mais la FAQ vous recommande de consulter un développeur si vous avez besoin de fscker un système de fichiers cassé.
Snapshots pour les sauvegardes en ligne et fsck
Les instantanés peuvent être utilisés pour fournir une cohérence source pour les sauvegardes, tant que vous faites attention à l'espace alloué (idéalement, l'instantané est de la même taille que le LV sauvegardé). L'excellent rsnapshot (depuis la version 1.3.1) gère même la création/suppression des snapshots LVM pour vous - voir ceci HOWTO sur rsnapshot utilisant LVM . Toutefois, notez les problèmes généraux liés aux instantanés et le fait qu'un instantané ne doit pas être considéré comme une sauvegarde en soi.
Vous pouvez également utiliser les snapshots LVM pour faire un fsck en ligne : snapshot du LV et fsck du snapshot, tout en utilisant le FS principal non snapshot -. décrit ici - cependant, c'est pas tout à fait simple il est donc préférable d'utiliser e2croncheck comme décrit par Ted Ts'o , mainteneur de ext3.
Vous devez "geler" le système de fichiers temporairement pendant la prise de l'instantané - certains systèmes de fichiers tels que ext3 et XFS seront faire cela automatiquement lorsque LVM crée le snapshot.
Conclusions
Malgré tout, j'utilise encore LVM sur certains systèmes, mais pour une configuration de bureau, je préfère les partitions brutes. Le principal avantage que je vois à LVM est la flexibilité de déplacer et de redimensionner les FS. lorsque vous devez avoir un temps de disponibilité élevé sur un serveur. - si vous n'en avez pas besoin, gparted est plus simple et présente moins de risques de perte de données.
LVM nécessite une grande attention dans la configuration de la mise en cache en écriture en raison des hyperviseurs VM, de la mise en cache en écriture des disques durs / SSD, etc. mais la même chose s'applique à l'utilisation de Linux comme serveur de base de données. Le manque de support de la plupart des outils ( gparted y compris les calculs de la taille critique, et testdisk etc.) le rend plus difficile à utiliser qu'il ne devrait l'être.
Si vous utilisez LVM, faites très attention aux snapshots : utilisez des snapshots VM/cloud si possible, ou étudiez ZFS/btrfs pour éviter complètement LVM - vous trouverez peut-être que ZFS ou btrfs est suffisamment mature par rapport à LVM avec des snapshots.
En résumé : Si vous ne connaissez pas les problèmes énumérés ci-dessus et la façon de les résoudre, il vaut mieux ne pas utiliser LVM.
Le redimensionnement en ligne avec xfs fonctionne parfaitement, vous n'avez même pas besoin de spécifier la taille. Il grandira jusqu'à la taille du LV, en savoir plus dans xfs_grow(5). OTOH je frappe +1 pour le résumé sur les barrières d'écriture.
@RichVel afaik il n'y a pas de support pour le rétrécissement dans XFS. Au début, je pensais que c'était un gros problème, mais en réalité je n'en ai eu besoin que quelques fois.
Votre deuxième balle ne devrait-elle pas être activer avec batterie de secours ? Le point suivant est désactiver sans batterie. De plus, comme d'autres l'ont dit, très peu de systèmes de fichiers nécessitent de spécifier la taille pour l'opération de redimensionnement. La plupart le font automatiquement.
Bien que fournissant une fenêtre intéressante sur l'état de LVM il y a plus de 10 ans, la réponse acceptée est maintenant totalement obsolète. Moderne (c'est-à-dire : LVM post-2012) :
lvmthin
lvmcache et une politique d'écriture rapide pour NVMe/NVDIMM/Optane via dm-writecache
vdo ) grâce au soutien de lvmvdo
lvmraid
linux-lvm@redhat.com
Évidemment, cela ne signifie pas que vous devez toujours ont d'utiliser LVM - la règle d'or pour le stockage est d'éviter les couches inutiles. Par exemple, pour les machines virtuelles simples, vous pouvez certainement vous contenter d'une partition classique. Mais si vous attachez de l'importance à l'une des caractéristiques ci-dessus, LVM est un outil extrêmement utile qui devrait figurer dans la boîte à outils de tout administrateur système Linux sérieux.
J'ai [+1] ce post, et au moins pour moi, je pense que la plupart des problèmes existent. Je les ai vus en gérant quelques 100 serveurs et quelques 100TB de données. Pour moi, le LVM2 dans Linux ressemble à une "idée intelligente" que quelqu'un a eue. Comme certaines de ces idées, elles s'avèrent parfois "pas intelligentes". Par exemple, ne pas avoir de séparation stricte entre les états du noyau et de l'espace utilisateur (lvmtab) aurait pu sembler vraiment intelligent, car il peut y avoir des problèmes de corruption (si le code n'est pas correct).
Eh bien, juste que cette séparation était là pour une raison - Les différences apparaissent avec la gestion des pertes de PV, et la réactivation en ligne d'un VG avec par exemple des PV manquants pour les remettre en jeu - Ce qui est un jeu d'enfant sur les "LVM d'origine" (AIX, HP-UX) devient de la merde sur LVM2 car la gestion des états n'est pas assez bonne. Et je ne parle même pas de la détection de perte de quorum (haha) ou de la gestion des états (si je retire un disque, il ne sera pas signalé comme indisponible. Il n'est même pas ont la colonne de l'état de damn)
Re : stabilité pvmove ... pourquoi est-ce que
perte de données pvmove
un tel article en tête de liste sur mon blog, hmmm ? Je viens juste de regarder un disque où les données lvm physiques sont toujours accrochées à l'état de mid-pvmove. Il y a eu quelques memleaks je pense, et l'idée générale que c'est une bonne chose de copier autour des données de bloc en direct de l'espace utilisateur est juste triste. Une belle citation de la liste lvm : "il semble que vgreduce --missing ne gère pas les pvmove". Cela signifie en fait que si un disque se détache pendant un pvmove, l'outil de gestion de lvm passe de lvm à vi. Oh et il y a aussi eu un bug où pvmove continue après une erreur de lecture/écriture de bloc et en fait n'écrit plus de données sur le périphérique cible. WTF ?
Re : Instantanés Le CdC est fait de manière non sécurisée, en mettant à jour les NOUVELLES données dans la zone lv de l'instantané, puis en fusionnant à nouveau une fois que vous avez supprimé l'instantané. Cela signifie que vous avez des pics d'E/S importants pendant la fusion finale des nouvelles données dans le LV d'origine et, plus important encore, vous avez bien sûr un risque beaucoup plus élevé de corruption des données, car ce n'est pas le snapshot qui sera cassé une fois que vous aurez frappé le mur, mais l'original.
L'avantage se situe au niveau des performances, en effectuant 1 écriture au lieu de 3. Choisir l'algorithme rapide mais peu sûr est quelque chose que l'on attend évidemment de personnes comme VMware et MS, sur "Unix" je préférerais penser que les choses seraient "bien faites". Je n'ai pas vu beaucoup de problèmes de performance tant que j'ai le magasin de sauvegarde des instantanés sur un serveur de type différents que les données primaires (et la sauvegarde sur un autre disque bien sûr).
Re : Barrières Je ne suis pas sûr qu'on puisse mettre ça sur le dos de LVM. C'était un problème de devmapper, pour autant que je sache. Mais on peut lui reprocher de ne pas s'être vraiment préoccupé de ce problème depuis au moins le noyau 2.6 jusqu'à 2.6.33. AFAIK Xen est le seul hyperviseur qui utilise O_DIRECT pour les machines virtuelles, le problème était auparavant lorsque "loop" était utilisé parce que le noyau continuait à utiliser le cache. Virtualbox a au moins un paramètre pour désactiver ce genre de choses et Qemu/KVM semble généralement autoriser la mise en cache. Tous les FS FUSE ont également des problèmes à ce niveau (pas de O_DIRECT).
Re : Tailles Je pense que LVM fait un "arrondi" de la taille affichée. Ou bien il utilise des GiB. Quoi qu'il en soit, vous devez utiliser la taille Pe du VG et la multiplier par le numéro LE du LV. Cela devrait donner la taille nette correcte, et ce problème est toujours un problème d'utilisation. Il est aggravé par les systèmes de fichiers qui ne remarquent pas une telle chose pendant le fsck/mount (bonjour, ext3) ou qui n'ont pas de "fsck -n" fonctionnel en ligne (bonjour, ext3).
Bien sûr, c'est révélateur que vous ne puissiez pas trouver de bonnes sources pour de telles informations. "combien de LE pour le VRA ?" "quel est le décalage phyisque pour le PVRA, VGDA, ... etc"
Par rapport à l'original, LVM2 est le parfait exemple de "Ceux qui ne comprennent pas UNIX sont condamnés à le réinventer, pauvrement".
Mise à jour quelques mois plus tard : Je me suis heurté au scénario "snapshot plein" pour un test maintenant. S'ils sont pleins, le snapshot se bloque, pas le LV original. J'avais tort quand j'ai d'abord posté ceci. J'ai pris de mauvaises informations dans un document, ou peut-être que je l'avais compris. Dans mes configurations, j'ai toujours été très paranoïaque pour ne pas les laisser se remplir et donc je n'ai jamais fini de corriger. Il est également possible d'étendre/réduire les snapshots, ce qui est un plaisir.
Ce que je n'ai toujours pas réussi à résoudre, c'est comment identifier l'âge d'un instantané. En ce qui concerne leurs performances, il y a une note sur la page du projet fedora "thinp" qui dit que la technique d'instantané est en cours de révision afin qu'ils ne deviennent pas plus lents à chaque instantané. Je ne sais pas comment ils l'implémentent.
De bons points, en particulier sur la perte de données de pvmove (je n'avais pas réalisé que cela pouvait planter en cas de faible mémoire) et la conception des instantanés. En ce qui concerne les barrières d'écriture et la mise en cache, je confondais LVM et le mappeur de périphériques du noyau, car du point de vue de l'utilisateur, ils travaillent ensemble pour fournir ce que LVM fournit. Upvoted. J'ai également apprécié votre article sur la perte de données de pvmove : deranfangvomende.wordpress.com/2009/12/28/
Sur les instantanés : ils sont notoirement lents dans LVM, donc il est clair que ce n'était pas une bonne décision de conception d'aller pour la performance sur la fiabilité. Par "frapper le mur", voulez-vous dire que l'instantané se remplit, et cela peut-il vraiment causer la corruption des données LV originales ? Le HOWTO de LVM indique que l'instantané est abandonné dans ce cas : tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html
"Le CdC est fait de manière non sécuritaire, en mettant à jour les NOUVELLES données dans la zone lv instantanée et en fusionnant à nouveau une fois que vous avez supprimé l'instantané." C'est tout simplement faux. Lorsque de nouvelles données sont écrites sur le périphérique original, le vieux est écrite dans la zone COW des instantanés. Aucune donnée n'est jamais fusionnée en retour (sauf si vous le souhaitez). Voir kernel.org/doc/Documentation/device-mapper/snapshot.txt pour tous les détails techniques gores.
Si vous prévoyez d'utiliser des instantanés pour les sauvegardes, préparez-vous à une impact majeur sur les performances lorsque le snapshot est présent . sinon tout va bien. J'utilise lvm en production depuis quelques années sur des dizaines de serveurs, bien que ma principale raison de l'utiliser soit le snapshot atomique et non la possibilité d'étendre facilement les volumes.
BTW si vous allez utiliser un disque de 1TB, n'oubliez pas l'alignement des partitions - ce disque a très probablement des secteurs physiques de 4kB.
D'après mon expérience, les disques de 1 To utilisent généralement des secteurs de 512 octets, mais la plupart des disques de 2 To utilisent des secteurs de 4 Ko.
@DanPritts il n'y a pas de mal à supposer que la taille du secteur est de 4kB ou même 128kB - juste au cas où il y aurait un raid entre les deux. vous perdez si peu - peut-être que 128kB et vous pouvez gagner beaucoup. aussi lors de l'imagerie de l'ancien disque vers un nouveau.
Adam,
Autre avantage : vous pouvez ajouter un nouveau volume physique (PV), déplacer toutes les données vers ce PV, puis supprimer l'ancien PV sans aucune interruption de service. J'ai utilisé cette possibilité au moins quatre fois au cours des cinq dernières années.
Un inconvénient que je n'ai pas encore vu clairement mis en évidence : Il y a une courbe d'apprentissage assez raide pour LVM2. Principalement dans l'abstraction qu'il crée entre vos fichiers et le support sous-jacent. Si vous travaillez avec quelques personnes qui se partagent les tâches sur un ensemble de serveurs, vous pouvez trouver la complexité supplémentaire écrasante pour votre équipe dans son ensemble. Les équipes plus importantes dédiées au travail informatique n'auront généralement pas ce problème.
Par exemple, nous l'utilisons beaucoup à mon travail et nous avons pris le temps d'enseigner à toute l'équipe les bases, le langage et les éléments essentiels de la récupération des systèmes qui ne démarrent pas correctement.
Une mise en garde s'impose : si vous démarrez à partir d'un volume logique LVM2, les opérations de récupération seront difficiles en cas de panne du serveur. Knoppix et ses amis n'ont pas toujours ce qu'il faut pour cela. Nous avons donc décidé que notre répertoire /boot serait sur sa propre partition et qu'il serait toujours petit et natif.
Globalement, je suis un fan de LVM2.
GRUB2 supporte le démarrage à partir d'un volume logique LVM (cf. wiki.archlinux.org/index.php/GRUB2#LVM ) mais pas GRUB1. J'utiliserais toujours un /boot séparé non-LVM pour m'assurer qu'il est facile à récupérer. La plupart des disques de secours de nos jours prennent en charge LVM - certains requièrent un processus manuel d'installation. vgchange -ay pour trouver les volumes LVM.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
24 votes
Lorsque vous lisez les réponses à cette question, gardez à l'esprit la date (année) à laquelle elles ont été publiées. Il se passe beaucoup de choses en trois ans dans ce secteur.
2 votes
J'ai fait quelques mises à jour récemment (avril 2015) en les parcourant pour voir si quelque chose a changé. Le noyau 2.6 est maintenant obsolète, les SSD sont plus courants, mais à part quelques petites corrections LVM, pas grand-chose n'a vraiment changé. J'ai écrit quelques nouvelles choses sur l'utilisation des instantanés de VM / serveur cloud au lieu des instantanés LVM. L'état de la mise en cache en écriture, le redimensionnement du système de fichiers et les instantanés LVM n'ont pas vraiment changé pour autant que je puisse voir.
1 votes
En ce qui concerne le commentaire "gardez à l'esprit la date", c'est assez vrai, mais considérez également que beaucoup d'"entreprises" utilisent encore RHEL 5 et RHEL 6, qui sont tous deux à la pointe ou plus anciens que la date de la réponse.