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

4cfd138ff3bf69d66409c0f6db3ecb71.jpeg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оборудование

Кол-во

Платформа Тринити ER215HR-M6, 1U, 2LGA3647, 24DDR4 reg, 82.5», 41G, M.2, 21200Вт

1

Intel Xeon Silver 4210R, 10 cores 2.4GHz (13,75MB L3, DDR4–2400/1TB, HT, 100W, FCLGA3647)

2

SNK-P0067PS, 1U Passive, Platform, Narrow

2

32GB Samsung DDR4 RDIMM (PC4–25600) 3200MHz ECC Reg 1.2V (M393A4K40EB3-CWE)

4

Сетевая карта Intel X520-DA2 E10G42BTDA Ethernet Server Adapter, 2×10Gb SFP+

1

SSD 240GB Micron 5300 Boot SSD, M.2, SATA 6 Gb/s, 50K/12K iops r/w [MTFDDAV240TDU-1AW1ZABYY]

1

SSD Samsung Enterprise SSD SATA2.5» 960GB PM893 TLC MZ7L3960HCJR-00A07 SAMSUNG

2

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

Оборудование

Кол-во

Платформа Тринити ER220HR0-M6, 2U, 2LGA3647, 16DDR4 reg, 43.5» (2NVMe), 22.5», 41G, M.2, 2800W

1

Intel Xeon Silver 4210R, 10 cores 2.4GHz (13,75MB L3, DDR4–2400/1TB, HT, 100W, FCLGA3647)

2

AS2UN-R83 LGA 3647, TDP 205W, 2U active Narrow

2

32GB Samsung DDR4 RDIMM (PC4–25600) 3200MHz ECC Reg 1.2V (M393A4K40EB3-CWE)

4

Сетевая карта Intel X520-DA2 E10G42BTDA Ethernet Server Adapter, 2×10Gb SFP+

1

SSD 240GB Micron 5300 Boot SSD, M.2, SATA 6 Gb/s, 50K/12K iops r/w [MTFDDAV240TDU-1AW1ZABYY]

1

SSD Samsung Enterprise SSD SATA2.5» 960GB PM893 TLC MZ7L3960HCJR-00A07 SAMSUNG

2

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

Оборудование

Кол-во

Платформа Тринити ER220DHR-M6, 2U, 2LGA3647, 24DDR4 reg, 123.5», 22.5», 21G, M.2, 21200W

1

Intel Xeon Silver 4210R, 10 cores 2.4GHz (13,75MB L3, DDR4–2400/1TB, HT, 100W, FCLGA3647)

2

AS2UN-R83 LGA 3647, TDP 205W, 2U active Narrow

2

32GB Samsung DDR4 RDIMM (PC4–25600) 3200MHz ECC Reg 1.2V (M393A4K40EB3-CWE)

4

Сетевая карта Intel X520-DA2 E10G42BTDA Ethernet Server Adapter, 2×10Gb SFP+

1

SSD 240GB Micron 5300 Boot SSD, M.2, SATA 6 Gb/s, 50K/12K iops r/w [MTFDDAV240TDU-1AW1ZABYY]

1

SSD Samsung Enterprise SSD SATA2.5» 960GB PM893 TLC MZ7L3960HCJR-00A07 SAMSUNG

2

Райзер 2U PCIe x16×16x8, электрически х8×8х8

2

Кабель HDmSAS-HDmSAS

1

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

Оборудование

Кол-во

IBM Storwize V7000 общее количество дисков SAS НDD 300 Gb — 24 шт.

1

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

Оборудование

Кол-во

Тип, назначение

Производитель, модель

Коммутатор LAN (Ethernet)

HP ProCurve 1810G-24GE

1

Коммутатор SAN (FC)

IBM SAN-24B

1

Коммутатор LAN (Ethernet)

TL-SX3016F

1

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

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

8a8e1151c3777abc7b426be8ce904a41.png

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

