Я использую хранилище EBS на экземпляре Debian. Я установил, что экземпляр не завершается при завершении работы.
Мне интересно, что происходит в случае отказа оборудования (RAM, CPU, HD и т. Д.).
какой тип тревоги я должен настроить, чтобы получать уведомления? Могу ли я положиться на «StatusCheckFailed»?
Следует ли ожидать, что команда AWS автоматически выполнит перезагрузку / перезагрузку на другом оборудовании? Если нет, то какие шаги я должен выполнить, чтобы перезапустить мой экземпляр на другом оборудовании? Сколько времени это занимает?
Могу ли я с уверенностью предположить, что НЕ потеряю свои данные (/ var / www и т. Д.)? Сейчас, если я остановлюсь и начну, все в порядке, но я не уверен, что могу на это положиться
В случае отказа жесткого диска, является ли он прозрачным, потому что AWS использует RAID или что-то еще? или я также должен быть уведомлен и, возможно, вручную перезапустить с предыдущего снимка?
Находясь в «облаке», особенно в AWS, я ожидал, что оно включает в себя управление аварийным переключением, с таким продуктом, как VMware, просто автоматически перезагружая виртуальную машину на другом HW. Итак, я понимаю, что мне следует ожидать аварийного переключения, но я ищу решения для автоматического запуска экземпляра в другой области / регионе при обнаружении сбоя HW или, если это невозможно, по крайней мере, вручную, выполнив пару шаги?
Спасибо, Род
В некоторых случаях Amazon замечает, что их оборудование находится в нерабочем состоянии, и просит вас выйти из него (остановить и запустить свой экземпляр) к определенной дате, иначе оно будет остановлено автоматически.
В некоторых случаях предупреждения не будет, и он просто остановится. Или не перейти в состояние СТОП, а просто стать недоступным. Он может или не может перезагрузиться после того, как они позаботятся об этом. Иногда постфактум приходит письмо с извинениями.
У меня еще не было сбоев тома EBS (у меня было много экземпляров, которые выходили из строя, но не тома), но все же планирую это. Не знаю, как это выглядит.
Лучше всего установить сигнал о сбое проверки состояния доступности.
AWS вряд ли перезапустит ваш экземпляр. Они предоставляют вам все инструменты для мониторинга и перезапуска экземпляров, поэтому они оставляют это вам. Они могут написать вам по электронной почте, если вам нужно что-то сделать. Если вы остановитесь, а затем запустите свой экземпляр, он перейдет на новое оборудование, но перезапуск не приведет к его перемещению на новое оборудование. Перезапуск моего экземпляра Amazon Linux обычно занимает около минуты.
Вы не должны потерять данные с диска EBS в случае отказа оборудования EC2, поскольку тома EBS хранятся с избыточностью в одной зоне доступности. Снимки состояния EBS хранятся в S3, в котором хранятся данные в трех зонах доступности в одном регионе, поэтому они значительно более надежны. Снимки можно автоматизировать и делать ежечасно, ежедневно, еженедельно и т. Д. С помощью различных инструментов. Первый снимок большой, последующие, как говорят, занимают сравнительно мало места. По моему опыту, снимки, расположенные близко друг к другу, занимают мало места, но со временем они увеличивают размер и стоимость, поэтому я регулярно удаляю ненужные снимки.
Помимо снимков, вы также должны делать резервные копии на уровне приложения, используя такое приложение, как Борг резервное копирование, Restic, или коммерческий инструмент.
Вы можете создать сигнал тревоги в CloudWatch, который перезагружает ваш экземпляр, если возникнет StatusCheckFailed. Документация с пошаговыми инструкциями есть Вот.
У меня только что произошел сбой EBS, из-за которого оба EC2 запускали якобы отказоустойчивую службу на Elastic Beanstalk.
Симптомами были HTTP-запросы GET, которые все еще работали, но POST не удавались. Это означает, что наши проверки работоспособности на основе GET не обнаружили никаких проблем, но пользователи не могли войти в систему, поскольку процесс входа использовал POST.
Просматривая логи, было много сообщений в /var/log/messages об ошибках ввода-вывода.
EXT4-fs warning (device dm-3): ext4_end_bio:314: I/O error -28 writing to inode 5905292 (offset 3198976 size 4096 starting block 1475341)
Buffer I/O error on device dm-3, logical block 1475341
EXT4-fs warning (device dm-3): ext4_end_bio:314: I/O error -28 writing to inode 5905292 (offset 0 size 0 starting block 1475340)
Buffer I/O error on device dm-3, logical block 1475340
JBD2: Detected IO errors while flushing file data on dm-3-8
EXT4-fs warning (device dm-3): ext4_end_bio:314: I/O error -28 writing to inode 5905292 (offset 0 size 0 starting block 1475341)
Buffer I/O error on device dm-3, logical block 1475341
В журналах nginx были сообщения с жалобами на сбой запросов POST из-за результирующего состояния файловой системы только для чтения.
open() "/var/lib/nginx/body/0000522584" failed (30: Read-only file system)
open() "/var/lib/nginx/body/0000522585" failed (30: Read-only file system)
open() "/var/lib/nginx/body/0000522586" failed (30: Read-only file system)
Похоже, что произошло обычное поведение Linux: отказавший диск переводит файловую систему в режим только для чтения, что не позволяет nginx создавать какие-либо временные файлы для хранения данных POST. Но GET работали нормально, потому что чтение файловой системы было нормальным.
Интересно, что, поскольку проверки работоспособности сообщали, что все в порядке, Elastic Beanstalk не завершал работу и не воссоздавал никаких экземпляров EC2, хотя примерно 35% запросов завершались ошибками HTTP 500.
Уроки выучены? Убедитесь, что URL-адреса проверки работоспособности пытаются записать в ту же файловую систему, которая используется другими процессами на вашем EC2, так что отказавший диск также приведет к сбою проверки работоспособности. В противном случае проблема может не быть обнаружена автоматически и может потребоваться ручное вмешательство.