Использование сервера с FC HBA QLogic на базе Debian GNU/Linux 9.3 и SCST в качестве СХД для томов CSV в кластере высоко-доступных виртуальных машин Hyper-V

Имеем удалённую площадку с одним хостом виртуализации на базе гипервизора Hyper-V (Windows Server 2012 R2) и пачкой виртуальных машин, запущенных на этом хосте. Всё работает, но есть желание хоть как-то повысить доступность виртуальных машин, так как в периоды обслуживания хоста возникает необходимость выключения всех ВМ, что в некоторых ситуациях приводит к нежелательным последствиям. Логичным решением здесь выступает построение, как минимум, двух-узлового кластера высоко-доступных виртуальных машин Hyper-V на базе Windows Failover Cluster. В таком кластере виртуальные машины должны размещаться на общем дисковом томе Cluster Shared Volumes (CSV), который должен быть доступен обоим хостам виртуализации. То есть, предполагается, что для построения кластера нам потребуется какое-то внешнее дисковое хранилище (СХД), к которому могут быть подключены хосты виртуализации.

Однако в нашем случае СХД на удалённой площадке нет, но есть свободные серверы. В этой заметке мы рассмотрим пример того, как с помощью Debian GNU/Linux 9.3 и свободно-распространяемого ПО Generic SCSI Target Subsystem for Linux (SCST) из обычного сервера сделать СХД. В результате у нас появится возможность создать двух-узловой кластер высоко-доступных виртуальных машин Hyper-V с подключением к третьему серверу, который будет использоваться в качестве СХД для организации общего тома CSV.

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

Для построения выше обозначенной конфигурации нами будут использоваться три сервера линейки HP ProLiant DL380 старого поколения Gen5. В серверы, помимо их базовой комплектации, дополнительно установлены старые оптические контролеры FC HBA 4G (сейчас такие можно купить "по рублю за чемодан"). Кстати, организовать точку подключения к СХД (Target) в ПО SCST можно и на базе более дешёвых сетевых адаптеров GigEthernet (iSCSI Target), но в данной заметке мы будем строить конфигурацию именно Fibre Channel Target на базе оптического адаптера FC HBA фирмы QLogic и SCST будет настраиваться соответствующим образом.

1) Сервер под роль СХД (KOM-AD01-FS03)

В сервер установлен двух-портовый адаптер FC 4Gb HP QLogic QLE2462 Dual-Port PCI-Express HBA (407621-001 FC1242SR AE312-60001) (каждый порт используется для подключения к одному из хостов виртуализации). Адресация FC-портов World Wide Port Name (WWPN):
- HBA Port0 WWPN: 50:01:43:80:02:00:c2:04
- HBA Port1 WWPN: 50:01:43:80:02:00:c2:06

В дисковую корзину сервера установлено 8 дисков:
- 2 диска SAS SFF 72GB 15K в RAID1 - под ОС Debian GNU/Linux 9.3 и ПО SCST
- 6 дисков SAS SFF 146GB 15K в RAID1+0 - под кластерные диски, которые будут презентованы хостам виртуализации

2) Хост виртуализации 1 (KOM-AD01-VM01)

В сервер установлен одно-портовый адаптер FC 4Gb HP FC2142SR (A8002A) Single-Port PCI-Express HBA (Emulex LPE1150 FC1120005-04C). Адрес HBA Port0 WWPN: 10:00:00:00:c9:6f:2c:e4

В дисковой корзине 2 диска SAS SFF 72GB 15K в RAID1 - под ОС Windows Server 2012 R2

3) Хост виртуализации 2 (KOM-AD01-VM02)

В сервер установлен двух-портовый адаптер FC 4Gb HP FC2242SR (A8003A) Dual-Port PCI-Express HBA (Emulex LPE11002 FC1110406-01 Rev.C). Для подключения к серверу KOM-AD01-FS03 используется только один порт. Адрес HBA Port0 WWPN: 10:00:00:00:c9:78:25:16

В дисковой корзине 2 диска SAS SFF 72GB 15K в RAID1 - под ОС Windows Server 2012 R2

Схема подключения оптических адаптеров в нашем примере весьма проста и представляет собой прямое подключение по типу Host-to-Host оптическими патч-кордами multimode 50/125 с коннекторами LC-LC:

В данной заметке мы не будем уделять внимания процедуре построения кластера Hyper-V, как таковой, а сделаем упор на описании процесса настройки FC Target на базе SCST и продемонстрируем дальнейшую возможность использования созданного нами дискового массива в качестве общего тома в кластере Windows Failover Cluster.

 

Подготовка сервера под роль СХД

Конфигурация выделенного сервера под роль СХД подразумевает ряд действий, которые нам нужно будет последовательно выполнить в дальнейшем. Готовя старый сервер под любую новую задачу, всегда стоит начать с базовой проверки состояния оборудования и обновления всех доступных на данный момент времени прошивок firmware, например, как это было описано ранее в начале заметки Установка CentOS Linux 7.2 на сервер HP ProLiant DL360 G5 с поддержкой драйвера контроллера HP Smart Array P400i.

Если говорить о базовой установке современной версии ОС Debian Linux на аппаратную платформу HP ProLiant DL380 Gen5, то ранее уже было опубликован ряд соответствующих заметок:

• Особенность установки Debian Linux Stretch с подключением firmware из non-free репозиториев (на примере bnx2)
• Установка HPE System Management Tools на сервер с ОС Debian Linux Stretch, а также HP Array Configuration Utility (ACU) для управления устаревшими контроллерами HP Smart Array

Таким образом мы предполагаем, что на сервер KOM-AD01-FS03 уже установлена ОС Debian GNU/Linux 9.3 и утилиты управления HP.

 

Получаем Firmware для FC HBA QLogic

По умолчанию в Debian нет поддержки firmware QLogic, так как этот тип ПО относится к категории non-free, поэтому установленный в сервер оптический адаптер FC HBA QLogic, который требуется нам для дальнейшей организации FC Target, просто так не заработает. В процессе загрузки системы драйвер, обеспечивающий работу HBA QLogic (модуль ядра qla2xxx), выдаст нам сообщение о невозможности загрузки микрокода HBA "Direct firmware load for ql2400_fw.bin failed with error -2":

В целом картина по обнаружению и загрузке устройств qla2xxx в нашем случае выглядит так:

# dmesg -t | grep -i qla

qla2xxx ... QLogic Fibre Channel HBA Driver: 8.07.00.38-k.
qla2xxx ... Found an ISP2432 irq 16 iobase 0xffffb94586265000.
qla2xxx ... MSI-X: Unsupported ISP 2432 SSVID/SSDID (0x103C,0x7041).
qla2xxx ... firmware: failed to load ql2400_fw.bin (-2)
qla2xxx ... Firmware images can be retrieved from: http://ldriver.qlogic.com/firmware/.
scsi host0: qla2xxx
qla2xxx ... QLogic HPAE312A - PCI-Express Dual Port 4Gb Fibre Channel HBA.
qla2xxx ... ISP2432: PCIe (2.5GT/s x4) @ 0000:0b:00.0 hdma+ host#=0 fw=5.03.15 (482).
qla2xxx ... Found an ISP2432 irq 17 iobase 0xffffb94586275000.
qla2xxx ... MSI-X: Unsupported ISP 2432 SSVID/SSDID (0x103C,0x7041).
qla2xxx ... firmware: failed to load ql2400_fw.bin (-2)
qla2xxx ... Direct firmware load for ql2400_fw.bin failed with error -2
qla2xxx ... Firmware images can be retrieved from: http://ldriver.qlogic.com/firmware/.
scsi host5: qla2xxx
qla2xxx ... QLogic HPAE312A - PCI-Express Dual Port 4Gb Fibre Channel HBA.
qla2xxx ... ISP2432: PCIe (2.5GT/s x4) @ 0000:0b:00.1 hdma+ host#=5 fw=5.03.15 (482).
qla2xxx ... Cable is unplugged...
qla2xxx ... Cable is unplugged...

Для работы с контроллером HBA QLogic встроенный в Linux драйвер qla2xxx будет пытаться использовать микрокод из каталога /lib/firmware. Поэтому нам нужно обеспечить наличие в этом каталоге совместимой с драйвером версии firmware.

Получить микрокод firmware можно из двух разных мест:

• c сайта QLogic http://ldriver.qlogic.com/firmware/, скачав соответствующие bin-файлы (в нашем случае, как минимум, требуется файл ql2400_fw.bin) и разместив эти файлы в каталоге /lib/firmware/
• из репозиториев Debian, подключив репозитории non-free и установив пакет qlogic-firmware.

Можно обнаружить то, что микрокод ql2400_fw.bin, доступный на сайте QLogic, судя по описанию CURRENT_VERSIONS имеет версию 7.03.00, в то время, как версия в репозиториях Debian Stretch, судя по описанию к пакету firmware-qlogic, - 8.03.00. Тут может возникнуть соблазн использовать более новую версию прошивки из репозиториев Debian. Однако, нужно учитывать то, что между используемым нами микрокодом HBA и драйвером должна быть обеспечена полная совместимость.

Здесь стоит отдельно остановится на том, почему мы будем использовать описанную далее конфигурацию, в которой вместо поставляемого в составе Debian драйвера qla2xxx будет использоваться предлагаемый разработчиками SCST драйвер qla2x00t. Ведь, казалось бы, использование микрокода, устанавливаемого из пакетов и драйвер, поставляемый в составе Linux, несколько упрощают процедура настройки. Однако, здесь есть несколько "НО".

Во первых такая конфигурация не будет считаться правильной с точки зрения разработчиков SCST, так как свое ПО они разрабатывают именно под свою версию драйвера qla2x00t. Драйвер qla2x00t, который, как я понял, является "форкнутым" несколько лет назад и отлаженным разработчиками SCST драйвером qla2xxx. В ходе изучения этого вопроса, где-то в мейл-листе SCST мне даже попадалась на глаза дискуссия на эту тему, но к сожалению не сохранил ссылку.

Во вторых, использование драйвера qla2x00t, предполагает использование совместимой с ним версии микрокода QLogic. Мои эксперименты показали то, что текущая версия драйвера qla2x00t не приводит к адекватной работе FC Target при условии использования микрокода, поставляемого в пакете firmware-qlogic из репозиториев Debian. Именно поэтому нужно использовать тот микрокод, который доступен на сайте QLogic.

Таким образом, в нашей конфигурации для обеспечения работы FC HBA QLogic под задачу FC Target будет использоваться микрокод с сайта QLogic и драйвер от SCST (qla2x00t).

Скачаем микрокод в каталог /lib/firmware и вызовем процедуру переcборки загружаемого образа initial ramdisk (initrd):

# cd /lib/firmware
# wget http://ldriver.qlogic.com/firmware/ql2500_fw.bin
# wget http://ldriver.qlogic.com/firmware/ql2400_fw.bin
# wget http://ldriver.qlogic.com/firmware/ql2322_fw.bin
# wget http://ldriver.qlogic.com/firmware/ql2300_fw.bin
# wget http://ldriver.qlogic.com/firmware/ql2200_fw.bin
# wget http://ldriver.qlogic.com/firmware/ql2100_fw.bin
# update-initramfs -u
# reboot

После этого выполним перезагрузку сервера и после загрузки системы снова посмотрим в лог загрузки через утилиту dmesg и убедимся в том, что микрокод HBA успешно загружен в процессе запуска системы

Далее перейдём к отключению встроенного в Linux драйвера qla2xxx.

 

Отключаем стандартный драйвер qla2xxx

Отключаем стандартный модуль ядра Linux с драйвером qla2xxx, исключаем этот модуль из загрузочного образа initrd и отправляем сервер в перезагрузку:

# rmmod qla2xxx
# echo blacklist qla2xxx >/etc/modprobe.d/blacklist-qla2xxx.conf
# update-initramfs -u
# reboot

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

# lsmod | grep qla
# dmesg | grep qla

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

 

Получаем исходные коды ядра Linux и SCST

Устанавливаем пакеты, необходимые для сборки и исходные коды используемой у нас версии ядра Linux:

# apt-get install -y linux-headers-$(uname -r) fakeroot kernel-wedge build-essential makedumpfile libncurses5 libncurses5-dev lsscsi patch subversion bc devscripts

