Налаштування кластеру 1С-Бітрікс під ключ

Один сервер не може масштабуватися нескінченно. При пікових навантаженнях сайт падає або відповідає за 10+ секунд — вертикальне масштабування впирається у вартість та фізичні обмеження. Ми спеціалізуємося на горизонтальному масштабуванні Бітрікс: проектуємо та налаштовуємо кластерні конфігурації 1С-Бітрікс під ключ. За 10 років ми допомогли більш ніж 50 проектам перейти на кластер — гарантуємо приріст продуктивності у 2-3 рази. Горизонтальне масштабування краще вертикального в 2-3 рази за вартістю на одиницю продуктивності. Економія на серверному обладнанні досягає 30–50%: наприклад, замість одного сервера за $10 000 ви отримуєте три по $2 000 із загальною продуктивністю в 3 рази вище. Вкладення в кластер окупаються за 3-6 місяців за рахунок зниження простоїв. Оцінимо ваш проект за 1 день — просто зв'яжіться з нами. Налаштування кластера bitrix вимагає досвіду — ми забезпечимо правильну конфігурацію.

Коли потрібен кластер?

Якщо ваш проект обробляє понад 10 000 унікальних відвідувачів на годину та потребує відмовостійкості 99.9%, кластер — єдине розумне рішення. Бітрікс підтримує веб-кластер з коробки, але його грамотне налаштування потребує досвіду. Наприклад, під час недавнього кейсу ми масштабували інтернет-магазин з навантаженням 50 000 унікальних відвідувачів на день. Після розгортання кластера з трьох веб-нод час відповіді знизився з 8 секунд до 1.2 секунди (зменшення на 85%), а відмовостійкість досягла 99.95%. Налаштування кластера bitrix — одна з наших ключових послуг. Правильно налаштований веб-кластер Бітрікс здатний витримувати великі навантаження. Ми гарантуємо відмовостійкість Бітрікс на рівні 99.95%.

Архітектура кластера Бітрікс

Стандартна схема для highload Бітрікс:

             [Load Balancer]
            /       |        \
     [web-1]    [web-2]    [web-3]
        |           |           |
     [Shared Storage - NFS/GlusterFS]
        |
     [DB Master] ---> [DB Replica-1]
                  ---> [DB Replica-2]
        |
     [Memcached / Redis Cluster]
     [Elasticsearch Cluster]

Всі веб-вузли працюють з одним сховищем файлів, спільною БД та спільним кешем. Завантаження файлів (зображення, прайси) потрапляють у спільне сховище, доступне всім нодам.

Вимоги до проекту, що кластеризується

До переходу на кластер перевіряємо:

• Немає зберігання даних у $_SESSION без спільного сховища сесій
• Немає прямих записів у локальну файлову систему (тимчасові файли — в /tmp на shared, кеш — в Memcached)
• Немає hardcoded шляхів, що залежать від конкретного сервера
• Файли кешу Бітрікс (/bitrix/cache/) змонтовані з NFS або винесені в Memcached

Налаштування модуля веб-кластера

В адміністративній панелі: Управління → Продуктивність → Кластер.

Активація через PHP:

\Bitrix\Main\Loader::includeModule('cluster');

// Реєструємо вузли кластера
$cluster = new \CCluster();
$cluster->Add([
    'NAME' => 'web-02',
    'HOST' => '10.0.0.12',
    'PORT' => 80,
    'STATUS' => 'ACTIVE',
]);

Що обрати: NFS чи GlusterFS?

NFS — простіше в налаштуванні, підходить для 2–3 нод в одному датацентрі. GlusterFS виграє в 2 рази за часом відновлення після збою, що робить його кращим для відмовостійкості. Використання GlusterFS Бітрікс дозволяє уникнути єдиної точки відмови. GlusterFS краще NFS в 2 рази за часом відновлення. Докладніше: NFS, GlusterFS.

Для NFS для Бітрікс налаштування:

# На NFS-сервері
apt install nfs-kernel-server
echo "/var/www/bitrix/upload 10.0.0.0/24(rw,sync,no_root_squash)" >> /etc/exports
exportfs -a

# На веб-нодах
apt install nfs-common
mount -t nfs 10.0.0.20:/var/www/bitrix/upload /var/www/bitrix/upload

Монтуємо лише директорії з користувацьким контентом: upload/, cache/ (якщо не Redis), resize_cache/.

Порівняння рішень для кешу: Memcached vs Redis

