Verkleinerung des Amazon EBS-Volumes

Ich habe diese Antwort für wachsende EBS-Volumina gesehen , aber ich möchte eine davon verkleinern.

Die Standard-Ubuntu-Server-Images sind 15 GB, während ich wirklich nur maximal 2 GB benötige (ich verwende ein anderes Volume für Daten). Gibt es eine Möglichkeit, die Größe des Volumens zu verkleinern?

Ich hatte die gleiche Frage wie Sie, also habe ich herausgefunden, wie es geht.

Zuerst habe ich dies mit dem 32-Bit-EBS-gestützten Ubuntu-Ami aus der Region USA-Ost gemacht. Andere Betriebssysteme oder Images funktionieren möglicherweise anders. Ich vermute jedoch, dass Sie in Ordnung sein sollten, solange Sie ein ext * -Dateisystem verwenden. Es könnte auf anderen Dateisystemen funktionieren, aber Sie müssen selbst herausfinden, wie Sie die Größe ändern können.

Die Schritte sind im Grunde:

1. Hängen Sie zwei Volumes an eine ausgeführte Instanz an. Das erste basiert auf dem zu verkleinernden Snapshot und das zweite auf einem leeren Volume mit der neuen Größe, auf die Sie verkleinern möchten.

2. Überprüfen Sie das Dateisystem des ersten Volumes und beheben Sie alle Fehler.

3. Verkleinern Sie das Dateisystem auf dem ersten Volume, sodass es nur so groß ist, wie es für die Speicherung der Daten erforderlich ist.

4. Kopieren Sie das Dateisystem vom ersten auf den zweiten Datenträger.

5. Erweitern Sie das Dateisystem auf dem zweiten Volume auf seine maximale Größe.

6. Stellen Sie sicher, dass alles gut aussieht, indem Sie das zweite Volume auf Fehler überprüfen.

7. Machen Sie einen Schnappschuss des zweiten Volumens.

8. Erstellen Sie ein Maschinen-Image basierend auf dem Schnappschuss des zweiten Volumes, das Sie gerade aufgenommen haben.

Sie müssen zuerst einige Informationen von dem Ami erhalten, den Sie verkleinern möchten. Insbesondere benötigen Sie die Kernel-ID und ggf. die Ramdisk-ID (das von mir geschrumpfte Image hatte keine Ramdisk). Alle diese Informationen sollten über die aws-Verwaltungskonsole im AMI-Fenster verfügbar sein.

Die Kernel-ID sieht aus wie kia-xxxxxxxx, und die Snapshot-ID sieht aus wie snap-xxxxxxxx, und Ramdisk-IDs sehen aus wie RIA-xxxxxxxx.

Starten Sie als Nächstes eine Linux-Instanz. Ich habe eine Ubuntu-Instanz gestartet. Sie können eine Instanz von t1.micro verwenden, wenn Sie möchten. Es braucht nicht viel Kraft, um diese nächsten Schritte auszuführen.

Fügen Sie nach dem Start des Computers den Schnappschuss an, den Sie vom ersten Schritt an notiert haben. In meinem Fall habe ich es an / dev / sdf angehängt

Erstellen Sie dann ein neues Volume mit der gewünschten Größe. In meinem Fall habe ich ein 5-GB-Volume erstellt, da dies die Größe ist, auf die ich es verkleinern wollte. Erstellen Sie dieses neue Volume nicht aus einem Snapshot. Wir brauchen ein neues leeres Volume. Als nächstes hängen Sie es an die laufende Instanz an. In meinem Fall habe ich es als / dev / sdg angehängt

Als nächstes ssh in den Rechner, aber mounten Sie die angehängten Volumes nicht.

Zu diesem Zeitpunkt habe ich mich auf der Seite der Paranoia geirrt und mich dafür entschieden, das Dateisystem auf dem großen Datenträger zu überprüfen, um sicherzustellen, dass keine Fehler aufgetreten sind. Wenn Sie sicher sind, dass es keine gibt, können Sie diesen Schritt überspringen:

$ sudo e2fsck -f /dev/sdf

Als Nächstes habe ich das Dateisystem auf dem großen Volume so angepasst, dass es nur so groß ist wie die Daten auf der Festplatte:

$ sudo resize2fs -M -p /dev/sdf

Das -M verkleinert es und das -p gibt den Fortschritt aus.

Das resize2fs sollte Ihnen sagen, wie groß das verkleinerte Dateisystem ist. In meinem Fall gab es mir die Größe in 4K-Blöcken.

Wir kopieren nun das Shrunkin-Dateisystem auf die neue Festplatte. Wir werden die Daten in 16-MB-Blöcke kopieren, also müssen wir herausfinden, wie viele 16-MB-Blöcke wir kopieren müssen. Hier kommt die Größe des verkleinerten Dateisystems ins Spiel.

In meinem Fall betrug das verkleinerte Dateisystem etwas mehr als 1 GB, da ich viele andere Programme auf dem grundlegenden Ubuntu-System installiert hatte, bevor ich einen Schnappschuss machte. Ich hätte es wahrscheinlich vermeiden können, die Größe des Dateisystems auf die nächsten 16 MB aufgerundet zu kopieren, aber ich wollte auf Nummer sicher gehen.

Also, 128 mal 16 MB Chunks = 2 GB:

$ sudo dd if=/dev/sdf ibs=16M of=/dev/sdg obs=16M count=128

Ich habe in Blöcken von 16 MB kopiert, weil Sie bei EBS für jedes Lesen und Schreiben zahlen, und deshalb wollte ich die Anzahl so gering wie möglich halten. Ich weiß nicht, ob das so ist, aber es hat wahrscheinlich nicht wehgetan.

Wir müssen dann die Größe des Dateisystems ändern, das wir gerade auf das neue Volume kopiert haben, damit es den gesamten verfügbaren Speicherplatz auf dem Volume nutzt.

$ sudo resize2fs -p /dev/sdg

Überprüfen Sie abschließend, ob alles in Ordnung ist:

$ sudo e2fsck -f /dev/sdg

Das ist alles, was wir in dieser Maschine tun müssen, obwohl es nicht schaden könnte, das neue Volume nur als Test zu mounten. Dieser Schritt ist jedoch mit ziemlicher Sicherheit optional, da e2fsck Probleme haben sollte.

Wir müssen jetzt einen Schnappschuss des neuen Volumes erstellen und einen darauf basierenden AMI erstellen. Wir sind mit der Maschine fertig, also können Sie sie beenden, wenn Sie möchten.

Stellen Sie sicher, dass das kleine Volume nicht gemountet ist, wenn Sie es gemountet haben, und machen Sie dann einen Schnappschuss. Auch dies können Sie in der Verwaltungskonsole tun.

Der letzte Schritt erfordert die Kommandozeilen-Tools von ec2.

BEARBEITEN:

Da diese Antwort veröffentlicht wurde, können Sie in der AWS-Konsole einfach mit der rechten Maustaste auf einen Schnappschuss klicken und "Bild aus Schnappschuss erstellen" auswählen. Sie müssen weiterhin die entsprechende Kernel-ID auswählen. Wenn es nicht in der Liste angezeigt wird, vergewissern Sie sich, dass Sie die entsprechende Architektur ausgewählt haben.

Wir verwenden die ec2-register-Anwendung, um ein AMI auf der Grundlage des gerade aufgenommenen Schnappschusses zu registrieren. Notieren Sie sich daher den Wert für snap-xxxxxxxx aus dem gerade aufgenommenen Schnappschuss.

Sie sollten dann einen Befehl verwenden wie:

ec2-register -C cert.pem -K sk.pem -n The_Name_of_Your_New_Image
-d Your_Description_of_This_New_AMI --kernel aki-xxxxxxxx
-b "/dev/sda1=snap-xxxxxxxx" --root-device-name /dev/sda1

Sie müssen natürlich die Kernel-ID durch die zu Beginn notierte und die Snapshot-ID durch die im vorherigen Schritt erstellte ID ersetzen. Sie müssen es auch auf Ihren oben genannten geheimen Schlüssel (sk.pem) und Ihr x509-Zertifikat (cert.pem) verweisen. Sie können natürlich wählen, was Sie für den Namen und die Beschreibung wollen.

Hoffe das hilft.

