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

Кластеризація 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 дні. Ми розрахуємо вартість індивідуально під ваші завдання. Замовте аудит — дізнайтеся точну архітектуру та бюджет.