Вечно живой, вечно доступный: как создать отказоустойчивый кластер для Битрикс24

• Отказоустойчивость системы: что это и как ее достичь
• Что такое кластер Битрикс24
• Модуль «Веб-кластер»: возможности и ограничения
• Как создать отказоустойчивый кластер Битрикс24
• Реальный пример создания отказоустойчивого кластера на Битрикс24

Люди делятся на два типа:
те, кто делает бэкапы, и те, кто уже делает бэкапы.

Чем крупнее бизнес, тем дороже обходятся простои, поэтому отказоустойчивость IT-систем стала обязательным требованием к ним. Корпоративный портал в таких компаниях становится ключевой платформой управления процессами, и его стабильная работа 24/7 необходима как кислород.

В статье разберем, как обеспечить отказоустойчивость Битрикс24 с помощью кластера.

Отказоустойчивость системы: что это и как ее достичь

Отказоустойчивость системы — её способность продолжать работу в нештатных ситуациях. Самый надежный способ достичь этого — создать избыток мощности, чтобы быстро заменить то, что вышло из строя.

Для оценки времени бесперебойной работы сервиса используют коэффициент uptime. Если он ниже 99% — плохо. Чем больше это число, тем надежнее работа сервиса. Пример: uptime условного портала — 99,95%, значит, 0,05% времени он может быть недоступен, т.е. 4 часа 23 минуты в году.

Обеспечить отказоустойчивость на 99,99% — дорого и объективно не всегда возможно. Ведь Битрикс24 может быть недоступен не только из-за неполадок, но и других причин, например, установки обновлений.

Задачу повышения отказоустойчивости обычно решают через создание резерва мощности в кластере.

Что такое кластер Битрикс24

Корпоративный портал состоит из нескольких компонентов:

• сервер приложений (php-fpm и веб-сервер) — занимается обработкой HTTP-запросов Битрикс24;

• Push and Pull — нужен для работы функциональностей Б24 в режиме реального времени (уведомления, счетчики задач и т.д.);

• база данных.

В большинстве случаев они расположены на одном выделенном сервере как монолитная структура. Если машина выходит из строя или подвергается атаке, то Битрикс24 полностью перестает быть доступным. Время простоя зависит от того, как быстро восстановят работоспособность сервера. На это могут уйти минуты или часы — заранее предсказать невозможно.

Кластер объединяет несколько вычислительных мощностей (серверов), которые обеспечивают работу одного Битрикс24. Простой пример кластеризации: компоненты распределяются по разным машинам с наиболее подходящими техническими характеристиками для каждого из них. Если каждый компонент эффективнее выполняет задачи, то повышается производительность всего портала. Однако нет страховки на случай «падения» одного из серверов — скорее всего, «ляжет» вся система.

Отказоустойчивый кластер гарантирует гораздо более высокую доступность системы по сравнению с единственным выделенным сервером и простым кластером. Резервные копии наиболее важных компонентов распределяются по разным физическим серверам. Если из строя выходит машина с основной базой данных, система переключается на реплику и продолжает работать. То же самое и с сервером приложений, кешем и файловым сервером.

Вычислительные машины в кластере — это узлы, или ноды, соединенные между собой по различным протоколам связи.

Помимо описанных выше компонентов кластер Битрикс24 также содержит:

1. Балансировщик — отвечает за распределение входящего трафика на «живые» серверы приложений и мониторит работоспособность нод.

2. Файловое хранилище — хранит загруженные пользователями файлы. Может быть в единственном числе или с репликой.

3. Кеш-сервер — хранит данные, в том числе сессии пользователей, в оперативной памяти. На каждый сервер приложений, как правило, один сервер кеша.

Поведение системы в аварийных ситуациях настраивается в соответствии с требованиями к отказоустойчивости, которые предъявляет компания. Несколько возможных вариантов:

1. При выходе из строя основного сервера приложений трафик автоматически распределяется на оставшиеся «в живых» машины. Когда проблема устранена, происходит повторное перераспределение.

2. Если отказала одна из реплик (slave), то кластер базы данных может перейти в режим «Только чтение» или же продолжить работу как есть — пользователи не заметят неполадки.

3. Если откажет master, то кластер БД может выбрать новую основную базу, перейдет в режим «Только чтение» или остановит работу.

4. При отказе одного из кеш-серверов часть запросов будут выполняться без кеширования либо работоспособные машины примут на себя эту нагрузку.

5. К отключению каких функций приведёт «падение» сервера Push and Pull и насколько это критично: отсутствие уведомлений о новых событиях в мессенджере, ленте, задачах и т.д.

Таким образом, в нештатных ситуациях сервис так или иначе останется доступным — полностью или с ограниченной функциональностью.

Модуль «Веб-кластер»: возможности и ограничения

Типовое решение для создания кластера Битрикс24 — модуль «Веб-кластер», доступный в коробочной версии только в редакции «Энтерпрайз». Он меняет поведение bitrix-ядра таким образом, чтобы портал мог корректно работать в кластерной среде. Настройки модуля доступны в панели администрирования.

Возможности стандартного модуля:

1. Репликация базы данных MySQL по типам master – slave (основная и дополнительные) и master – master (несколько основных). Это позволяет распределить запросы: записываются данные на ведущий сервер, читаются — из дополнительных баз. Это разгружает master-базу.

2. Slave-базу можно использовать в качестве резервной копии для непрерывного бэкапа.

3. Перенос некоторых модулей Битрикс24 на отдельные сервера, чтобы разделить обращения к ним и не перегружать базу данных в целом.

4. Использование нескольких memcached-серверов, что позволяет хранить кешируемые данные в оперативной памяти. Такой подход ускоряет работу портала. Объем кеша можно расширять до бесконечности, подключая новые машины.

5. Создание нескольких веб-серверов для распределения возросшей нагрузки. Функция доступна в «админке» в настройках веб-кластера.

6. Хранение данных о сессиях пользователей в базе данных как необходимая мера при использовании нескольких веб-серверов.

Использование стандартного модуля «Веб-кластер» в Битрикс24 помогает, прежде всего, повысить производительность портала за счет разделения большого числа запросов между разными серверами приложений, базы данных и кеша. Тем не менее, у типовых инструментов Б24 есть некоторые ограничения, например:

• один балансировщик в кластере, который находится на мастер-узле («входе» в кластер). При его выходе из строя сервис становится полностью недоступным;

• отсутствует как ручной, так и автоматический механизм аварийного переключения с ведущего сервера базы данных на реплику;

• также пока не реализован автоматический выбор нового ведущего сервера приложений и БД;

• работа модуля с PostgreSQL ещё не до конца отлажена.

Есть и другие технические нюансы, которые не позволяют достичь максимальной отказоустойчивости Битрикс24. Резервирование и создание бэкапа в режиме реального времени страхует от потери данных из-за атаки или аварии, но не обеспечивает доступность сервиса на 99% и более.

Как создать отказоустойчивый кластер Битрикс24

Создать кластер Битрикс24 можно не только средствами стандартного модуля, доступного в редакции «Энтерпрайз». Для каждого проекта с кластеризацией ИНТЕРВОЛГА с нуля разрабатывает гибкие архитектурные решения, которые содержат все необходимые компоненты для достижения отказоустойчивости. Они обеспечивают максимально достижимую доступность корпортала: при аварийных ситуациях сотрудники продолжают работу с минимальным перерывом или вовсе без него.

В вопросах кластеризации универсального решения быть не может — уникален каждый портал, требования к uptime, конфигурации «железа» серверов и безопасности. Например, одним из обязательных условий может быть использование только российского софта. В условиях санкций установка Битрикс24 на машинах с отечественной ОС становится не прихотью, а вопросом доступности сервиса. Мы умеем автоматизировать внедрение Б24 на Astra Linux и Alt Linux — это позволяет ускорить процесс, исключить ошибки и развернуть несколько контуров одновременно.

Этапы работ по созданию кластера:

1. Установочная встреча. Сбор требований и пожеланий к работе Битрикс24 в кластерной среде, уточнение технических деталей.

2. Проектирование решения. Разработка архитектуры развертывания с описанием компонентов кластера и их взаимодействия. В проекте отображаются параметры инфраструктуры (количество серверов, конфигурация «железа» и ОС каждой ноды).

3. Согласование архитектуры и порядка ее реализации. Обсуждение и корректировка предложенного решения.

4. Подготовка инфраструктуры. Заказчик покупает или арендует необходимые серверы, устанавливает операционные системы. Продолжительность  этапа зависит от бюджета и наличия требуемых машин в продаже/аренде.

5. Развертывание. Установка на серверы виртуальных машин и компонентов Битрикс24, обеспечение сетевого взаимодействия, тестирование кластера.

6. Введение в эксплуатацию. Перенос кластера в продуктивную среду, начало работы реальных пользователей, устранение возможных ошибок и поддержка проекта.

В нашем портфеле есть несколько проектов, где создавался отказоустойчивый кластер для сайта и портала Битрикс24. Вот один из примеров.

Реальный пример создания отказоустойчивого кластера на Битрикс24

Заказчик под NDA — крупная компания: в корпоративном портале ежедневно работают более 2500 сотрудников. Б24 для организации — сердце и мозг: здесь ведут задачи и сделки, обмениваются документами, используют мессенджер, базу знаний, ленту новостей и прочие инструменты. Ситуаций, когда сервис полностью «упал», ещё не случалось, однако под большой нагрузкой производительность снизилась — заказчик понял, что скорость работы и высокая доступность сервиса критичны.

Одним из требований к Битрикс24 было автоматическое переключение на резервные серверы в случае аварии: доступ к порталу не должен прерываться, данные всегда должны быть защищены.