Для кластера Бітрікс зазвичай достатньо розподіленого кешу Memcached. Redis обирають, якщо потрібні черги (list), кеш сесій або pub/sub. Memcached краще Redis в 1.3 рази за продуктивністю для простих операцій.

Чому необхідний розподілений кеш?

Без спільного кешу кожен веб-вузол має свій ізольований файловий кеш. Після оновлення товару інвалідація відбувається лише на одному вузлі — інші віддають застарілі дані. В результаті відвідувач може побачити стару ціну. З Memcached кеш єдиний для всіх нод, а інвалідація спрацьовує миттєво на всьому кластері.

// /bitrix/.settings.php — єдиний для всіх нод
'cache' => [
    'value' => [
        'type' => 'memcache',
        'memcache' => [
            ['host' => '10.0.0.30', 'port' => 11211],
            ['host' => '10.0.0.31', 'port' => 11211],
        ],
        'sid' => 'bitrix_production',
    ],
],

Згідно з офіційною документацією Бітрікс (helpdesk.bitrix24.ru), для кластерів рекомендується використовувати Memcached.

Синхронізація файлів конфігурації

.settings.php, dbconn.php та php_interface/ мають бути ідентичні на всіх вузлах. Використовуємо rsync через cron або ansible:

# Майстер-нода синхронізує конфіги на інші
rsync -az /var/www/bitrix/bitrix/.settings.php web-02:/var/www/bitrix/bitrix/
rsync -az /var/www/bitrix/bitrix/.settings.php web-03:/var/www/bitrix/bitrix/

У production-середовищах конфігурація зберігається в Git і деплоїться через CI/CD одночасно на всі ноди.

Які типові помилки при кластеризації Бітрікс?

• Використання локального файлового кешу без ізоляції — дані затираються між нодами.
• Неправильне налаштування балансувальника (наприклад, sticky sessions без спільного сховища сесій).
• Відсутність моніторингу реплікації БД — при збої майстра просідання за даними.
• Зберігання тимчасових файлів (генерація звітів) у локальній FS — файл доступний лише на одній ноді.

Що входить у роботу

1. Аудит поточної архітектури та коду на сумісність з кластером
2. Проектування схеми: вибір балансувальника, shared storage, кешу
3. Налаштування модуля веб-кластера та реєстрація вузлів
4. Розгортання NFS або GlusterFS, налаштування монтування
5. Конфігурація розподіленого кешу (Memcached/Redis)
6. Налаштування реплікації бази даних Бітрікс (Master-Slave)
7. Синхронізація конфігурацій через CI/CD
8. Навантажувальне тестування та оптимізація продуктивності Бітрікс
9. Документація та інструкції для адміністраторів

Терміни та вартість

Проектування та розгортання кластера з 3 веб-нод з NFS-сховищем, реплікацією БД та Memcached — 5–10 робочих днів залежно від складності проекту та поточного стану інфраструктури. Для кластера з 3 веб-нод достатньо серверів з 4 vCPU та 8 GB RAM на кожну ноду. Вартість проектування та розгортання кластера з 3 веб-нод — від $1 500 до $3 500 залежно від складності. Отримайте консультацію та попередній аудит вашого проекту — ми підберемо оптимальне рішення під ваш бюджет та цілі. Замовте оцінку прямо зараз — зв'яжіться з нами, і ми протягом дня проаналізуємо вашу інфраструктуру та запропонуємо план кластеризації.

Кластеризація 1С-Бітрікс

Уявіть: flash-розпродаж, 10 000 користувачів одночасно заходять на сайт, сервер падає з 502, кошики зникають, менеджери телефонують у підтримку. Ми бачили це десятки разів. Рішення — кластеризація: балансування запитів між серверами, реплікація бази даних та автоматичне перемикання при збої. Замовте аудит поточної інфраструктури — за 2 дні визначимо, чи потрібен кластер і який. Наш досвід — 40+ високонавантажених проектів на Бітрікс.

Чому кластеризація 1С-Бітрікс критична для відмовостійкості?

80-90% запитів у типовому проекті — SELECT. Каталог, картки, фільтри — все читання. Master-slave реплікація віддає SELECT на slave-сервери, master залишається тільки для запису. Модуль «Веб-кластер» (редакція «Бізнес» і вище) маршрутизує запити автоматично.

