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

избыточный балансировщик нагрузки http

Получил простой сценарий с двумя веб-серверами для резервирования и масштабирования.

Но как мне сделать установку двух веб-серверов полностью избыточной? Я могу придумать два решения;

  1. два веб-сервера, один балансировщик нагрузки, распределяющий нагрузку. одна дополнительная машина для балансировщика нагрузки. но как будет дублировать балансировщик нагрузки?

  2. две машины, каждая из которых запускает веб-сервер И балансировщик нагрузки, распределяя нагрузку между ними. иметь точку входа DNS на обе машины. не требуется дополнительных машин для балансировки нагрузки.

Как вы, ребята, обычно решаете такие проблемы?

Но как мне сделать установку двух веб-серверов полностью избыточной?

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

Вы должны думать о состоянии сеанса - состояние входа пользователя, содержимое корзины покупок и т. д. Как это будет обрабатываться?

Если ваша служба полностью не зависит от состояния (статический файл FX обслуживается без настройки для каждого пользователя), вы можете просто использовать DNS Round Robin для публикации 2 IP-адресов для вашего сайта, по одному для каждого сервера.

Если вам нужно немного больше контроля над тем, как обрабатывается отработка отказа, вы можете рассмотреть 2 веб-сервера, оба используют один и тот же IP-адрес через Windows NLB или в Linux, используя что-то вроде Linux-HA, Keepalivedи т.д. (есть несколько возможных решений).

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

Предполагая, что аппаратные балансировщики нагрузки, их обычно можно настроить в активном / пассивном кластере для аварийного переключения с использованием их собственных конфигураций. Если вы используете программный балансировщик нагрузки (не Microsoft NLB), найдите тот, который совместим с VRRP, и используйте VRRP для обработки отказа балансировщика нагрузки. Если вы используете Microsoft NLB, то он работает на всех машинах в масштабируемом кластере и автоматически обрабатывает сбои машин.

http://www.howtoforge.com/high-availability-load-balancer-haproxy-heartbeat-debian-etch

Установите haproxy на оба сервера вместе с Heartbeat. Haproxy будет балансировать нагрузку как на веб-серверы, так и Heartbeat обеспечит аварийное переключение на виртуальный IP-адрес в случае сбоя одного из серверов.

Обычно есть два способа реализовать отказоустойчивые решения с высокой доступностью / масштабируемостью. Первый - использовать короткие TTL для записи DNS с циклическим перебором в сочетании с балансировщиком нагрузки, а второй - использовать мониторинг пульса и переключение IP-адресов с помощью аппаратного или программного решения. В некоторых решениях для повышения надежности используется комбинация этих двух подходов.

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

FWIW, вы должны быть достаточно надежными, используя короткие TTL в своих записях DNS, а затем программно указывая DNS на резервную веб-страницу, если вы потеряете LB. Для этого вы можете использовать такую ​​службу, как Zerigo, поскольку они предоставляют API, с помощью которого вы можете изменять свои записи на лету. Если вы хотите оптимизировать затраты, это лучший вариант.

Кажется, есть несколько решений для этого с Linux, включая решение, построенное на основе LVS: http://www.cyberciti.biz/faq/rhel-centos-fedora-keepalived-lvs-cluster-configuration/, но могут быть ограничения на то, где вы можете его развернуть (например, не на AWS), и дополнительные расходы на его настройку, мониторинг и правильную реализацию.