Уявіть: ваш інтернет-магазин на 1С-Бітрікс «Бізнес» починає гальмувати під навантаженням у годину пік — при 500 одночасних сесіях час відповіді падає до 10 секунд. Клієнти скаржаться, менеджери нервують, а ви розумієте — час масштабуватися. Ми, як команда сертифікованих спеціалістів по Бітрікс з 7-річним досвідом та більш ніж 100 міграціями, часто стикаємося з такою ситуацією. Перехід на редакцію «Ентерпрайз» — це не просто зміна ключа, а архітектурна перебудова, яка вирішує проблему навантажень та відмовостійкості.
Чим «Ентерпрайз» відрізняється від «Бізнес»
| Функція | «Бізнес» | «Ентерпрайз» |
|---|---|---|
| Кількість сайтів | Обмежена ліцензією | Необмежено |
| Кластеризація | Часткова | Повноцінний кластер |
| Кешування | Стандартне | Кластерне (memcached) |
| Пошук | Вбудований | Sphinx/Elasticsearch |
| Файлове сховище | Локальне | S3-сумісне |
| Підтримка | Стандартна | Пріоритетна SLA |
Необмежена кількість сайтів — в «Ентерпрайз» явно дозволена необмежена кількість доменів і сайтів, що принципово для холдингів та агентств. Кластеризація без обмежень: повноцінний веб-кластер з кількома веб-серверами за балансувальником nginx, розподілене сховище сесій через memcached або Redis, реплікація бази даних, окремий сервер пошуку Sphinx. Розширене кешування через \Bitrix\Main\Data\Cache в кластерному режимі. Рольова модель на рівні кількох сайтів через b_user_site. Пріоритетна підтримка з SLA від вендора. Сховище файлів на S3-сумісних об'єктних сховищах через модуль clouds.
Коли перехід на «Ентерпрайз» виправданий?
Перехід обґрунтований за наявності хоча б однієї з умов:
- Пікові навантаження, які один сервер не витримує (від 500–1000 одночасних користувачів)
- Вимога до відмовостійкості: зупинка однієї ноди не повинна зупиняти сайт
- Кілька десятків сайтів під управлінням однієї команди
- Інтеграція з корпоративними системами (SAP, великі 1С-конфігурації) з вимогою до стабільності
- Регуляторні вимоги до зберігання даних та резервного копіювання
Чому «Ентерпрайз» краще справляється з навантаженнями?
За рахунок кластеризації Enterprise перерозподіляє трафік між кількома серверами, що дає приріст продуктивності в 3–5 разів порівняно з одиночною нодою «Бізнес». Кластерний кеш на memcached знижує час відповіді бази даних, а S3-сховище розвантажує файлову систему. Проконсультуйтеся зі спеціалістом з архітектури — ми безкоштовно проаналізуємо поточне навантаження.
Як відбувається перехід на «Ентерпрайз»?
- Проектування кластерної інфраструктури. Визначаємо топологію: кількість веб-нод, балансувальник (nginx/HAProxy), схема реплікації БД (master+replica), розподілений кеш.
- Налаштування кластера. Конфігурація в
dbconn.phpдля підключення до slave-серверів, налаштування кластерного кешу через\Bitrix\Main\Config\Option, сховище сесій. - Перенесення медіафайлів. Якщо переходимо на S3 — вивантаження файлів з
/upload/у сховище, налаштування CDN, оновлення шляхів у базі. - Налаштування пошуку. Sphinx або Elasticsearch як зовнішній пошуковий двигун — налаштування модуля
searchдля роботи із зовнішнім індексом. - Тестування під навантаженням. Після збірки кластера — навантажувальне тестування (Apache JMeter або аналог) для перевірки балансування та відмовостійкості.
Таблиця термінів залежно від складності
| Сценарій | Терміни | Особливості |
|---|---|---|
| Мультисайтовість без кластера | 2–4 тижні | Одна ліцензія, єдиний каталог, регіональні налаштування |
| Кластер з 2–3 нод | 4–6 тижнів | Балансування, реплікація, memcached, S3 |
| Повноцінний кластер з пошуком та S3 | 6–10 тижнів | 3+ ноди, Elasticsearch, об'єктне сховище, CDN |
Приклад конфігурації кластерного кешу
Кластерний кеш налаштовується через bitrix/.settings.php:
'cache' => array( 'type' => 'memcache', 'hosts' => array('192.168.1.10:11211'), 'usecluster' => true, ) Кейс: перехід великого рітейлера
Наш клієнт — федеральний рітейлер, 47 регіональних сайтів на окремих ліцензіях «Бізнес», об'єднаних спільною адміністративною панеллю через самописний агрегатор. Сайти періодично лягали в періоди акцій. Завдання: перейти на єдиний «Ентерпрайз» з кластерною архітектурою.
Архітектура після переходу:
- 3 веб-ноди за nginx-балансувальником
- MySQL master + 2 replicas (read queries на replicas)
- Кластерний memcached для кешу та сесій
- Яндекс Object Storage для
/upload/через модульclouds - 47 сайтів під однією ліцензією з єдиним каталогом та регіональними цінами
Робота зайняла 6 тижнів: проектування (2 тижні), реалізація (3 тижні), навантажувальне тестування та запуск (1 тиждень). На наступну пікову акцію сайт витримав навантаження без деградації — балансувальник розподілив трафік по нодах.
Що входить в роботу
- Аналіз поточної архітектури та навантажень
- Проектування кластерної топології
- Налаштування веб-серверів, балансувальника, кешу
- Міграція даних та налаштування сховищ
- Навантажувальне тестування та оптимізація
- Документування та навчання вашої команди
Терміни
Перехід з налаштуванням кластерної інфраструктури — 4–10 тижнів залежно від кількості сайтів, складності інтеграцій та вимог до інфраструктури. Для простих сценаріїв (мультисайтовість без кластера) — 2–4 тижні.
Замовте перехід під ключ — оцінимо ваш проект і запропонуємо оптимальну архітектуру. Отримайте консультацію щодо вашого проекту: ми безкоштовно проаналізуємо поточне навантаження та порадимо шлях міграції.