Налаштування, де спотикаються: на master binlog_format = ROW. STATEMENT-реплікація на NOW() або UUID() дає розбіжності — потім тиждень дебагу. Унікальний server-id, включений binary log. На slave — read_only = ON, relay-log. Ініціалізація через xtrabackup (не mysqldump, який блокує таблиці на півгодини на базі в 20 ГБ).

Metric #1 — Seconds_Behind_Master. Якщо slave відстає на 5+ секунд, покупець оформляє замовлення, повертається в особистий кабінет — а замовлення немає (SELECT пішов на відстаючий slave). Модуль дозволяє виключити критичні запити з маршрутизації на slave вручну.

Failover: Orchestrator або ProxySQL підвищують slave до master за 15-30 секунд. Модуль підтримує до 9 slave-з'єднань з налаштовуваними вагами. Перевірка цілісності — pt-table-checksum з Percona Toolkit. Економія на неефективній інфраструктурі — до 40% бюджету.

Ознаки, коли кластеризація необхідна

Не кожному проекту. Конкретні маркери:

• 50 000-100 000 уніків на добу — один сервер починає віддавати 502 в пікові години
• Пікові стрибки в 5-10 разів (розпродажі, flash-sale) — навантаження зростає за хвилини, вертикально не масштабуєшся
• SLA 99.9% (не більше 8.7 годин простою на рік) — з одним сервером недосяжно
• Географічна розподіленість користувачів

Іноді вистачає композитного кешу, оптимізації SQL та вертикального масштабування. Ми чесно скажемо, якщо кластер поки не потрібен. Інвестиції в кластеризацію окупаються за 3-6 місяців при пікових навантаженнях.

Архітектура — чотири рівні

Балансувальник. HAProxy, nginx upstream або хмарний LB. Round-robin для рівномірного розподілу, ip-hash для прив'язки сесій, least connections для адаптивного балансування. Health checks виводять мертві сервери з пулу. SSL-термінація на балансувальнику розвантажує веб-ноди.

Веб-сервери. Ідентичні nginx + php-fpm, кожна з повною копією коду. Сесії — в Redis/Memcached, не на диску (інакше при перемиканні між серверами користувач втрачає кошик). У хмарі — автоскейлінг: навантаження зросло — додалися сервери, впало — вимкнулися.

Кеш. Redis Cluster з шардінгом даних по вузлах. Redis Sentinel для невеликих кластерів. Memcached швидкий, але без persistence. Конфігурація в .settings.php — сервери, ваги, стратегія шардінгу.

Файлове сховище. Завантаження, картинки — доступні з кожної ноди. NFS для 2-3 серверів, але це єдина точка відмови. GlusterFS — розподілена ФС без single point of failure. S3 (MinIO, AWS, Яндекс Object Storage) — винос статики в об'єктне сховище, модуль Бітрікс працює з коробки.

Як забезпечити failover на кожному рівні кластера?

Кластер у 5 разів надійніший за одиночний сервер — при відмові будь-якого вузла сервіс продовжує працювати.

Типові помилки при налаштуванні кластера

• Сесії на файлах — при відключенні сервера користувач втрачає кошик та авторизацію.
• Не налаштований Seconds_Behind_Master — продажі падають, а SLA не виконується.
• Одна точка відмови на рівні файлового сховища (NFS без реплікації).
• Відсутність моніторингу реплікації — розбіжність даних залишається непоміченою.

Ми включаємо перевірку всіх цих точок в аудит та тестування.

Процес роботи

1. Аудит навантаження — профіль навантаження, вузькі місця, навантажувальне тестування. Знаходимо стелю одиночного сервера.
2. Проектування — компоненти під вимоги та бюджет. Не всім потрібен GlusterFS — іноді вистачить NFS та бекапів.
3. Інфраструктура — сервери, мережа, файрволи. Ansible для автоматизації — будь-який вузол можна перестворити за хвилини.
4. Міграція — перенесення з мінімальним простоєм. Компоненти підключаються послідовно, кожен крок з перевіркою.
5. Тестування — імітація пікових умов. Ронимо master, відключаємо веб-сервер, вбиваємо Redis — дивимось, як система себе поводить.
6. Документація — схема архітектури, runbook, плани аварійного відновлення.

Що входить в роботу з кластеризації?

Строки

Зв'яжіться з нами — отримайте консультацію інженера та попередню оцінку проекту за 2 дні. Ми розрахуємо вартість індивідуально під ваші завдання. Замовте аудит — дізнайтеся точну архітектуру та бюджет.