Уменьшение размера тома Amazon EBS

Я видел этот ответ для растущих объемов EBS , но я хотел бы уменьшить его.

Образы Ubuntu Server по умолчанию составляют 15 ГБ, в то время как мне действительно нужно только 2 ГБ максимум (я использую другой объем для данных). Есть ли способ уменьшить размер тома?

У меня был такой же вопрос, как и у вас, поэтому я решил, как это сделать.

Во-первых, я сделал это из 32-битного Ebi с поддержкой Ebu из Ubuntu из региона Восток США, другие ОС или образы могут работать по-другому. Тем не менее, я подозреваю, что вы должны быть в порядке, если вы используете файловую систему ext *. Это может работать на других файловых системах, но вам придется выяснить, как изменить их размер самостоятельно.

Шаги в основном:

1. Присоедините два тома к работающему экземпляру, первый на основе снимка, который вы хотите сжать, а второй - пустой том с новым размером, на который вы хотите сжать.

2. Проверьте файловую систему первого тома и устраните все ошибки.

3. Уменьшите файловую систему на первом томе, чтобы она была настолько большой, насколько это необходимо для хранения данных.

4. Скопируйте файловую систему с первого тома на второй.

5. Разверните файловую систему на втором томе до максимального размера.

6. Убедитесь, что все выглядит хорошо, проверив второй том на наличие ошибок.

7. Сделайте снимок второго тома.

8. Создайте образ машины на основе снимка второго тома, который вы только что сделали.

Сначала вам нужно получить информацию от ами, которые вы хотите уменьшить. В частности, вам нужен идентификатор ядра и идентификатор ramdisk, если таковые имеются (образ, который я сжал, не имел ramdisk). Вся эта информация должна быть доступна из консоли управления aws в окне AMI.

Идентификатор ядра выглядит как kia-xxxxxxxx, а идентификатор моментального снимка выглядит как snap-xxxxxxxx, а идентификаторы ramdisk выглядят как RIA-xxxxxxxx.

Затем запустите экземпляр Linux. Я запустил экземпляр Ubuntu. Вы можете использовать экземпляр t1.micro, если хотите. Это не займет много сил, чтобы сделать эти следующие шаги.

После запуска машины прикрепите снимок, который вы записали с первого шага. В моем случае я прикрепил его к / dev / sdf

Затем создайте новый том нужного размера. В моем случае я создал том объемом 5 ГБ, так как я хотел уменьшить его. Не создавайте этот новый том из снимка. Нам нужен новый чистый том. Затем присоедините его к работающему экземпляру, в моем случае я прикрепил его как / dev / sdg

Далее, ssh в машину, но не монтируйте подключенные тома.

В этот момент я допустил ошибку из-за паранойи и решил проверить файловую систему на большом томе, просто чтобы убедиться в отсутствии ошибок. Если вы уверены, что их нет, вы можете пропустить этот шаг:

$ sudo e2fsck -f /dev/sdf

Затем я изменил размер файловой системы на большом томе, чтобы она была такой же большой, как данные на диске:

$ sudo resize2fs -M -p /dev/sdf

-M сжимает его, а -p печатает прогресс.

Resize2fs должен сказать вам, насколько велика файловая система shrunkin. В моем случае это дало мне размер в 4K блоков.

Теперь мы копируем файловую систему shrunkin на новый диск. Мы собираемся скопировать данные порциями по 16 МБ, поэтому нам нужно выяснить, сколько порций по 16 МБ нам нужно скопировать. Вот где этот уменьшенный размер файловой системы приходит в хэнди.

В моем случае размер сжатой файловой системы составлял чуть более 1 ГБ, потому что я установил множество других программ в базовой системе Ubuntu, прежде чем сделать снимок. Возможно, я мог бы просто скопировать размер файловой системы, округленный до ближайших 16 МБ, но я хотел, чтобы это было безопасно.

Итак, 128 раз по 16 МБ порций = 2 ГБ:

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

