Недостаточно места на диске "/" в экземпляре AWS


28

Я запускаю экземпляр Ubuntu 11.04 для моего веб-сервера в облаке AWS, теперь я получаю, что на / разделе моего сервера нет места на диске . df -ah скажи это

Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda1            7.9G  7.8G   97M  99% /
proc                     0     0     0   -  /proc
none                     0     0     0   -  /sys
fusectl                  0     0     0   -  /sys/fs/fuse/connections
none                     0     0     0   -  /sys/kernel/debug
none                     0     0     0   -  /sys/kernel/security
none                  3.7G  112K  3.7G   1% /dev
none                     0     0     0   -  /dev/pts
none                  3.7G     0  3.7G   0% /dev/shm
none                  3.7G   80K  3.7G   1% /var/run
none                  3.7G     0  3.7G   0% /var/lock
/dev/xvdb             414G   16G  377G   4% /mnt

Теперь я попробовал эти вещи для получения дополнительного места на / раздел

  • Очистите все файлы журнала для Apache.
  • Удалены все ненужные файлы с сервера.
  • Домашний каталог Уборка.

Но все же я не получаю достаточно места. Этот тип экземпляра m1.large с 8 ГБ EBS. Теперь я получаю достаточно места на диске в / dev / xvdb .

Есть ли способ, которым я могу выделить некоторое дисковое пространство в / из / dev / xvdb или любым другим способом . Пожалуйста, предложите мне возможное решение для этого. Можно ли использовать тот же раздел / dev / xvdb с другим экземпляром.


1
Обновление 2017 года: Amazon позволяет изменять размеры ваших дисков (даже загрузочных) на лету! см. мой SO ответ здесь: stackoverflow.com/a/42791031/7022062
Дмитрий Шевкопляс

Ответы:


26

Ответ двоякий.

Обходной путь: используйте / dev / xvdb (/ mnt) для временных данных

Это так называемое эфемерное хранилище вашего экземпляра Amazon EC2, и его характеристики сильно отличаются от постоянного хранилища Amazon EBS, которое используется где-то еще. В частности, эта эфемерная память будет потеряна в циклах остановки / запуска и, как правило, может исчезнуть , поэтому вы определенно не хотите помещать туда что-либо имеющее длительную ценность, то есть размещаете там только временные данные, которые вы можете позволить себе потерять или восстановить легко , как файл подкачки или строго временные данные, используемые во время вычислений. Конечно, вы можете хранить там огромные индексы, например, но должны быть готовы перестроить их после того, как хранилище было очищено по любой причине (перезагрузка экземпляра, аппаратный сбой, ...).

Решение: измените размер / dev / xvda1 (/), чтобы получить желаемое хранилище

Это так называемый Root Устройство хранения вашей Amazon EBS поддержанного экземпляра EC2, что облегчает Amazon EBS для гибкости и прочности , в частности, то есть данные , поставить там достаточно безопасно и выживают сбои экземпляра; Вы можете еще больше повысить гибкость и долговечность, регулярно снимая том EBS, который хранится в Amazon S3 , с хорошо известной долговечностью 99,999999999%.

Эти функции моментального снимка позволяют поочередно решить вашу проблему, поскольку вы можете заменить текущее корневое хранилище EBS объемом 8 ГБ (/ dev / xvda1) на более или менее желаемое. Процесс описан в отличной статье Эрика Хаммонда « Изменение размера корневого диска в работающем экземпляре EBS Boot EC2» :

Если у вас все в порядке с небольшим временем простоя на экземпляре EC2 (несколько минут), можно заменить корневой том EBS на большую копию без необходимости запуска нового экземпляра.

Если вы правильно подготовите шаги, которые он описывает (я настоятельно рекомендую сначала протестировать их с одноразовым экземпляром EC2, чтобы ознакомиться с процедурой, или даже автоматизировать его с помощью специального скрипта), вы сможете завершить процесс с несколькими минуты простоя только действительно.

Большинство описанных шагов также можно выполнить с помощью Консоли управления AWS , что позволяет избежать использования инструментов Amazon EC2 API ; это сводится к:

  • остановить (не завершить!) экземпляр EC2
  • отсоедините том EBS от остановленного экземпляра
  • создать снимок отсоединенного тома EBS
  • создать новый (больший) том EBS из созданного снимка
  • присоедините новый том EBS к экземпляру EC2 ( Важно ! Если это ваше корневое устройство, убедитесь, что оно названо точно в качестве корневого устройства экземпляра, как было упомянуто, например (/ dev / sda1) или (/ dev / xdva1) в противном случае он будет подключен как блочное устройство, а не как корневое устройство, и вы не сможете запустить экземпляр, так как для него не будет указано корневое устройство.)
  • SSH в работающий экземпляр и подтвердите все в порядке через df -ah
    • если ваша система не изменила размер файловой системы автоматически, вам нужно будет сделать это вручную, как описано в статье Эрика.

