Послуги з кластеризації та масштабування 1С-Бітрікс

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

Master-Slave реплікація MySQL — ядро всієї затії

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

Налаштування, де зазвичай спотикаються:

На master: binlog_format = ROW. Не STATEMENT — на складних запитах із NOW(), UUID() або недетермінованими функціями STATEMENT-реплікація дає розбіжності між master і slave. Дебажити потім тиждень. Плюс обов'язково унікальний server-id, увімкнений binary log.

На slave: read_only = ON, свій server-id, relay-log. Ініціалізацію робимо через xtrabackup — mysqldump на базі в 20 ГБ заблокує таблиці на півгодини.

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

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

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

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

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

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

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

Балансувальник. 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 на кожному рівні

Наш підхід

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

Терміни