Портал на триста пользователей может годами жить на одном сервере и не доставлять хлопот. Потом отдел продаж переезжает в CRM целиком, подключается телефония, на каждую сделку вешается бизнес-процесс, склад начинает выгружать остатки каждые пять минут. И в пятницу вечером список сделок открывается двенадцать секунд. Дальше идёт знакомый цикл: добавили оперативной памяти, полегчало на месяц, переехали на диски побыстрее, полегчало на два. Кластеризация Битрикс24 начинается там, где наращивать один сервер уже некуда, а нагрузка на сервер CRM продолжает расти.
Где проходит граница одного сервера
Масштабирование бывает двух видов. Вертикальное означает, что одному серверу добавляют ядер, памяти и дисковой производительности. Горизонтальное означает, что серверов становится больше одного. Первый путь простой и до определённого момента дешёвый, поэтому им и пользуются, пока он работает.
Проблема в том, что вертикальный рост упирается в потолок дважды. Сначала в железо: сервер конкретной конфигурации нельзя расширять бесконечно, а следующая ступень стоит непропорционально дороже предыдущей. Потом в архитектуру: база данных остаётся одна, и как бы вы ни разгоняли машину, все запросы всё равно идут в один экземпляр MySQL. В какой-то момент узким местом становится сама схема «один портал, одна база», а процессор тут уже ни при чём.
Симптомы, по которым инженер понимает, что дело идёт к кластеру, довольно однообразные. Время отклика растёт при том же количестве активных пользователей. Процесс mysqld стабильно держит высокую загрузку процессора вместо коротких всплесков. Агенты и задания по расписанию не успевают отработать за отведённое окно и накладываются друг на друга. Любые работы на сервере означают простой всего портала, потому что запасной машины нет. Последний пункт часто важнее производительности. В кластер обычно идут за тем, чтобы обновление ядра операционной системы перестало превращаться в объявление «портал недоступен до вечера».
Перед тем как считать бюджет на вторую машину, стоит открыть встроенный раздел производительности в настройках портала. Он показывает время генерации страниц, количество запросов к базе, ошибки конфигурации и рекомендации по настройке. Половина случаев «портал тормозит» разбирается прямо там: неоптимальный кастомный код, отсутствующие индексы в самописных таблицах, кеширование, отключённое кем-то три года назад ради отладки.
Что Битрикс24 понимает под веб-кластером
В коробочном Битрикс24 за горизонтальное масштабирование отвечает модуль «Веб-кластер». Вендор описывает его как комбинацию технологических решений, которые позволяют распределить один портал на несколько серверов. Задачи у этой комбинации три: высокая доступность портала, масштабирование в условиях растущей нагрузки и балансирование нагрузки, трафика и данных между серверами.
Стоит сразу разделить две цели, которые постоянно путают. Производительность отвечает на вопрос «сколько людей система обслужит одновременно». Доступность отвечает на вопрос «что будет, когда одна машина выйдет из строя». Кластер работает на обе задачи, но конфигурации под них разные: под производительность добавляют читающие реплики и веб-серверы, под доступность дублируют каждый слой, включая тот, который в обычный день простаивает. Компания, которая заказывает кластер «чтобы не тормозило», а на самом деле боится простоя, рискует получить быстрый портал, который всё так же ложится целиком.
Формулировка вендора тут важна. Веб-кластер не отдельный продукт и не внешняя надстройка, это модуль внутри самой платформы. Портал не переписывают под распределённую архитектуру, логика приложения остаётся прежней. Настройки кластера живут в администраторской части, и с точки зрения пользователя не меняется ничего: тот же адрес и та же работа.
Из чего собирается кластер
Официальное описание модуля перечисляет составляющие довольно конкретно, и каждая закрывает свою часть проблемы.
Вертикальный шардинг выносит отдельные модули на отдельные серверы MySQL. Одна база данных разделяется на две и более за счёт выделения модулей, причём без изменения логики работы приложения. Практический смысл простой: самый тяжёлый по записи модуль перестаёт мешать всем остальным.
Репликация MySQL добавляет балансирование нагрузки между серверами. Это классическая схема master-slave, в которой запись идёт на ведущий сервер, а чтение распределяется между ведущим и ведомыми. Для портала, где на одну запись приходится десяток чтений, такая схема даёт заметный запас.
Распределённый кеш данных работает на memcached. Пул серверов memcached становится общим хранилищем кеша для всех веб-серверов кластера. Без него каждый веб-сервер держал бы свою копию кеша, и половина машин работала бы вхолостую.
Хранение сессий в базе данных отвечает за непрерывность сессии между веб-серверами. Пользователя может обслуживать любая машина кластера, и его не выбросит из портала на середине работы.
Кластеризация веб-сервера идёт в паре с синхронизацией файлов. Веб-серверов становится несколько, а загруженные документы, аватары и вложения должны быть одинаково доступны на каждом из них.
Отдельно про шардинг стоит уточнить терминологию, потому что слово используют в двух смыслах. Вертикальный шардинг, который описан у вендора, разносит по разным серверам целые модули: например, модуль статистики или поиска перестаёт делить базу с CRM. Горизонтальный шардинг разносит по серверам записи внутри одной сущности, и это уже задача другого класса сложности. В типовом проекте по коробочному Битрикс24 работают с вертикальным вариантом, потому что он не требует вмешательства в логику приложения.
Замыкает список независимость от дата-центра. Ноды кластера не обязаны стоять в одной стойке, и это даёт запас прочности другого порядка, чем просто вторая машина рядом с первой.
Редакция решает всё
Здесь чаще всего и рушатся планы. Коробочный Битрикс24 выпускается в трёх редакциях: «Интернет-магазин + CRM» для небольших отделов, «Корпоративный портал» для средних организаций и «Энтерпрайз» для крупных компаний. Веб-кластер доступен в редакции «Энтерпрайз». Там же живёт многодепартаментность, то есть поддержка филиальной структуры с разделением по департаментам.
План «купим коробку подешевле, а когда вырастем, соберём кластер» из-за этого не работает: рост в кластер означает переход на старшую редакцию. Развилка тут лицензионная, и проходить её нужно до покупки, а не когда портал уже лежит под нагрузкой. Если вы сейчас выбираете между облаком и коробкой или между редакциями, есть смысл посчитать сценарий на три года вперёд. Наши услуги по Битрикс24 включают такой расчёт вместе с подбором конфигурации серверов.
Про облако стоит сказать отдельно. Облачный Битрикс24 масштабируется силами вендора, и вопрос кластеризации перед клиентом там просто не стоит. Коробку выбирают, когда нужен свой контур, доработки на уровне ядра, интеграция с внутренними системами или выполнение требований по хранению данных. За эту свободу и приходится платить собственной инфраструктурой.
Как распределяют роли между машинами
Кластер редко состоит из нескольких одинаковых серверов. У каждой машины своя роль, и от того, как роли разложены, зависит и стоимость, и запас прочности.
Серверы базы данных обычно самые дорогие по железу: им нужны быстрые диски, много памяти под буферный пул и стабильный процессор. Ведущий обслуживает запись, ведомые разгружают чтение. На небольших внедрениях ведомый часто один и совмещает две задачи: принимает часть читающих запросов и служит горячей копией на случай отказа ведущего.
Веб-серверы, наоборот, дешёвые и заменяемые. Они не хранят состояние: сессии лежат в базе, кеш в memcached, файлы на общем хранилище. Именно поэтому веб-серверов удобно добавлять по мере роста числа пользователей, а выпадение одного из них не заметит никто, кроме мониторинга.
Слой кеша живёт отдельно. Memcached может стоять и на веб-серверах, но чем крупнее портал, тем сильнее аргумент вынести его на выделенные машины: перезапуск веб-сервера тогда не выбивает кеш, который набирался часами.
Балансировщик стоит перед веб-серверами и решает, какой машине отдать запрос. Он же снимает трафик с упавшей ноды. Часто именно балансировщик оказывается единственной точкой отказа во всей красивой схеме, поэтому его дублируют так же, как и остальные слои.
Файловое хранилище недооценивают чаще прочего. Пока портал живёт на одной машине, вопроса нет. Как только веб-серверов становится два, документы, аватары и вложения задач должны стать общими, и решать это приходится либо синхронизацией, либо сетевым хранилищем.
Как собирается master-slave на практике
Требование, которое проверяют первым: все таблицы базы данных должны работать на движке InnoDB. Таблицы на других механизмах конвертируют до начала работ. На старых порталах, переживших несколько миграций, такие таблицы находятся почти всегда.
Дальше работа идёт через меню виртуальной машины «1С-Битрикс». В документации разработчика описан порядок из трёх пунктов меню.
Пункт «Create master node» превращает текущую машину в ведущую ноду. Мастер спрашивает доменное имя ноды, пароль пользователя root для MySQL и базу данных, которую нужно реплицировать, после чего настраивает сервисы и сам модуль веб-кластера.
Пункт «Add slave node» выполняется уже в консоли ведущей ноды и добавляет ведомую. Понадобятся имя хоста и адрес будущей ноды, а также пароли root от MySQL на обеих машинах. Мастер сам переносит файлы портала, базу и поднимает репликацию.
Пункт «Make slave node a master node» пригодится, когда ведущая нода вышла из строя: одна из ведомых переназначается ведущей.
Подготовка машин до включения в кластер описана явно: меняют стандартные пароли пользователей root и bitrix, а на будущей ведомой ноде удаляют базу с именем базы ведущей ноды. Пункт про пароли кажется формальностью, пока портал не проходит первый аудит безопасности.
Сколько на самом деле выдерживает кластер
У вендора есть публичные результаты нагрузочного тестирования, и цифры там предметные. Тестировали коробочный Битрикс24 редакции «Энтерпрайз». В тестовом развёртывании было 111 304 сотрудника, портал располагался в кластерном решении из пяти серверов, и такая конфигурация обеспечивала одновременную работу до 30 000 сотрудников. Нагрузка шла 24 часа и имитировала типовые действия реальных пользователей, портал при этом наполнялся новостями, задачами, процессами и сообщениями. Тестирование проводили совместно с компанией Selectel в январе 2021 года.
Эти числа стоит читать как ориентир соотношения, а не как обещание. Пять серверов на тридцать тысяч одновременных пользователей задают порядок величины, от которого можно отталкиваться при планировании. Портал на пятьсот человек с активной CRM и телефонией пяти нод не требует, ему обычно хватает двух-трёх с правильно разнесёнными ролями.
Иллюстративный сценарий: производственная компания на 400 человек
Дальше идёт придуманный пример, показывающий логику решения, а не описание конкретного внедрения.
Компания держит коробочный портал на одной машине. В CRM работают 60 менеджеров, остальные сотрудники сидят в задачах, документах и внутренних коммуникациях. Каждое утро с девяти до одиннадцати портал ощутимо замедляется: менеджеры массово открывают списки сделок, одновременно отрабатывают ночные интеграции с учётной системой, и туда же попадает выгрузка отчётов для руководителей.
Разбор показывает, что процессор занят преимущественно базой. Первый шаг очевидный и дешёвый: перенести отчёты за пределы утреннего окна и переписать интеграцию так, чтобы она не дёргала базу построчно. Это снимает половину проблемы и стоит нескольких дней работы.
Вторая половина не снимается. Пиковая нагрузка на сервер CRM остаётся, а любая плановая работа на машине означает остановку всей компании. Вот здесь и появляется кластер. Конфигурация из ведущего сервера базы, ведомого для чтения и двух веб-серверов за балансировщиком закрывает обе задачи: и утренний пик, и возможность обслуживать по одной ноде за раз.
Порядок в этом примере важнее содержания. Сначала оптимизация того, что есть, потом расширение. Кластер, собранный поверх неоптимального кода, просто размножит проблему на несколько машин.
Что усложняется после перехода
Кластер меняет не только производительность, но и эксплуатацию, и об этом честнее говорить заранее.
Репликация вносит задержку. Данные, записанные на ведущий сервер, появляются на ведомом не мгновенно, и приложение должно это учитывать. В самой платформе логика распределения запросов реализована на уровне модуля, но кастомный код, написанный без оглядки на кластер, может прочитать со ведомого то, что секунду назад записал на ведущий.
Файлы перестают быть локальными. Любая доработка, которая пишет что-то во временную папку и рассчитывает найти это на следующем запросе, ломается ровно в тот момент, когда следующий запрос уходит на другой веб-сервер.
Обновления становятся процедурой. На одной машине обновление портала занимает полчаса. Обновление кластера без потери репликации и рассинхронизации нод требует регламента и окна работ.
Мониторинга нужно больше. Одна машина либо работает, либо нет. Кластер умеет деградировать частично: отстала репликация, отвалился один memcached, один веб-сервер отдаёт ошибки, а балансировщик продолжает слать на него трафик. Без наблюдения за состоянием нод такие вещи обнаруживаются по жалобам пользователей.
Стоимость владения растёт не только на железе. Прибавляются лицензии старшей редакции, работа администратора и время на регламентные процедуры. Для компании, которая честно упёрлась в потолок, это оправданные расходы. Для компании, у которой просто не настроено кеширование, лишние.
Что стоит подготовить до старта работ
Проект кластеризации выглядит инфраструктурным, хотя львиная доля рисков приходит из самого портала.
Начните с инвентаризации доработок. Нужен список всего, что писалось под портал: интеграции, обработчики событий, свои компоненты, скрипты по расписанию. Каждый пункт проверяется на два вопроса. Пишет ли он файлы локально? Рассчитывает ли на мгновенную видимость только что записанных данных? Оба ответа «да» означают переделку.
Дальше нужен профиль нагрузки. Замеры за неделю дают больше, чем ощущения пользователей: когда приходят пики, что именно работает в это время, какая доля запросов идёт в CRM, а какая в задачи и на диск. Туда же ложится состояние базы, то есть движок таблиц, размер, самые тяжёлые запросы и объём журналов. Перенос неухоженной базы в кластер переносит вместе с ней все её проблемы.
Отдельная договорённость понадобится по обновлениям. До кластера портал часто обновляют «когда получится». После этого нужно плановое окно с проверкой репликации до и после. Обсудить регламент с бизнесом проще заранее, чем в момент первого отставшего ведомого сервера.
И минимальный мониторинг: состояние репликации, доступность каждой ноды, память memcached, свободное место на дисках. Всё это должно писать не в лог, а живому человеку.
Когда кластер точно не нужен
Есть набор ситуаций, где вторая машина не поможет и лечить надо другое.
Портал тормозит равномерно, независимо от времени суток и числа пользователей. Скорее всего, проблема в коде страницы или в конкретном запросе, а ресурсы тут ни при чём.
Нагрузку создаёт один тяжёлый отчёт или одна интеграция. Их переносят по времени или переписывают.
Кеширование отключено или настроено формально. Включение композитного кеша и правильных настроек кеша компонентов часто даёт больше, чем удвоение железа.
База не обслуживалась годами: не чистились журналы, не пересчитывались индексы, лежат таблицы от давно отключённых модулей.
Сервер виртуальный и делит ресурсы с шумными соседями. Здесь помогает переезд.
Разумный порядок действий выглядит так: сначала измерить, потом оптимизировать, потом увеличить один сервер, и только затем строить горизонтальную схему. Каждый шаг дешевле следующего и часто закрывает вопрос на год-полтора. Кластеризация Битрикс24 нужна тем, кто прошёл предыдущие ступени и упёрся в них по-настоящему. Купить производительность в обход инженерной работы она не позволяет.
Частые вопросы
Можно ли собрать кластер на редакции «Корпоративный портал»?
Нет. Модуль «Веб-кластер» доступен в коробочном Битрикс24 редакции «Энтерпрайз». Переход в кластер означает и переход на старшую редакцию, это нужно закладывать в бюджет заранее.
Сколько серверов нужно для старта?
Минимальная осмысленная схема включает ведущий сервер базы, ведомый и несколько веб-серверов за балансировщиком. Точная конфигурация зависит от профиля нагрузки: портал с тяжёлой CRM и телефонией и портал с упором на документы нагружают систему по-разному.
Нужно ли переписывать доработки портала под кластер?
Логику приложения платформа менять не заставляет, но кастомный код проверяют отдельно. Опасны места, где доработка пишет файлы в локальную папку сервера или читает данные сразу после записи, рассчитывая на одну общую базу.
Даёт ли кластер отказоустойчивость сам по себе?
Он даёт основу для неё: несколько веб-серверов, реплики базы и возможность назначить ведущей одну из ведомых нод. Полноценная отказоустойчивость требует ещё балансировщика, мониторинга и отработанного регламента переключения.
Что делать, если бюджета на «Энтерпрайз» нет, а портал тормозит?
Начать с измерений во встроенном разделе производительности, привести в порядок кеширование и базу, вынести тяжёлые операции за пиковые часы и рассмотреть вертикальный апгрейд сервера. В большинстве случаев этого хватает надолго.