Синхронная и асинхронная репликация: как выбрать режим для вашего ЦОД
Синхронная репликация в ПО «Юпитер» реализуется командой vol synccopy create и подтверждает запись на удалённом томе перед завершением операции на основном, обеспечивая нулевой RPO при условии низкой задержки канала. Асинхронная репликация выполняется через vol copy с параметрами interval или timepoint — данные передаются по расписанию, что снижает требования к каналу связи, но допускает отставание удалённой копии. Выбор режима зависит от расстояния между площадками, критичности данных и допустимого окна потери информации при аварии.
Инженеры ЦОД знают: путаница между синхронной репликацией и Метрокластером — частая ошибка на этапе проектирования DR-стратегии. Это разные функции ПО «Юпитер»: Метрокластер обеспечивает непрерывную доступность между удалёнными ЦОД на уровне кластера, а репликация тома — это механизм копирования данных между независимыми системами хранения. Разберём, чем отличаются два режима репликации и как рассчитать применимость каждого.
Синхронная репликация: нулевая потеря данных
Команда vol synccopy create создаёт зеркальную копию тома на удалённом хосте, причём каждая операция записи считается завершённой только после подтверждения от обеих сторон. Такая схема даёт RPO, близкий к нулю, — при аварии основной площадки удалённая копия содержит все транзакции без исключения.
- Требует стабильного канала с низкой задержкой между площадками.
- Задержка канала напрямую добавляется к времени отклика каждой операции записи.
- Оптимальна для критичных БД, финансовых транзакций, систем с жёсткими требованиями к целостности.
Асинхронная репликация: гибкость и экономия канала
Механизм vol copy передаёт данные по расписанию — параметр interval задаёт периодичность в секундах, а timepoint позволяет привязать копирование к конкретным минутам, часам, дням, месяцам или дням недели. На практике мы видим этот режим там, где расстояние между ЦОД велико и синхронная схема просто физически не даст приемлемой производительности записи.
Асинхронная репликация допускает отставание удалённой копии на величину заданного интервала — это и есть RPO, который заказчик сознательно принимает в обмен на снижение требований к каналу и отсутствие влияния на латентность записи на основной площадке.
Консистентные группы для согласованной репликации
Отдельные тома редко существуют изолированно — база данных часто состоит из нескольких LUN, которые логически связаны между собой. Функция csgroup объединяет такие тома в консистентную группу, гарантируя, что снепшот фиксирует согласованное состояние всех томов группы одновременно.
- Снепшоты консистентной группы создаются командой csgroup snap create.
- Откат группы к предыдущему состоянию выполняется через csgroup snap rollback.
- Такой подход исключает рассинхронизацию между связанными томами БД при восстановлении после аварии.
Сравнение режимов репликации
| Параметр | Синхронная (vol synccopy) | Асинхронная (vol copy) |
|---|---|---|
| RPO | Близко к нулю | Равен заданному интервалу |
| Требования к каналу | Низкая задержка, высокая стабильность | Допускает нестабильный или удалённый канал |
| Влияние на производительность записи | Есть, задержка канала добавляется к latency | Минимальное, репликация вне пути записи |
| Настройка расписания | Не применимо, репликация непрерывна | interval или timepoint (минуты/часы/дни/месяцы) |
| Типичный сценарий | Критичные БД, финансовые транзакции | Резервные копии, удалённые ЦОД на большом расстоянии |
Практический кейс: выбор режима для филиальной сети
Банк с центральным ЦОД в Москве и резервной площадкой в другом регионе на расстоянии более 500 км не может использовать синхронную репликацию из-за неизбежной задержки канала — это ударит по производительности транзакционной системы. Решение — асинхронная репликация через vol copy с интервалом в несколько минут для некритичных данных и синхронная схема vol synccopy только для локального резервирования внутри одного ЦОД с низкой задержкой. Консистентные группы применяются для связанных томов ядра банковской системы, чтобы гарантировать целостность при восстановлении. Расчёт оптимальной схемы репликации под конкретную топологию сети можно обсудить со специалистами на nimbus.ru.
Частые вопросы
Можно ли использовать синхронную репликацию между городами?
Технически возможно, но задержка канала будет напрямую увеличивать время отклика записи на основной системе, поэтому синхронная схема рекомендуется для площадок с низкой сетевой задержкой.
Чем репликация тома отличается от Метрокластера?
Репликация тома копирует данные между независимыми системами хранения, а Метрокластер обеспечивает непрерывную доступность данных на уровне кластера между удалёнными ЦОД без переключения приложений.
Как задать расписание асинхронной репликации?
Через параметры interval, задающий периодичность в секундах, или timepoint, привязывающий копирование к конкретным минутам, часам, дням или месяцам.
Нужны ли консистентные группы для одиночного тома?
Нет, csgroup актуальна для сценариев с несколькими взаимосвязанными томами, например для многодисковой базы данных.
Что произойдёт при разрыве канала во время синхронной репликации?
Операции записи могут замедлиться или приостановиться до восстановления связи, поскольку подтверждение записи требуется с обеих сторон.
Гром
система хранения данных
В реестре
Оптимально подходит для организаций среднего и крупного бизнеса, которым требуется надежное, масштабируемое и эффективное решение для хранения данных с возможностью адаптации к различным типам нагрузок
Молния
система хранения данных
В реестре
Решение премиум-класса для организаций, чей бизнес зависит от скорости обработки данных и требует инфраструктуры хранения с высокой пропускной способностью. Подходит для отраслей: телекоммуникации, финансы, госучреждения и производство