К нам обратился заказчик с задачей построения катастрофоустойчивого кластера виртуализации. Из-за отсутствия на рынке доступных предложений пришлось подгонять под нужные параметры отечественные решения. Рассказываем, как Департамент вычислительных систем STEP LOGIC справился с этой задачей.

Что такое метрокластер?

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

Зачем он нужен?

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

Для определения уровня надежности центров обработки данных используется классификация Uptime Institute, включающая четыре уровня:

• Tier I — базовая инфраструктура без резервирования;

• Tier II — инфраструктура с резервными мощностями;

• Tier III — инфраструктура, поддерживающая параллельный ремонт;

• Tier IV — отказоустойчивая инфраструктура.

Считается, что уровень доступности для каждого уровня составляет:

• для Tier I — 99,671 или 1729 минут годового простоя;

• для Tier II — 99,741 или 1361 минут годового простоя;

• для Tier III — 99,982 или 95 минут годового простоя;

• для Tier IV — 99,995 или 26 минут годового простоя.

Почти все сертифицированные Uptime Institute российские ЦОДы имеют класс Tier III, но иногда встречается и Tier II.

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

Вывод напрашивается сам собой: достичь показателей хотя бы 99,995, не говоря о 99,999, без использования технологии георезервирования невозможно.

Доступность отдельных компонентов определяется уравнением:

Где:

• MTBF — среднее время между отказами,

• MTTR — среднее время до восстановления работоспособности.

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

В связи с уходом с отечественного рынка западных производителей оборудования и ПО уровень технической поддержки для их решений оказался сильно ограничен. Поэтому создание надежной ИТ-инфраструктуры в текущий момент невозможно без использования отечественных компонентов.

А это проблематично, так как у российских производителей, как оказалось после изучения и рассмотрения десятков различных вариантов, нет готовых решений для построения гео-распределенного кластера виртуализации. Одни из самых продвинутых отечественных систем на базе программного обеспечения RADIX и YADRO TATLIN.UNIFIED поддерживают механизм синхронной репликации. Однако функционал метрокластера, необходимый для идентификации выхода одной из систем хранения из строя и быстрого автоматического переключения клиентских узлов на резервную систему хранения, в них пока не реализован.

С отечественными платформами виртуализации ситуация во многом аналогичная — архитектурно реализовать механизм отказоустойчивости для системы управления другими платформами возможно только сторонними наложенными средствами. Западное же оборудование и программное обеспечение, имеющее данную функциональность, официально не поставляются в Россию и не покрываются гарантией производителя.

Поэтому нам пришлось собирать конструктор на базе отечественных компонентов.

• В качестве системы хранения данных использовали гибридную СХД "Аэродиск ENGINE" от разработчика АЭРОДИСК, как единственную на момент разработки решения отечественную дисковую систему, в которой полностью реализован механизм метрокластера.

• По тем же причинам операционной системой и системой виртуализации в решении были выбраны ПО Astra Linux Special Edition и "Брест" от компании «РусБИТех-Астра»;

• А вот варианты серверного оборудования могут различаться, единственное условие – совместимость с Astra  Linux, то есть подойдут серверы Depo, ICL, Yadro и другие.

Кстати, все кусочки нашего пазла внесены в «Единый реестр российских программ для электронных вычислительных машин и баз данных».

Из чего же сделан метрокластер?

СХД

Метрокластер позволяет виртуальным машинам, распределенным по центрам обработки данных, действовать так, как будто они находятся в одном локальном кластере. Чтобы обеспечить эту функциональность, виртуальным машинам необходим доступ к одному и тому же хранилищу на всех узлах. СХД Аэродиск ENGINE поддерживает такой функционал. Подключить узлы кластера к системе хранения данных можно по протоколу iSCSI.

Подробное описание работы Aэродиск ENGINE в режиме метрокластера можно найти в статье AERODISK Engine: Катастрофоустойчивость. Часть 1 / Хабр (habr.com)

Общее хранилище

Для организации общего хранилища мы выбрали тип LVM_LVM. При использовании драйвера хранилища LVM_LVM необходимо наличие на всех узлах кластера, включая узлы Front-end, общих блочных устройств хранения данных. Этот тип хранилища обладает следующими особенностями:

• при загрузке образа диска виртуальной машины в хранилище образов (image) автоматически создается LVM-том, в который записывается загружаемый образ в формате RAW;

• при развертывании виртуальной машины в системном хранилище (system) автоматически создается копия LVM-тома из хранилища образов;

• пока не поддерживается создание снимков (snapshot) дисков.

Кроме него мы рассматривали и другие сценарии организации хранилищ.

Сервисы управления

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

В отличие от многих других систем управления виртуализацией, платформа виртуализации “Брест” имеет встроенный механизм обеспечения высокой доступности средств управления. Для его задействования разворачивается нечетное количество экземпляров Front-end, которые взаимодействуя между собой по алгоритму RAFT, обеспечивают доступность сервисов управления облаком при отказе менее половины узлов. Для создания метрокластера мы разместили по одному или более Front-end на каждой площадке, и дополнительно вынесли один Front-end на третью площадку для создания кворума.

Проверяем, что получилось

Мы протестировали несколько аварийных ситуаций метрокластера на базе платформы виртуализации “Брест” и системы хранения данных Аэродиск ENGINE.

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