Я копировал блоками по 16 МБ, потому что с EBS вы платите за каждое чтение и запись, поэтому я хотел максимально уменьшить их количество. Я не знаю, делал ли это таким образом, но это, вероятно, не повредило.

Затем нам нужно изменить размер файловой системы, которую мы только что скопировали, на новый том, чтобы она использовала все доступное пространство на томе.

$ sudo resize2fs -p /dev/sdg

Наконец, проверьте это, чтобы убедиться, что все хорошо:

$ sudo e2fsck -f /dev/sdg

Это все, что нам нужно сделать на этой машине, хотя это не помешает смонтировать новый том, просто как тест. Однако этот шаг почти наверняка необязателен, так как e2fsck должен был поймать любые проблемы.

Теперь нам нужно сделать снимок нового тома и создать AMI на его основе. Мы закончили с машиной, так что вы можете прекратить ее, если хотите.

Убедитесь, что небольшой том отключен, если вы подключили его, а затем сделайте снимок. Опять же, вы можете сделать это в консоли управления.

Последний шаг требует инструментов командной строки ec2.

РЕДАКТИРОВАТЬ:

Поскольку этот ответ был опубликован, консоль AWS позволяет просто щелкнуть правой кнопкой мыши по снимку и выбрать «Создать изображение из снимка». Вам все равно нужно будет выбрать соответствующий идентификатор ядра. Если он не отображается в списке, убедитесь, что вы выбрали соответствующую архитектуру.

Мы используем приложение ec2-register для регистрации AMI на основе только что сделанного снимка, поэтому запишите значение snap-xxxxxxxx из только что сделанного снимка.

Затем вы должны использовать команду вроде:

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

Вам, конечно, нужно заменить идентификатор ядра на тот, который вы записали в начале, а идентификатор снимка на тот, который вы создали на предыдущем шаге. Вам также нужно указать его на свой секретный ключ (называемый sk.pem) и свой сертификат x509 (называемый cert.pem). Конечно, вы можете выбрать все, что вы хотите для имени и описания.

Надеюсь это поможет.

Да, я тоже удивился Следующий учебник излишним, но я думаю, что он содержит необходимые инструменты: http://www.linuxconfig.org/Howto_CREATE_BUNDLE_UPLOAD_and_ACCESS_custom_Debian_AMI_using_ubuntu

Вместо установки на новый образ диска, как описано выше, должна быть возможность запустить большой AMI, создать новый EBS, подключить EBS к работающему экземпляру и скопировать работающий AMI на новый EBS. Наконец, зарегистрируйте новый EBS как AMI.

Взгляните на этот пост в блоге, чтобы получить дополнительную информацию, особенно комментарий freremark: http://alestic.com/2010/01/public-ebs-boot-amis-for-ubuntu-on-amazon-ec2

В заключение отметим, что euca2ools кажется отличной заменой ec2-ami-tools - в euca2ools есть настоящие справочные страницы! Они имеют те же имена, что и команды ec2- *, только с префиксом euca-. http://open.eucalyptus.com/wiki/Euca2oolsUsing

Я хотел уменьшить размер тома, используемого обычным экземпляром EC2. Я следовал за подобными шагами к другим ответам здесь, но столкнулся с проблемой. Итак, вот что я должен был сделать, чтобы уменьшить мой корневой объем ...

В консоли AWS

 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

На экземпляре EC2

 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

Вернуться в Консоль AWS

 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

Здесь мы столкнулись с проблемой, которая не была упомянута, насколько я могу судить. Инстанция началась отлично, отлично! Но когда я попытался подключиться к ssh, я не смог подключиться. После множества изменений описанных выше шагов я, наконец, решил попробовать использовать корневой том из недавно запущенного экземпляра EC2.

В консоли AWS

 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

На экземпляре EC2

 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

Вернуться в Консоль AWS

 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

Надеюсь, это поможет кому-то