Выходим в непривилегированное окружение стандартного пользователя Linux, где будем заниматься правкой и сборкой исходных кодов. Создаём в домашнем каталоге текущего пользователя подкаталог, в котором будем работать с исходниками, например ~/Build, переходим в него и выполняем загрузку исходного кода используемого у нас ядра Linux:

$ mkdir ~/Build
$ cd ~/Build
$ apt-get source linux-source-4.9

Сюда же, в каталог ~/Build выполняем загрузку исходных кодов актуальной версии SCST:

$ cd ~/Build
$ svn co https://svn.code.sf.net/p/scst/svn/trunk scst

Кстати, в моём случае svn не захотел использовать переменные окружения текущего пользователя, описывающие параметры прокси в файле ~/.profile, поэтому на время пришлось открыть машине прямой доступ в интернет.

Посмотрим, что в конечном итоге получилось в нашем сборочном каталоге:

 

Накладываем патчи SCST на исходные коды ядра Linux

Давайте заглянем в исходные коды SCST и посмотрим то, какие патчи там имеются для ядра Linux используемой у нас 4-ой версии:

$ find ~/Build/scst -name *4.*.patch

Как видим, для нашей версии ядра Linux 4.9 имеется патч nolockdep-4.9.patch, который мы и будем накладывать на исходные коды ядра Linux.

Переходим в каталог с файлами исходных кодов ядра Linux и накладываем патч:

$ cd ~/Build/linux-4.9.82/
$ patch -p1 < ~/Build/scst/scst/kernel/nolockdep-4.9.patch

 

 

Меняем в исходных кодах ядра драйвер qla2xxx на драйвер от SCST - qla2x00t

Заменяем драйвер в исходниках ядра Linux на тот, что в предлагается в исходниках SCST. Для этого сначала переименуем каталог с оригинальными исходниками драйвера, поставляемыми вместе с исходниками ядра Linux. Затем слинкуем каталог с исходниками драйвера из поставки SCST на имя каталога, которое ранее использовалось исходниками оригинального драйвера

$ mv ~/Build/linux-4.9.82/drivers/scsi/qla2xxx ~/Build/linux-4.9.82/drivers/scsi/qla2xxx_orig
$ ln -s ~/Build/scst/qla2x00t ~/Build/linux-4.9.82/drivers/scsi/qla2xxx

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

$ ls -la ~/Build/linux-4.9.82/drivers/scsi/ | grep qla2xxx

 

 

Выполняем конфигурацию ядра Linux

Если по какой-то причине Вы собираете 32-битное ядро, то обратите внимание на рекомендации, данные в пункте 11 статьи How to Configure the FC QLogic Target Driver for 22xx/23xx/24xx/25xx/26xx Adapters.

В каталоге с пропатченными исходными кодами ядра запускаем режим конфигурирования параметров ядра

$ cd ~/Build/linux-4.9.82/
$ make menuconfig

Конфигурация пары описанных далее параметров подсмотрена в статье Linux Fibre Channel SCSI Target using SCST. На самом деле она не является обязательной, но предлагается в качестве дополнительного тюнинга для предположительного улучшения показателей производительности работы Linux с блочными устройствами.

В открывшемся интерактивном режиме настройки параметров ядра перейдём в пункт "Enable the block layer"

В списке опций выберем "IO Schedulers" и удостоверимся в том, что в качестве планировщика по умолчанию "Default I/O Scheduler" выбран вариант "CFQ":

Подробнее про разные типы планировщиков, в том числе и про CFQ, на русском языке можно прочитать, например здесь. А в заметке Linux I/O Scheduler. Выбираем оптимальный можно найти нехитрый скрипт, для проведения экспериментов по самостоятельному выявлению оптимального планировщика.

Далее переходим в пункт "Processor type and features" и выбираем опцию "Preemption Model". Переключаем опцию в значение "No Forced Preemption (Server)":

^{Для понимания сути этой опции приведу цитату:}

No Forced Preemption (Server)  - Это традиционная для Linux модель с приоритетным прерыванием обслуживания (preemption model), она обеспечивает хорошее время отклика (latency), но не дает никаких гарантий, и при её применении возможны случайные длительные задержки. Выбирайте эту опцию, если Вы собираете ядро для сервера или для научных/вычислительных систем, или если Вы хотите увеличить «сырую» вычислительную мощность ядра.

 

