Как вы автоматизируете аварийное переключение на EC2?
Из тех, кто управляет своими собственными кластерами (то есть не использует / не платит за Amazon Autoscale, Rightscale, Scalr и т. Д.), Как вы управляете своими экземплярами в EC2 и обрабатываете (например) восстановление после отказа? Мне интересно, если большинство людей просто заканчивают тем, что пишут свои собственные скрипты для API EC2, как я подозреваю.
Это, безусловно, наш подход: создайте наш собственный демон мониторинга / перезапуска на основе Python Boto, который работает вне сайта, прослушивая UDP-сообщения активности из наших экземпляров. В случае неудачи мы снимаем тома, регистрируем изображения, запускаем новые экземпляры, удаляем старые тома и так далее.
Время от времени, когда вы взламываете наши скрипты, я думаю, что должны быть какие-то инструменты с открытым исходным кодом, которые уже имеют дело с этими проблемами и не имеют ограничений, скажем, Scalr, но я всегда возвращаюсь из Google с пустыми руками. (Такие вещи, как Scalr, довольно ограничены в поддерживаемом наборе / версиях / конфигурациях программного обеспечения и имеют специализированные и IMO громоздкие способы манипулирования этими настройками.)
Кроме того, экосистема Linux-HA/Pacemaker (Heartbeat, ldirectord и т. Д.), Похоже, на самом деле не подходит для EC2. (Но потом я нашел это - хотя я не уверен, что это действительно качественное решение).
6 ответов
Ну, я не хочу просто заявить об очевидном, но основная идея заключается в том, чтобы внедрить эту сложность в сервисы, управляемые Amazon.
Поэтому на внешнем интерфейсе вы должны использовать Amazon Elastic Load Balancing (ELB) для обеспечения высокой доступности балансировки нагрузки. С другой стороны, вы используете Amazon Relational Database Service (MySQL), SimpleDB и S3 для хранения. Все они управляются Amazon и содержат некоторую обработку высокой доступности / отработки отказа.
Обычно это оставляет серверы веб-приложений и любые менее распространенные типы серверов, которые вы можете использовать (серверы рендеринга, самостоятельно установленные хранилища данных NoSQL и т. Д.).
Серверы веб-приложений обычно обрабатываются достаточно хорошо с помощью проверок работоспособности, встроенных в ELB. Вы можете принять небольшое снижение производительности, когда один сервер веб-приложений не работает, или постоянно предоставлять +1 на сервер больше, чем вам нужно. Или, если ваша конфигурация проста, то при сбое сервера веб-приложений ELB вместе с Cloudwatch может автоматически создать для вас новый сервер веб-приложений.
Ваши собственные серверы - это другое дело. Для них это правда, вы сами по себе, и вам нужно будет обойтись со встроенными методами приложения или скотчем что-то с помощью пользовательских сценариев / инструментов HA с открытым исходным кодом.
Решение о покупке Rightscale может быть слишком дорогим. Но менее дорогие инструменты Amazon, такие как ELB, базовое оповещение CloudWatch (теперь бесплатное с разрешением 5 минут) или AutoScale, того стоят, если вам нужна высокая доступность.
Вы устанавливаете heartbeat на обоих серверах. Вы присоединяете Elastic IP к "активному" серверу. Вы настраиваете сценарий для переключения при отказе, инициируя запрос API для получения эластичного IP. Как только "резервный" сервер получил эластичный IP (занимает около 30-60 секунд) может быть мастером / активным.
У меня нет подробностей, чтобы предоставить здесь.
Недавно я написал в нашем инженерном блоге сообщение о том, как использовать ELB в сочетании с автоматическим масштабированием для автоматического переключения при сбое для любого типа приложения. В нем рассказывается, как проверки работоспособности ELB можно использовать для проверки состояния вашего приложения и запуска действий автоматического масштабирования.
Проблемы, которые вы описываете (HA, мониторинг пользовательских серверов, сервисы "приклеивания воздуховодов"), как правило, решаются поставщиком PaaS. Rightscale и Scalr уже упоминались в предыдущем ответе, и есть дополнительные полезные опции (некоторые варианты PaaS см. Здесь:
https://stackoverflow.com/questions/9542784/looking-for-paas-providers-recommendations)
Вам следует подумать, какой из поставщиков наиболее точно соответствует вашим потребностям.
Уведомление: я работаю в cloudify, провайдере PaaS с открытым исходным кодом.
RightScale имеет несколько отличных статей о том, как автоматизировать отработку отказа на EC2. Хотя большинство из них показывают вам, как это сделать с помощью самой RightScale, принципы являются общими и, вероятно, полезны для всех, кто задумывается о том, как настроить архитектуру отработки отказа в EC2.
Amazon уже предоставляет Elastic Load Balancing... Зачем изобретать велосипед?