Балансировщик нагрузки серверов


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



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

Варианты организации отказоустойчивости существуют, для одного крупного проекта может задействоваться от 2 до 20-30 серверов и больше.

Балансировщик нагрузки серверов


Балансировщик нагрузки серверов на примере


Разберем простую схему, которая довольно часто применяется на практике.

Потребуются 2 сервера, которые в идеале должны быть физическими, а не виртуальными и размещаться в разных датацентрах.

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

Адреса можно использовать публичные — маршрутизируемые в сети или приватные, из локальной сети в которую объединяются машины.

Сервер 1. Датацентр г. Екатеринбург

  • VM 1.1 — фронтэнд, Nginx распределяющий запросы между бэкэндами 1.2 и 2.2
  • VM 1.2 — бэкенд, само приложение с бизнес логикой

Сервер 2. Датацентр г. Москва

  • VM 2.1 — фронтэнд, Nginx распределяющий запросы между бэкэндами 1.2 и 2.2
  • VM 2.2 — бэкенд, само приложение с бизнес логикой
 

VMX.1 является в обоих случаях балансировщиком



Настройка фронтэнда

В конфигурационном файле виртуального хоста задаются 2 upstream, представляющих собой адреса VM.

server 123.123.123.125;
server 123.123.123.126 backup;
}

Если ограничиться адресами, запросы будут распределяться поровну, если дописать backup — использоваться upstream будет только тогда когда он является единственным возможным вариантом и вторая VM недоступна.

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

Есть и более простой вариант с 2-мя А-записями DNS с минимальным TTL. В сочетании с мониторингом это дает в случае аварии потерю работоспособности для половины клиентов на 4-5 минут.

Это время, которое требуется для обновления DNS после удаления А-записи ставшего недоступным сервера.



Настройка бэкенда

Специальных настроек не требуется. Просто существует две версии сайта, которые каким-то образом могут существовать и синхронизировать данные.
Для сравнительно небольших проектов это может быть просто синхронизация БД с рабочего сервера по CRON. В Nginx для одного upstream из примера указано backup, т.е. на VM 2.2 запросы пойдут только если VM 1.2 недоступен.

Балансировщик нагрузки - добавление базы и хранилища сессий

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



Получен балансировщик нагрузки серверов с возможностью масштабироваться как вертикально, так и горизонтально.

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

Подробнее про upstream в Nginx

Сказать спасибо