Один сервер не може масштабуватися нескінченно. При пікових навантаженнях сайт падає або відповідає за 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 | GlusterFS |
|---|---|---|
| Простота налаштування | Висока | Середня |
| Відмовостійкість | Низька (SPOF) | Висока (реплікація) |
| Продуктивність | Висока при малій кількості нод | Залежить від конфігурації |
| Підходить для | 2–3 ноди, 1 ЦОД | 3+ ноди, розподілені ЦОД |
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 |
|---|---|---|
| Тип зберігання | In-memory | In-memory + disk persist |
| Підтримка структур | Тільки ключ-значення | Рядки, списки, множини |
| Простота | Висока | Середня |
| Продуктивність | Дуже висока | Висока (на 30% нижча для простих операцій) |
Для кластера Бітрікс зазвичай достатньо розподіленого кешу 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 — файл доступний лише на одній ноді.
Що входить у роботу
- Аудит поточної архітектури та коду на сумісність з кластером
- Проектування схеми: вибір балансувальника, shared storage, кешу
- Налаштування модуля веб-кластера та реєстрація вузлів
- Розгортання NFS або GlusterFS, налаштування монтування
- Конфігурація розподіленого кешу (Memcached/Redis)
- Налаштування реплікації бази даних Бітрікс (Master-Slave)
- Синхронізація конфігурацій через CI/CD
- Навантажувальне тестування та оптимізація продуктивності Бітрікс
- Документація та інструкції для адміністраторів
Терміни та вартість
Проектування та розгортання кластера з 3 веб-нод з NFS-сховищем, реплікацією БД та Memcached — 5–10 робочих днів залежно від складності проекту та поточного стану інфраструктури. Для кластера з 3 веб-нод достатньо серверів з 4 vCPU та 8 GB RAM на кожну ноду. Вартість проектування та розгортання кластера з 3 веб-нод — від $1 500 до $3 500 залежно від складності. Отримайте консультацію та попередній аудит вашого проекту — ми підберемо оптимальне рішення під ваш бюджет та цілі. Замовте оцінку прямо зараз — зв'яжіться з нами, і ми протягом дня проаналізуємо вашу інфраструктуру та запропонуємо план кластеризації.