Далее с верхнего уровня переходим последовательно в пункты "Device Drivers" > "SCSI device support" > "SCSI low level drivers" и убеждаемся в том, что для драйвера QLA2XXX присутствует и включена built-in опция "QLogic 2xxx target mode support"

 

Затем переходим в раздел настроек "General setup" и выбираем пункт "Local version – append to kernel release", чтобы добавить в имя ядра строку, идентифицирующую наше кастомизированное ядро:

Введём понятный нам постфикс, который будет добавлен к имени ядра при сборке, например "-scst-enabled"

При выходе из интерактивного режима конфигурирования ядра ответим утвердительно на вопрос о сохранении:

 

Собираем и устанавливаем ядро Linux

Находясь в текущем каталоге (напоминаю, что мы работаем в каталоге с пропатченными исходными кодами ядра, параметры которого только что были настроены) запускаем процесс компиляции ядра и сборки deb-пакетов:

$ cd ~/Build/linux-4.9.82/
$ make deb-pkg clean

Процесс может занять длительное время, в зависимости от проворности процессора. По окончании процесса мы получим несколько deb-пакетов в каталоге верхнего уровня, относительно каталога компиляции:

Устанавливаем пакеты нашего кастомизированного ядра Linux:

$ cd ~/Build
$ sudo dpkg -i linux-image-4.9.82-scst-enabled_4.9.82-scst-enabled-1_amd64.deb
$ sudo dpkg -i linux-headers-4.9.82-scst-enabled_4.9.82-scst-enabled-1_amd64.deb

В ходе установки автоматически будет обновлён загрузочный образ initrd

После этого выполняем перезагрузку сервера. В процессе загрузки системы, если заглянем в текущий список ядер в загрузчике GRUB, то увидим, что по умолчанию для загрузки системы используется наше кастомизированное ядро

Для того, чтобы собранное нами кастомизированное ядро Linux не обновилось в дальнейшем в процессе обновления всех пакетов системы (не было заменено в загрузчике новой версией ядра из пакета linux-image-amd64), настроим исключение для менеджера пакетов apt.

# dpkg --get-selections | grep -E "linux-(image|headers)"
# apt-mark hold linux-image-amd64

Теперь давайте попробуем выполнить обновление кеша менеджера пакетов и убедимся в том, что не смотря на то, что новая версия пакета linux-image-amd64 в репозиториях присутствует, при установке обновлений данный пакет не устанавливается, так как ранее мы его пометили в hold:

# apt-get update
# apt list --upgradable
# apt-get upgrade

С ядром закончили, переходим к сборке SCST.

 

Компилируем и устанавливаем SCST

Переходим в каталог с исходными кодами SCST, компилируем и устанавливаем SCST:

$ cd ~/Build/scst/
$ make 2release
$ sudo BUILD_2X_MODULE=y CONFIG_SCSI_QLA_FC=y CONFIG_SCSI_QLA2XXX_TARGET=y make all install

После окончания компиляции и установки убедимся в том, что нужные нам для работы модули ядра присутствуют в системе:

$ ls -l /lib/modules/`uname -r`/extra/
$ ls -l /lib/modules/`uname -r`/extra/dev_handlers

Убедимся в том, что для нужных нам модулей ядра, при попытке их загрузки не возникает никаких ошибок:

$ sudo modprobe scst
$ sudo modprobe qla2x00tgt
$ sudo modprobe qla2xxx_scst
$ sudo modprobe scst_vdisk
$ sudo modprobe scst_user
$ sudo modprobe scst_disk

Если при попытке загрузки модулей возникает ошибка типа "modprobe: FATAL: Module qla2x00tgt not found in directory /lib/modules/4.9.82-scst-enabled", но соответствующий ko-файл при этом в каталоге присутствует, попробуйте выполнить обновление зависимостей модулей командой:

$ sudo depmod --all

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

$ cat /etc/modules

# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
#
scst
qla2xxx_scst
qla2x00tgt
scst_vdisk
scst_user
scst_disk

Перезагрузим систему, чтобы убедиться в том, что в процессе загрузки модули SCST загружаются успешно. Проверим это в выводе команды dmesg

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

 

