EBS et LVM2 ou comment optimiser l’élasticité des AWS

Le stockage de données en lui même n’est plus réellement un problème de nos jours. Nous pouvons facilement trouver des solutions qui permettent, selon les moyens techniques et financiers, de stocker un grand nombre de données. De son côté, Amazon, avec ses AWS, propose une solution « In the Cloud » permettant de créer un disque réseau de la taille désirée et de le raccrocher à une instance virtuelle. Cette solution, nommée EBS (Elastic Block Store), permet de créer à la volée des disques qui peuvent être attachés à chaud à une instance EC2 (Elastic Compute Cloud). Bien évidemment le coût financier de ce service est fonction de l’espace alloué. Trois solutions s’offrent alors à nous :

  • Allocation surestimée d’un disque permettant en théorie de subvenir aux besoins futurs du système ce qui occasionne un surcoût.
  • Allocation d’un disque pour assurer la pérennité à court ou moyen terme puis migration des données sur un disque plus grand quand le premier sera trop petit. Cette solution va demander un coût élevé en termes de maintenance et d’indisponibilité du système.
  • Utilisation de LVM2 (Logical Volume Manager, version 2) pour la gestion des disques. Elle permet de lisser l’augmentation de la quantité d’espace alloué en ajoutant des disques au fur et à mesure des besoins tout en assurant un minimum d’indisponibilité.

Principe de fonctionnement
L’unité de base est le volume physique représenté par un disque (PV : Physical Volume). Un ou plusieurs PV sont nécessaires pour construire un VG (Volume Group). Cette entité va donc fédérer les PV pour mettre leur espace en commun et le rendre disponible pour créer un ou des LV (Logical Volume). C’est le LV qui sera formaté et utilisé comme un disque standard.

Logical Volume Management

Logical Volume Management

Monter un système LVM2
LVM2 est relativement simple à exploiter. Quand on dispose d’un disque physique attaché au système et accessible via les devices habituels (/dev/hdx ou /dev/sdx), il est simple d’ajouter ce disque à un système LVM ou de créer celui-ci.
LVM2 dispose de 3 niveaux de commandes :

  • Les commandes destinées à la partie devices physiques qui sont préfixées par « pv » (pvcreate, pvscan, pvs, pvdisplay, pvremove, pvmove, pvchange).
  • Les commandes destinées à gérer les « volume group » qui sont préfixées par « vg » (vgcreate, vgdisplay, vgscan, vgs, vgck, vgremove, vgchange, vgimport, vgexport).
  • Les commandes destinées à gérer les « logical volume » qui sont préfixées par « lv » (lvcreate, lvmdiskscan, lvs, lvdisplay, lvremove, lvextend).

De plus, il existe une commande de bas niveau, dmsetup, prévue pour la gestion de LVM2, mais elle est réservée aux cas exceptionnels (récupération de données après un crash très grave du système LVM, par exemple).

Pour créer un système LVM2 il suffit d’ajouter un disque physique à la liste des devices utilisables par LVM2 avec la commande « pvcreate » :

pvcreate /dev/sdd

Une fois le device connu par LVM2, on peut le rattacher à un volume group ou créer un nouveau volume group (un système peut comporter plusieurs volume groups) :

vgcreate vg_exemple /dev/sdd (pour la création d’un VG)

vgextend vg_exemple /dev/sde (pour l’ajout d’un PV à un VG existant du nom de « vg_exemple »)

Cette opération a permis d’ajouter des Physical Extents (PE) au VG. Ces PE sont des blocs d’espace disque : le PE est l’unité de calcul de LVM, exprimé en Ko. Une fois cette opération réalisée nous disposons donc d’un VG avec de l’espace supplémentaire que nous pouvons, à loisir, destiner à la création d’un nouveau LV ou à l’augmentation de la taille d’un LV ou aux deux en même temps :

lvcreate -l 10230 vg_exemple -n lv_exemple (va créer une LV du nom de « lv_exemple » sur le VG « vg_exemple ».

Il ne reste plus qu’à formater le LV (ext3, xfs, …). Il faut cependant faire attention au type de Filesystem que l’on y place. Tous les Filesystems ont leurs spécificités et leurs contraintes, certain n’acceptent pas le redimensionnement à la volée, d’autres n’accepteront tout simplement pas la diminution de taille.

Remarque : Il est possible de monter un système Linux bootable sur un volume LVM mais cette opération est délicate et relativement dangereuse à réaliser.

Elasticité et souplesse de la solution
Une fois que nous disposons d’un système comportant LVM2 il est possible ensuite d’ajouter des disques, d’en retirer, de faire migrer les données d’un disque à un autre ou de répartir les données d’un disque vers la place libre du VG dont il fait parti. Toutes ces opérations se font sans stopper les traitements en cours sur un disque (copies de fichiers, base de données… etc). Il est à noter que certaines opérations peuvent avoir un léger impact sur les performances pendant leur déroulement (migration de données). Mais ces opérations sont relativement rapides et ne causeront donc que peu de dérangement.
Seule les opérations d’augmentation et, à fortiori, de réduction de la taille d’un Filesystem peut nécessiter l’arrêt des traitements sur un LV. Cependant, le redimensionnement d’un Filesystem est une opération rapide qui ne dure en général jamais plus que quelques dizaines de secondes.

Fonctionnalités avancées
LVM2 ne s’arrête pas là. Il dispose de fonctionnalités qui vont nous faciliter la vie.

Snapshot
Le Snapshot est un volume logique permettant de prendre une photo à un instant ‘t’ d’un autre volume logique du même volume groupe. Cette photo permettra de travailler sur des données qui ne bougent pas (ex: sauvegarde). De plus le Snapshot ne nécessite pas autant de place que le volume d’origine. On peut considérer qu’il faut réserver 15% de la taille du volume pour un Snapshot. Ces 15% sont destiné à absorber les modifications effectuées sur le volume d’origine ce qui permet de figer le Snapshot. Mais ces 15% ne sont qu’une estimation et il faut adapter cette taille à la quantité prévisible de données écrites pendant l’utilisation du Snapshot.
La principale limite du Snapshot est sa volatilité. Il n’existera plus après un reboot de l’OS.

Striping
Le principe du striping LVM2, à l’instar de RAID0, est de répartir les écritures d’un volume logique sur plusieurs volumes physiques. A la création du volume logique nous devons spécifier le nombre d’unités physiques à utiliser (unités présentes dans le VG). Cette technique permet d’améliorer les performances mais rend LVM plus sensible aux pannes d’un disque. En ce qui concerne les pannes, nous pouvons nous appuyer sur la robustesse des EBS (qui assure la durabilité des données via RAID1) pour garantir un maximum de sécurité à ce sujet.

Mirroring
Tout comme en RAID1, LVM2 propose une solution de mirroring. Ce mirroring s’effectue entre deux VG distincts (donc des disques physiques séparés). Il permet d’ajouter un niveau de sécurité supplémentaire au système LVM2.

LVM2 hors du nuage
Les avantages de LVM2 sont également appréciables dans une infrastructure physique. Dans ce cas, les volumes physiques peuvent être de différentes formes. Nous pouvons aussi bien avoir des disques physiques de différentes technologies que des disques réseau (LUNs dans un SAN, …). La solution de mirroring de LVM2 est appréciable quand le RAID1 n’est pas applicable entre deux unités de stockage.

Conclusion
Vous l’aurez compris, le couple EBS/LVM2 est parfait pour permettre une maitrise au plus juste de la quantité d’espace à allouer et ainsi de mieux maitriser les coûts. Mais ce couple va plus loin en proposant une souplesse d’utilisation et une sécurité en termes de manipulation des unités de stockage. Il offre de plus des fonctionnalités permettant d’améliorer les performances.

Laurent ROUX

9 commentaires pour EBS et LVM2 ou comment optimiser l’élasticité des AWS

  • Merci pour cet article très intéressant !

    Pour rebondir sur ce qui a été dit :

    le redimensionnement d’un Filesystem est une opération rapide qui ne dure en général jamais plus que quelques dizaines de secondes

    Effectivement, c’est une différence notable de fonctionnement par rapport à l’utilisation d’EBS seuls : dans le cadre d’une production sur des EBS de plusieurs dizaine de Go, si l’on souhaite redimensionner un EBS sans utiliser LVM, il faut arrêter la production pour figer les données, effectuer un snapshot de l’EBS, recréer une nouvel EBS plus grand à partir du snapshot, puis, après avoir attaché le nouvel EBS, effectuer un « resize » du filesystem. L’opération de « resize » commune aux 2 méthodes est effectivement rapide et ne dure que quelques dizaines de secondes. En revanche, le snapshot d’un EBS de plusieurs dizaines de Go prend un temps certain (jusqu’à plusieurs dizaines de minutes).

    L’utilisation de LVM est donc très importante en termes de disponibilité.

    Il est même possible de ne pas arrêter du tout la production sur le « resize » du filesystem (dans le cas de ext3) après attribution de ressources au LV (augmentation du nombre de LE, Logical Extent) : je préfère cependant un arrêt de quelques secondes pour garantir l’intégrité des données.

    Mais ces 15% ne sont qu’une estimation et il faut adapter cette taille à la quantité prévisible de données écrites pendant l’utilisation du Snapshot

    Concernant le snapshot, il s’agit d’un snapshot différentiel, c’est à dire que ce n’est pas la taille du volume d’origine qui compte, mais son taux de modification.

    Il est à noter pour finir que l’on peut attacher un nombre donné d’EBS à un EC2 : 11 au maximum, à cause de la limitation du nombre d’emplacements libres pour les devices (/dev/sdx).

    A bientôt !

  • Tiens marrant je viens de monter un LVM composé d’une grappe RAID5 de 5 EBS de 250Go. Je prend le raid pour la stabilité et répartir les écritures.Si un des EBS répond trop lentement, j’ai vue des cas à 1s par I/O, j’espere que l’EBS sera déclarer fault par le Raid qui restera stable en incorporant le disque de spare.

    Si j’agrandi mon LV je le fais avec une grappe RAID5 de même taille, mais ceci n’a rien d’obligatoire.

    Karles

  • Salut Karles !

    Alors ça a fonctionné ? Le disque de spare a pris le relai (enfin si tu as rencontré à nouveau le problème de latence EBS) ?

    Ca m’intéresse ! En tout cas bonne idée !

    Dans le cas où le disque de spare a bien pris le relai, tu n’as pas été impacté par la latence due à la reconstruction du disque ?

    Fred

  • Bon et bien il me semble que c’était une mauvaise idée. si un EBS ralenti le raid reste hyper stable et c’est toute la grappe qui devient lente. Les performances ce dégrade au niveau du maillont le plus faible. Visiblement la dégradation d’un EBS n’est jamais suffisamment critique pour que le RAID éjecte le disque.

    Karles

  • Laurent Roux

    Effectivement c’était le risque. Comme toujours il y a un alignement sur le maillon le plus faible de la chaine.

  • [...] of modification is what counts. You can find further information on LVM2 and EBS by consulting this very good article (in French) by Laurent [...]

  • frdt

    Bonjour
    je lis avec intérêt ce blog..
    disposant d’un EC2 sur ext3 .. puis tout migrer a la volée vers un système LVM2 ?

  • Bonjour,

    Pourriez-vous préciser votre question ?

    Frédéric FAURE

  • Laurent Roux

    Bonjour frdt,
    En fait il suffit de monter de nouveaux EBS et de les gérer avec LVM2. Ensuite transférer la donnée et modifier les accès à ces fichiers (via sym links par exemple).
    Ne pas oublier d’installer les bons packages :)
    Un conseil, ne pas essayer de mettre la partition / sous LVM2, il n’y a pas grande utilité pour un serveur sur EC2.

Répondre

 

 

 

Vous pouvez utiliser ces balises HTML

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>