Мы учли требования заказчика, профиль нагрузки портала, объем бюджета на кластеризацию и разработали оптимальное решение.

В этом кейсе отказоустойчивый кластер Битрикс24 включает 10 компонентов.

Балансировщик L4

Для работы Б24 в кластере достаточно балансировщика, работающего на 4 уровне модели OSI. Он принимает трафик от пользователей и автоматически распределяет его по серверам приложений. Балансировщик также постоянно проверяет работоспособность машин и в случае отказа одной из них переводит все запросы на «живой» компонент. Входящий трафик принимается на порты :443 и :8894 TCP.

Оптимальный вариант балансировщика в этом кейсе — HAProxy. Это ПО с открытым исходным кодом, которое отлично справляется с высоким трафиком и отражением DDoS-атак.

Два сервера приложений

На них размещены копии Битрикс24 и конфигурационные файлы. Приложение Syncthing обеспечивает синхронизацию корневого каталога между серверами — обе машины являются ведущими, и в случае поломки одной вторая беспрепятственно примет трафик на себя.

Данные о сессиях пользователей хранятся вне серверов приложений — при сбое одного из из них сотрудников не «выкинет» из портала.

Любой сервер приложений можно переводить в режим обслуживания: балансировщик перестает отправлять на него трафик, а выполнение фоновых задач останавливается. Режим позволяет выполнять обновление в рабочее время, не прерывая доступ пользователей к порталу.

Файловый сервер

На нем запущена служба Samba, с помощью которой сервера приложений могут обращаться к файлам по протоколу SMB. Выбор этой сетевой файловой системы обусловлен пожеланием заказчика.

Вместо файлового сервера в кластер можно добавить объектное хранилище S3 — это наиболее стабильный вариант. Его легко масштабировать, данные в нем защищены от потерь и DDoS-атак. Для подключения S3 к серверам в Битрикс24 есть универсальный коннектор.

Два кеш-сервера

Наличие двух серверов приложений диктует необходимость во внешнем кеш-сервере — общем для них обоих. Его отказ не влияет на работоспособность всей системы, но сильно «затормаживает» ее.

Чтобы минимизировать последствия возможного сбоя, кеш-сервер дублируется. Репликацию настраивать не нужно — система автоматически распределяет кеш по нодам. Каждый сервер приложений имеет доступ к обоим хранилищам, и в случае «падения» одного узлы автоматически переключатся на второй.

Push-сервер

Этот компонент является, пожалуй, наименее критичным в кластере, поэтому не дублируется. Push and Pull в Битрикс24 отвечает за realtime-функциональность: мгновенные уведомления в чатах, задачах, ленте и других инструментах.

На этом же сервере мы дополнительно разворачиваем хранилище кеша Redis, которое использует Push and Pull. Отдельное кеширование помогает оптимизировать работу службы уведомлений, что особенно важно, если на портале много задач и чатов с большим число пользователей.

Два сервера базы данных

В этом кейсе Битрикс24 работает с базой данных MySQL 8.x. Мы настроили асинхронную репликацию с ведущего сервера БД на вторичный по схеме master – slave. Слейв переключается на мастер вручную, однако можно настроить и автоматический переход.

Репликация может быть и синхронной, где кластер БД содержит не одну, а две–три реплики мастера. Это более дорогой, но максимально надежный вариант — отказоустойчивость кластера БД крайне высокая.

Для повышения производительности Битрикс24 запросы на запись и чтение можно распределить между основной БД и репликой (по аналогии с модулем «Веб-кластер»). Для этого используем приложение ProxySQL.

Если кластеризация Б24 совмещается, например, с полным переходом на российское ПО, обеспечиваем миграцию на СУБД PostgreSQL.

Сервер CI/CD

Не является компонентом кластера как таковым, но интегрируется для непрерывности поставки кода. С помощью CI/CD можно быстро и корректно доставлять обновления ПО на оба сервера приложений, исключив рассинхронизацию.

Этот кейс — не исчерпывающий пример построения отказоустойчивого кластера Битрикс24. В него можно интегрировать различные сервисы, например, службу Active Directory для централизованного доступа к ресурсам корпоративной сети («единый вход»), систему мониторинга (ELK, Zabbix и другие). Кластер БД может быть представлен большим числом реплик и балансировщиком на входе для распределения нагрузки и высочайшей доступности.

Способов построения отказоустойчивых кластеров много, и для каждой задачи мы находим индивидуальное решение. Если вам нужна высоконадежная система, которая минимизирует простои и потери данных при сбоях оборудования или внештатных ситуациях — заполните форму внизу. Наш эксперт свяжется с вами и организует онлайн-встречу для подробного обсуждения задачи.

Больше статей о развитии корпоративного портала:

• Миграция с MySQL на PostgreSQL в Битрикс24

• SSO-авторизация в Битрикс24 с Keycloak

• Почему Битрикс24 тормозит и как ускорить его работу

• Как мы заново написали модуль учета рабочего времени сотрудников в среде Битрикс24