Компилируем и устанавливаем SCSTAdmin

Снова входим в режим непривелегированного пользователя, переходим в наш каталог с исходными файлами scst в подкаталог ../scstadmin и даём последовательно команды компиляции и установки:

$ cd ~/Build/scst/scstadmin/
$ make
$ sudo make install

Последуем совету, который будет выдан нам в процессе установки, и включим автоматическую загрузку службы scst.service при старте системы:

$ sudo systemctl enable scst.service

Теперь давайте спросим у scstadmin, какие типы HANDLER и TARGET_DRIVER нам доступны для настройки нашей конфигурации:

# scstadmin -list_handler
# scstadmin -list_driver

Как видим, в списке поддерживаемых scstadmin драйверов есть интересующий нас драйвер qla2x00t.

Посмотрим информацию о доступных TARGET, которыми мы можем оперировать в конфигурации:

# scstadmin -list_target

Теперь можно переходить к настройке конфигурации SCST, но перед этим нужно определиться с дисковыми ресурсами, которые мы будем транслировать с нашего Linux-сервера на хосты виртуализации через FC Target.

 

Настраиваем дисковые ресурсы Linux-сервера

Для построения кластера высоко-доступных виртуальных машин Hyper-V нам, как минимум, потребуется один выделенный диск под том CSV, на котором будут размещаться виртуальные машины. Дополнительно нам не помешает иметь ещё один кластерный диск для роли диска-свидетеля, который нужен для организации кластерного кворума Windows Failover Cluster.

На имеющейся в нашем распоряжении конфигурации из 6 дисков в утилите управления HPE SSA, об установке которой мы говорили ранее, создан массив Smart Array (Array B). В этом массиве созданы 2 логических диска:

Логический диск "Logical Drive 2" размером в 1GB определён в нашей Linux-системе, как блочное устройство /dev/cciss/c0d1. Этот диск будет использоваться в качестве диска-свидетеля. Есть мнение, что при построении кластеров Windows Failover Cluster в качестве диска-свидетеля правильней выбирать диск не связанный напрямую с диском, который будет использоваться под кластеризуемые сервисы, как например, в нашем случае - под размещение ВМ. Ну или по крайней мере эти диски лучше иметь из разных RAID массивов. Но в моём случае конфигурация весьма ограниченная, поэтому используется такая вот упрощённая схема.

Логический диск "Logical Drive 3", которому выдана вся оставшаяся ёмкость дискового массива, определён в Linux, как блочное устройство /dev/cciss/c0d2. Этот диск будет использоваться в качестве диска для хранения ВМ. В последствии данный диск будет преобразован в CSV

 

Настраиваем конфигурацию SCST

По умолчанию основная служба scst.service будет загружаться без использования какой-либо конфигурации. Поэтому нам потребуется создать основной конфигурационный файл scst.conf, описать в нём нужную нам конфигурацию FC Target и обеспечить его автоматическую загрузку при старте системы.

Создадим отсутствующий по умолчанию файл scst.conf:

# nano /etc/scst.conf

Наполним его содержимым примерно следующего характера (основную информацию относительно написания конфигурационного файла можно посмотреть в man scst.conf):

HANDLER vdisk_fileio {
        #
        # HP Smart-Array P400 Controller -  Array B - Logical Drive 2
        #
        DEVICE FS03-P400-B-LD2 {
            filename /dev/cciss/c0d1
        }
        #
        # HP Smart-Array P400 Controller -  Array B - Logical Drive 3
        #
        DEVICE FS03-P400-B-LD3 {
            filename /dev/cciss/c0d2
        }
}

TARGET_DRIVER qla2x00t {
        #
        # HBA HP QLogic QLE2462 - Port 0
        #
       TARGET 50:01:43:80:02:00:c2:04 {
                enabled 1
                #
                # Access for host KOM-AD01-VM02
                #
                GROUP Host-VM02 {
                        LUN 0 FS03-P400-B-LD2
                        LUN 1 FS03-P400-B-LD3
                        INITIATOR 10:00:00:00:c9:78:25:16
                }
        }
        #
        # HBA HP QLogic QLE2462 - Port 1
        #
       TARGET 50:01:43:80:02:00:c2:06 {
                enabled 1
                #
                # Access for host KOM-AD01-VM01
                #
                GROUP Host-VM01 {
                        LUN 0 FS03-P400-B-LD2
                        LUN 1 FS03-P400-B-LD3
                        INITIATOR 10:00:00:00:c9:6f:2c:e4
                }
        }
}