Удачи!


альтернатива

Принимая во внимание универсальность и простоту использования этих томов EBS, дополнительным вариантом будет присоединение большего количества томов EBS к вашему экземпляру и перемещение туда четко разделенных проблемных областей.

Например, мы используем несколько довольно тяжёлых Java-приложений, каждое из которых потребляет 1-2 ГБ памяти на версию; чтобы упростить обновление версий и вообще иметь возможность перемещать эти приложения в разные экземпляры по своему усмотрению, я разместил их на выделенных томах EBS каждый, подключил их к экземпляру и мягко связал их с нужным местом, например, обычно /var/lib/<app>/<version>и /usr/local/<app>/<version>.

Используя этот метод, в настоящее время мы запускаем экземпляры EC2 с хранилищем корневого устройства, размер которого по умолчанию составляет 8 ГБ (как у вас), но иногда также подключается до 8 томов EBS с различными размерами (1-15 ГБ).

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


Я использую / dev / xvdb, чтобы сохранить базу данных размером почти 16 ГБ. Один фоновый процесс выполняется, чтобы поддерживать ее в актуальном состоянии. Так что должно быть лучшее постоянное хранилище для этой базы данных. Должен ли я пойти на Amazon RDS или Amazon DynamoDB. каково ваше предложение. Я использую сервер PHP на этом экземпляре.
Sumant

2
@Sumant: Это нехорошо, так что вы сделали именно то, что опасно, а именно, поместили данные, которые должны быть сохранены на диск, который в принципе может исчезнуть в любое время (обычно это не так, но нужно относиться к этому так)? Я надеюсь , что я не пчела в заблуждение в связи с этим - пожалуйста , будьте особенно осторожны при смягчающих это для того , чтобы потери данных , избегайте во время процесса (вы делаете резервные копии базы данных независимо, не так ли?)!
Штеффен Опель

@Sumant: Что касается вашего вопроса - вам вообще не нужно менять архитектуру вашего приложения (или, соответственно, БД), чтобы устранить проблему с хранилищем, просто измените размер корневого диска или подключите больше томов EBS, как это предлагается. Однако, если вы хотите улучшить и отсоединить свой уровень БД, что, в принципе, неплохо, если учесть будущий рост (но с соответствующими затратами с самого начала) и при условии, что вы в настоящее время используете MySQL, тогда Amazon RDS будет идеальным и удобным выбором. Amazon DynamoDB требует полностью новой архитектуры приложений и применяется только к конкретным случаям использования.
Штеффен Опель

1
@Sumant: Имейте в виду, однако, что перенос вашей БД в экземпляр RDS m1.small может на самом деле демонстрировать более медленную производительность, чем ваш текущий MySQL на EC2, на котором работает m1.large с соответствующими преимуществами производительности ЦП и ввода / вывода - независимо от того, применимо ли это, зависит от текущей рабочей нагрузки БД. Конечно, вы можете использовать более крупные экземпляры RDS, чтобы исправить это, но ваша стоимость будет соответственно увеличиваться.
Штеффен Опель

1

Да, простой способ это fstab это и затем смонтировать это, чтобы сказать / var / www / html / files2 /

затем mkdir / var / www / html / files2 / website, затем ln -s -d / var / www / html / website / var / www / html / files2 / website


используйте UUID для монтирования раздела, используя команду blkids и fdisk скажите '/ dev / vxds /' для создания раздела. Используйте Midnight Commander, чтобы переместить файлы с F6 из одной папки в другую, убедитесь, что вы выбрали правильную папку в позиции монтирования oh и, конечно, вам нужно будет «mount -a» после добавления в fstab
Daniel Chay

0

Сегодня у меня возникла та же проблема, когда вы устанавливаете новый ec2 intance, по умолчанию EBS составляет 8 ГБ. Вы можете изменить размер подключенного EBS, не создавая новое intace, не делая снимок или не отключая EBS. Вот три шага, которые вы можете выполнить:

  1. Изменить размер тома EBS
  2. Изменить размер раздела
  3. Изменение размера раздела Для первого шага перейдите на консоль AWS, нажмите EBS, измените нужный размер и нажмите «Изменить».

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

Благодарность!

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.