В архитектурных системах, обслуживающих популярные веб-сайты, типовой задачей является балансировка нагрузки. Чаще всего для реализации задачи применяется front-end сервер Haproxy. Он может быть один или несколько — функция данного программного обеспечения заключается в переадресации запросов пользователя на один из back-end серверов. Для Haproxy настройка базовой конфигурации не представляет сложностей.
Используемые back-end сервера перечисляются в конфигурационном файле Haproxy, также задается стратегия согласно которой будут распределяться запросы. Основная функция системы — снижение нагрузки на веб-серверы, непосредственно обрабатывающие скрипты, также подобная реализация обеспечивает некоторую избыточность.
При выходе из строя одного из back-end серверов Haproxy автоматически определит, что он недоступен и не будет направлять на него запросы. Это означает возрастание нагрузки на доступные back-end сервера (часть пользователей на короткое время увидят ошибку на сайте), однако система останется работоспособна.
В качестве сервера обрабатывающего скрипты может применяться любое программное обеспечение — чаще всего это Apache или широко использующийся в нагруженных системах Nginx с PHP-FPM (Nginx используется и как фронтэнд).
Настройку веб-сервера в рамках статьи разбирать не будем и условно примем, что используем Nginx.
В примере Nginx используется исключительно для обработки пользовательских запросов.
Будем использовать три VDS, объединенных в локальную сеть. Этого можно не делать — разницы помимо белых IP адресов не будет.
Настраиваем два сервера (их может быть любое количество) таким образом, чтобы они начали отдавать содержимое файла index.html.
На первой машине — Server 1:
mcedit /var/www/example.com/index.html
<html>
<p>Server 1</p>
</html>
На втором VDS аналогичным образом добавляем строку Server 2
Цель настройки — заставить систему отдавать содержимое index.html на рандомном сервере при обращении к IP адресу front-end сервера.
На третьем сервере устанавливаем программный пакет Haproxy.
apt-get update
apt-get install haproxy -y
Проверяем статус службы
service haproxy status
Вывод пуст — причина в том, что данное ПО предполагает его непосредственное включение в конфигурационном файле
mcedit /etc/default/haproxy
ENABLE=1
Службу запустим после внесения необходимых коррективов.
Переходим в главный конфигурационный файл
mcedit /etc/haproxy/haproxy.cfg
frontend haproxy_in bind *:80
default_backend haproxy_http
После указания функции сервера — frontend задаем произвольное имя — например, haproxy_in, затем задаем дополнительные опции
backend haproxy_http
balance roundrobin
mode http
server be1 172.16.11.48:80 check
server be2 172.16.11.49:80 check
Перечисляем сервера с Nginx, которые будут обрабатывать контент — имена задаются произвольно, после локальных IP адресов указываем check — благодаря этой опции haproxy будет каждый раз проверять доступность сервера прежде чем направлять на него запросы пользователя.
Здесь используется принцип распределения запросов roundrobin, который является стандартным и часто применяется. Но используются и другие.
Даем команду на перечитывание конфигурационных файлов и запуск службы
service haproxy reload
В браузере проверяем результат — при обращении по IP каждый раз будет отдаваться строка Server 1 или Server 2.
Фронтэнд сервера тоже могут оказываться недоступны и их нужно дублировать и объединять в кластеры избегая образования единой точки отказа.