Назад | Перейти на главную страницу

haproxy и keepalived на Amazon EC2

Новый сервис Amazon Opsworks использует haproxy, а не собственный очень ограниченный эластичный балансировщик нагрузки Amazon, поэтому я начал исследовать haproxy как лучший вариант для балансировки нагрузки наших серверов веб-приложений, обеспечения переключения сеанса при отказе и т. Д. Я получил haproxy, работающий без сбоев. с одним сервером haproxy и несколькими серверами веб-приложений, но я бы хотел избежать SPOF.

Мой вопрос: нужно ли мне настраивать второй сетевой адаптер на каждом сервере haproxy, возможно, с тем же внутренним IP-адресом 10.0.0.x? Поскольку назначение внешнего адреса (эластичный IP-адрес) и пересылка трафика на внутренний IP-адрес выполняется Amazon, я не уверен, как это настроить.

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

Я также использую haproxy для нашей балансировки нагрузки, потому что на момент разработки Amazon Elastic Load Balancing (ELB) не поддерживал серверы в VPC. У них есть эта функция сейчас (я полагаю, что не использовал ее, поскольку haproxy отлично работает для нас).

Мы вообще не пробовали keepalived по двум причинам:

  1. Мы сомневались, что сможем изменить частный IP-адрес на сервере без использования AWS (консоли или API). Кроме того, AWS не позволяет двум серверам в одном VPC иметь один и тот же внутренний IP-адрес.
  2. Для обеспечения высокой доступности нам требовалась установка с несколькими зонами доступности. Внутренний IP-адрес сервера в VPC основан на подсети VPC, и каждая подсеть может принадлежать только 1 VPC. Следовательно, у нас не может быть двух хостов в двух разных зонах доступности в одной подсети.

Поэтому реализованное нами решение было:

  • Настроить haproxy на двух серверах (по одному в каждой зоне доступности)
  • Также разделите наши внутренние (например, веб-серверы) на две или более зоны доступности.
  • Установите эластичный IP-адрес на один из серверов haproxy (в выбранной нами «основной» зоне доступности). Это VIP, к которому будут обращаться веб-клиенты.
  • Отслеживайте VIP из внешнего источника (за пределами региона AWS). В случае сбоя (экземпляр или вся зона доступности) переназначьте эластичный IP-адрес вторичному серверу haproxy (при условии, что на этом хосте проходят тесты).
    • Ссылка EIP: http://aws.amazon.com/articles/1346
    • Примечание. На данный момент мы делаем это вручную (очень редко - один или два раза в год для отключений в зоне доступности), но это можно легко создать с помощью сценария с использованием API AWS и заставить сервер мониторинга запускать переключение в случае сбоя.
    • Также обратите внимание на стоимость переназначения EIP (0,10 доллара за переназначение из 100 бесплатных переназначений в месяц). Поскольку перебои в работе AZ относительно редки, я не думаю, что это будет проблемой.

Один из потенциальных рисков заключается в том, что во время серьезных сбоев AWS мы иногда замечали, что консоль AWS и API начинают отказывать (полностью или чаще, чем обычно). Это может повлиять на попытки переназначить эластичный IP-адрес.