Ви запускаєте рекламу, сайт на 1С-Бітрікс захльостує 3000+ одночасних відвідувачів, і сервер лягає. MySQL упирається в 100% CPU, кеш скидається кожні дві секунди, користувачі бачать 502 Bad Gateway. Знайома картина? Типове рішення — веб-кластер із трьох нод з балансуванням навантаження та реплікацією бази даних. Правильне налаштування такого кластера дозволяє витримувати до 10 000 відвідувачів, а вартість володіння знижується на 30–50% за рахунок дешевих реплік. Наприклад, клієнт зекономив $1200/міс після переходу на кластер. Ми налаштували вже 50+ кластерів і маємо сертифікат Bitrix Partner. Гарантія на роботи — 1 рік.
Модуль «Веб-кластер» у Бітрікс — це набір механізмів, які змушують кілька серверів працювати як єдине ціле: спільний кеш, реплікація файлів, єдині сесії. Без правильної конфігурації кожного компонента кластер працює непередбачувано — один вузол інвалідує кеш, інший віддає старі дані. Нижче розберемо, що входить до модуля, як налаштувати read/write split та синхронізацію файлів, і які підводні камені на вас чекають.
Що входить до модуля веб-кластера
Модуль cluster (BitrixVM Enterprise або окрема ліцензія) включає:
- Управління вузлами — реєстрація серверів, моніторинг доступності.
- Балансування навантаження — перенаправлення запитів між вузлами.
- Синхронізація кеша — інвалідація по всіх нодах через спільний Memcached.
- Реплікація файлів — синхронізація
upload/між серверами. - Реплікація БД — налаштування read/write split для MySQL.
Офіційна документація 1С-Бітрікс: «Модуль cluster дозволяє об'єднати кілька серверів у кластер для забезпечення відмовостійкості та масштабування».
Як активувати та налаштувати вузли?
Модуль встановлюється на кожній ноді, але керується через одну адміністративну панель. Додавання ноди через API:
\Bitrix\Main\Loader::includeModule('cluster'); $result = \Bitrix\Cluster\Node::add([ 'NAME' => 'web-02', 'HOST' => '10.0.0.12', 'PORT' => 443, 'HTTPS' => 'Y', 'STATUS' => 'ACTIVE', 'SORT' => 100, ]); if ($result->isSuccess()) { echo 'Нода додана: ' . $result->getId(); } Read/Write Split для бази даних
Найцінніша частина кластера для highload — направлення SELECT-запитів на репліки, а INSERT/UPDATE/DELETE на майстер. Знижує навантаження на майстер на 60–80% при типовому співвідношенні читання/запис 10:1. Це в 3 рази ефективніше за простого масштабування.
У .settings.php:
'connections' => [ 'value' => [ 'default' => [ 'className' => '\Bitrix\Main\DB\MysqlConnection', 'host' => 'db-master:3306', 'database' => 'bitrix', 'login' => 'bitrix', 'password' => 'secret', ], 'slave' => [ 'className' => '\Bitrix\Main\DB\MysqlConnection', 'host' => 'db-replica:3306', 'database' => 'bitrix', 'login' => 'bitrix_ro', 'password' => 'secret_ro', ], ], ], Налаштування в модулі кластера вказує, які запити йдуть на яке з'єднання. Транзакційні запити примусово маршрутизуються на майстер незалежно від типу операції.
Синхронізація файлів: вбудований модуль vs lsyncd
| Критерій | Вбудована синхронізація | lsyncd + rsync |
|---|---|---|
| Залежність від PHP | Так, через агенти | Ні, на рівні ОС |
| Продуктивність | Середня, при великій кількості файлів гальмує | Висока, використовує inotify |
| Складність налаштування | Низька, через адмінку | Середня, вимагає конфіга LUA |
| Надійність | Залежить від агентів Бітрікса | Висока, незалежний демон |
Вбудований модуль вміє синхронізувати файли між нодами через HTTP-запити до агентів. При завантаженні файлу на ноді-1 модуль автоматично копіює його на ноду-2 та ноду-3. Для захисту агента обмежте доступ по IP в Nginx: allow 10.0.0.0/24; deny all;.
Альтернатива — inotify + rsync через lsyncd. Працює швидше та надійніше для великих обсягів. Приклад конфіга lsyncd:
sync { default.rsync, source = "/var/www/bitrix/upload", target = "web-02:/var/www/bitrix/upload", delay = 1, rsync = { compress = false, owner = true, perms = true, } } Чому сесії потрібно зберігати в Memcached?
Сесії у файловій системі в кластері непрацездатні — запити від одного користувача можуть потрапляти на різні ноди. Переводимо на Memcached або Redis. Sticky sessions на балансувальнику — тимчасове рішення, не рекомендується: при виході ноди з ладу всі її користувачі втрачають сесію. Ми завжди налаштовуємо централізоване сховище.
Приклад конфігурації PHP для Memcached:
session.save_handler = memcached session.save_path = "10.0.0.30:11211,10.0.0.31:11211" Порівняння балансувальників для веб-кластера 1С-Бітрікс
| Характеристика | Nginx | HAProxy | Хмарний LB (AWS, Yandex) |
|---|---|---|---|
| Простота налаштування | Висока | Середня | Низька (через API) |
| SSL offloading | Так | Так | Так |
| Sticky sessions | Так (ip_hash) | Так (cookie insert) | Так |
| Ціна | Безкоштовно | Безкоштовно | Плата за трафік |
Як виконати перевірку роботи кластера?
Використовуйте shell-скрипт для перевірки статусу нод та очищення кеша:
# Перевірка статусу нод curl http://admin:[email protected]/bitrix/admin/cluster_nodes.php?ajax=Y # Очищення кеша на всіх нодах php -r "\Bitrix\Main\Loader::includeModule('cluster'); \Bitrix\Cluster\Cache::clearAll(); echo 'Cache cleared';" Покрокова інструкція налаштування веб-кластера
- Встановіть BitrixVM Enterprise на кожну ноду.
- Налаштуйте реплікацію MySQL: майстер-слейв.
- В адмінці Бітрікс додайте ноди в модуль кластера.
- Налаштуйте read/write split у
.settings.php. - Виберіть спосіб синхронізації файлів: вбудований або lsyncd.
- Перенесіть сесії на Memcached або Redis.
- Налаштуйте балансувальник (nginx, haproxy або хмарний).
- Перевірте працездатність через
cluster_nodes.php.
Типові помилки при налаштуванні
Найчастіше зустрічається ігнорування кешування: без спільного Memcached кеш інвалідується окремо на кожній ноді, що призводить до неконсистентності даних. Також нерідкі неправильні права доступу до агентів синхронізації файлів — агент не може прочитати файл або записати його на іншу ноду. Відсутність моніторингу зв'язності нод призводить до того, що одна нода випадає, а трафік продовжує на неї направлятися. І нарешті, використання sticky sessions без централізованого сховища сесій — при виході ноди всі її користувачі втрачають дані.
Детальніше про концепцію кластерів читайте на Wikipedia.
Наша команда має 10+ років досвіду в налаштуванні кластерів 1С-Бітрікс. Зв'яжіться з нами для аудиту вашого кластера — отримайте план оптимізації під ваше навантаження. Замовте консультацію, і ми допоможемо налаштувати кластер, який витримає будь-який пік.