Dois-je créer une partition sur un volume EBS? Qu’est-ce qui est mieux?

J’ajoute un nouveau volume EBS à un serveur Ubuntu existant sur AWS EC2.

J’ai créé le volume et il est attaché au serveur, je peux le voir là-bas, tout va bien.

Quels sont les bonus de la création d’une partition sur le volume (je vais donc l’utiliser comme “/ dev / xvdf1”) contre son utilisation telle quelle (“/ dev / xvdf”), en créant le système de fichiers directement sur le volume ?

Pour moi, dans EC2, il n’a vraiment de sens que d’utiliser le volume entier pour le système de fichiers, en raison de la flexibilité offerte par les volumes Elastic Block Store (EBS), qui sont très différents de nombreux disques physiques, en ce sens au besoin, détruisez-les au besoin, attachez-les et détachez-les des instances sans redémarrer, prenez des instantanés et clonez-les sans utiliser le processeur, la mémoire ou les E / S de l’instance. Et, sans table de partition, redimensionner lorsque vous avez besoin de plus d’espace est un gâteau.

Besoin d’un plus gros système de fichiers? Si vous utilisez la totalité du volume sans table de partition, c’est très simple.

Créez un instantané EBS du volume à l’aide de la console AWS, le volume toujours monté et en cours d’utilisation. Vous n’utiliserez pas réellement cet instantané, mais croyez-moi un instant. Si vous avez récemment créé un instantané du volume et que vous l’avez toujours, vous pouvez ignorer cette étape, car l’objective est d’accélérer le rest des étapes.

Démontez le volume.

Prenez un deuxième instantané. C’est celui que tu veux. Nous avons créé le précédent car cela rendra cet instantané beaucoup plus rapidement. Lorsque EBS prend un instantané, il enregistre le contenu du disque dans un référentiel masqué sur S3. Pour chaque capture instantanée consécutive du même volume, seuls les blocs modifiés doivent être stockés. Cette capture instantanée est donc généralement construite avec des pointeurs stockés vers l’emplacement de toutes les données déjà capturées et seuls les blocs modifiés sont sauvegardés physiquement. up.

Créez un nouveau volume en utilisant le dernier instantané.

Attachez le nouveau volume à l’instance à la place de l’ancien et montez-le. Vérifiez les données si nécessaire.

Ensuite, vous pouvez utiliser resize2fs pour développer le système de fichiers afin de remplir la taille disponible sur le nouveau volume, pendant l’utilisation du volume.

Supprimez ensuite le premier instantané ci-dessus. EBS “annulera” tout ce qu’il contient et qui est également nécessaire pour l’instantané final, de sorte que l’instantané final est toujours valide.

sudo dd if=/dev/xvdx of=/dev/null bs=1M , vous pouvez souhaiter réchauffer le nouveau volume à l’aide de sudo dd if=/dev/xvdx of=/dev/null bs=1M . Lorsqu’un volume est créé à partir d’un instantané, le contenu du volume est chargé “paresseusement” de l’instantané sur le volume réel, ce qui signifie que le volume devient entièrement disponible avant que ses performances ne soient optimales. Si vous demandez quelque chose du volume qui n’a pas encore été chargé par le processus d’arrière-plan, vous l’obtiendrez toujours presque immédiatement, mais pas aussi rapidement que si le processus d’arrière-plan avait tout chargé. L’opération dd ci-dessus effectue une lecture physique de l’ensemble du volume, le rendant ainsi disponible avec le temps de latence le plus faible possible, plus rapidement qu’il ne le pourrait autrement. Ceci est documenté comme quelque chose qui devrait être fait avec le volume non monté, mais que vous le fassiez avant ou après le redimensionnement n’a pas une grande importance. Les différentes saveurs des volumes EBS de préchauffage sont décrites à l’ adresse http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-prewarm.html

Pour moi, utiliser tout le volume du système de fichiers, sans table de partition, semble être la seule solution, car cela minimise les temps d’arrêt et les risques d’erreur. Tous mes volumes EBS (et éphémères, d’ailleurs) sont réalisés de cette façon, à l’exception de certains très anciens.

Vous pouvez, bien sûr, utiliser fdisk ou partitioned pour créer et modifier la table de partition de la manière habituelle, mais – à mon avis – cela ajoute inutilement des “pièces mobiles” supplémentaires … ce qui se traduit généralement par davantage d’erreurs .

Si vous savez comment faire fonctionner le serveur X de votre machine locale et accepter les connexions entrantes de l’instance EC2 afin d’afficher localement la sortie de l’interface graphique, vous pouvez également utiliser facilement l’outil graphique gparted sur les instances EC2, l’interface graphique étant affichée à l’écran. votre écran de poste de travail local – oui, cela fonctionne, je l’ai fait -, mais cela fonctionne en dehors du champ de cette question.