f8df21dbffb1af8863735c10f033d3d1.png

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

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

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

  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.

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

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

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

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

web-интерфейс управления ПАК СВ РУСТЭК

web-интерфейс управления ПАК СВ РУСТЭК

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

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

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

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

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

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

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

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

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

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

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

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

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

Настройка доступа к IPMI узла виртуализации

Настройка доступа к IPMI узла виртуализации

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

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

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

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

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

Cервер/СХД

NIC/HBA

IP/mask (WWN)

Назначение

ER215HR-M6

Арбитр

IMM

192.168.242.11/24

Ethernet-порт управляющей подсети передачи данных

Bond0

192.192.192.11/24

Агрегат 4×1Gb сетевых портов для продуктивной подсети передачи данных

Bond1

192.168.151.11/24

Агрегат 2×10Gb сетевых портов для сети хранения данных

М2335149

Основной узел

IMM

192.168.242.12/24

Ethernet-порт управляющей подсети передачи данных

Bond0

192.192.192.12/24

Агрегат 4×1Gb  сетевых портов для продуктивной подсети передачи данных

Bond1

192.168.151.12/24

Агрегат 2×10Gb сетевых портов для сети хранения данных

ER220HDR-M6

Дополни-

тельный узел

IMM

192.168.242.13/24

Ethernet-порт управляющей подсети

Bond0

192.192.192.13/24

Агрегат 4×1Gb  сетевых портов для продуктивной подсети передачи данных

Bond1

192.168.151.13/24

Агрегат 2×10Gb сетевых портов для сети хранения данных

IBM Storwize V7000 (хранилище данных)

Eth1 (контроллер 1)

192.192.192.20/24

Ethernet-порт управляющей подсети передачи данных

ISCSI target

192.168.151.10/24

Ethernet-порт для сети хранения данных

ISCSI target

192.168.151.9/24

Ethernet-порт для сети хранения данных

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

Сервер

host

ОС

IP адрес

Описание/ Сервисы

ER215HR-M6 Арбитр

N1

rustackos

192.192.192.11

Арбитр

М2335149 Основной узел

N2

rustackos

192.192.192.12

Основной узел

ER220HDR-M6 Дополнительный узел

N3

rustackos

192.192.192.13

Дополнительный узел

ВМ для управления кластером

rustackos

192.192.168.25

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

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

Система хранения

Ресурс / volume

Объем

Физический сервер

Хост назначения

Примечание

Storwize v7000

iscsi-

target

2000ГБ

ER215HR-M6

Арбитр

Презентованные дисковые ресурсы выделены из пула, состоящего из RAID1 собран из шести SAS-дисков.

М2335149

Основной узел

ER220HDR-M6

Дополнительный узел

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

Сервер

Хост (Нода/

ВМ)

IP-адрес/URL доступа

Логин

Пароль

Примечание

ER215HR-M6

n1.rustack.demo

192.192.192.11

root

P@ssw0rd

ssh

М2335149

n1.rustack.demo

192.192.192.12

root

P@ssw0rd

ssh

ER220HDR-M6

n1.rustack.demo

192.192.192.13

root

P@ssw0d

ssh

Storwize v7000

testing_storage

https://192.168.240.101/login

superuser

passw0rd

web-браузер

ВМ для управления кластером

192.192.192.25

admin

LfwsvIsE

web-браузер

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

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

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

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

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

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

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

Статус узлов HA-кластера ПАК СВ «Рустэк»

Статус узлов HA-кластера ПАК СВ «Рустэк»

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

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

  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

ff246a8b543ec0d54c739cbd0e76120e.png

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

9484def245118a4ea18a97a460e3f4e0.png560ba23b864fdf72cde642324ce0db23.png

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

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

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

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

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

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

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

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

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

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

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

cb638488aa89e2055313fdb7d86af03b.png

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

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

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

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

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

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

Инициированная авария

Инициированная авария

Заключение

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

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

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

© Habrahabr.ru