Хабрахабр

Реакция на аварию: растянутый кластер против DR-площадки

Они имеют несколько точек сохранения снэпшотов. У нас есть два подхода к Disaster Recovery: «растянутый» кластер (active-active-инсталляция) и площадка с выключенными виртуальными машинами (репликами).

Поэтому мы начали прорабатывать обе схемы в рамках нашего продакшна. Запрос на катастрофоустойчивость есть, и многим нашим клиентам это реально нужно.

У методов есть плюсы и минусы, сейчас про них расскажу.

«Растянутый» кластер

В плюсах — практически нулевой простой, пауза только на время запуска виртуальных машин. Как видите, это стандартная история метрокластера. Она видит, что хосты потерялись, и сразу же перезапускает ВМ на удалённой площадке. Отрабатывает такая фича — VMware High Availability (HA).

Запуск делается сразу с СХД, которая находится в кластере.

У других производителей есть нечто с похожим названием. СХД с геораспределённым кластером — это маркетинговая фича NetApp. Пишем на одну ноду в локальной сети и синхронизируем через специализированные каналы связи с другой. По сути, это продуманная асинхронная репликация с одной стороны на другую.

На них перезапускаются ВМ, которые погибли. В случае отказа одной из СХД оставшаяся (на другой площадке) презентует пути к дискам оставшимся же хостам. Клиент увидел, что всё моргнуло и перезапустилось. Всё происходит автоматически — ЦОД грохнулся, всё перезагрузилось, СХД отработали, VMware отработала.

Но если база данных его скинула, то потеря нулевая по времени. Единственное, кэш из оперативной памяти ВМ может потеряться.

Если у нас теряется связь между площадками, то всё продолжает работать на своих местах и, как только связь восстанавливается, начинает синхронизироваться.

Потому что нужна фактически двойная СХД (причём аналогичная по типам, скорости и объёму дисков первой СХД на основной площадке), которую нельзя как-то использовать, кроме как под резерв. Минус — высокая цена. Плюс обвязка к СХД для метрокластера, это FC-бриджи, FC-сеть и прочее.

Это две железки, каждая обеспечивает по 200 Гбит пропускной способности для FC и Ethernet. У нас два ЦОДа, между ними FC-связка по двум лучам (четыре линии тёмной оптики и DWDM).

Альтернатива с DR

Есть софт с интуитивно запоминающимся названием — VMware vCloud Availability for Cloud-to-Cloud DR.

К ней на изоленте примотана система презентации всего этого правильным образом в механизмы управления облаком. Это система создания идентичной ВМ на удалённой площадке раз, условно говоря, в 15 минут.

В случае отказа мы вручную запускаем DR-план на второй площадке, он автоматически прекращает попытки реплицировать, затем регистрирует ВМ в vCloud Director, кастомизирует IP-адреса (чтобы не пришлось менять их на ВМ) и запускает ВМ в нужном порядке. То есть в бэкенде находится технология VMware Replication. В нашем решении менять адресацию не нужно, мы растягиваем сети на оба ЦОДа.

Реплицируется раз в какое-то время, минимальный интервал — 15 минут (это идеальный случай, когда всё летает и есть выделенный сервер репликации и минимум изменений на ВМ). Машины реплицируются постоянно, но не весь ЦОД, а только выбранные — критичные процессы. Если что-то пошло не так, то данные, которые попали в интервал, потерялись. На практике у вас есть копия на полчаса или час назад. Veeam говорят, что могут меньше 15 минут, но по факту тоже на практике дольше, если не используют фичи СХД. 15 минут — это вопрос агента, который собирает новую репликацию. Я не видел на промышленной машине (не на тесте), чтобы было иначе.

Уже давно у NetApp, как и у многих других производителей СХД, есть технология SnapMirror, которая позволяет переложить работу по репликации с гипервизоров на СХД, и VMware Replication умеет этим пользоваться.

Но зато это дёшево. Пока сервис репликации пробежит, поезд уходит далеко.

Почему ещё дёшево — потому что можно использовать любую СХД с любой стороны (от разных производителей, разного класса), не надо выделять заранее большой объём дисков.

Просто берётся место на локальной СХД и применяется по факту наличия записи от виртуальной машины. Не надо выделять большую дисковую группу, внутри которой нарезаются луны. А она используется, так как мы не всем клиентам даём такую услугу. За счёт этого оптимальнее занимается место на СХД, если она используется под другие задачи.

Создавать DR-планы для каждого клиента, проводить их испытания. Минус — надо настраивать репликацию на уровне ВМ, то есть контролировать, что всё верно настроено, что это та машина, следить за тем, что репликация проходит, что ошибок нет.

А тут одна машина может отвалиться по причине отваливания задачи из-за каких-то софтверных причин, связанных с багом на высоких уровнях, или из-за проблем с доступностью. В первом случае СХД берётся, условно, инфраструктурно, чуть ли не по секторам (точнее, по объектам). Это случается чуть чаще, чем если брать именно низкие уровни.

Можно откатиться на несколько снепшотов назад. В плюсе — DR хранит несколько точек.

Снаружи от гостевых ОС нужен дополнительный софт.

Вообще, вся сетевая связность в этом варианте остаётся на нашем администраторе. Чтобы до Vcloud Director прокинуть все нужные сети, нужна работа нашего администратора. Для клиента облака это означает заявку, что тоже занимает время.

Добавил ВМ — надо отправить заявку, что необходимо её реплицировать. Репликация настраивается тоже через заявку. Нужно уделять внимание админу. Автоматом она в задачи по репликации не попадёт.

Разница

В итоге цена может отличаться больше чем в два раза. Репликация будет умножать стоимость дискового пространства на два и больше (две полные копии + история изменений), плюс что-то за сервис и резервацию вычислительных ресурсов. В случае с метрокластером стоимость пространства будет умножаться на два, но само пространство будет стоить значительно дороже, плюс надо жёстко резервировать узлы на удалённой площадке. То есть и вычислительные ресурсы должны умножаться на два, мы их не можем утилизировать под что-то ещё.

Если на основном ЦОДе часть дисков быстрые, часть медленные на 10 тысяч оборотов в минуту, то нужна идентичная конфигурация. В случае с метрокластером мы можем использовать только одинаковые типы дисков, чтобы было полное зеркало. Но при переключении на резерв он окажется по производительности меньше. В случае реплики возможны более медленные диски на резервной площадке, а это дешевле за счёт хранения. То есть если он что-то хранит на SSD в основном кластере, а реплицируется на обычные диски, то хранение будет значительно дешевле ценой замедления инфраструктуры резерва.

Прямо сейчас мы выбираем то, что войдёт в более ранний релиз, поэтому хотим посоветоваться: можете коротко рассказать, как вы организуете свои DR-площадки и что бы от них хотели вообще в целом?

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть