Использование сервера с 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, то ранее уже было опубликован ряд соответствующих заметок:
Таким образом мы предполагаем, что на сервер 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 в нашем случае выглядит так:
Для работы с контроллером 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):
После этого выполним перезагрузку сервера и после загрузки системы снова посмотрим в лог загрузки через утилиту dmesg и убедимся в том, что микрокод HBA успешно загружен в процессе запуска системы
Далее перейдём к отключению встроенного в Linux драйвера qla2xxx.
Отключаем стандартный драйвер qla2xxx
Отключаем стандартный модуль ядра Linux с драйвером qla2xxx, исключаем этот модуль из загрузочного образа initrd и отправляем сервер в перезагрузку:
После перезагрузки убеждаемся в том, что отключенный ранее модуль действительно не загружен и его сообщений не было в процессе загрузки системы
Как видим, вывод отсутствует, то есть стандартный драйвер qla2xxx успешно отключен и больше не используется.
Получаем исходные коды ядра Linux и SCST
Устанавливаем пакеты, необходимые для сборки и исходные коды используемой у нас версии ядра Linux:
Выходим в непривилегированное окружение стандартного пользователя Linux, где будем заниматься правкой и сборкой исходных кодов. Создаём в домашнем каталоге текущего пользователя подкаталог, в котором будем работать с исходниками, например
/Build , переходим в него и выполняем загрузку исходного кода используемого у нас ядра Linux:
/Build выполняем загрузку исходных кодов актуальной версии SCST:
Кстати, в моём случае svn не захотел использовать переменные окружения текущего пользователя, описывающие параметры прокси в файле
/.profile , поэтому на время пришлось открыть машине прямой доступ в интернет.
Посмотрим, что в конечном итоге получилось в нашем сборочном каталоге:
Накладываем патчи SCST на исходные коды ядра Linux
Давайте заглянем в исходные коды SCST и посмотрим то, какие патчи там имеются для ядра Linux используемой у нас 4-ой версии:
Как видим, для нашей версии ядра Linux 4.9 имеется патч nolockdep-4.9.patch , который мы и будем накладывать на исходные коды ядра Linux.
Переходим в каталог с файлами исходных кодов ядра Linux и накладываем патч:
Меняем в исходных кодах ядра драйвер qla2xxx на драйвер от SCST — qla2x00t
Заменяем драйвер в исходниках ядра Linux на тот, что в предлагается в исходниках SCST. Для этого сначала переименуем каталог с оригинальными исходниками драйвера, поставляемыми вместе с исходниками ядра Linux. Затем слинкуем каталог с исходниками драйвера из поставки SCST на имя каталога, которое ранее использовалось исходниками оригинального драйвера
Проверим, что получилось:
Выполняем конфигурацию ядра Linux
Если по какой-то причине Вы собираете 32-битное ядро, то обратите внимание на рекомендации, данные в пункте 11 статьи How to Configure the FC QLogic Target Driver for 22xx/23xx/24xx/25xx/26xx Adapters .
В каталоге с пропатченными исходными кодами ядра запускаем режим конфигурирования параметров ядра
Конфигурация пары описанных далее параметров подсмотрена в статье 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)»:
Для понимания сути этой опции приведу цитату :
Далее с верхнего уровня переходим последовательно в пункты «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-пакетов:
Процесс может занять длительное время, в зависимости от проворности процессора. По окончании процесса мы получим несколько deb-пакетов в каталоге верхнего уровня, относительно каталога компиляции:
Устанавливаем пакеты нашего кастомизированного ядра Linux:
В ходе установки автоматически будет обновлён загрузочный образ initrd
После этого выполняем перезагрузку сервера. В процессе загрузки системы, если заглянем в текущий список ядер в загрузчике GRUB, то увидим, что по умолчанию для загрузки системы используется наше кастомизированное ядро
Для того, чтобы собранное нами кастомизированное ядро Linux не обновилось в дальнейшем в процессе обновления всех пакетов системы (не было заменено в загрузчике новой версией ядра из пакета linux-image-amd64), настроим исключение для менеджера пакетов apt.
Теперь давайте попробуем выполнить обновление кеша менеджера пакетов и убедимся в том, что не смотря на то, что новая версия пакета linux-image-amd64 в репозиториях присутствует, при установке обновлений данный пакет не устанавливается, так как ранее мы его пометили в hold:
С ядром закончили, переходим к сборке SCST.
Компилируем и устанавливаем SCST
Переходим в каталог с исходными кодами SCST, компилируем и устанавливаем SCST:
После окончания компиляции и установки убедимся в том, что нужные нам для работы модули ядра присутствуют в системе:
Убедимся в том, что для нужных нам модулей ядра, при попытке их загрузки не возникает никаких ошибок:
Если при попытке загрузки модулей возникает ошибка типа » modprobe: FATAL: Module qla2x00tgt not found in directory /lib/modules/4.9.82-scst-enabled «, но соответствующий ko-файл при этом в каталоге присутствует, попробуйте выполнить обновление зависимостей модулей командой:
Убедившись в том, что все нужные нам модули загружаются без ошибок, настраиваем их автоматическую загрузку при старте системы, дописав названия модулей в конец конфигурационного файла /etc/modules
Перезагрузим систему, чтобы убедиться в том, что в процессе загрузки модули SCST загружаются успешно. Проверим это в выводе команды dmesg
Далее мы рассмотрим пример настройки и загрузки рабочей конфигурации SCST, но прежде нам потребуется собрать и установить утилиту управления scstadmin.
Компилируем и устанавливаем SCSTAdmin
Снова входим в режим непривелегированного пользователя, переходим в наш каталог с исходными файлами scst в подкаталог ../scstadmin и даём последовательно команды компиляции и установки:
Последуем совету, который будет выдан нам в процессе установки, и включим автоматическую загрузку службы scst.service при старте системы:
Теперь давайте спросим у scstadmin, какие типы HANDLER и TARGET_DRIVER нам доступны для настройки нашей конфигурации:
Как видим, в списке поддерживаемых scstadmin драйверов есть интересующий нас драйвер qla2x00t.
Посмотрим информацию о доступных 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 :
Наполним его содержимым примерно следующего характера (основную информацию относительно написания конфигурационного файла можно посмотреть в man scst.conf):
В целом структура конфигурационного файла 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 отказывается загружать созданный нами вручную конфигурационный файл scst.conf , то вполне возможно, что где-то допущена синтаксическая ошибка. В таком случае правку конфигурации можно выполнять через набор встроенных команд в утилиту scstadmin (смотреть встроенную справку scstadmin —help )
В любом случае при попытке загрузки созданной нами конфигурации никаких ошибок быть не должно и соответствующие LUN-ы должны в этот момент стать доступны на стороне хостов виртуализации. Однако, прежде чем, переходить к использованию LUN-ов на стороне хостов Hyper-V нам нужно решить ещё одну задачу – обеспечить автоматическую загрузку созданной нами конфигурации в процессе загрузки Linux.
Настраиваем автоматическую загрузку конфигурации SCST
Создадим новую службу (systemd unit), например с именем scst-config.service, описав её конфигурацию в каталоге /etc/systemd/system :
Наполним файл содержимым:
Включим автозагрузку службы при старте системы:
Перезагрузим сервер и убедимся в том, что наша служба успешно стартовала после загрузки ОС:
Проверим лог, созданной нами службы scst-config.service, чтобы увидеть вывод утилиты scstadmin в процессе загрузки конфигурации из файла /etc/scst.conf :
Как видим, конфигурация SCST загружена успешно и никаких ошибок и предупреждений в процессе загрузки нет.
Настроенная нами служба scst-config.service устроена таким образом, что её перезапуск равнозначен команде scstadmin -config /etc/scst.conf , то есть если нужно заставить SCST перечитать конфигурацию scst.conf, то для этого достаточно перезапустить службу:
При этом остановка службы никак не повлияет на работу 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, которое обработку отказа путей подключения.
Дополнительные источники информации: