Перейти к содержимому
BXWiki

Сайт на нескольких веб-узлах - балансировщик, файлы, выкладка

Разносим сайт на несколько веб-узлов за общим балансировщиком и разбираем файловую половину задачи. Раздача запросов, общий каталог загрузок, локальный кэш узла и выкладка кода сразу на все машины. Базу, сессии и распределённый кэш разбирает соседняя страница про устройство веб-кластера.

Решение

Раздаём запросы балансировщиком

Описываем узлы в блоке upstream:

upstream backend {
    # ip_hash;                    # привязка посетителя к одному узлу
    server 10.0.0.11:80 weight=3 max_fails=3 fail_timeout=30s;
    server 10.0.0.12:80          max_fails=3 fail_timeout=30s;
}
server {
    listen 80;
    location / {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        proxy_pass http://backend;
    }
}

Вес узла задаёт его долю запросов, а max_fails с fail_timeout выводят упавший узел из раздачи. Заголовки нужны узлу, чтобы он видел адрес посетителя, а не адрес балансировщика.

Проверяем живость узлов

Опрашиваем каждый узел напрямую:

Окно терминала
for n in 10.0.0.11 10.0.0.12; do
  curl -s -o /dev/null -w "$n %{http_code} %{time_total}\n" \
       -H 'Host: example.ru' "http://$n/"
done
# узел за узлом, минуя балансировщик и его кэш соединений

Проверка по корню сайта проходит через PHP и базу, а не только через nginx. Узел, отвечающий заметно медленнее остальных, находится именно так, до первых жалоб посетителей.

Держим каталог загрузок общим

Монтируем один каталог загрузок на все узлы:

Окно терминала
# /etc/fstab на каждом узле
10.0.0.20:/export/upload  /home/bitrix/www/upload  nfs  rw,hard,noatime  0 0
mount -a && sudo -u bitrix touch /home/bitrix/www/upload/.probe
# запись проверяют от пользователя сайта, а не от администратора

Файл, загруженный через административную часть, ложится на тот узел, который обработал запрос. Без общего каталога остальные узлы отдают на эту же картинку ошибку 404. Полностью снимает вопрос вынос файлов в облачное хранилище, и тогда монтировать между узлами уже нечего.

Синхронизируем то, что не смонтировать

Раскладываем изменения по узлам синхронизацией:

Окно терминала
csync2 -xv                      # двусторонняя сверка узлов по расписанию
lsyncd -rsync /home/bitrix/www/upload \
       bitrix@10.0.0.12:/home/bitrix/www/upload   # односторонняя, по событию

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

Оставляем кэш узла локальным

Исключаем каталоги кэша из синхронизации:

/etc/csync2.cfg
exclude /home/bitrix/www/bitrix/cache;
exclude /home/bitrix/www/bitrix/managed_cache;
exclude /home/bitrix/www/bitrix/stack_cache;

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

Выкладываем код сразу на все узлы

Раскатываем сборку и сбрасываем кэш кода:

Окно терминала
for n in 10.0.0.11 10.0.0.12; do
  rsync -a --delete --exclude '/upload/' /build/www/ bitrix@$n:/home/bitrix/www/
  ssh bitrix@$n 'sudo systemctl reload php-fpm'   # сброс кэша кода на узле
done

Кэш акселератора живёт в памяти каждого узла отдельно, поэтому сбрасывают его на всех машинах. Пока один узел отдаёт старый код, посетители видят две разные версии одной страницы.

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

Типичные проблемы

Картинка из административной части видна не всем посетителям.

Файл лёг на тот узел, который обработал загрузку, а каталог /upload у каждого узла свой. Каталог монтируют один на все машины либо синхронизируют между ними.

Посетителя выбрасывает из личного кабинета при переходах.

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

После выкладки часть запросов отдаёт старый код.

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

Узел выключили, а посетители всё равно получают ошибку.

Балансировщик убирает узел из раздачи только после нескольких неудачных попыток подряд. Пороги задают max_fails и fail_timeout, а узел снимают заранее.

К узлу открывается прямой доступ мимо балансировщика.

Наружу торчат порты самих узлов, а не только порты балансировщика площадки. Публично оставляют 80 и 443 на балансировщике, служебные порты закрывают правилами сети.

Частые вопросы

Нужен ли модуль веб-кластера ради нескольких веб-узлов?

Для раздачи запросов не нужен: балансировщик и общий каталог файлов работают сами по себе. Модуль отвечает за балансировку чтения базы, хранение сессий и распределённый кэш.

Что выбрать: общий сетевой каталог или синхронизацию?

Сетевой каталог даёт одну версию файла для всех узлов ценой задержки на каждом обращении. Синхронизация быстрее, но между узлами появляется расхождение на длину цикла.

Почему после второго узла слетает авторизация?

Файловые сессии лежат на узле, который обслуживал вход, а следующий запрос уходит на соседний. Сессии выносят в общее хранилище либо привязывают посетителя к узлу на балансировщике.

Куда ставить расписание при нескольких узлах?

На один узел. Запущенное на каждой машине, расписание выполняет одни и те же задания по нескольку раз: письма уходят дублями, а обмен стартует параллельно сам с собой.

Насколько быстрее станет сайт от второго узла?

При неизменном объёме данных добавление узла даёт прирост около 90-95%. На больших объёмах рост сублинейный, поэтому оборудование берут с запасом 10-30%.

Смежное

Первоисточник