Как вы автоматизируете аварийное переключение на EC2?

13

Из тех, кто управляет своими собственными кластерами (т.е. не использует / не платит за Amazon Autoscale, Rightscale, Scalr и т. Д.), Как вы управляете своими экземплярами в EC2 и обрабатываете (например) восстановление после отказа? Мне интересно, если большинство людей просто заканчивают тем, что написали свои собственные скрипты для API EC2, как я подозреваю.

Это, безусловно, наш подход: создайте наш собственный демон мониторинга / перезапуска на основе Python Boto, который работает вне сайта, прослушивая UDP-сообщения активности из наших экземпляров. В случае неудачи мы снимаем тома, регистрируем изображения, запускаем новые экземпляры, удаляем старые тома и так далее.

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

Кроме того, экосистема Linux-HA / Pacemaker (Heartbeat, ldirectord и т. Д.), Похоже, на самом деле не подходит для EC2 . (Но потом я нашел это - хотя я не уверен, что это действительно качественное решение).

Ян
источник

Ответы:

5

Ну, я не хочу просто заявить об очевидном, но основная идея заключается в том, чтобы внедрить эту сложность в сервисы, управляемые 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, того стоят, если вам нужна высокая доступность.

Джеспер М
источник
3
Мы знакомы с набором функций AWS, а также с их ограничениями. В качестве первого примера, доступ к ELB осуществляется через CNAME RR, которые не могут сосуществовать с SOA RR и, следовательно, не могут обслуживать TLD, а также не могут быть доступны через статические IP-адреса - разочарования, которые часто отражаются на форумах. В качестве второго примера, да, RDS - это MySQL, что является гигантским ограничением. Да, мы заинтересованы в автоматизации отработки отказа наших собственных типов машин. Да, развертывание частного облака актуально для нас. Да, мне просто любопытно. И т.д.
Ян
2
@Yang: Вы должны были сформулировать свой вопрос более тщательно, и избавили меня от необходимости набирать мой ответ. Не существует универсального решения для HA; это зависит от рассматриваемой службы, от того, как поддерживается состояние, свойств отработки отказа протокола и т. д. Вы правы насчет ограничений / трудностей при использовании типичных инструментов HA уровня IP в EC2. Но нет единого ответа, который универсально применим к «HA на AWS».
Джеспер М
0

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

Суман
источник
0

Проблемы, которые вы описываете (HA, мониторинг пользовательских серверов, сервисы «приклеивания воздуховодов»), как правило, решаются поставщиком PaaS. Rightscale и Scalr уже упоминались в предыдущем ответе, и есть дополнительные полезные опции (некоторые варианты PaaS см. Здесь:

/programming/9542784/looking-for-paas-providers-recommendations )

Вам следует подумать, какой из поставщиков наиболее точно соответствует вашим потребностям.

Уведомление: я работаю в cloudify, провайдере PaaS с открытым исходным кодом.

Barak
источник
0

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

TheDeveloper
источник
0

Вы устанавливаете heartbeat на обоих серверах. Вы присоединяете Elastic IP к «активному» серверу. Вы настраиваете сценарий для переключения при отказе, инициируя запрос API для получения эластичного IP. Как только «резервный» сервер получил эластичный IP ( занимает около 30-60 секунд) может быть мастером / активным.

У меня нет подробностей, чтобы предоставить здесь.

Амир Мехлер
источник
-1

Amazon уже предоставляет Elastic Load Balancing ... Зачем изобретать велосипед?

Крис С
источник
3
Из-за различных ограничений ELB? Потому что он требует CNAME и не может обслуживать foo.com и www.foo.com? Потому что я хочу реализовать собственную логику планирования? Потому что мне просто интересно, как вы сами внедрите ELB в кластер ненадежных виртуальных машин? Выбирайте.
Ян
@Yang, вы делаете это так же, как если бы они были серверами в вашем центре обработки данных. Нет принципиальной разницы, нет волшебного соуса, который делает его облачной средой.
Крис С