В целом структура конфигурационного файла SCST очень наглядна и логична.

В нашем примере в разделе HANDLER описаны имеющиеся в нашем распоряжении блочные устройства, которые нужно транслировать на FC Target. Типы поддерживаемых устройств мы проверяли ранее командой scstadmin -list_handler. Каждое блочное устройство описывается в отдельной секции DEVICE. Имена дисковым устройствам SCST в нашем примере назначены таким образом, чтобы сразу было очевидно физическое месторасположение этих устройств.

В разделе TARGET_DRIVER описаны так называемые цели – Target. Типы поддерживаемых драйверов мы проверяли ранее командой scstadmin -list_driver. Каждый порт оптического контроллера, который мы хотим превратить в FC Target имеет отдельную секцию TARGET.

В свою очередь для каждой отдельной цели (TARGET) мы описываем группу GROUP, в которой определяем перечень устройств (из HANDLER\DEVICE) с номерами LUN и WWPN портов оптических адаптеров хостов, которым нужно предоставить доступ к данным LUN-ам через данный TARGET (WWPN портов со стороны FC Initiator).

Подготовив конфигурационный файл, заставим SCST перечитать конфигурацию:

# scstadmin -conf /etc/scst.conf

Если scstadmin отказывается загружать созданный нами вручную конфигурационный файл scst.conf, то вполне возможно, что где-то допущена синтаксическая ошибка. В таком случае правку конфигурации можно выполнять через набор встроенных команд в утилиту scstadmin (смотреть встроенную справку scstadmin --help)

В любом случае при попытке загрузки созданной нами конфигурации никаких ошибок быть не должно и соответствующие LUN-ы должны в этот момент стать доступны на стороне хостов виртуализации. Однако, прежде чем, переходить к использованию LUN-ов на стороне хостов Hyper-V нам нужно решить ещё одну задачу – обеспечить автоматическую загрузку созданной нами конфигурации в процессе загрузки Linux.

 

Настраиваем автоматическую загрузку конфигурации SCST

Создадим новую службу (systemd unit), например с именем scst-config.service, описав её конфигурацию в каталоге /etc/systemd/system:

# nano /etc/systemd/system/scst-config.service

Наполним файл содержимым:

[Unit]
Description=SCST Configuration Service
After=scst.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/sbin/scstadmin -config /etc/scst.conf
StandardOutput=journal

[Install]
WantedBy=multi-user.target

Включим автозагрузку службы при старте системы:

# systemctl enable scst-config.service

Перезагрузим сервер и убедимся в том, что наша служба успешно стартовала после загрузки ОС:

# systemctl status scst-config.service

Проверим лог, созданной нами службы scst-config.service, чтобы увидеть вывод утилиты scstadmin в процессе загрузки конфигурации из файла /etc/scst.conf:

# journalctl --unit scst-config.service --output cat

Как видим, конфигурация SCST загружена успешно и никаких ошибок и предупреждений в процессе загрузки нет.

Настроенная нами служба scst-config.service устроена таким образом, что её перезапуск равнозначен команде scstadmin -config /etc/scst.conf, то есть если нужно заставить SCST перечитать конфигурацию scst.conf, то для этого достаточно перезапустить службу:

# systemctl status scst-config.service

При этом остановка службы никак не повлияет на работу SCST.

Теперь можем переходить к инициализации транслируемых через FC Target дисковых устройств на хостах виртуализации.

 

Проверяем доступность LUN-ов на хостах виртуализации

На любом из хостов виртуализации откроем консоль Device Manager и удостоверимся в том, что в разделе Disk drives присутствуют созданные нами ранее в конфигурации SCST дисковые устройства. Затем перейдём в консоль управления дисками Disk Management и переведём соответствующие дисковые устройства в состояние Online:

После того, как диски переведены в Online, выполняем инициализацию этих дисков (Initialize Disk), затем создаём на диске простой том NTFS (New Simple Volume…)

