Балансировщик нагрузки серверов — аппаратная схема или один сервер, распределяющий запросы к веб-приложению. Целью использования балансировщика является достижение отказоустойчивости и распределение нагрузки.
Создание отказоустойчивого архитектурного решения для работы веб-проекта является непростой задачей. Каждый проект индивидуален и имеет особенности, которые нужно учитывать.
Варианты организации отказоустойчивости существуют, для одного крупного проекта может задействоваться от 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