Создание пула серверов

Пул серверов — это управляемая группа узлов BitrixEnv с распределёнными ролями (веб, база, кэш, push, поиск). Пул превращает разрозненные машины в единый кластер, которым вы управляете из одного меню на master-узле.

Зачем нужен пул серверов

Пока проект живёт на одной машине, роли web, MySQL и memcached совмещены. Как только нагрузка растёт, компоненты разносят по отдельным серверам — и здесь нужен пул как механизм централизованного управления.

• Масштабирование: добавляете веб-ноды под рост трафика без переустановки.
• Отказоустойчивость: репликация MySQL master → slave, несколько веб-узлов за балансировщиком.
• Единое управление: роли, конфиги и обновления раскатываются с master-узла на все хосты.

Роли узлов в пуле

Каждый узел пула несёт одну или несколько ролей. Master-узел (роль управления) хранит конфигурацию и раскатывает её на остальные через Ansible и SSH.

На малых инсталляциях все роли живут на одном хосте. По мере роста их «размазывают» по отдельным серверам, не меняя логику управления.

Создание пула на master-узле

Пул создаётся на будущем master-узле через меню. До создания в меню доступен пункт вида Create Management pool of servers.

1. Убедитесь, что задан корректный hostname — он станет именем узла в пуле и его сложно менять потом.
2. Запустите /root/menu.sh и выберите создание пула.
3. Окружение сгенерирует SSH-ключи и настроит роль управления на текущем хосте.

Добавление серверов в пул

Новые узлы добавляются с master-узла. Требования к добавляемой машине: та же линейка ОС, установленный BitrixEnv, сетевая доступность и открытый SSH.

1. В меню выберите управление серверами пула → добавить сервер.
2. Укажите IP или hostname нового узла и пароль root (для первичного обмена ключами).
3. Master скопирует SSH-ключ и через Ansible настроит узел, включив его в пул.

После добавления узел появляется в списке пула со статусом. Дальнейшее взаимодействие идёт по ключам — пароль больше не требуется.

Распределение ролей по узлам

Когда узлы в пуле, роли назначают через соответствующие разделы меню. Типовая схема разнесения для нагруженного магазина:

• Узел 1 (mgmt + web): управление и обработка запросов;
• Узел 2 (web): дополнительная веб-нода за балансировщиком;
• Узел 3 (mysql master): основная база;
• Узел 4 (mysql slave): реплика для чтения и отказоустойчивости;
• memcached — на отдельном узле или распределённо на веб-нодах.

Настройка репликации MySQL выполняется из раздела конфигурации БД: назначаете master и slave, окружение само настраивает bin-log и подключение реплики.

Проверка состояния пула

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

• список узлов и ролей — в разделе управления пулом;
• связность по SSH — ssh bx-node2 hostname должно отработать без пароля;
• репликация — статус slave в разделе MySQL (задержка, ошибки);
• службы на узле — systemctl status nginx php-fpm mysqld memcached.

В админке продукта корректность кластера отражает раздел Настройки → Веб-кластер: там видно веб-ноды, memcached и статус репликации базы.

Эксплуатация и подводные камни

Кластер требует дисциплины. Частые проблемы и как их избегать:

• Рассинхрон времени. Настройте NTP на всех узлах — иначе репликация и логи «поедут».
• Firewall между узлами. Порты MySQL (3306), memcached (11211), push и SSH должны быть открыты внутри пула, но закрыты наружу.
• Ручные правки конфигов. Меню перезапишет их на всех узлах — вносите изменения централизованно.
• Единая точка отказа. Один master mgmt — это нормально, но бэкап его конфигурации обязателен.

Итог

Создание пула — это назначение master-узла, добавление серверов по SSH и распределение ролей web, MySQL, memcached и push через меню. Пул даёт масштабирование и отказоустойчивость при едином управлении с одной точки.

Проектирование кластера под конкретную нагрузку, настройка репликации, балансировки и мониторинга — наша профильная задача. В B2Bsite мы строим отказоустойчивые инсталляции 1С-Битрикс и сопровождаем их, чтобы рост трафика не превращался в аварию.