При форматировании первого диска, который будет использоваться в будущем кластере в качестве диска свидетеля, присвоим букву диска, например Q. Второму диску, который будет использоваться в кластере в качестве CSV для размещения виртуальных машин, при форматировании букву диска не присваиваем, так как в дальнейшем этот диск будет смонтирован в каталог C:\ClusterStorage на обоих узлах кластера.

В результате на первом хосте мы получим примерно следующую картину

Теперь подключимся ко второму хосту и убедимся в том, что там оба диска также доступны, но они при этом будут находится в состоянии Offline.

Как видим, диски доступны на обоих хостах виртуализации и подготовлены для того, чтобы использовать их для построения кластера Windows Failover Cluster.

 

Выполняем валидацию LUN-ов и создаём кластер Windows Failover Cluster

Сразу скажу, что мы не будем рассматривать все подготовительные процедуры, необходимые для создания кластера Windows Failover Cluster, а заострим внимание лишь на тех моментах, которые имеют непосредственное отношение к работе с дисковыми ресурсами, подключенными к хостам виртуализации с Linux-сервера c SCST.

Предполагаем, что на обоих хостах виртуализации у нас уже установлены компоненты Windows Failover Cluster и настроены выделенные сетевые адаптеры для меж-узлового обмена. Открываем на любом из хостов оснастку Failover Cluster Manager (Cluadmin.msc) и вызываем мастер проверки конфигурации кластера Validate a Configuration Wizard. Добавив в мастер оба наших хоста виртуализации, запускаем процедуру проверки конфигурации хостов на предмет возможности включения этих хостов в кластер.

В результате мы должны удостовериться в том, что презентованные с Linux-хоста с SCST дисковые устройства успешно проходят все проверки. Детальную информацию о выполненных проверках можно посмотреть, пройдя по гиперссылкам в отчёте в разделе Storage

В общем-то уже на данном этапе мы видим, что поставленная цель превращения обычного сервера в СХД нами достигнута. Далее на базе проверенной конфигурации хостов создаём опорный кластер Windows Failover Cluster, преобразуем диск в CSV,  а затем создаём в кластере высоко-доступную ВМ Hyper-V. После проверяем штатное перемещение ВМ между узлами кластера, а также проверяем обработку отказа узла в кластере.

 

Выводы

Итак, базовая кластерная конфигурация Hyper-V с подключённой по оптике дисковой ёмкостью собрана нами в простом бюджетном варианте с использованием свободно-распространяемого ПО SCST на базе современной версии Debian Linux на старом серверном оборудовании. Отдельно приобретаемые под эту задачу адаптеры HBA старых поколений FC 4G сейчас стоят довольно скромных денег. Хотите скоростей, пожалуйста, используйте на стороне сервера SCST и подключаемых к нему хостов более современные адаптеры HBA FC 8G или даже 16G

Если Linux-сервер c SCST подключать не напрямую к хостам, а к фабрикам FC SAN, то можно отдавать дисковую ёмкость бОльшему количеству хостов виртуализации, используя более широкие кластерные конфигурации Windows Failover Cluster.   

Разумеется описанное решение имеет свои "узкие места".

Если сервер SCST собран без учёта избыточности аппаратных компонент, как, например, в нашем случае используется только один контроллер FC HBA QLogic, то выход из строя таких компонент может привести к недоступности всех виртуальных машин (дисковая ёмкость станет недоступна сразу всем хостам кластера). В качестве решения можно расширить конфигурацию на сервере SCST вторым контроллером, а на узлах использовать, двух-портовые HBA или пару одно-портовых HBA, чтобы можно было использовать multipath-подключение к дисковым ресурсам SCST, которое обработку отказа путей подключения.

 

Дополнительные источники информации:

• SCST Howto - How to Configure the FC QLogic Target Driver for 22xx/23xx/24xx/25xx/26xx Adapters
• thejimmahknows.com - Linux Fibre Channel SCSI Target using SCST
• debianforum.de - FC Target (SAN) unter Debian 8 / Jessie
• nandydandyoracle - SCST Debian Package Build from Source (Ubuntu 17.04)
• Хабрахабр - Бюджетное SAN-хранилище на LSI Syncro