Репликация между дата-центрами: актив-актив против актив-пассив и отработка переключений

Изображение: recraft
Репликация между дата-центрами – это технология, которая решает задачи обеспечения достаточности данных и доступности сервисов. Основная задача заключается в том, чтобы создать дополнительные копии не только пользовательских данных, но и программного обеспечения, виртуальных машин, коммутаторов и других компонентов на всех уровнях инфраструктуры. Это позволяет решить несколько важных вопросов для бизнеса: либо обеспечить непрерывность, либо, в случаях, где это приемлемо, согласовать допустимое время простоя. Репликация между дата-центрами часто воспринимается как универсальный ответ на эти вызовы. Однако, ее наличие еще не означает, что система действительно переживет отказ дата-центра без серьезных последствий.
Репликация как инструмент имеет определенные плюсы: предотвращение потери данных, снижение времени простоя вплоть до нулевых значений; минусы: дорогостоящая архитектура, требования к каналам связи, механизмам согласованности. Ключевым архитектурным выбором становится модель взаимодействия площадок: актив-актив или актив-пассив. Эти подходы различаются не только схемой репликации, но и концепцией построения системы в целом. Они по-разному влияют на согласованность данных, сложность эксплуатации, стоимость и сценарии восстановления. Понимание этих различий особенно важно в условиях высоких нагрузок и строгих требований к целостности данных.
Активная репликация обеспечивает доступность данных на всех площадках одновременно, с живой миграцией данных и сессий пользователей между ними, при этом сервис и пользователи не замечают переключения, а нагрузку распределяют балансировщики. Архитектура актив-актив предполагает, что несколько дата-центров одновременно находятся в рабочем состоянии и обслуживают пользовательский трафик. На первый взгляд это выглядит как идеальная модель: нет простаивающих ресурсов, отказ одной площадки не приводит к полной остановке сервиса, а нагрузка может распределяться географически ближе к пользователю.
Тем не менее, ключевая сложность конфигурации актив-актив заключается не в самой репликации данных, а в управлении распределенным состоянием. В такой архитектуре несколько площадок одновременно принимают решения, изменяющие общее состояние системы. Это требует четко определенной модели согласованности и понимания того, какие расхождения допустимы, а какие – нет. Распределенный центр обработки данных (ЦОД) в этой модели подразумевает абсолютно идентичные копии данных с механизмами консистентности для предотвращения «split-brain» (расщепленного мозга – когда площадки действуют независимо).
Активная (синхронная) репликация позволяет минимизировать потерю данных, но напрямую связывает производительность системы с задержками между дата-центрами. Даже небольшие задержки могут приводить к расхождению данных и риску конфликтов, в частности для геораспределенных ЦОД, поскольку они особенно подвержены рискам расхождения данных и конфликтов при синхронной репликации по причине больших сетевых задержек между удаленными локациями. Синхронная репликация популярна для критических сервисов, таких, как банки, медицина, госуслуги, но требует идентичного оборудования, хороших каналов связи и дополнительного согласования. Асинхронная (пассивная) репликация снижает это влияние, но создает окно несогласованности, которое необходимо учитывать на уровне бизнес-логики. Пассивная репликация допускает небольшую потерю данных, не ограничена расстоянием, позволяет использовать облака и разные площадки без поддержания идентичности инфраструктуры.
Предсказуемость – главное преимущество модели актив-пассив. Отсутствие параллельной записи данных с нескольких площадок упрощает модель согласованности и снижает вероятность логических конфликтов. Асинхронная репликация позволяет размещать дата-центры на значительном расстоянии друг от друга, не опасаясь снижения производительности.
Несмотря на это, модель актив-пассив не лишена недостатков. Переключение на резервную площадку почти всегда сопровождается простоем, а величина RTO (Recovery Time Objective, целевое время восстановления) напрямую зависит от степени автоматизации и готовности дежурной смены ЦОД. Кроме того, при аварийном переключении возможна потеря части данных, накопленных после последней успешной репликации.
С точки зрения экономики актив-пассив также не всегда оптимален: резервный дата-центр большую часть времени простаивает или используется в ограниченном режиме. В то же время, во многих организациях этот недостаток компенсируется снижением эксплуатационных рисков и упрощением поддержки.
Важно отметить, что модель актив-актив обычно имеет преимущество в скорости восстановления и использовании ресурсов, однако, также имеет ограничение в простоте эксплуатации. Модель актив-пассив, напротив, теряет преимущество в части доступности ради управляемости, предсказуемости и простоты понимания состояния системы.
УЦСБ, как компания, специализирующаяся на информационной безопасности, активно использует механизм репликации для двух ключевых задач. Во-первых, для повышения доступности и отказоустойчивости средств защиты информации, таких как NGFW и песочницы. Во-вторых, она предназначена для сохранения копий данных в исходном состоянии с временными отметками для анализа и расследования инцидентов, поскольку первичные источники постоянно изменяются и бывает сложно отследить их эволюцию. Для этого применяем асинхронную репликацию: снимаем нагрузку с основного оборудования посредством создания резервных копий, чтобы не снижать производительность систем.
Раньше большая часть инструментов для создания реплик была зарубежными, но сейчас активно разрабатываются российские, и у нас уже есть позитивный опыт их внедрения. Российские решения поддерживают синхронную и асинхронную репликацию, распределенные виртуальные тома, среды виртуализации между площадками, горячий и холодный резерв, вторичную репликацию и распределенные базы данных (БД) для почтовых сервисов. Выстраивается позитивная тенденция к полному замещению стэка и реализации сложных задач по сохранности данных.
Независимо от архитектурной модели, реальная отказоустойчивость системы определяется тем, насколько корректно реализованы и отработаны сценарии переключений. В архитектуре актив-пассив ключевыми понятиями становятся primary (основной) и standby (резервный). Существуют различные варианты готовности standby площадки.
Холодный резерв предполагает минимальную подготовку: инфраструктура существует, но сервисы запускаются только в момент аварии. Такой подход снижает затраты, но увеличивает RTO и риск ошибок при ручном запуске. Теплый резерв подразумевает частично запущенные сервисы и предварительно синхронизированные данные, что сокращает время восстановления. Горячий резерв максимально приближен к активному состоянию и позволяет переключаться с минимальным простоем, однако, требует дополнительных ресурсов и постоянного контроля.
В архитектуре актив-актив ситуация с переключениями менее очевидна. Здесь принципиальной задачей является не включение резервной площадки, а корректное исключение отказавшей площадки из общего контура, перераспределение нагрузки и последующее восстановление согласованности данных.
Ключевой проблемой является то, что без регулярной практики даже корректно настроенная система перестает быть надежной. Конфигурации меняются, зависимости усложняются, и резервные сценарии устаревают. Поэтому отработка failover (аварийное переключение) и switchover (плановое переключение) должна рассматриваться как регулярный процесс, а не как разовая проверка при вводе системы в эксплуатацию. Поэтому необходимо подготовить соответствующие плейбуки и регулярно проводить испытания различных сценариев переключения. Процесс репликации между дата-центрами является набором архитектурных инструментов, каждый из которых имеет свои ограничения. Репликация – распределенный механизм, решающий задачи на разных уровнях: от данных и БД до хранилищ резервных копий. Модели актив-актив и актив-пассив подходят для разных сценариев и уровней зрелости инфраструктуры. Ключевым фактором успеха служит системная работа по отработке переключений и управлению рисками. Только в этом случае репликация действительно выполняет свою основную задачу по обеспечению устойчивости сервисов к отказам на уровне дата-центров.
Автор: Юлия Сонина, старший аналитик Аналитического Центра ИТ-компании УЦСБ.
