Как-то понадобилось интегрировать Росплатформу (Р-Виртуализацию и Р-Хранилище) с аппаратным СХД( 3PAR), и это может очень пригодится в различных сценариях.
?

Конфигурация Synergy

Ранее такого рода интеграция тестировалась на лезвиях(Blade CH121 v5) блейд центра Huawei c СХД Dorado 5000 v3, где SDS(software-defined storage) Р-Хранилище Росплатформы поверх СХД показал себя довольно хорошо за счет all flash, но с Synergy, при наличии JBOD дисков с модуля D3940, все намного интереснее и гибче.

3 серверных лезвия (Synergy 480 Gen10 (871940-B21)):

• В каждом по два CPU Intel® Xeon® Platinum 8270.
• Сеть два порта по 20 Gb/s.
• RAM по 256GB.
• Жесткие диски в лезвиях отсутствуют.
• В дисковом модуле Synergy 2HDD по 900GB в RAID1 для каждого ОС/гипервизор и 3SSD HPE VK0960GFDKK 960GB для роли метаданные+кэш (каждый для одного сервера), а также 9HDD EG0900JFCKB по 900GB.

Загрузка ОС осуществлялась по каналу через RAID контроллер с дискового модуля Synergy.
Локальный SDS развернут по JBOD каналу с дискового модуля Synergy.

Конфигурация 3PAR

К Synergy подключена 3PAR(FC16 Gb/s):
Один LUN(один ко многим) RAID6 из SSD c объемом 200GB. 9 LUN RAID6 из HDD, каждый с объемом 150GB(по три LUN на лезвие).


Рис. 1 Схема тестового стенда.

Описание сценариев

Тестировались несколько вариантов интеграции с 3PAR, которые также можно одновременно использовать все сразу в смешанной конфигурации.

Сценарий с развертыванием SDS Росплатформы на отдельных LUN по 150GB от 3PAR:


Рис. 2 Сценарий с развертыванием SDS Росплатформы на отдельных LUN
с СХД для каждого узла из трех было презентовано по FC по 3 LUN объемом 150GB.

На СХД они были сконфигурированы в RAID6 из HDD дисков. На Рис. 2 показаны схематически 10Gb и switch, но реализация была на уровне коммутатора Synergy c портами по 20Gb, где один интерфейс для управления и виртуализации, а другой для SDS хранилища.

Данный сценарий тестировался для проверки возможности работы следующих вариантов:

• Работы SDS Росплатформы поверх 3PAR.
• Усиление SDS Росплатформы поверх 3PAR за счет добавления локальных SSD кэш.
• Созданием небольшого SDS Росплатформы для хранения конфигурационных файлов ВМ, где сами ВМ созданы на LUN 3PAR.
• Тестирование SDS Росплатформы поверх 3PAR с определением его под чуть медленный тир чем тир из локальных дисков.

2)Сценарий с созданием ВМ на LUN от 3PAR:


Рис. 3 Сценарий с созданием ВМ на LUN от 3PAR.

С СХД был презентован LUN 200GB RAID6 из SSD для ВМ. Конфигурация LUN-а один ко многим.
Данный сценарий тестировался для проверки возможностей:

• Прикрепление к ВМ LUN от 3PAR напрямую.
• Использование прикрепленного LUN для ВМ в качестве основного диска без использования qcow2.
• Использование несколько ВМ с прикрепленным одним и тем же LUN 200GB для последующей установки гостевой кластерной файловой системы.
• Миграция ВМ с LUN 200GB от 3PAR и аварийный отказ узлов с перезапуском этой ВМ на оставшихся узлах.
• Использование SDS от 3PAR в качестве хранения конфигурационных файлов ВМ, а гостевую ОС с развертыванием на LUN от 3PAR напрямую.
• Использование SDS на локальных дисках модуля Synergy в качестве хранения конфигурационных файлов ВМ, а гостевую ОС с развертыванием на LUN 200GB от 3PAR напрямую.

Описание настроек

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

1. включение службы multipath в автозагрузку:

#chkconfig multipathd on

2. включение загрузки модулей:

#modprobe dm-multipath
#modprobe dm-round-robin

3. копирование шаблона конфига в папку для рабочего конфига:

#cp /usr/share/doc/device-mapper-multipath-0.4.9/multipath.conf /etc/

4. проверка в шаблоне включения ниже следующих параметров:

defaults {
        user_friendly_names yes
        find_multipaths yes
}

5. добавление alias для расшареного диска для ВМ:

multipaths {
        multipath {
#               wwid                    3600508b4000156d700012000000b0000
#               alias                   yellow
#               path_grouping_policy    multibus
#               path_selector           "round-robin 0"
#               failback                manual
#               rr_weight               priorities
#               no_path_retry           5
#       }
        multipath {
                wwid                    360002ac0000000000000000f000049f4
                alias                   test3par
        }
}

6. проверка на запуск службы:

#systemctl start multipathd

7. Проверка работы службы и вывод устройств с mpath:

#multipath –ll

8. Обязательная перезагрузка:

#reboot

9. Проверка работы службы и вывод устройств с mpath:

#multipath –ll

Далее выполнялись стандартные настройки кластера.


Рис. 4 web UI до включения службы multipath.


Рис. 5 После включения службы multipath, появились устройства dm.

Скриншот после создания кластера Росплатформы, где 200GB LUN для ВМ специально с не назначенной ролью:


Рис. 6 Скриншот после создания кластера Росплатформы.

На скриншоте изображены два тир0 и тир1, где тир0 это локальный SDS, а тир1 SDS поверх 3PAR:


Рис. 7 Локальный SDS и поверх 3PAR.

Далее была создана ВМ без локального диска с прикрепленным вместо него LUN 200GB от 3PAR:

#prlctl set testVM --device-add hdd --device /dev/mapper/ test3par

ВМ создана со следующими параметрами:

• Тип – CentOS Linux
• vCPU – 4
• RAM – 8
• Гостевая ОС – Centos 7(1908)

Тесты миграции

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


Рис. 8 Результат и время миграции ВМ.

Test1 – обычная ВМ с такими же параметрами только с локальным образом диска QCOW2 64GB и Живая миграция ВМ test10 c LUN 200GB от 3PAR.

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


Рис. 9 Результаты Ping.

Во время живой миграции производился ping по адресу ВМ с LUN 200GB от 3PAR.

Зафиксировано пропадание только одного пакета, точно такое же происходит и с обычной ВМ на SDS, но ВМ остается доступной по сети и продолжает работать.

Тесты аварийного выключения

При выключении сервера по питанию на котором находилась ВМ с LUN 200GB от 3PAR, и после обнаружения службой HA пропавшего узла, тестируемая ВМ успешно перезапустилась на другом выбранном по дефолтному алгоритму drs,round robin узле, продолжив работать. За время ping было потеряно 7 пакетов. При переключении запускался только конфигурационный файл ВМ, а гостевая ОС была все время доступна по прикрепленному пути к LUN.

Тестировалось также создание резервной копии, где успешно резервировался конфигурационный файл ВМ и при восстановлении с этой копии ВМ, она успешно запускалась.



Тесты последовательной записи в ВМ с LUN 200GB от 3PAR, которые показали производительность этого LUN от 3PAR, где Росплатформа не являлась промежуточным слоем, а тест показывает работу гостевой ОС и СХД 3PAR.

Используемые параметры fio внутри ВМ с LUN 200GB от 3PAR:

[seqwrite]
rw=write
size=4g
numjobs=4
bs=1m
ioengine=libaio
iodepth=32
time_based
#runtime=60
direct=1
filename_format=__testfile'$jobnum'
thread
directory=/sdb/

Тесты с кластерной файловой системой внутри гостевой ОС

Рис. 10 Кластерная файловая система внутри гостевой ОС.

Успешно протестирован сценарий с прокинутым одним LUN 200GB к двум ВМ, на котором внутри ВМ средствами гостевой ОС установлена кластерная файловая система GFS2. При тесте выключали одну из ВМ или хост после чего другая ВМ продолжала работать с этим LUN и писать/читать оттуда файлы. Ниже скриншот с настройками GFS2 внутри ВМ, показанны так же выводы команд pacemaker-а:



Далее SDS Росплатформы поверх LUN:


Рис. 11 Конфигурация с SDS Росплатформы развернутой на LUN от 3PAR.

Был успешно протестирован тот же сценарий с прокинутым одним LUN 200GB к двум ВМ, на котором внутри ВМ средствами гостевой ОС была установлена кластерная файловая система, но в качестве размещения ВМ использовался datastore от SDS Росплатформы созданный на LUN от 3PAR. При тесте выключали одну из ВМ или хост после чего другая ВМ продолжала работать с этим LUN и писать/читать оттуда файлы.


Рис. 12 Тест с добавлением SSD под роль кэш с дискового модуля Synergy.

Был успешно протестирован тот же сценарий с прокинутым одним LUN 200GB к двум ВМ, на котором внутри ВМ средствами гостевой ОС была установлена кластерная файловая система, но в качестве размещения ВМ использовался datastore от SDS Росплатформы созданный на LUN от 3PAR. Плюс этот datastore был усилен по производительности за счет добавления SSD под роль кэш с дискового модуля Synergy. При тесте выключали одну из ВМ или хост после чего другая ВМ продолжала работать с этим LUN и писать/читать оттуда файлы.

Тесты кластерной файловой системой на узлах Росплатформы

Рис. 13 Тест с конфигурационными файлами ВМ расположенными на SDS Росплатформы, от 3PAR презентован LUN 200GB.

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


Рис. 14 SDS поднят на LUN от 3PAR.

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


Рис. 15 SDS tier0 на LUN от 3PAR, SDS tier1 на дисках от модуля Synergy.

Протестирован сценарий с общим хранилищем от 3PAR для образов дисков ВМ на кластерной файловой системе, которая была установлена на узлах Росплатформы, а конфигурационные файлы этих ВМ располагались на SDS Росплатформы, где SDS tier0 был поднят на LUN от 3PAR и второй SDS tier1 на дисках от модуля Synergy. При тесте выключали один из хостов после чего ВМ должны были работать со своими образами дисков за счет работы двух других хостов согласно реплики 3 на SDS кластере под конфигурационные файлы ВМ и 3 журналам кластерной файловой системы под образы дисков ВМ. Но возникли проблемы работы kvm-qemu с GFS2, после длительного исследования был обнаружен отказ работы менеджера блокировки от GFS2 и Росплатформа из-за этого не может запустить ВМ на другом хосте кластера. Вопрос остается открытым. То же самое с вариантами на рисунке 13 и 14. Возможна проблема этого сценария заключается в особенностях работы kvm-qemu с образом qcow2 и raw, где операции записи происходят синхронно, а менеджер блокировки от GFS2 ограничен для таких операций.

Заключение

Варианты с SDS на LUN от 3PAR и презентация LUN от 3PAR вполне рабочие и могут быт использованы для работы в инфраструктуре, но имеют конечно некоторые минусы.

Например, в случае с SDS на лунах производительность будет всегда чуть ниже, чем SDS на локальных дисках, можно это улучшить за счет локальных SSD с ролью кэш, но обычный SDS всегда будет преимущественно быстрее. Как вариант SDS на СХД можно конфигурировать в отдельный тир. Еще один не маловажный минус, это отказоустойчивость, на SDS каждый узел является контроллером, где как минимум кластер начинается с трех узлов то, в случае с СХД там всегда два контроллера на стойку. Для SDS это единая точка отказа, но несмотря на эти минусы такие сценарии имеют место быть при постепенном переходе с внешнего СХД на SDS или при утилизации существующего СХД. Плюс есть возможности самой СХД, такие как дедупликация, компрессия, которых из-за особенностей архитектурного подхода нет на SDS Росплатформы, но есть у 3PAR и благодаря выше описанным сценариям их можно задействовать на уровне СХД.

Так же актуальны сценарии с презентацией LUN для ВМ, для гостевых систем со своей кластерной системой. В случае с презентацией LUN к каждой ВМ в отдельности, появляются такие минусы как отсутствие автоматизации при жизненном цикле большого количества ВМ, которая могла бы быть за счет кластерной файловой системы на узлах Росплатформы, но GFS2 c kvm-qemu в этом случае подвела, Если ее использовать под любые другие файлы, то все работает даже в аварийных тестах на Росплатформе, но как только туда положить образы ВМ то, в аварийных тестах менеджер блокировок GFS2 не справляется. Возможно эта проблема будет решена.

Выше описанные сценарии использования multipath могут быть полезны для подключения ленточных библиотек. В Росплатформе имеется встроенная система резервного копирования (СРК), которая может писать копии в папку кластера Р-хранилища или локальную папку, но не умеет работать с ленточными устройствами пока вы сами не напишите скрипт или для этих целей можно использовать внешние СРК например rubackup, которая по мимо работы с лентой, поможет делать копии ВМ с прикрепленными LUN, что актуально при интеграции с СХД.