Совместимость серверов «Тринити» с платформами виртуализации: «РУСТЭК»

Привет! Меня зовут Эрик Игнатов, я — ведущий инженер «Тринити».  С недавнего времени у нас в R&D-отделе появился план по тестированию различного ПО. В него входит в том числе порядка 12 отечественных решений для серверной виртуализации, которые мы хотим проверить на совместимость с нашим серверным железом. Ведь заказчикам важно быть гарантированно уверенными в работоспособности предлагаемых нами систем виртуализаций, особенно в условиях настолько стремительного вывода на рынок замен импорту, что некоторым компаниям некогда и тестировать. 

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

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

О платформе виртуализации РУСТЭК

«РУСТЭК» — российская сервисная платформа виртуализации для создания и управления ИТ-инфраструктурой (разработчик с недавнего времени объединился с компанией «Базис»). Платформа включает в себя функционал для эффективного управления серверами, виртуальными машинами, сетью, кластерами и другими объектами среды виртуализации через графический интерфейс единой панели управления. Входит в реестр Минпромторга и имеет сертификаты ФСТЭК. 

Функциональность и преимущества платформы:

• Создание кластеров из физических серверов с разными техническими параметрами и привязка к ним ВМ;

• Автоматическая балансировка нагрузки между узлами кластера;

• Специализированная ОС;

• Поддержка популярных ОС (российских и зарубежных);

• Встроенная система мониторинга платформы и виртуальных машин;

• Интерфейс для самостоятельного развертывания, конфигурирования, масштабирования и обслуживания платформы;

• Отказоустойчивость и катастрофоустойчивость для виртуальных машин и управляющих сервисов;

• Автоматизированная система учёта потребляемых ресурсов до уровня отделов;

• Возможности SDN: фаервол, IPAM, виртуальные роутеры, DNSaaS, BGP, NAT, VXLAN, GRE, GENEVA;

• Автоматизация типовых задач: инфраструктура как код, организация рабочих процессов;

• Высокоуровневые сервисы: Kubernetes, балансировщики;

• Наглядная аналитика;

• Ролевая модель позволяет делегировать управление частями виртуальной инфраструктуры;

• Система выдачи прав на действия над объектами инфраструктуры (ВМ, сети, хранилища, серверы);

• Возможность управления отдельными изолированными областями видимости;

• Техподдержка на всех уровнях.

«РУСТЭК» — собственная разработка компании на базе OpenStack. Напомним, что специалисты «РУСТЭК» еще недавно были мейнтэйнерами OpenStack, разрабатывали для него модули (например, сложный сетевой модуль), имели большое влияние на сообщество. Поэтому платформа почти полностью совместима с исходником. Решение популярно у интеграторов, экспертов по строительству дата-центров и компаний, предоставляющих облачные сервисы (например, облачную виртуализацию). На основании его тестирования мы проводили вебинар по миграции.

Документация к платформе. 

Тестирование платформы виртуализации  РУСТЭК

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

Демо-стенд был построен на базе трёх серверов и системы хранения данных, объединённых посредством сети Ethernet и SAN-сети. Цель стенда — продемонстрировать состав, устройство и функционирование среды виртуализации «РУСТЭК» в формате отказоустойчивого кластера, а также поведение последнего при отказах различных компонентов. Такой кластер виртуальных машин подходит для построения крупных инфраструктур и ЦОДов, специализирующихся на облачных сервисах.

Спецификация оборудования

