Балансировщик нагрузки серверов — аппаратная схема или один сервер, распределяющий запросы к веб-приложению. Целью использования балансировщика является достижение отказоустойчивости и распределение нагрузки.
Создание отказоустойчивого архитектурного решения для работы веб-проекта является непростой задачей. Каждый проект индивидуален и имеет особенности, которые нужно учитывать.
Варианты организации отказоустойчивости существуют, для одного крупного проекта может задействоваться от 2 до 20-30 серверов и больше.
![Балансировщик нагрузки серверов](https://server-gu.ru/wp-content/uploads/2018/10/balancer-vm.png)
Балансировщик нагрузки серверов на примере
Разберем простую схему, которая довольно часто применяется на практике.
Потребуются 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 недоступен.
![Балансировщик нагрузки - добавление базы и хранилища сессий](https://server-gu.ru/wp-content/uploads/2018/10/balancer-vm2.png)
Это самый простой вариант для отказоустойчивости. Если требуется балансировка нагрузки добавляются дополнительные элементы, обычно это общее хранилище сессий и база данных.
Получен балансировщик нагрузки серверов с возможностью масштабироваться как вертикально, так и горизонтально.
Авария в одном из датацентров не станет критической для проекта, также он сможет продолжать работать при неисправности одной из виртуальных машин, применяемых в качестве фронтэнда/бэкенда.
Подробнее про upstream в Nginx