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

Для начала поговорим о шаблонах виртуальных машин. Р-виртуализация поддерживает хранение шаблонов в двух локациях:

1. Шаблоны которые хранятся на сетевой папке т.н. “Template Library”;
2. Локальные для каждого узла;
   1. Локальные шаблоны, но хранящиеся в Р-Хранилище.

Веб-интерфейс предлагает именно два расположения - библиотека и каждый узел в отдельности.

При конвертировании виртуальной машины в локальный шаблон - он сохраняется на узле, на котором выполнялась виртуальная машина. Просмотреть шаблоны созданные на каждом узле можно в элементе интерфейса “%название узла% - Изменить - Шаблоны виртуальных машин”.

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

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

Но, к счастью в “руководстве администратора с коммандной строкой” описывается механизм переноса шаблона из локального хранилища на СХД “Р-хранилище”. После осуществления переноса шаблон по прежнему располагается на хосте, но теперь каждый сервер имеет к нему доступ.

Сеть в “Р-Виртуализации” настраивается на каждом вычислительному узле отдельно, как это было с “VMware Standard vSwitch”. Для этого необходимо выполнить как минимум следующие шаги:

1. Создать новую виртуальную сеть в разделе Управление - Виртуальные сети - Новая виртуальная сеть.
2. Создать vlan интерфейс, для этого перейти: %название узла% - Сеть - Сетевые адаптеры - Новый интерфейс VLAN.
3. При создании vlan поддерживается одновременная привязка к созданной виртуальной сети.
4. Если привязка не выполнена, она производится на вкладке хоста Сеть - Виртуальные сети.

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

Не удалось обновить информацию о виртуальной сети. Can not add device: prlsrvctl error: Failed to add Virtual Network demo_112: A virtual network named demo_112 already exists. Specify another name for this virtual network.

Для лечения этой неисправности необходимо подключиться к серверу по протоколу SSH и выполнить следующие комманды:

prlsrvctl net list - отобпражает список виртуальных сетей настроеных на сервере. В данном выводе видимо что виртуальные сети настроены не правильным образом.

[root@rvirt02 ~]# prlsrvctl net list
Network ID        Type      Bound To       Bridge         Slave interfaces
Bridged           bridged   eno1           br0
Host-Only         host-only                virbr0
demo_112          host-only                virbr1
demo_113          bridged                  br-eno50.113

Удаляем неверно настроенные сети для повторной настройки через веб-интерфейс, коммандой net del demo_112

[root@rvirt02 ~]# prlsrvctl net del demo_113
[root@rvirt02 ~]# prlsrvctl net del demo_112
[root@rvirt02 ~]# prlsrvctl net list
Network ID        Type      Bound To       Bridge         Slave interfaces
Bridged           bridged   eno1           br0
Host-Only         host-only                virbr0

Продолжаем настройку через веб интернфейс. Все проходит без ошибок теперь.

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

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

• Используются только стандартные серверы;
• Полная абстракция от аппаратного обеспечения;
• Виртуализация вычислительных мощностей;
• Виртуализация хранения (программно-определяемая СХД или SDS);
• Виртуализация сети (SD LAN? / vxlan);
• Единая консоль управления;
• и возможно что то еще.

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

Конвергентным данное решение тоже не поднимается рука назвать, так как этот термин еще более измученный и неоднозначный. Видимо такой путь “гиперконвергенции по-русски”.

Кто среди отечественных решений может посягнуть на звание гиперконвергентного решения?

• ECP Veil - очень хорошая виртуализация, но в плане хранения нам предлагают использовать GlusterFS со всеми вытекающими.
• HostVM, zVirt, ROSA - дети “овирта”. Всё тот-же GlusterFS, хотя ходят слухи о том что RedHat планирует в RHV а значит и в oVirt перейти на CEPH как основную СХД. Я уверен что наши отечественные сборщики пакетов немного отстают от самых современных западных тенденций и не поддерживают CEPH.
• Альт Виртуализация - упаковывает в свой дистрибутив Proxmox с поддержкой CEPH и Open Nebula …
• Брест - opennebula встала на путь принятия CEPH и наверное скоро мы сможем увидеть массовое принятие этой SDS в отечественных решениях.

Другими словами хоть Росплатформа подкачала в плане сети, она достаточно бодро смотрится среди решений на базе СПО за счёт отлаженной и отточенной SDS.

Но если заказчику ненужно гиперконвергентное решение, по крайней мере сейчас? У многих назрел вопрос импортозамещения виртуализации, но с сохранением ранее приобретенного оборудования. СХД пока никуда не пропали и всё еще продолжают свою работу.

После долгих рассказов про будущее гиперконвергенции в России вы можете узнать что СХД с песнями и плясками но поддерживаются и вендор против такого решения честно не возражает.

На текущий момент существует два подхода к подключению СХД к Р-Виртуализации:

1. Создание Raid-0 на каждом отделном диске СХД (по аналогии с RAID контроллерами без поддержки JBOD режима).
   1. На СХД, желательно на кжадом отдельном диске создается массив уровня RAID0.
   2. В массиве создается один логический том и презентуется серверу. Точное распределение томов между серверами уточняется на этапе внедрения.
   3. В операционной системе сервера на котором установлено Р-хранилище необходимо настроить MPIO.
   4. Полученные диски отображаются как внутренние на узлах Р-хранилища и даже через веб-интерфейс поддерживается создание массива.
   5. Рекомендуется на каждом сервере иметь соответсвующее колличество локальных SSD для кэширования.
2. Презентация дисков непосредственно для хранения на систему Р-виртуализация.
   1. Данный вариант требует наличия Р-хранилища для обеспечения работы кластерной службы, потому что именно спомощью Р-хранилища распределяется кластерная конфигурация между участниками кластера. Поэтому минимальное колличество дисков в каждый сервер установить необходимо.
   2. Презентованные диски на каждый сервер можно либо отдать в виртуальную машину целиком, либо разметить с использованием LVM и отдать в виртуальную машину логические тома LVM.
   3. Автоматизация создания виртуальных машин отдаётся на откуп заказчика.

— Mikhail Chusavitin 2022/09/05 17:19