В AWS мы хотели бы использовать ELB для балансировки нагрузки экземпляров EC2, на которых размещено несколько приложений. В идеале мы хотели бы проверить работоспособность приложения.
Однако в настоящее время балансировщики нагрузки AWS Elastic Load Balancer позволяют выполнить эхо-запрос только в одном месте для проверки работоспособности.
Как лучше всего реализовать проверку работоспособности с помощью ELB, которая учитывает состояние нескольких приложений, развернутых на каждом экземпляре EC2?
Вот два способа решить эту проблему;
Первый вариант - добавить еще одну проверку работоспособности на хосте, которая проверяет работоспособность и возвращает HTTP 200 в ELB, если логика говорит, что вы хотите, чтобы хост оставался в сети. Логика здесь, конечно, зависит от вас. Недостатком здесь было бы то, что если бы приложение 2 было успешно развернуто на некоторых хостах, все хосты по-прежнему были бы «исправны» и получали трафик.
Другой вариант - использовать дополнительный ELB для каждого приложения. Вы можете указать несколько ELB на один и тот же серверный инстанс EC2, и это будет довольно не дорого. Таким образом, вы можете проверить работоспособность для каждого приложения и удалить узлы с проблемами на уровне каждого приложения, а не по принципу «все или ничего».
Изменить: обратите внимание, что это более старый ответ и относится к ELB, а не ALB. ALB изначально поддерживает отдельные цели на одном хосте.
Здесь можно использовать один ELB для каждого приложения.
Во-первых, они могут вам понадобиться в любом случае, если каждое приложение находится в собственном домене и вам необходимо поддерживать SSL. В настоящее время Amazon ELB допускает использование только одного SSL-сертификата для каждого домена, требуя отдельных ELB для каждого домена с поддержкой SSL. (Исключением являются сертификаты SSL с подстановочными знаками).
Проблема здесь в том, что проверки работоспособности ELB в настоящее время не могут быть направлены на конкретный виртуальный домен, размещенный на экземпляре EC2. (Заголовок "Host:" не отправляется). Пинги работоспособности ELB всегда отправляются в домен по умолчанию, как если бы вы загрузили IP-адрес для экземпляра EC2 в свой браузер. Таким образом, требуется немного клея, чтобы получать проверки работоспособности в домене по умолчанию, а затем отвечать со статусом работоспособности конкретного приложения.
Вот рабочий пример конфигурации, которую можно добавить в Nginx server директива. Он будет установлен на каждом экземпляре EC2 с балансировкой нагрузки.
# This goes in the `server` block noted by 'default_server', often /etc/nginx/sites-enabled/default
# All AWS Health Checks from the ELBs arrive at the default server.
# Forward these requests on the appropriate configuration on this host.
location /health-check/ {
rewrite ^/health-check/(?<domain>[a-zA-Z0-9\.]+) /api/v1/status break;
# Lie about incoming protocol, to avoid the backend issuing a 301 redirect from insecure->secure,
# which would not be considered successful.
proxy_set_header X-Forwarded-Proto 'https';
proxy_set_header "Host" $domain;
proxy_pass http://127.0.0.1;
}
В настройке «Проверка работоспособности» ELB для «first-application.com» вы должны выбрать «HTTP» и порт 80 и ввести такой путь:
/health-check/first-application.com
Если указанная выше конфигурация Nginx запущена на хосте, запрос будет получен в домене по умолчанию, а ответ от конфигурации Nginx на том же хосте будет прокси-сервером для https://first-application.com/api/v1/status
При таком подходе в Nginx нет конфигурации для каждого приложения. Поскольку каждое приложение имеет уникальное доменное имя, вам просто нужно убедиться, что вы правильно настроили ELB для каждого приложения.
11 августа 2016 года Amazon представила Балансировщики нагрузки приложений. Они позволяют указать несколько целевых групп, каждая из которых имеет свой тип проверки работоспособности. Так что теперь это возможно с помощью одного балансировщика нагрузки!