Резервный дата-центр: не «второй сервер на всякий случай»
Когда владелец компании впервые слышит про резервный дата-центр для Битрикс24, в голове обычно возникает картинка: где-то стоит копия сервера, и если основной упадёт, кто-то нажмёт кнопку, и всё продолжит работать. На практике за этой формулировкой стоит несколько принципиально разных сценариев, и стоят они по-разному: от нескольких десятков тысяч тенге в месяц до бюджета, сопоставимого с зарплатой отдельного системного администратора.
Разберём терминологию, потому что именно из-за путаницы в ней бизнес переплачивает. Есть три разных вещи, которые в разговорах называют одним словом «резерв».
Первое: резервная копия (бэкап). Это архив базы данных и файлов, который лежит отдельно от рабочего сервера. При аварии его нужно скачать, развернуть на новом сервере, проверить, переключить домен. Занимает это от получаса до суток в зависимости от объёма портала и подготовленности команды.
Второе: горячий резерв (реплика). Это работающая копия базы данных, которая непрерывно получает изменения с основного сервера. Восстанавливать нечего: данные уже там, нужно только переключить нагрузку. Время простоя измеряется минутами.
Третье: резервный дата-центр. Это не один сервер, а полноценная группа серверов в другом здании, другом городе или другой стране, со своей базой, своими веб-серверами и своим каналом связи. Смысл именно в географии: если в основном дата-центре пропало электричество, оборвался магистральный канал или произошёл пожар, вторая площадка живёт своей жизнью.
Для малого бизнеса вопрос почти никогда не звучит как «нужен ли резерв вообще»: он нужен всегда. Вопрос в том, на каком из трёх уровней остановиться, и вот здесь ответ для компании на 30 человек и для холдинга на 2000 сотрудников совершенно разный.
Как отказоустойчивость устроена в коробочном Битрикс24
Ключевое отличие коробочной версии от облачной в том, что за инфраструктуру отвечаете вы. В облаке резервное копирование делает сама платформа: по официальному описанию Битрикс24 ежедневно создаёт резервные копии всех данных портала и хранит их семь дней, а заявку на восстановление подаёт администратор портала в техподдержку, после чего портал целиком откатывается на выбранную дату. В коробке такой кнопки нет: есть инструменты, которыми нужно правильно воспользоваться.
На уровне самой платформы отказоустойчивость коробочной версии обеспечивает модуль «Веб-кластер». Это не одна функция, а набор технологий, которые официально описаны так: вертикальный шардинг (вынесение отдельных модулей на самостоятельные серверы MySQL), репликация MySQL по схеме master-slave с балансированием нагрузки между серверами, распределённый кеш на пуле серверов memcached, централизованное хранение сессий в базе данных (это делает сессию пользователя прозрачной для всех веб-серверов кластера) и собственно кластеризация веб-серверов с синхронизацией файлов между ними.
Отдельно в описании продукта выделен географический веб-кластер. Формулировка производителя прямая: он повышает отказоустойчивость проекта и обеспечивает независимость от дата-центра, объединяя несколько групп веб-кластеров, расположенных в разных городах или странах; при отказе одного дата-центра в работу включается другой без необходимости восстановления бэкапа. Это ровно тот сценарий, который мы выше назвали третьим уровнем.
Технически развернуть базовую часть этой схемы проще, чем кажется. Если портал работает на рекомендованном производителем окружении (виртуальной машине BitrixVM или веб-окружении BitrixEnv, которые распространяются бесплатно и уже содержат операционную систему, веб-сервер, базу данных, firewall и почтовый сервер), то создание кластера делается через меню самой машины. В нём есть пункты «Create master node» для назначения основного узла, «Add slave node» для подключения реплики и «Make slave node a master node» для превращения реплики в основной узел, когда мастер вышел из строя.
Но у этой лёгкости есть предусловия, о которых обязательно нужно знать заранее: перед включением машины в кластер меняются пароли системных пользователей root и bitrix, на будущей реплике удаляется база с рабочим именем основной базы, все таблицы базы данных переводятся в InnoDB, а сам продукт должен быть установлен с модулем «Веб-кластер». Последний пункт самый важный, и именно он чаще всего ломает планы.
Ограничение, из-за которого разговор нередко заканчивается
Модуль «Веб-кластер» в коробочном Битрикс24 доступен не во всех редакциях. По официальному описанию редакции Энтерпрайз, технология «Веб-кластер» доступна только в ней: именно она позволяет горизонтально масштабировать систему добавлением серверов, балансировать нагрузку и обеспечивать отказоустойчивость. Эта же редакция позиционируется производителем для крупных компаний, ориентировочно от 500 сотрудников, с заявленным временем отклика не более секунды при 30 000 одновременных пользователей и масштабированием до 100 000+ пользователей в вашей инфраструктуре.
Отсюда следует практический вывод, который экономит компаниям много времени. Если у вас коробка в редакции «Корпоративный портал» на 50 или 100 сотрудников, «настроить географический веб-кластер» вам не предложат: сначала придётся перейти на Энтерпрайз. И вопрос из технического сразу становится финансовым: разница в стоимости лицензии между редакциями для небольшой компании почти всегда превышает потенциальные потери от одного-двух часов простоя в год.
Это не значит, что малый бизнес обречён на беззащитность. Это значит, что защищаться нужно другими средствами, и они, вопреки ожиданиям, закрывают 90 % реальных аварий. Мы регулярно проектируем такие схемы, когда занимаемся внедрением и настройкой Битрикс24 для казахстанских компаний, и почти всегда сходимся с клиентом на промежуточном варианте.
Сначала посчитайте стоимость простоя, потом выбирайте технологию
Правильная последовательность: не «какую технологию поставить», а «сколько стоит час, когда портал недоступен». В управлении непрерывностью для этого используют два показателя, и их полезно знать любому руководителю.
RTO: допустимое время восстановления. Через сколько после аварии система обязана снова работать. RPO: допустимая потеря данных. За какой период вы готовы потерять внесённую информацию: за пять минут, за час, за сутки.
Дальше считается просто. Возьмите месячную выручку и поделите на количество рабочих часов в месяце, чтобы получить валовую стоимость часа работы компании. Умножьте на долю процессов, которые реально встают без CRM: если менеджеры не могут посмотреть историю клиента, но телефон работает и заказы записываются на бумагу, это не 100 %, а, скажем, 40 %. Добавьте отдельно стоимость потерянных заявок: сколько лидов приходит в час и какая у вас конверсия.
Отдельно стоит учесть то, что в расчёты обычно не попадает: время сотрудников на восстановление ручной работы после аварии. Если портал лежал шесть часов, менеджеры не просто простаивали: потом несколько дней они переносят в CRM то, что писали в блокнотах и мессенджерах, и часть информации теряется навсегда. По нашему опыту, этот «хвост» добавляет к прямым потерям ещё 30-50 %, и именно он делает вторую аварию подряд особенно болезненной для команды.
Для компании с выручкой 30 млн тенге в месяц и 176 рабочими часами час полного простоя стоит около 170 тысяч тенге валовой выручки. Если CRM отвечает за 40 % процессов, час простоя портала стоит примерно 68 тысяч. Сутки простоя стоят около 550 тысяч тенге при восьмичасовом рабочем дне. Теперь сравните это с годовой стоимостью второго дата-центра и перехода на старшую редакцию. Для большинства компаний малого и среднего бизнеса математика однозначная: дешевле обеспечить восстановление за два-три часа, чем платить за мгновенное переключение.
Но есть категории бизнеса, где эта же математика даёт обратный результат. Интернет-магазин с приёмом заказов через портал, сервисная компания с диспетчерской, работающей круглосуточно, логистика, медицинские центры с записью: в этих сферах простой стоит кратно дороже, и разговор про резервную площадку начинается всерьёз даже при небольшом штате.
Три уровня защиты и что даёт каждый
Уровень 1. Регулярное резервное копирование с внешним хранением. Обязательный минимум для любой коробки без исключений. Настраивается в административной части: Настройки → Инструменты → Резервное копирование → Регулярное резервное копирование. Минимальная частота автоматического создания копии: один раз в сутки. Копии можно хранить локально, в облаке 1С-Битрикс или в стороннем облачном хранилище; при автоматическом создании копии пароль пользователя хранится в базе в зашифрованном виде, а для шифрования используется лицензионный ключ. Запускать процесс можно агентами на cron или напрямую через служебный скрипт резервного копирования.
Что даёт: защиту от потери данных и от логических аварий, например если удалили не ту воронку, обновление сломало кастомный код или шифровальщик добрался до сервера. RPO: до суток, RTO: от нескольких часов. Что не даёт: быстрого возврата в строй.
Уровень 2. Реплика базы данных на второй машине. Схема master-slave через штатное меню виртуальной машины. Вторая машина непрерывно получает изменения, и при отказе основной её можно перевести в роль мастера. Требует редакции с модулем «Веб-кластер».
Что даёт: RPO близкий к нулю, RTO: десятки минут. Что не даёт: защиты от аварии всего дата-центра, если обе машины стоят в одной стойке или хотя бы в одном здании. Это очень частая ошибка: реплика поднята «для отказоустойчивости», но живёт на соседнем гипервизоре того же хостинга.
Уровень 3. Вторая площадка в другом дата-центре. Полноценная группа серверов со своим мастером в независимом ДЦ, тот самый географический веб-кластер. Что даёт: устойчивость к отказу площадки целиком. Что требует: старшей редакции, второго комплекта серверов, канала между площадками, регламента переключения и, это забывают чаще всего, регулярных учений по переключению.
Последний пункт стоит подчеркнуть. Резервная площадка, на которой никто ни разу не пробовал переключиться, это не отказоустойчивость, а её имитация. Проверка раз в квартал по написанному сценарию, с фиксацией фактического времени переключения, превращает строчку в договоре в реальную гарантию.
Иллюстративный пример: как считали для дистрибьютора в Алматы
Приведём условный, но типичный для нашей практики расчёт: это иллюстрация логики принятия решения, а не описание конкретной задокументированной функции продукта.
Компания: оптовый дистрибьютор строительных материалов, 45 сотрудников, коробочный Битрикс24 на собственном сервере в офисе, 60 тысяч сделок в базе за четыре года. Запрос звучал как «хотим резервный дата-центр, чтобы точно ничего не потерять».
Первое, что выяснилось при аудите: резервные копии делались, но складывались на тот же физический сервер, что и сам портал. То есть от главного риска (выхода из строя дискового массива) защиты не было вообще. Второе: сервер стоял в офисе, где электричество за прошлый год отключалось четыре раза, а ИБП держал нагрузку 20 минут.
Посчитали стоимость простоя: около 40 тысяч тенге в час с учётом того, что часть заказов принимается по телефону и записывается вручную. Допустимое время восстановления руководитель определил как рабочий день, то есть до 8 часов. Допустимая потеря данных: не больше часа, потому что за час набегает 10-15 сделок, которые придётся восстанавливать по переписке.
Итоговое решение оказалось дешевле исходного запроса примерно втрое. Портал перевезли из офиса в коммерческий дата-центр, настроили регулярное резервное копирование с выгрузкой во внешнее хранилище и отдельную копию базы с более частым снятием, чем раз в сутки, написали и один раз проверили на практике регламент восстановления. Никакого второго дата-центра не потребовалось: фактическое время восстановления на учениях составило 2 часа 40 минут при допустимых восьми.
Через полгода компания выросла и добавила интернет-магазин с оформлением заказов через портал, и вот тогда разговор про вторую площадку и переход на старшую редакцию стал экономически обоснованным. Это нормальная эволюция: инфраструктура должна догонять бизнес, а не опережать его на два размера.
Чек-лист для малого бизнеса: что сделать в ближайший месяц
Если у вас коробочный Битрикс24 и нет уверенности в защищённости, пройдите по семи пунктам: это займёт несколько часов и закроет большинство рисков.
1. Проверьте, где физически лежат резервные копии. Если на том же сервере или том же дисковом массиве, это не резервная копия. Настройте выгрузку во внешнее хранилище.
2. Проверьте, что копии действительно создаются. В административной части видно, когда копия создана, какого она размера и загрузилась ли во внешнее хранилище. По журналу резервного копирования быстрее всего понять, что процесс не сломался ещё полгода назад.
3. Разверните копию на тестовом сервере. Единственная настоящая проверка бэкапа: восстановление из него. Пока копия не развёрнута хотя бы раз, вы не знаете, работает ли она.
4. Зафиксируйте RTO и RPO письменно. Не «чтобы всё быстро», а «восстановление за 4 часа, потеря данных не более часа». Без цифр нельзя ни выбрать решение, ни проверить подрядчика.
5. Оцените, где стоит сервер. Сервер, который стоит в офисе, чаще всего оказывается самой уязвимой точкой в малом бизнесе: подводят электричество, кондиционирование, интернет-канал и физический доступ посторонних. Переезд в дата-центр обычно даёт больший прирост надёжности, чем любые кластерные технологии.
6. Проверьте версии окружения. Устаревшая версия PHP или базы данных несёт двойной риск: это уязвимость сама по себе и вероятность того, что при аварийном восстановлении портал просто не запустится на актуальном окружении. Обновления делаются планово и обязательно после снятия копии.
7. Опишите, кто и что делает при аварии. Один документ на страницу: кто получает сигнал, у кого пароли, в каком порядке поднимается система, кого предупреждают из сотрудников и клиентов. В момент аварии никто не будет разбираться заново.
Когда второй дата-центр действительно нужен
Есть несколько признаков, по которым видно, что компания доросла до географического резерва, и решение перестаёт быть избыточным.
Портал стал каналом продаж, а не только внутренним инструментом: клиенты оформляют заказы, оставляют заявки, пользуются личным кабинетом. В этом случае простой означает прямую потерю выручки, а не только неудобство сотрудников.
Работа идёт круглосуточно или в нескольких часовых поясах, и «починим утром» не подходит по определению. Диспетчерские, сервисные службы, логистика, поддержка с обязательствами перед клиентами.
Требования исходят от контрагента или регулятора: крупный заказчик прописывает в договоре доступность сервисов, или отраслевые правила требуют плана обеспечения непрерывности. Здесь резервная площадка не про технику, а про допуск к контракту.
Число сотрудников и нагрузка выросли настолько, что вы и так рассматриваете старшую редакцию ради масштабирования. В этом случае модуль «Веб-кластер» вы получаете как часть решения, и добавление второй площадки становится инкрементальным шагом, а не отдельным проектом с нуля.
Если ни один из признаков не про вас, вкладывайте бюджет в качественный первый уровень и регламент. Компания, у которой копии лежат вне основного сервера, проверены восстановлением и сопровождаются понятным планом действий, защищена лучше, чем та, у которой есть дорогая резервная площадка, но никто не помнит, как на неё переключаться. А когда бизнес дорастёт до географического кластера, переход обопрётся на уже отработанные процессы и пройдёт спокойнее.
Частые вопросы
Можно ли настроить резервный дата-центр на любой редакции коробочного Битрикс24?
Нет. Модуль «Веб-кластер», на котором строится и обычный, и географический кластер, по официальному описанию доступен только в редакции Энтерпрайз. На младших редакциях коробки доступны резервное копирование и организационные меры, но не штатная кластеризация.
Чем отличается реплика базы данных от резервного дата-центра?
Реплика: непрерывно обновляемая копия базы, которая может стоять в том же дата-центре и защищает от отказа одного сервера. Резервный дата-центр: отдельная площадка со своей группой серверов в другом городе или стране, которая защищает от отказа всей площадки целиком.
Как часто нужно делать резервные копии коробочного Битрикс24?
Штатная минимальная частота автоматического копирования: раз в сутки. Этого достаточно, если вы готовы потерять данные за день. Если нет, нужны более частые снимки базы средствами сервера и отдельный расчёт допустимой потери данных.
Где лучше хранить резервные копии?
Обязательно вне основного сервера. Штатно доступны локальное хранение, облако 1С-Битрикс и стороннее облачное хранилище: рабочая практика в том, чтобы иметь минимум одну копию за пределами площадки, где стоит портал.
Сервер в офисе или в дата-центре: насколько это критично?
Для малого бизнеса перенос портала из офиса в коммерческий дата-центр обычно даёт больший прирост надёжности, чем любые кластерные схемы: снимаются риски по электропитанию, охлаждению, каналу связи и физическому доступу. Начинать имеет смысл именно с этого.