В настоящее время у меня есть один веб-сервер, на котором работают мои веб-сайты, все запросы идут прямо туда. Веб-сервер запускает ruby on rails, и все идет хорошо, но по мере роста моих сайтов мне нужно будет либо получить сервер большего размера, либо масштабироваться с большим количеством серверов, обрабатывающих дополнительную нагрузку.
Я хотел бы пойти по второму сценарию. Вместо одного огромного сервера я бы хотел два или три меньших и более дешевых сервера. Вот как я считать это должно быть сделано:
Все домены указывают на x.x.x.30 (HAProxy.) Когда HAProxy получает запрос GET, он отправляет этот запрос на наименее загруженный доступный веб-сервер. Веб-сервер напрямую отвечает клиенту. С такой установкой я мог легко расти, добавляя веб-серверы в любое время, и быстро устранять любые проблемы, удаляя проблемные веб-серверы из кластера.
x.x.x.30 <-- HAProxy
x.x.x.31 <-- webserver1: Rails/Passenger3
x.x.x.32 <-- webserver2: Rails/Passenger3
Правильно ли я понимаю эту установку?
Ага - я думаю, у вас есть основы:
Это прокси - и только прокси, который работает с чем угодно, основанным на TCP, а не только с HTTP. Он не обслуживает файлы - это просто прокси.
HAProxy поставляется с множеством алгоритмов балансировки нагрузки, включая стратегию «наименьшего количества соединений», которая выбирает серверную часть с наименьшим количеством ожидающих соединений.
Серверные ВМ можно проверять на работоспособность и работоспособность по URL-адресу, чтобы избежать маршрутизации запросов к серверным ВМ, поврежденным мозгом. (Он может даже пошатнуть эти проверки, чтобы избежать всплесков.)
Специальная страница состояния дает вам статус серверной части, время безотказной работы и множество действительно хороших показателей. Запросы могут маршрутизироваться на основе самых разных вещей: файлов cookie, подстрок URL-адресов, IP-адреса клиента и т. Д.
listen app_a_proxy 127.0.0.1:8100
# - equal weights on all servers
# - queue requests on HAPRoxy queue once maxconn limit on the appserver is reached
# - minconn dynamically scales the connection concurrency (bound my maxconn) depending on size of HAProxy queue
# - check health of app. server every 20 seconds
server a1 127.0.0.1:8010 weight 1 minconn 3 maxconn 6 check inter 20000
server a1 127.0.0.1:8010 weight 1 minconn 3 maxconn 6 check inter 20000
listen app_b_proxy 127.0.0.1:8200
# - second cluster of servers, for another app or a long running tasks
server b1 127.0.0.1:8050 weight 1 minconn 1 maxconn 3 check inter 40000
server b2 127.0.0.1:8051 weight 1 minconn 1 maxconn 3 check inter 40000
server b3 127.0.0.1:8052 weight 1 minconn 1 maxconn 3 check inter 40000
Проверьте здесь некоторые дополнительные примеры и подробности
По большей части вы правы, но одна деталь, которую вы как бы упустили, - это часть ответа. Описываемая вами настройка называется «Прямая маршрутизация», что означает, что пакеты поступают в балансировщик нагрузки, перенаправляются на внутренний сервер, и этот сервер отвечает непосредственно клиенту, не передавая трафик обратно через балансировщик нагрузки. .
Чтобы аварийное восстановление работало, IP-адрес балансировщика нагрузки должен ТАКЖЕ существуют на всех веб-серверах. Однако вам необходимо отключить ответы ARP для этих адресов на других серверах. Вот ссылка на обсуждение этого в CentOS.
Еще нужно помнить, что этот прокси-сервер теперь может стать узким местом или единственной точкой отказа. Обычно, когда эти прокси-серверы балансировки нагрузки настраиваются, они настраиваются как кластер машин с высокой доступностью, так что обслуживание может выполняться на одном или на одном из них может произойти сбой без остановки всего сайта.
Помимо DR, вы также можете использовать NAT, когда веб-серверы используют балансировщик нагрузки в качестве шлюза, а веб-серверы имеют частный IP-адрес, который балансировщик нагрузки переводит на общедоступные IP-адреса и обратно. Обычно это проще настроить, потому что вам не нужно беспокоиться о проблемах ARP, асимметричной маршрутизации и т. Д.
Наконец, один метод, о котором не часто говорят, - это использование модуля iptables CLUSTERIP. Этот модуль блокирует трафик на основе удаленного IP-адреса или IP-адреса и номера порта, а также информации о том, на каком узле кластера он работает. Итак, вы должны настроить IP-адрес на всех машинах как псевдоним и настроить CLUSTERIP. Он использует хэш информации о соединении, чтобы каждая машина в кластере согласовывала, какой узел будет ее обрабатывать. Пакеты блокируются на узлах, которые не обрабатывают их, и принимаются узлом, который это делает. Это делается с использованием многоадресного MAC-адреса на низком уровне.
Это отлично работает, потому что у вас нет специального балансировщика нагрузки, который мог бы выйти из строя. Однако он несколько примитивен и, очевидно, не может выполнять балансировку нагрузки на основе URL-адресов или другой информации «уровня 7», только на основе IP-адреса.
Вот статья, которую я написал в прошлом году о том, как настроить CLUSTERIP..
Есть много вариантов, и мы используем их все в зависимости от ситуации. У всех есть свои сильные и слабые стороны, в зависимости от конкретной ситуации, целей и уровня опыта.