Сервер Тринити ER215HR-M6 (узел кластера #1)

Сервер Тринити М2335149 (узел кластера #2)

Сервер Тринити ER220HDR-M6-1200W (узел кластера #3)

Хранилище данных

Коммутационное оборудование

Сетевые подключения

Схема коммутаций сети передачи данных LAN:

Схема коммутаций сети хранения данных SAN:

Устройство кластера

Аппаратные компоненты кластера

Представленный демо-стенд построен по схеме: основной узел, дополнительный узел и арбитр с единым сетевым хранилищем данных. Основными компонентами кластера являются:

1. Среда управления виртуализацией («Портал» в терминологии системы виртуализации «РУСТЭК») — выполняет функции управления средой виртуализации и кластером, функционирует на базе виртуальной среды, размещённой в кластере.

2. Узлы кластера — обеспечивают локальное функционирование гипервизоров Kernel-based Virtual Machine (KVM) и предоставляют необходимые системные ресурсы для запускаемых на них виртуальных машин. Функционируют на базе трёх серверов «Тринити».

3. Хранилище данных (Datastore) — служит для хранения шаблонов, образов и файлов данных виртуальных машин кластера. Функционирует на базе СХД IBM Storwize v7000.

4. Сеть передачи данных (LAN) — обеспечивает доступ Портала к узлам кластера (в целях мониторинга и управления физическими узлами, гипервизорами и виртуальными машинами), а также для организации сети виртуальных машин.

5. Сеть хранения данных (SAN) — предоставляет доступ фронтальной машины и узлов кластера к общему хранилищу данных.

Для обеспечения работы ПАК СВ РУСТЭК необходимо выполнение следующих условий:

• ПАК СВ РУСТЭК разворачивается в среде базовой ОС, предоставляемой разработчиком;

• Базовая ОС должна быть установлена на каждом узле;

• Развёртывание РУСТЭК подразумевает наличие выделенной СХД;

• Продуктивная инсталляция с высокой доступностью ВМ и управляющих сервисов подразумевает наличие минимум трёх узлов;

• Требования к организации сети:

• сеть управления: 1 маршрутизируемая сеть c известным VLAN ID, достаточной адресной емкости для всех узлов инсталляции + 1 IP; доступ из этой сети к интерфейсам удаленного управления – IPMI;

• сеть виртуальной инфраструктуры: 1 сеть достаточной адресной емкости для всех узлов инсталляции с известным VLAN ID;

• сеть хранения данных: 1 сеть достаточной адресной емкости для всех узлов инсталляции + СХД;

• внешние сети: произвольное число маршрутизируемых сетей с известными VLAN ID.

• На презентованных нодам дисках общего хранилища необходимо создаётся кластерная файловая система OCFS2.

Управление инфраструктурой виртуализации

Управление средой виртуализации и кластером осуществляется централизованно с помощью web-интерфейса. Для управления через web-интерфейс необходимо использовать браузер (например, Google Chrome, Mozilla Firefox, Internet Explorer, Opera и т. п.). Портал доступен по адресу: https://[Виртуальный_IP]. Для входа в портал и начала работы с РУСТЭК нужно иметь учетные данные:

• имя пользователя по умолчанию: admin;

• чтобы получить первичный пароль, надо выполнить в консоли команду: cat /var/lib/rustack- ansible/creds/keystone/admin_pass;

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

Средства обеспечения отказоустойчивости

Высокую доступность виртуальных машин в РУСТЭК реализует модуль Virtual Appliance High Availability, VAHA.

VAHA работает на множестве хостов, на каждом — в одном из трёх режимов:

• контроллер — работает на узлах с ролью «Управление ВМ», следит за состоянием агентов и выполняет необходимые операции при обнаружении отказа;

• агент — работает на вычислительных узлах, пишет дисковые хартбиты (heartbeats) и отслеживает изоляцию узла, на котором установлен;

• смешанный — используется, если на узле включены обе роли и работает, выполняя функции как агента, так и контроллера.

Для его работы необходимо соблюдение следующих условий:

• наличие минимум трёх физических узлов;

• на узлах должны быть применены такие профили узлов, как: Основной узел, Дополнительный узел, Арбитр;

• СХД или общее хранилище дисков виртуальных машин, доступное на каждом из узлов кластера;

• поддержка со стороны узлов технологии IPMI (Intelligent Platform Management Interface), позволяющей контролировать «физическое здоровье» каждого узла;

Учётные данные для авторизации по IPMI должны быть указаны в настройках каждого узла в web-интерфейсе управления:

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

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

• Проверка по общему хранилищу: каждый агент раз в минуту пишет текущую временную метку в файл на общем хранилище, который используется контроллерами для определения последнего времени активности узла. По умолчанию дисковый хартбит выключен, включается в разделе РУСТЭК.Конфигуратора «Настройки высокой доступности виртуальных машин». Рекомендуется включать только при использовании отдельной сети для СХД или при подключении общего хранилища по протоколу Fibre Channel. При использовании протоколов NFS или iSCSI через основную сеть управления дисковый хартбит не имеет смысла, поскольку использует ту же самую сеть и перестаёт работать вместе с ней.

Конфигурация стенда

Сетевые интерфейсы

Хосты, операционные системы

Дисковые ресурсы

 

Реквизиты доступа и учётные данные

Поведение кластера виртуализации при различных отказах компонентов

Узел может быть в нескольких состояниях:

• ОК — в последнюю проверку узел был доступен по всем включенным хартбитам;

• PARTIAL FAILED — в последнюю проверку узел был недоступен по одному из хартбитов, применимо, только если настроен дисковый хартбит;

• FAILED — в последнюю проверку узел был недоступен по всем включенным хартбитам;

• EVACUATED — время недоступности хоста превысило таймаут, он был выключен и все ВМ были эвакуированы на другие вычислительные узлы.

Помимо состояния, на выполнение действий будет влиять опция «Эвакуировать частично недоступные узлы» в настройках высокой доступности в РУСТЭК.Конфигураторе.

Контроллеры определяют отказавший узел по последней метке времени его активности любым из доступных путей.

Агенты определяют собственную изоляцию по нескольким критериям:

1. Недоступность остальных узлов через сервис consul.

2. Отсутствие пинга до шлюза.

3. Недоступность общего хранилища, если включены дисковые хартбиты.

Таймаут изоляции до начала активных действий всегда на 30 секунд меньше, чем основной таймаут.

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

Если один из узлов признан отказавшим, VAHA эвакуирует виртуальные машины, опционально — выключает узел через IPMI.

Если узел, на котором выполняется агент, признан изолированным, VAHA выключает все ВМ, которые расположены на нём, и вызывает kernel panic, после чего контроллер эвакуирует виртуальные машины с отказавшего узла. Проверка изоляции выполняется только в том случае, если не включена опция «Использовать IPMI для выключения изолированных узлов».

Проведение испытаний

Установка базовой ОС и регистрация новых серверов в инфраструктуре

Установка и регистрация производилась, согласно предоставленной инструкции по первоначальной установке/настройке. При первой инсталляции возникали ошибки с подключением к СХД. После ручных правок initiatorname и перезапуском службы rc-service iscsid ошибки были устранены.

Команды необходимые для корректного запуска iscsi инициатора:

echo «InitiatorName=$(iscsi-iname)» > /etc/iscsi/initiatorname.iscsi

rc-service iscsid restart

Далее со стороны СХД требуется настроить доступ к targetname. Был сформирован acl (лист доступа с именами инициаторов подключения) для iqn.2016-04.com.open-iscsi:123456789001, iqn.2016-04.com.open-iscsi:123456789002, iqn.2016-04.com.open-iscsi:123456789003, 

которые мы указали в /etc/iscsi/initiatorname.iscsi — потому что так удобнее.

Выполняем подключение к СХД по iscsi (на всех узлах)

iscsiadm —mode discoverydb —type sendtargets —portal 192.168.151.10 —discover

При последующих инсталляциях ошибок или трудностей не возникло.

Создание новой ВМ из ISO-образа и создание образа для библиотеки. Работа с веб-консолью

Инсталляционный образ был загружен в раздел с образами. При создании/редактировании параметров виртуальных машин ошибок или трудностей не возникло.

Создание виртуальных машин из мастер-образа

Создаем ВМ на основе заранее созданной конфигурации ВМ и убираем галочку «Удалять диск вместе с виртуальной машиной». 

Производим установку ОС и удаляем ВМ без удаления диска. Диск преобразуем в мастер образ и на основе этого образа создаём уже продуктивные ВМ с предустановленной ОС.

Подготовка к нагрузочному тестированию

Было создано одновременно 24 виртуальные машины из мастер-образа с различными конфигурациями и предустановленными ОС. При создании ВМ проблем не возникло.

Управление ресурсами виртуальных машин

При смене конфигурации ВМ перезагружается. Жесткий диск можно расширять «на живую».

Миграция виртуальных машин

Миграция занимает 50 секунд, при этом даунтайма фактически нет — сетевое соединение не прерывается, но происходит отключение от консоли.

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

При анализе мной и инженерами разработчика ПО была выявлена следующая особенность: при установке базовой ОС на хосты гипервизора система генерировала идентичные UUID-ы для всех хостов, в следствие чего кластер не понимал, куда мигрирует ВМ.

UUIDы были переназначены вручную и исправлены в файле /etc/libvirt/libvirtd.conf

Я не придал значения указанным рекомендациям в документации по формированию установочных образов и получил следующую ошибку. Это ошибка создания Windows-машины из мастеробраза, которая возникает, если не проставить в свойствах параметры контроллеров. Поэтому внимательнее читаем документацию)

После исправления UUID_host при миграции ошибок или проблем не возникло.

Управление резервными копиями

Я создал план резервного копирования виртуальной машины. Проблем или ошибок не возникло.

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

Проверка отказоустойчивости серверной виртуализации

Условия для проверки: виртуальные машины запущены на трёх хостах гипервизора с достаточным запасом вмещения эвакуированных ВМ.

Выключил питание на хосте №3 — спустя 40 секунд кластер обнаружил «падение» хоста и начал миграцию ВМ. Через 2 минуты после отключения питания на хосте 2 ВМ с него были полностью функциональны на двух оставшихся хостах.

После восстановления работоспособности хоста №3 необходимо «разрешить» работу хоста в кластере. Переходим в раздел Конфигурация — физические узлы и в меню выбираем «разрешить».

Управление кластером доступно до тех пор, пока «жива» хотя бы одна нода.

Нагрузочные испытания

Собран кластер из трёх нод с СХД:

Создано 24 виртуальных машины с характеристиками: 40 ядер vCPU 10Gb RAM 60GbHDD. Виртуальные машины были распределены равномерно по всем трём нодам. На каждой из ВМ запущен стресс-тест с комплексной нагрузкой на процессор, оперативную память и дисковую подсистему:

stress-ng —cpu 40 —io 40 —vm 1 —vm-bytes 10G —timeout 10m —metrics-brief

Перед тестами провели утилизацию ресурсов. При прогоне стресс-теста провели 

утилизацию ЦП гипервизоров. В процессе прогона теста виртуальные машины зависли на какое-то время, но не «сломались», а по завершении теста отвисли и продолжили работать штатно. Проблем и зависаний в работе гипервизоров и кластера в целом не наблюдалось.

Тест с аварией при высокой загрузке виртуальных машин

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

Заключение

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

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

Анонсы вебинаров и обзоров мы публикуем в ТГ-канале Тринити.