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