настройка fibre channel в linux
Выполняю установку, настройку, сопровождение серверов. Для уточнения деталей используйте форму обратной связи
Данная статья является в некотором смысле вольным переводом статьи http://blogs.oracle.com/vreality/entry/storage_virtualization_with_comstar + мои дополнения.
1) Введение.
Сам по себе протокол FC инкапсулирует команды iSCSI, но в качестве среды передачи данных использует оптические каналы. В связи с этим, увеличивается стоимость (нужны соответственно оптические коммутаторы и прочее оборудование), но зато увеличивается и надёжность. Этот протокол, в отличии от iSCSI, лишён потери пакетов (так как не использует TCP/IP).
В FC существуют 2 типа портов: initiator и target. Initiator — это по сути клиент, а target — порт через который доступно хранилище.
Список портов можно посмотреть через команду:
Если порт присутствует, но не подключён — мы об этом узнаем.
По сути данная команда показывает только порты initiator’ы. Что бы посмотреть все доступные порты, можно использовать такой метод:
Здесь мы видим присутствие 2-х портов в режиме initiator (используется драйвер qlc).
2) Установка поддержки FC
В Solaris 11, в отличии от 10 очень много сервисов (samba, iscsi, fc, …) собраны в единый пакет storage-server. Отдельно поставить какой-нибудь компонент никак нельзя. Ставим его:
#pkg install storage-server
Для управления шарами используется сервис STMF, который по умолчанию отключён.
# svcs stmf
disabled 15:58:17 svc:/system/stmf:default
# svcadm enable stmf
# svcs stmf
online 15:59:53 svc:/system/stmf:default
3) Создание target’a.
Создаём пул, на котором будем создавать ФС, которая и будет выступать в последствии LUN’ом (логической единицей для хранения данных). Хочу обратить внимание, что zfs нужно создавать обязательно с указанием объёма, иначе LUN не создастся:
и проверим создание
Следующим этапом сделаем наш LUN видимым для всех initiator’ов в сети:
# stmfadm add-view 600144f07bb2ca0000004a4c5eda0001
4) Информация о портах
Посмотрим информацию о портах:
Детальная информация о порте:
А так можно посмотреть информацию об устройствах (порты c12, c13 — FC-порты)
5) Изменения режима работы порта.
Что бы перевести порт в режим, например, target’a делаем следующее:
где путь берётся из вывода luxadm и /pci@0,0/pci1002,5a1f@b/pci1077,138@0,1/fp@0,0 — путь относительно каталога /devices. Ошибка значит лишь то, что в данный момент оно не может выгрузить драйвер — он будет выгружен при ребуте.
После изменения выполним
Далее, заходим в mdb и смотрим:
Как видим изменения прошли. Так же можно посмотреть инфу и через fcinfo:
Так же можно посмотреть список target’ов:
После того, как вы настроили target’ы, переходим к initiator’ам.
Что бы заново пересканировать все доступные target’ы, выполним команду:
и теперь новые диски станут доступными. Что посмотреть изменения, запустим команду format:
# format
Searching for disks.
AVAILABLE DISK SELECTIONS:
0. c1t0d0
/pci@7c0/pci@0/pci@1/pci@0,2/LSILogic,sas@2/sd@0,0
1. c1t2d0
/pci@7c0/pci@0/pci@1/pci@0,2/LSILogic,sas@2/sd@2,0
2. c1t3d0
/pci@7c0/pci@0/pci@1/pci@0,2/LSILogic,sas@2/sd@3,0
3. c2t210000E08B91FACDd0
/pci@7c0/pci@0/pci@9/SUNW,qlc@0/fp@0,0/ssd@w210000e08b91facd,0
Specify disk (enter its number):
Как можно заметить, у нас появился новый диск SUN-COMSTAR. Далее с ним можно работать как с обычным, то есть создавать пул, ФС, …
Примечание.
По не выясненным причинам во время загрузки ОС FC-порт долго поднимался, и в итоге пул был недоступен и из-за этого ОС грузилась достаточно долго, но пул всё равно оставался недоступным. В итоге пришлось отказаться от FC.
7) Multipathing
При настройке разного рода FC/iSCSI очень желательно настроить и multipathing.
Очень неплохой tutorial по multipathing описан здесь
База знаний wiki
Продукты
Статьи
Содержание
fc подключение к схд сервера под linux
Применимость: Linux, выделенный сервер
Слова для поиска: storage, Huawei OceanStor
Задача:
Как подключиться к LUN выделенному на системе хранения
Решение:
Обновите систему и перезагрузите сервер с новым ядром
Обновление драйвера QLE2562
Ядро уже содержит драйвер для QLE2562, но вы можете использовать самый свежий драйвер с сайта производителя. Скачайте архив с драйвером
Установка компиляторов и прочих пакетов:
Распаковать архив с драйвером и выполнить установку:
Проверить версию установленного драйвера:
Получение параметров HBA
Найти HBA карты на вашем сервере:
Есть другие способы чтобы получить информацию о HBA, но удобнее использовать systool (пакет sysfsutils).
Сообщите эти значения администратору для настройки параметров доступа к вашему LUN
Определить статус портов:
Если статус Online и настроен доступ на СХД, то можно перезагрузить модуль адаптера и попытаться увидеть ваш LUN
В этом примере мне выделен один LUN на 200GB, но я вижу 8 штук. Причина в том, что этот LUN виден по 8-ми путям. 2 порта на моем сервере и группа из 4-х портов на СХД образуют 8 возможных путей прохождения данных.
Это необходимо для распределения нагрузки и отказоустойчивости.
Для использования всех нужно использовать либо службу Multipath или Huawei OceanStor UltraPath
Многопутевой ввод-вывод (Multipath I/O)
Использовать много-путевой доступ необходимо даже в том случае если на вашем сервере используется 1 порт.
Иначе, например, в случае обновления прошивки на одном из контроллеров СХД произойдет временное отключение вашего сервера от СХД и данные на вашем LUN могу быть повреждены.
Многопутевой ввод-вывод (Multipath I/O) — технология подключения узлов сети хранения данных с использованием нескольких маршрутов. В случае отказа одного из контроллеров, операционная система будет использовать другой для доступа к устройству. Это повышает отказоустойчивость системы и позволяет распределять нагрузку.
Multipath устройства объединяются в одно устройство с помощью специализированного программного обеспечения в новое устройство. Multipath обеспечивает выбор пути и переключение на новый маршрут при отказе текущего. Это происходит невидимо для программ и процессов использующих это устройство. Кроме того Multipath способен распределять передачу данных по разным путям посредством различных алгоритмов, например:
Преимущества Huawei UltraPath
Установка OceanStor UltraPath
Запросить у службы поддержки ссылку на пакет OceanStor UltraPath соответствующий версии вашей ОС.
В ходе установки вам будет предложено выбрать опции:
Если для подключения к системе хранения используются HBA адаптеры HCA, QLogic или Emulex, мы рекомендуем установить значение N.
Установите следующие параметры драйвера HBA адаптера:
Например для QLogic (qla2xxx) в файле /etc/modprobe.d/nxupmodules.conf следует добавить строки, если их там нет:
Для программного адаптера Linux-iscsi (Red Hat AS4) в файле /etc/iscsi.conf должны быть параметры:
Для программного адаптера open-iscsi (RHEL-7, Centos) в файле /etc/iscsi/iscsid.conf должны быть параметры:
Убедитесь, что UltraPath работает
lsscsi | grep updisk [8:0:0:1] disk up updisk 4303 /dev/sdc
В данном случае виртуальный диск созданный UltraPath имеет имя /dev/sdc
В дальнейшем вы можете использовать его для всех нужд
Создать файловую систему XFS:
Настройка UltraPath
Для управления параметрами используется утилита upadmin
Конфигурация по умолчанию после установки:
Здесь стоит изменить параметр Working Mode чтобы данные одновременно передавались по всем путям
Контроль I/O по путям для LUN с идентификатором 0:
Пересканировать SCSI
Если у вас изменился список scsi устройств (добавили LUN), то система не увидит их сама В дистрибутивах основанных на Red Hat есть скрипт:
После отрабатывания скрипта проверьте вывод команды:
Использование сервера с 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), который должен быть доступен обоим хостам виртуализации. То есть, предполагается, что для построения кластера нам потребуется какое-то внешнее дисковое хранилище (СХД), к которому могут быть подключены хосты виртуализации.
Конфигурация серверов
Для построения выше обозначенной конфигурации нами будут использоваться три сервера линейки 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
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
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
Схема подключения оптических адаптеров в нашем примере весьма проста и представляет собой прямое подключение по типу Host-to-Host оптическими патч-кордами multimode 50/125 с коннекторами LC-LC:
В данной заметке мы не будем уделять внимания процедуре построения кластера Hyper-V, как таковой, а сделаем упор на описании процесса настройки FC Target на базе SCST и продемонстрируем дальнейшую возможность использования созданного нами дискового массива в качестве общего тома в кластере Windows Failover Cluster.
Подготовка сервера под роль СХД
Если говорить о базовой установке современной версии ОС Debian Linux на аппаратную платформу HP ProLiant DL380 Gen5, то ранее уже было опубликован ряд соответствующих заметок:
Таким образом мы предполагаем, что на сервер KOM-AD01-FS03 уже установлена ОС Debian GNU/Linux 9.3 и утилиты управления HP.
Получаем Firmware для FC HBA QLogic
В целом картина по обнаружению и загрузке устройств qla2xxx в нашем случае выглядит так:
Получить микрокод firmware можно из двух разных мест:
Здесь стоит отдельно остановится на том, почему мы будем использовать описанную далее конфигурацию, в которой вместо поставляемого в составе Debian драйвера qla2xxx будет использоваться предлагаемый разработчиками SCST драйвер qla2x00t. Ведь, казалось бы, использование микрокода, устанавливаемого из пакетов и драйвер, поставляемый в составе Linux, несколько упрощают процедура настройки. Однако, здесь есть несколько «НО».
Во первых такая конфигурация не будет считаться правильной с точки зрения разработчиков SCST, так как свое ПО они разрабатывают именно под свою версию драйвера qla2x00t. Драйвер qla2x00t, который, как я понял, является «форкнутым» несколько лет назад и отлаженным разработчиками SCST драйвером qla2xxx. В ходе изучения этого вопроса, где-то в мейл-листе SCST мне даже попадалась на глаза дискуссия на эту тему, но к сожалению не сохранил ссылку.
Таким образом, в нашей конфигурации для обеспечения работы 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 выполняем загрузку исходных кодов актуальной версии SCST:
Кстати, в моём случае svn не захотел использовать переменные окружения текущего пользователя, описывающие параметры прокси в файле
Посмотрим, что в конечном итоге получилось в нашем сборочном каталоге:
Накладываем патчи SCST на исходные коды ядра Linux
Давайте заглянем в исходные коды SCST и посмотрим то, какие патчи там имеются для ядра Linux используемой у нас 4-ой версии:
Переходим в каталог с файлами исходных кодов ядра Linux и накладываем патч:
Заменяем драйвер в исходниках ядра Linux на тот, что в предлагается в исходниках SCST. Для этого сначала переименуем каталог с оригинальными исходниками драйвера, поставляемыми вместе с исходниками ядра Linux. Затем слинкуем каталог с исходниками драйвера из поставки SCST на имя каталога, которое ранее использовалось исходниками оригинального драйвера
Проверим, что получилось:
Выполняем конфигурацию ядра Linux
В каталоге с пропатченными исходными кодами ядра запускаем режим конфигурирования параметров ядра
В открывшемся интерактивном режиме настройки параметров ядра перейдём в пункт «Enable the block layer«
В списке опций выберем «IO Schedulers» и удостоверимся в том, что в качестве планировщика по умолчанию «Default I/O Scheduler» выбран вариант «CFQ«:
Далее переходим в пункт «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.service при старте системы:
Теперь давайте спросим у scstadmin, какие типы HANDLER и TARGET_DRIVER нам доступны для настройки нашей конфигурации:
Как видим, в списке поддерживаемых scstadmin драйверов есть интересующий нас драйвер qla2x00t.
Теперь можно переходить к настройке конфигурации SCST, но перед этим нужно определиться с дисковыми ресурсами, которые мы будем транслировать с нашего Linux-сервера на хосты виртуализации через FC Target.
Настраиваем дисковые ресурсы Linux-сервера
Для построения кластера высоко-доступных виртуальных машин Hyper-V нам, как минимум, потребуется один выделенный диск под том CSV, на котором будут размещаться виртуальные машины. Дополнительно нам не помешает иметь ещё один кластерный диск для роли диска-свидетеля, который нужен для организации кластерного кворума Windows Failover Cluster.
Настраиваем конфигурацию SCST
Создадим отсутствующий по умолчанию файл scst.conf :
Наполним его содержимым примерно следующего характера (основную информацию относительно написания конфигурационного файла можно посмотреть в man scst.conf):
В целом структура конфигурационного файла SCST очень наглядна и логична.
Подготовив конфигурационный файл, заставим SCST перечитать конфигурацию:
В любом случае при попытке загрузки созданной нами конфигурации никаких ошибок быть не должно и соответствующие LUN-ы должны в этот момент стать доступны на стороне хостов виртуализации. Однако, прежде чем, переходить к использованию LUN-ов на стороне хостов Hyper-V нам нужно решить ещё одну задачу – обеспечить автоматическую загрузку созданной нами конфигурации в процессе загрузки Linux.
Настраиваем автоматическую загрузку конфигурации SCST
Создадим новую службу (systemd unit), например с именем scst-config.service, описав её конфигурацию в каталоге /etc/systemd/system :
Наполним файл содержимым:
Включим автозагрузку службы при старте системы:
Перезагрузим сервер и убедимся в том, что наша служба успешно стартовала после загрузки ОС:
Проверим лог, созданной нами службы scst-config.service, чтобы увидеть вывод утилиты scstadmin в процессе загрузки конфигурации из файла /etc/scst.conf :
Как видим, конфигурация SCST загружена успешно и никаких ошибок и предупреждений в процессе загрузки нет.
При этом остановка службы никак не повлияет на работу SCST.
Теперь можем переходить к инициализации транслируемых через FC Target дисковых устройств на хостах виртуализации.
Проверяем доступность LUN-ов на хостах виртуализации
На любом из хостов виртуализации откроем консоль Device Manager и удостоверимся в том, что в разделе Disk drives присутствуют созданные нами ранее в конфигурации SCST дисковые устройства. Затем перейдём в консоль управления дисками Disk Management и переведём соответствующие дисковые устройства в состояние Online:
После того, как диски переведены в Online, выполняем инициализацию этих дисков (Initialize Disk), затем создаём на диске простой том NTFS (New Simple Volume…)
В результате на первом хосте мы получим примерно следующую картину
Теперь подключимся ко второму хосту и убедимся в том, что там оба диска также доступны, но они при этом будут находится в состоянии 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, которое обработку отказа путей подключения.
Дополнительные источники информации: