Modifier un volume EBS à chaud, c’est possible ?


Après avoir traité le cas Amazon S3, et Amazon RDS, Osones vous propose de comprendre les EBS à travers un cas concret : comment modifier un volume EBS à chaud ?
Vous pouvez à tout moment retrouver ces informations sur la page produit Amazon EBS (fr).


Qu'est-ce qu'Amazon EBS ?


Qu'est-ce qu'Amazon RDS

Les instances Amazon EC2 proposent du stockage local (“instance store” en anglais), permettant de stocker des données rapidement accessibles par l’instance. Ce stockage local est cependant limité :

Ce stockage est exclusif à l’instance EC2 dont il dépend. Les données ne seront pas réparties sur la totalité des instances qui constituent vos groupes d’autoscaling. Il est donc fortement déconseillé d’y stocker des données utilisateurs (sessions par exemple). Ce stockage est éphémère : il sera irrémédiablement supprimé si l’instance EC2 venait à disparaitre, volontairement ou sous l’effet de l’auto-scaling.

Il existe donc une autre solution de stockage sur Amazon Web Services : Amazon Elastic Block Store (EBS). Amazon EBS fournit des volumes de stockage en mode bloc, qui s'utilise avec les instances Amazon EC2.


Amazon S3 vs EBS vs Instance Store

Chaque volume Amazon EBS est automatiquement répliqué au sein de sa zone de disponibilité, ce qui garanti une disponibilité et une durabilité élevées. Ils sont conçu pour être disponible 99,999 % du temps.
Il existe différents types de volumes EBS, les volumes SSD ainsi que les volumes HDD.


Disques SSD :

SSD gp2 : general purpose.

Volume SSD à usage général offrant un bon rapport prix/performances pour un large éventail d’application :

Volume SSD Type SSD à usage général (gp2) Type SSD provisionnés (io1)
Nom d’API GP2 Io1
Taille / Nombre E/S 1 Go - 16 T / 10 000 iops / max 4 Go - 16 T / 20 000 iops max
Débit Max 1,250 Mo/s 1,250 Mo/s


Disque HDD :

Disques magnétiques, conçus pour des charges de travail moins importantes, ils sont aussi moins coûteux.

HDD à débit optimisé (st1) :

Volume HDD économique conçu pour les charges de travail à débit élevé fréquemment consultées

Cold HDD (sc1) :

Volume HDD le plus abordable, conçu pour les charges de travail moins importantes

Volume HDD HDD à débit optimisé (st1) Cold HDD (sc1)
Nom d’API st1 sc1
Taille / Nombre E/S 500 Go - 16 T / 500 iops max 500 Go - 16 T / 250 iops max


Les Snapshots EBS :

Il est possible de sauvegarder les données d’un volume EBS via ce que l’on appelle des snapshot. Ce type de sauvegarde est incrémental et les données sauvegardées via snapshot sont ensuite stockées en utilisant la technologie d’Amazon S3.

C’est un moyen fiable de sauvegarder ses données, mais aussi d’augmenter la taille d’un volume, pour cela il suffit d’effectuer un snapshot, et de créer un volume EBS de taille supérieure avec ce même snapsho


Et les "Elastic volumes" dans tout ça ?

Annoncé le 13 Février 2017, Les Elastic Volume permettent d'augmenter la taille d'un volume, ajuster les performances ou même modifier le type d’un volume en cours d'utilisation. Dans les fait la manipulation semble très simple, mais qu’en est-il en réalité ? (en fait c’est vraiment simple)

Nous allons tester sur un volume root, en passant d’un SSD gp2 de 8Go à un volume de 20 Go. Attention, il faut attendre 6h entre chaque modification d’un volume. En quelques clics le volume passe en statut “optimizing”, puis “Okay”, mais que se passe t-il au niveau d'une instance sous ubuntu 16.04 ?

Le filesystem malgré la modification que nous venons d’apporter continue d’afficher un volume de 7,8GiB:

~$ df -h

Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1      7.8G  946M  6.5G  13% /

Après un lsblk :

NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  20G  0 disk 
└─xvda1 202:1    0   8G  0 part /

On voit bien un volume /dev/xvda de 20Go mais le volume /dev/xvda où est notre OS nous affiche 8go d’espace. Deux solutions s’offrent alors à nous, un bon vieux reboot de l’instance, (qui n’est pas toujours possible), ou l’utilisation de parted.


Le reboot : Suite à un reboot, le changement est effectif, cela est dû a cloud-init, qui détecte les changements de taille du volume, le changement est donc pris en compte automatiquement.

~$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  20G  0 disk 
└─xvda1 202:1    0   20G  0 part


Avec parted :

Parted fonctionne de manière interactive, mais notre partition étant utilisée, notre commande ne fonctionnera pas. Il faut utiliser parted en ignorant le mode interactif, grâce à la directive ---pretend-input-tty

-$ /sbin/parted ---pretend-input-tty /dev/xvda1 resizepart 1 yes 100%

Warning: Partition /dev/xvda1 is being used. Are you sure you want to continue?
Information: You may need to update /etc/fstab.


Puis nous utilisons resize2fs:

~$ sudo resize2fs /dev/xvda1
Filesystem at /dev/xvda1 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
The filesystem on /dev/xvda1 is now 5240871 (4k) blocks long.

~$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  20G  0 disk 
└─xvda1 202:1    0  20G  0 part /

Le volume est alors à 20Go.

La discussion continue !

Nous attendons vos questions, remarques & mots doux sur notre Twitter :