Ja, ich habe mich das auch gefragt. Das folgende Tutorial ist übertrieben, aber ich denke, es enthält die notwendigen Tools: http://www.linuxconfig.org/Howto_CREATE_BUNDLE_UPLOAD_and_ACCESS_custom_Debian_AMI_using_ubuntu

Anstatt wie oben beschrieben auf einem neuen Disk-Image zu installieren, sollte es möglich sein, den großen AMI zu starten, einen neuen EBS zu erstellen, EBS an die ausgeführte Instanz anzuhängen und den ausgeführten AMI auf den neuen EBS zu kopieren. Zum Schluss registrieren Sie das neue EBS als AMI.

Schauen Sie sich diesen Blog-Beitrag an, um mehr Hintergrundinformationen zu erhalten, insbesondere den Kommentar von freremark: http://alestic.com/2010/01/public-ebs-boot-amis-for-ubuntu-on-amazon-ec2

Abschließend scheint euca2ools ein großartiger Ersatz für ec2-ami-tools zu sein - euca2ools enthält aktuelle Hilfeseiten! Sie haben alle die gleichen Namen wie die ec2- * -Befehle, nur mit dem Präfix euca. http://open.eucalyptus.com/wiki/Euca2oolsUsing

Ich wollte die Größe des Volumes reduzieren, das von einer allgemeinen EC2-Instanz verwendet wird. Ich habe hier ähnliche Schritte wie bei den anderen Antworten ausgeführt, bin jedoch auf ein Problem gestoßen. Also hier ist, was ich tun musste, um mein Root-Volumen zu verkleinern ...

In der AWS Console

 1. Stop the source EC2 instance
 2. Create a snapshot of the volume you want to shrink
 3. Use the snapshot to create a new 'source' volume
 4. Created a new volume with smaller size (made sure it was big enough for the data on source)
 5. Attached both volumes to any EC2 instance (mine were /dev/sdf = source & /dev/sdg = target)
 6. Start the EC2 instance

Auf der EC2-Instanz

 7. sudo su -   (everything from here is run as root)
 8. mkdir /source /target
 9. mount -t ext4 /dev/sdf /source
 10. mkfs.ext4 /dev/sdg
 11. mount -t ext4 /dev/sdg /target
 12. rsync -aHAXxSP /source/ /target 
     ** notice that there is no trailing '/' after target if 
       you put one there your data will be copied to 
       /target/source and you will have to move it up a directory
 13. cat /boot/grub/grub.conf  (indicated that grub is using root=LABEL=/)
 14. cat /source/etc/fstab (indicated that fstab was also using LABEL=/)
 15. e2label /dev/sdg /
 16. umount /source
 17. umount /target

Zurück in der AWS Console

 18. Stop the instance
 19. Detach ALL volumes from the instance
 20. Attach the 'target' volume to the instance using /dev/sda1 as the device
 21. Start the instance

Hier sind wir auf ein Problem gestoßen, das meines Erachtens nicht erwähnt wurde. Die Instanz hat gut angefangen, großartig! Als ich jedoch versuchte, eine Verbindung zur Instanz herzustellen, konnte ich keine Verbindung herstellen. Nach vielen, vielen Variationen der obigen Schritte habe ich mich schließlich entschlossen, das Root-Volume einer frisch hochgefahrenen EC2-Instanz zu verwenden.

In der AWS Console

 1. Create a new EC2 instance with the right sized root volume
 2. Stop the new instance
 3. Detach the /dev/sda1 volume from the new instance
    ** used the 'source' volume from before & the new volume we just detached
 4. Attached both volumes to the original EC2 instance (/dev/sdf & /dev/sdg)
 5. Start the instance with the attached volumes

Auf der EC2-Instanz

 1. sudo su - 
 2. mkdir /source /target (only need to do this if you don't already have these directories)
 3. mount -t ext4 /dev/sdf /source
 4. mount -t ext4 /dev/sdg /target (no need to create a file system because it is already there)
 5. rsync -aHAXxSP /source/ /target 
 6. umount /source
 7. umount /target

Zurück in der AWS Console

 1. Stop the instance
 2. Detach the 'source' and 'target' volumes from instance
 3. Attach the 'target' volume to the instance from step 1 using /dev/sda1 as the device
 4. Start the instance
 5. ** we use an elastic IP so we just reassigned the IP to the new instance

Hoffe das hilft jemandem