«Если ЦОД выйдет из строя, производство не должно упасть»

Именно с таким запросом к нам обратился заказчик, который запускал новое промышленное предприятие. На первый взгляд задача звучала стандартно: построить виртуальную инфраструктуру между двумя дата-центрами…но на базе встроенных решений, без покупки дорогих систем и с максимальной отказоустойчивостью. Дело нехитрое — подумал я. Спойлер: нет.

Меня зовут Алексей Макаров, я ведущий системный инженер оператора ИТ-решений «ОБИТ». За годы работы я убедился: даже если ты специалист с огромным опытом развёртывания инфраструктур различной степени сложности с нуля, всегда найдётся проект с типовой задачей, но нетиповым решением. А решение приходится искать уже по ходу проекта — проверяя гипотезы, ошибаясь и постепенно собирая рабочую архитектуру.

Наш заказчик — крупное производственное предприятие с несколькими заводами. На подобных предприятиях через информационные системы проходят все системообразующие процессы: производственное планирование, складской учёт, логистика, документооборот, ERP, контроль поставок. Если виртуальная инфраструктура упадёт хотя бы на час, последствия бизнес ощутит на всех уровнях и в деньгах.

Заказчик запустил строительство нового производства и обратился к нам с задачей построения отказоустойчивой виртуальной инфраструктуры между двумя ЦОДами.

Руководство сформировало четыре ключевых требования:

К моменту старта проекта у заказчика уже были два территориально разнесённых дата-центра — две независимые площадки, на которых должна была работать единая виртуальная инфраструктура.

В каждом из них размещены четыре сервера (узла Hyper-V) с SSD-накопителями, предназначенных для запуска виртуальных машин, а также высокоскоростная сетевая инфраструктура со скоростью передачи данных до 25 Гбит/с.

Также предусмотрена третья независимая площадка. На ней размещён так называемый узел кворума — специальный сервис, который помогает системе определить, какая из площадок остаётся работоспособной в случае сбоя связи между дата-центрами. Благодаря этому удаётся избежать ситуации, когда обе площадки одновременно считают себя «главными» и пытаются взять управление на себя, что может привести к рассинхронизации данных и сбою системы.

Все три площадки соединены зарезервированными выделенными каналами связи с минимальной задержкой.

Первым делом нужно было ответить на главный вопрос: на какой архитектуре вообще строить такую инфраструктуру?

Самый очевидный вариант — создать два независимых кластера серверов (по одному в каждом ЦОДе) с использованием технологии резервного копирования Hyper-V Replica. Метод использует независимые площадки и достаточно прост в реализации, но с учётом асинхронной репликации (когда изменения передаются с задержкой) в случае серьёзной аварии существует риск потерять последние изменения данных, а часть сервисов придётся переключать вручную.

Второй вариант — классическая SAN-репликация, которая позволяет автоматически копировать все данные с одного главного сервера-хранилища на резервный. Технология надёжная и давно используется на рынке, но требует дорогих систем хранения данных (СХД) и высокоскоростных каналов связи.

В итоге выбор пал на распределённый кластер (Stretch Cluster) на базе Storage Spaces Direct (S2D). S2D — технология, которая объединяет диски нескольких серверов в единое отказоустойчивое хранилище. Решение также встроено в Windows Server и позволяет получить синхронную репликацию между площадками, автоматическое переключение сервисов и единое управление всей инфраструктурой без дополнительных лицензий на специализированные СХД. В чём подвох — требуется сложная настройка, глубокое понимание принципов отказоустойчивой кластеризации и высокие требования к сети.

Но именно здесь начинается разница между теорией и промышленной эксплуатацией. Распределённый кластер, который одновременно работает сразу в двух дата-центрах, предъявляет гораздо более жёсткие требования к инфраструктуре, чем обычный кластер внутри одного ЦОДа:

Первым делом мы взялись за проектирование и настройку сети. Именно от неё зависело, сможет ли вся система корректно работать сразу между двумя дата-центрами.

Чтобы разные процессы не мешали друг другу, мы разделили сетевой трафик по отдельным каналам. Один использовался для управления инфраструктурой (Management), второй — для синхронной репликации данных между площадками (Storage Replica), третий отвечал за служебный обмен информацией между узлами кластера (Cluster Heartbeat), а четвертый — за миграцию виртуальных машин между серверами (Live Migration).

Если представить инфраструктуру в виде города, то вместо одной общей дороги мы построили несколько магистралей для разных видов транспорта: автомобилей, поездов, судов. Благодаря этому даже при высокой нагрузке разные типы трафика не мешают друг другу.

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

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

Во время тестирования кластеры неожиданно начали терять связь друг с другом. Узлы периодически исключались из кластера, службы останавливались, а картина происходящего всё меньше напоминала отказоустойчивую инфраструктуру.

Такие ситуации и нужны для того, чтобы найти слабые места до запуска системы в эксплуатацию. Шаг за шагом мы начали разбираться: анализировали журналы событий, проверяли сеть, исключали возможные причины. В итоге источник проблемы оказался в настройках межсетевого экрана и особенностей протокола IPv6. Подобные сюрпризы появлялись и по мере того, как мы дорабатывали политики приоритизации трафика, корректировали ограничения для разных подсетей, настраивали системные компоненты.

Заканчивается ли на этом этапе настройка и тестирование? Конечно, нет. Настаёт время самого интересного — моделирования аварийных сценариев:

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

Добиться отказоустойчивой инфраструктуры невозможно без её проверки на прочность. А это десятки мелочей, которые появляются во время тестирования и моделирования различных инцидентов.

Поэтому при реализации подобных проектов мы всегда придерживаемся нескольких принципов: