SnapMirror SM-BC

Business continuity as it finest

Что значит business continuity?

Если коротко - гранулярное обеспечение RTO 0 и RPO 0 для Tier 1 приложений с автоматическим переключение приложений на другую площадку

Детальнее - обеспечение отказоустойчивой работы mission critical приложений в инфраструктуре, где metrocluster еще не нужен, а вот обычной синхронной репликации уже недостаточно

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

В чем его основное отличие от SnapMirror synchronous?

Отличительной чертой и достаточно важным отличием является то, что читать и писать можно одновременно как в primary так и в secondary

За корректировку консистентности данных между площадками отвечает медиатор

В своей основе для передачи трафика используется синхронный SM-S движок, но все же есть кардинальные отличия

Главное из них отличие в гранулярность репликации:

	SM-S	SM-BC
Гранулярность	Volume	Application
Протоколы	Все	FC, iSCSI
LUN identity	независимые LUN	Consistency groups (Полные клоны)
Failover	Ручное перключение нагрузки на secondary площадке	Автоматическое переключение нагрузки на secondary площадке
ONTAP	минимум ONTAP 9.5	минимум ONTAP 9.8
RTO	до 120sec	0sec
RPO	0	0
Платформы	Поддерживает AFF, FAS, ASA	Поддерживает AFF, ASA
cross platform	ASA, AFF или FAS могут быть как Source так и Destination	AFF to AFF ASA to ASA Нельзя миксовать
Типы нод на площадках	Могут быть разных поколений	Могут быть разных поколений
Кластер	Нет ограничений	Только по 2 ноды на каждую площадку
Mediator	Не нужен медиатор	Нужен медиатор

Основные преимущества

Учитывая, что это все тот же старый добрый SM-S, SM-BC решает конкретную задачу, а значит его преимущества сконцентрированы вокруг mission critical приложений

Он позволит вам создать консистентные группы для снятия консистентных снепшотов на уровне грунулярности нескольких вольюмов (LUN) одновременно. Что гарантирует полную консистентность приложения вне зависимость от количества лунов на которое он разбит.

Другими словами - снимается групповой снэпшот и зеркадируется на другую площадку

Получается, SM-BC не умеет защищать вольюмы а только Applications?

Не совсем так

SM-BC собирает LUN в консистентные группы и зеркалирует их на secondary площадку. Что по сути и есть гранулярность на уровне вольюма

Трюк в том что мы не можем защитить "любую" нагрузку как в случае с SM-S, а можем защитить только конкретные поддерживаемые Application которые находятся на лунах в консистентных группах

А что значит Application и какие поддерживаются?

Application в понимании SM-BC это LUNы организованные в консистентные группы для обеспечения отказоустойчивости конкретной нагрузки. Например кластер SQL, Oracle

На текущий момент поддерживаются такие application:

• Stand alone windows or linux hosts

• VMware Metro Storage Cluster (vMSC)

• Монолитные кластеры БД (ORACLE, SQL)

Что такое консистентные группы и зачем они нужны?

Consistency group - набор вольюмов (LUN) содержащих в себе приложение и зеркалированных на другую площадку

Основное предназначение консистентных групп - создание общего crash-consistent снепшота. Движок SM-BC гарантирует что все луны что входят в конкретную группу снимут полностью консистентный снепшот и синхронизируют его между собой и второй площадкой

Какое количество консистентных групп поддерживается?

5 групп, по 12 вольюмов в каждой (будет увеличиваться в следующих прошивках)

LUN может быть много в пределах этих 12 вольюмов

Можно использовать совместно с другими типами репликации?

Да

Он платный?

Отдельно не лицензируется. Входит в общий пакет Data protection и движок Snapmirror