Comment puis-je augmenter la taille du volume EBS d’une instance en cours d’exécution?

J’ai un serveur exécutant les AMI Ubuntu récentes de Canonical. La taille du volume de démarrage EBS est de 8 Go. Je sais que je peux redimensionner les volumes EBS en prenant un instantané, en créant un nouveau volume et en étendant la partition sur celui-ci. Comment puis-je augmenter la taille du volume lorsque la machine est en marche? Si ce n’est pas possible, quelle est la méthode préférée pour augmenter la taille du volume de démarrage avec un temps d’arrêt minimal?

Malheureusement, il n’est pas possible d’augmenter la taille d’un volume de stockage d’un périphérique racine Amazon EBS lorsque l’instance Amazon EC2 est en cours d’exécution – Eric Hammond a écrit un article détaillé (je suis enclin à dire «canonique») sur le redimensionnement du disque racine sur une instance E2 Boot EC2 en cours d’exécution :

Tant que vous avez un peu de temps d’arrêt sur l’instance EC2 (quelques minutes), il est possible de changer le volume EBS racine avec une copie plus grande, sans avoir à démarrer une nouvelle instance.

Si vous préparez correctement les étapes qu’il décrit (je vous recommande fortement de les tester avec une instance EC2 jetable pour vous familiariser avec la procédure), vous devriez être en mesure de terminer le processus avec quelques minutes d’arrêt.

Bonne chance!

Nous pouvons augmenter la taille du volume avec les nouveaux volumes EBS Feature Elastic, et signaler que nous devons suivre les étapes suivantes pour utiliser la taille d’augmentation, comme indiqué ici.

Supposons que votre volume était de 16 Go et que vous l’augmentiez à 32 Go.

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

Pour étendre xvda1 de 16 Go à 32 Go, nous avons besoin de growpart. growpart est disponible dans le cadre de cloudutils

 sudo apt install cloud-utils 

Après l’installation de cloud-utils, exécutez la commande growpart

 sudo growpart /dev/xvda 1 

Maintenant, lsblk, montrera

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

mais df -h affichera seulement 16 Go

La commande finale pour l’extension de xvda1 à 32 Go est

 sudo resize2fs /dev/xvda1 

Une réponse tardive à cette question de 5 ans

AWS vient d’annoncer une nouvelle fonctionnalité EBS appelée Elastic Volumes , qui vous permet d’augmenter la taille du volume, d’ajuster les performances ou de modifier le type de volume lorsque le volume est utilisé.

Vous pouvez en savoir plus sur le blog AWS ici .

Vous devez d’abord créer son instantané et à partir de ce snapshot, créer un autre volume et, une fois le nouveau volume prêt, détacher l’ancien volume de l’instance et attacher le nouveau volume. Assurez-vous d’arrêter l’instance avant de lancer ce processus et de redémarrer l’instance une fois celle-ci terminée.

Voir http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-expand-volume.html

Cela fonctionnera pour le système de fichiers xfs juste lancer cette commande xfs_growfs /

J’ai constaté qu’en essayant d’augmenter la partition racine / dev / sda1 qui était signalée sous la forme / dev / xvda1 sur centos6, je ne pouvais pas démonter le volume pour étendre la partition.

J’ai contourné cela en montant mon volume original sous / dev / sda1 et mon instantané sous la forme / dev / sdb. J’ai ensuite redémarré l’image et redimensionné la partition / dev / sdb1 en utilisant parted.

Une fois que la partition / dev / sdb1 a été redimensionnée, j’ai détaché les deux volumes et attaché le nouveau volume à / dev / sda1 et exécuté resize2fs / dev / xvda1.

Tu ne peux pas faire ça. Mais si vous êtes plus concentré sur les temps d’arrêt, vous pouvez peut-être cloner votre instance principale, monter un périphérique de stockage EBS plus grand sur votre système, copier les données puis redirect le trafic vers votre nouvelle instance.

Si vous le souhaitez, une méthode que j’utilise récemment, S3, dispose d’un moyen de sauvegarde et de déploiement sur d’autres systèmes. Ainsi, par exemple, votre système existant exécute un script pour charger vos données dans s3 toutes les N minutes / heures / jours, puis rédige un script à utiliser lors du lancement de nouvelles instances pour télécharger ces données. Si vos données ne sont pas constamment mises à jour, cela devrait fonctionner (pour moi, je les utilise pour dissortingbuer la version mise à jour de mon code alors que les données sont gérées sur un serveur de firebase database ec2).

J’espère que cela pourra aider.