Перехід з редакції 1С-Бітрікс Бізнес на Ентерпрайз
Перехід з редакції 1С-Бітрікс Бізнес на Ентерпрайз
Редакція «Ентерпрайз» — це не просто чергова сходинка в лінійці. Це принципово інший рівень масштабування платформи. Компанії переходять на неї не через нові функції в інтерфейсі, а через технічні вимоги: високі навантаження, безліч сайтів під однією ліцензією без обмежень, веб-кластер з кількома нодами, розширена кеш-інфраструктура, SLA від вендора.
Чим «Ентерпрайз» відрізняється від «Бізнес»
Необмежена кількість сайтів. У «Бізнес» кількість сайтів технічно не обмежена, але ліцензія розрахована на один домен. В «Ентерпрайз» явно дозволено необмежену кількість доменів і сайтів — це принципово для холдингів і агентств.
Кластеризація без обмежень. «Ентерпрайз» підтримує повноцінний веб-кластер: кілька веб-серверів за балансувальником, розподілене сховище сесій (через session_module на базі memcached або Redis), реплікація бази даних, окремий сервер пошуку (Sphinx). У «Бізнес» кластеризація обмежена.
Розширене кешування. Підтримка кластерного кешу (\Bitrix\Main\Data\Cache через \Bitrix\Main\Data\ManagedCache з memcached-бекендом у кластерному режимі).
Рольова модель на рівні кількох сайтів. В «Ентерпрайз» права користувачів можна налаштовувати на рівні конкретного сайту в рамках мультисайтової установки через b_user_site.
SLA і технічна підтримка вендора. «Ентерпрайз» включає пріоритетну підтримку від 1С-Бітрікс — це важливо для проєктів з вимогою до часу відновлення (RTO).
Сховище файлів. Підтримка S3-сумісних сховищ (AWS S3, Яндекс Object Storage) через модуль clouds — для розподіленого зберігання медіафайлів у кластері.
Коли перехід на «Ентерпрайз» виправданий
Перехід обґрунтований за наявності хоча б однієї з умов:
- Пікові навантаження, які один сервер не витримує (від 500–1000 одночасних користувачів)
- Вимога до відмовостійкості: зупинка однієї ноди не повинна зупиняти сайт
- Кілька десятків сайтів під управлінням однієї команди
- Інтеграція з корпоративними системами (SAP, великі 1С-конфігурації) з вимогою до стабільності
- Регуляторні вимоги до зберігання даних і резервного копіювання
Процес переходу і архітектурні рішення
Перехід на «Ентерпрайз» — це не просто зміна ключа. Це архітектурний проєкт:
Проєктування кластерної інфраструктури. Визначаємо топологію: скільки веб-нод, де балансувальник (nginx / HAProxy), схема реплікації БД (master + replica), схема розподіленого кешу.
Налаштування кластера. Конфігурація в dbconn.php для підключення до slave-серверів, налаштування \Bitrix\Main\Config\Option для кластерного кешу, налаштування сховища сесій.
Перенесення медіафайлів. Якщо переходимо на S3 — вивантаження файлів з /upload/ у сховище, налаштування CDN, оновлення шляхів у базі.
Налаштування пошуку. Sphinx або Elasticsearch як зовнішній пошуковий рушій — налаштування модуля search для роботи з зовнішнім індексом.
Тестування під навантаженням. Після збирання кластера — навантажувальне тестування (Apache JMeter або аналог) для перевірки балансування і відмовостійкості.
Кейс: перехід великого рітейлера
Клієнт — федеральний рітейлер, 47 регіональних сайтів на окремих ліцензіях «Бізнес», об'єднаних спільною адміністративною панеллю через самописний агрегатор. Сайти періодично лягали в періоди акцій.
Задача: перейти на єдиний «Ентерпрайз» з кластерною архітектурою.
Архітектура після переходу:
- 3 веб-ноди за nginx-балансувальником
- MySQL master + 2 replicas (read queries на replicas)
- Кластерний memcached для кешу і сесій
- Яндекс Object Storage для
/upload/через модульclouds - 47 сайтів під однією ліцензією з єдиним каталогом і регіональними цінами
Робота зайняла 6 тижнів: проєктування (2 тижні), реалізація (3 тижні), навантажувальне тестування і запуск (1 тиждень).
В наступну пікову акцію сайт витримав навантаження без деградації — балансувальник розподілив трафік по нодах.
Терміни
Перехід з налаштуванням кластерної інфраструктури — 4–10 тижнів залежно від кількості сайтів, складності інтеграцій і вимог до інфраструктури. Для простих сценаріїв (мультисайтовість без кластера) — 2–4 тижні.