Отказоустойчивость на два ЦОД: как устроен active-active Stretched Cluster в российской виртуализации

Разбираем, чем «высокая доступность» внутри одного ЦОД отличается от катастрофоустойчивости на две площадки, какие подходы есть на российских платформах и как работает растянутый кластер, когда падает целый дата-центр.

Отказоустойчивость на два ЦОД (катастрофоустойчивость) означает способность инфраструктуры продолжать работу, даже когда из строя выходит не отдельный сервер, а целая площадка. В российской виртуализации это решают тремя способами:

Последний вариант ближе всего к непрерывной доступности, но требует быстрой сети между ЦОД с низкой задержкой.

Высокая доступность (HA) внутри одного дата-центра спасает от отказа узла: виртуальная машина перезапускается на другом сервере кластера. Но если из строя выходит вся площадка (пожар, потеря электропитания, обрыв магистрали), HA не поможет: весь кластер находился в одном месте.

Для критичных систем (банки, ритейл, госуслуги, телеком) простой измеряется в деньгах и репутации. Поэтому инфраструктуру растягивают на два географически разнесённых ЦОД.

Дальше вопрос в том, а как именно это сделать?

1. Метрокластер через внешние СХД.

Серверы двух ЦОД объединяются в кластер, а синхронная репликация данных обеспечивается на уровне систем хранения: их ставят в режим метрокластера. Платформа виртуализации при этом лишь «переезжает» между площадками. Минус: нужны внешние СХД с поддержкой метрокластера и их лицензии.

2. Асинхронная репликация (active-passive, DR).

Одна площадка рабочая, вторая резервная. Данные копируются на резерв с некоторым интервалом. Подходит для больших расстояний, но при аварии теряются последние изменения (ненулевой RPO), а на переключение нужно время. Это катастрофоустойчивость, но не непрерывность.

3. Растянутый кластер (stretched cluster) в HCI, active-active.

Узлы обеих площадок образуют единый кластер, а программно-определяемое хранилище (SDS) реплицирует данные между ЦОД синхронно. Обе площадки активны и делят нагрузку. При отказе одной вторая продолжает обслуживать сервисы без потери данных. Из трёх подходов это ближе всего к непрерывной работе сервисов, и реализует его гиперконвергентная архитектура.

Растянутый кластер — функция платформы vStack HCP, его строят средствами самой платформы, без отдельной внешней СХД.

Механика такая:

- Единый кластер на два ЦОД.

Вычислительные узлы обеих площадок и программно-определяемое хранилище (SDS собственной разработки) работают как одна система; поддерживается живая миграция (live migration) ВМ между площадками.

- Синхронная репликация данных (на уровне блоков).

Все операции записи выполняются синхронно на обеих площадках и хранятся с избыточностью (модель 2N, зеркало RAID-1) на локальных дисках; консистентность восстанавливает сам SDS. Потеря данных при отказе площадки практически исключена — RPO практически равен нулю.

- Арбитр в третьей точке.

Отдельный арбитр (quorum-сервер) на независимой площадке нужен, чтобы разрешать «split-brain», то есть ситуацию, когда связь между двумя ЦОД временно пропала и каждая площадка «думает», что выжила только она. Арбитр определяет, кто продолжает работу, и не даёт данным разойтись.

- Автоматическое переключение.

При потере целой площадки нагрузки продолжают работать на второй, восстановление проходит без ручного вмешательства (RTO ≈ 2 минуты); после возврата связи данные синхронизируются.

Растянутый active-active нужно проектировать. Три вещи, которые нужно продумать заранее:

- Каналы между ЦОД.

Синхронная репликация требует высокоскоростной связи с минимальной задержкой (обычно единицы миллисекунд). Чем больше расстояние, тем сложнее удержать синхронность; на больших расстояниях подходит асинхронный DR.

- Арбитр и кворум.

Третья независимая площадка для арбитра обязательна для защиты от split-brain.

- Тестирование сценариев отказа.

Перед вводом в прод нужно смоделировать потерю узла, потерю площадки и обрыв каналов между ЦОД, а затем измерить фактические RPO и RTO.

- Нужно: банкам и финтеху, госуслугам и КИИ, ритейлу, телеком-операторам, провайдерам: везде, где недопустим простой и потеря данных.

- Избыточно: для некритичных сред, тестовых контуров и небольших инсталляций достаточно HA внутри одного ЦОД или асинхронного DR; растянутый кластер там не окупит требований к каналам.