Отказоустойчивый прокси на Amazon AWS?

Question

Это довольно общий вопрос. Предположим, у меня есть три блока ec2: два блока приложений и блок, в котором размещен nginx в качестве обратного прокси-сервера, делегирующий запросы двум блокам приложений (моя база данных размещена в другом месте). Теперь две машины приложений могут поглотить сбой между собой, однако третья представляет одну точку сбоя. Как я могу настроить мои настройки так, чтобы, если обратный прокси-сервер отключился, сайт все еще был доступен?

Я смотрю на keepalived и HAproxy. Для меня эта штука неочевидна, и любая помощь для ушей новичка приветствуется.

Answer 1

Если ваш nginx делает не больше, чем проксирование HTTP-запросов, ознакомьтесь с Amazon Elastic Load Balancer.Вы можете настроить два (или более) ящика приложений, оставить некоторые запасные (чтобы всегда было два или более, если вам это нужно), настроить проверки работоспособности, иметь SSL-завершение на балансировщике, использовать липкиесеансы и т. д.

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

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

Answer 2

Я думаю, что если вы новичок с HA и кластерами, ваше лучшее решение - Elastic Load Balancer (ELB), который поддерживается Amazon.Они автоматически масштабируются и реализуют кластер балансировщиков высокой доступности.Таким образом, используя сервис ELB, вы уже смягчаете точку отказа, которую прокомментировали.Также важно иметь в виду, что ELB дешевле, чем 2 экземпляра в AWS.И, конечно, легче запустить и поддерживать.

Вы не можете видеть несколько ELB, потому что это услуга, поэтому вам не нужно заботиться о доступности.

Другим важным моментом является то, что эластичные ips AWS не назначаютсяк интерфейсу NIC вашего экземпляра ОС, поэтому использовать виртуальные ips также в классических инфраструктурах сложно.

После этого объяснения, если вы по-прежнему хотите использовать Nginx в качестве обратного прокси в AWS, потому что ваши причины, я думаю, вы можете реализоватьавтомасштабирующая группа со слоем, состоящим из экземпляров Nginx.Но если вы не разбираетесь в технологиях автоматического масштабирования, это может быть очень сложно.