Отказоустойчивость — способность кластера продолжать работу при отказе отдельных узлов. Разберём, как резервировать каждый слой инфраструктуры 1С-Битрикс, что такое RPO/RTO и как выстроить бэкапы и регламент восстановления.
Принципы отказоустойчивости
Отказоустойчивая система не имеет единой точки отказа (SPOF): падение любого одного узла не должно останавливать сервис. Достигается это резервированием каждого слоя — веб, балансировщик, база данных, кеш, хранилище файлов.
Веб-кластер Битрикс закрывает часть задачи (несколько веб-нод, реплики БД), но полная отказоустойчивость требует внимания и к тем компонентам, которые модуль cluster сам не резервирует — прежде всего к балансировщику и к мастеру БД.
Резервирование веб-нод
Веб-слой резервируется проще всего: ноды stateless и взаимозаменяемы. Достаточно двух и более идентичных нод за балансировщиком с health-check — упавшая нода автоматически выпадает из ротации.
- Минимум N+1: столько нод, чтобы при падении одной оставшиеся держали нагрузку.
- Обязательное условие — вынесенные наружу сессии, кеш и файлы, иначе падение ноды теряет пользовательские данные.
- Health-check балансировщика должен проверять реальную работоспособность (например, страницу-пробу), а не только открытый порт.
server 10.0.0.11:80 max_fails=3 fail_timeout=15s;
server 10.0.0.12:80 max_fails=3 fail_timeout=15s;Резервирование балансировщика
Балансировщик — коварная единая точка отказа: если он один, его падение роняет весь сайт, сколько бы ни было веб-нод. Поэтому резервируют и его:
- Keepalived + VRRP — два балансировщика с общим виртуальным IP; при отказе активного адрес переезжает на резервный.
- DNS / облачный LB — управляемый балансировщик провайдера с встроенной отказоустойчивостью.
- Anycast — для геораспределённых инсталляций.
Отказоустойчивость базы данных
Мастер БД — самый сложный для резервирования слой, потому что запись идёт только на него. Штатная репликация Битрикс масштабирует чтения, но не переключает мастер автоматически. Варианты:
| Решение | Модель | Failover |
|---|---|---|
| MySQL master-slave + MHA | Асинхронная | Автопродвижение реплики |
| Galera / Percona XtraDB | Синхронный мультимастер | Встроенный |
| Ручное продвижение | Асинхронная | По регламенту, вручную |
Выбор зависит от допустимого времени простоя записи. Синхронный кластер (Galera) даёт лучший failover, но требует совместимости приложения с его особенностями — например, поведением при конфликтах записи.
Резервное копирование
Резервирование узлов не отменяет бэкапов: кластер защищает от отказа железа, но не от логических ошибок, порчи данных или атаки. Полноценная стратегия включает и то, и другое.
- База данных — регулярные дампы (
mysqldump/xtrabackup), лучше с реплики, чтобы не грузить мастер. - Файлы —
/upload/и конфигурация; каталог ядра восстанавливается из дистрибутива. - Хранение — копии на отдельной площадке (offsite), иначе сбой ЦОД унесёт и продакшн, и бэкап.
- Регулярно проверяйте восстановление из бэкапа — непроверенный бэкап равен отсутствию бэкапа.
Штатный модуль резервного копирования Битрикс подходит для средних объёмов; для крупных баз используют xtrabackup и снапшоты хранилища.
RPO, RTO и регламент
Проектирование отказоустойчивости начинается с двух метрик:
- RPO (Recovery Point Objective) — сколько данных допустимо потерять. Определяет частоту бэкапов и тип репликации.
- RTO (Recovery Time Objective) — за сколько сервис должен восстановиться. Определяет уровень автоматизации failover.
Из этих цифр выводятся технические решения: жёсткий RTO требует автоматического failover (MHA, Keepalived), мягкий — допускает ручной регламент. Регламент восстановления должен быть зафиксирован письменно и отрепетирован: кто, что и в каком порядке делает при аварии.
Итог
Отказоустойчивый кластер 1С-Битрикс — это резервирование каждого слоя без единой точки отказа: взаимозаменяемые веб-ноды, дублированный балансировщик (Keepalived/VRRP), БД с механизмом failover и проверенные offsite-бэкапы. Всё это проектируется от метрик RPO/RTO и подтверждается регулярными учениями.
Мы строим отказоустойчивые инсталляции на Битрикс под ключ: убираем SPOF, настраиваем failover БД и балансировщиков, выстраиваем бэкапы с проверкой восстановления и пишем регламенты. Поможем довести «кластер на бумаге» до системы, которая реально переживает отказ узла.
Частые вопросы
Что такое единая точка отказа (SPOF)?
Это узел, падение которого останавливает весь сервис. В кластере Битрикс частый скрытый SPOF — единственный балансировщик или единственный мастер БД.
Даёт ли веб-кластер Битрикс полную отказоустойчивость?
Частично. Он резервирует веб-ноды и масштабирует чтение БД, но не переключает мастер автоматически и не резервирует балансировщик — это добавляют отдельно.
Как зарезервировать балансировщик?
Обычно двумя балансировщиками с общим виртуальным IP через Keepalived/VRRP или управляемым облачным балансировщиком с встроенной отказоустойчивостью.
Нужны ли бэкапы, если есть кластер?
Да. Кластер защищает от отказа железа, но не от логических ошибок, порчи или удаления данных. Бэкапы и репликация решают разные задачи.
Что важнее — RPO или RTO?
Обе метрики. RPO задаёт допустимую потерю данных и частоту бэкапов, RTO — допустимое время простоя и уровень автоматизации failover. Их определяют из требований бизнеса.
Как автоматически переключать мастер БД?
Внешними инструментами: MHA или Orchestrator для продвижения реплики, либо синхронный кластер Galera/Percona XtraDB со встроенным failover.
Зачем проводить учения по отказу?
Чтобы убедиться, что failover реально работает, и выявить скрытые SPOF в контролируемых условиях, а не во время настоящей аварии.
Поможем с настройкой и поддержкой Для разработчиков
Поможем с настройкой, доработкой и поддержкой Для разработчиков.