Fc подключение к схд сервера под windows

Обновите операционную систему, скачайте с сайта, извлеките из архива, установите пакет QConvergeConsole CLI for Windows и пакет UltraPath for Windows.

1. Зайти по ссылке на сайт http://driverdownloads.qlogic.com/QLogicDriverDownloads_UI/Defaultnewsearch.aspx, указать операционную систему:

2. Выбрать пакет для загрузки:

3. Установку пакета выполнять в режиме Custom:

4. Отключить все кроме драйвераFC и консольных утилит QConvergeConsole CLI:

5. Скачать и установить пакет UltraPath for Windows. Ссылку для скачивания последней версии пакета вам должен передать служба технической поддержки.

Сервер подключается к СХД по такой схеме:

Использовать много-путевой доступ необходимо даже в том случае если на вашем сервере используется 1 порт.

Иначе, например, в случае обновления прошивки на одном из контроллеров СХД произойдет временное отключение вашего сервера от СХД и данные на вашем LUN могу быть повреждены.

Многопутевой ввод-вывод (Multipath I/O) — технология подключения узлов сети хранения данных с использованием нескольких маршрутов. В случае отказа одного из контроллеров, операционная система будет использовать другой для доступа к устройству. Это повышает отказоустойчивость системы и позволяет распределять нагрузку.

Multipath устройства объединяются в одно устройство с помощью специализированного программного обеспечения в новое устройство. Multipath обеспечивает выбор пути и переключение на новый маршрут при отказе текущего. Это происходит невидимо для программ и процессов использующих это устройство. Кроме того Multipath способен распределять передачу данных по разным путям посредством различных алгоритмов, например:

Без Ultrapath ваша система будет видеть 4 устройства вместо одного.

Преимущества Huawei UltraPath

6. После перезагрузки системы в менеджере устройств (Секция Storage Controllers)убедитесь что установлена актуальная версия драйвера Qlogic и Ultra-Path support

7. Запустить консоль Ultra-Path, зайти в меню System > Global Settings и установить параметры как на этом снимке:

8. Зайдите в менеджер дисков, активируйте диск, создайте раздел с файловой системой.

9. В консоли Ultra-Path выберите все пути (1), запустите Performance Monitor (2), выберите тип измерений / measurement (3), запустите мониторинг (4), дайте нагрузку на диск и убедитесь что данные передаются по всем путям.

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

Здесь же остановимся на технической части. А точнее — на процессе подключения СХД к серверу предприятия. Чтобы все правильно работало, отвечало критериям безопасности, не вызывало проблем на дистанции. Тема объемная, затрагивает массу смежных протоколов и сервисов. Но если разобраться — ничего сложного.

---

Общие сведения и определения

Для начала давайте пройдемся по терминологии. Системы хранения данных (или сети хранения данных) в кругу специалистов принято именовать SAN (Storage Area Network). Основные компоненты SAN — накопители и контроллеры. Чтобы равномерно распределять нагрузку между дисками и серверами, не потеряв при этом в скорости и надежности, используют несколько путей ввода-вывода, не менее двух интерфейсов подключения и HBA (Host Bus Adapter) — выделенную плату-контроллер, которая связывает диски.

Связь между блоками обеспечивают коммутаторы. Они же отвечают за принадлежность к определенным ресурсам. Для этих целей у каждого SAN собственный WWN-адрес (World Wide Name), некий сетевой аналог MAC-адреса.

Подключение производят посредством LUN-интерфейса (Logical UNit). Это отчасти аналог раздела на жестком диске, но используемый для контроллеров. Благодаря такому подходу сервер видит LUN-диски как физические копии. Полезный подход, поскольку в дальнейшем через LUN можно подключить неограниченное количество физических и облачных мощностей в единую систему, формируя один полноценный диск. С него и будет раздаваться информация по серверам.

Распределение происходит через Disk Manager, или посредством утилит уровня LAN/SAN Mapping. Сам же хост LUN-интерфейс не видит.

Специалисты отмечают, что цеплять все имеющиеся LUN-ы на единый контроллер не стоит — быстро перегрузите систему. Всегда разделяйте мощности.

При создании СХД можно использовать как SATA, так и SAS-диски. Зависит от бюджета и потребностей.

Само же подключение SAN к хосту выполняется по следующему принципу:

• физическая компоновка;
• программная настройка.

И будь вы хоть трижды заслуженный админ с самым красивым бубном и хронически красными глазами (борода, само собой, должна быть длинной и окладистой), не забывайте действовать по инструкции. Производитель всегда кладет ее в комплект, чтобы минимизировать риски и снизить количество классических обращений в сервисный центр.

Схема подключения СХД к серверу по SCSI, SAS, FC

Опустим различия между производителями и сосредоточимся на сути. Основной процесс создания системы выглядит следующим образом:

1. Установите контроллер HBA в свободный PCI-слот сервера.
2. Подключите SAN к соответствующим интерфейсам, которые подразумеваются дисковым вместилищем (SCSI, SAS, FC).
3. Настройте сетевое подключение, определите порты, используемые для оптической сети.
4. Скачайте официальное ПО, если оно не предусмотрено в комплекте (зачастую это необходимо, потому как CD-привода в большинстве серверов давно нет).
5. Инсталлируйте софт с дальнейшей регистрацией, если необходимо.
6. Подключите HBA хоста и полку с дисками (стойку с накопителями) в одну подсеть на физическом свитче.
7. Временно отключите файрволл во избежание ненужных ошибок и возмущений системы.
8. Запустите программу сканирования СХД, которая определит топологию сети, а заодно покажет количество и номера устройств.
9. Проведите регистрацию хоста на полке. Задачу можно произвести автоматически (рекомендуется), или руками через веб-морду.
10. Введите IP хоста, привязав его к дисковой полке. Также не забудьте задать пароль администратора при первом старте.
11. Зайдите в СХД и убедитесь, что все накопители нормально работают в режиме стандартных SCSI-устройств.
12. Перейдите с помощью браузера к СХД по IP-адресу, а заодно убедитесь в наличии серверов, которые прошли регистрацию в массиве.
13. Откройте вкладку с инициаторами, которые связывают блоки СХД с хостами. Дополнительно проверьте IP-адреса и, по необходимости, пропишите их вручную.
14. Свяжите воедино хосты и LUN-ы, только последовательно.

Если все сделано правильно, то возле раздела с HBA появится соответствующая пиктограмма.

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

Первым делом, необходимо разрезать диски на LUN-ы и оставить 1-2 ГБ свободного места на всякий случай. Далее переведите все накопители в статус «онлайн», но буквы никому не присваивайте — особенности работы. А вот форматировать стоит (NTFS. ExFAT или другой алгоритм на усмотрение администратора).

Завершаем настройку установкой HBA-драйверов под FC, SAS или SCSI.

На этом можно считать, что работы завершены. Системой можно управлять специализированным ПО от производителя, или благодаря веб-морде. Это не принципиально.

Полезные советы

Если вы создаете СХД с нуля, настоятельно рекомендуем закупить железо единого производителя. В идеале — одной серии. Так вы избежите 90% ошибок, нестыковок, проблем совместимости.

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

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

И самое главное. При отсутствии опыта у штатных техников и администраторов, обращайтесь к аккредитированным специалистам. Это не та сфера, где можно по щелчку пальцев настроить все самостоятельно — большое количество смежного оборудования, коннекторов, плат управления и контроллеров. Специалисты Маркет.Марвел, имея большой опыт работы в этом направлении, помогут вам подобрать грамотную конфигурацию и оборудование для неё.

Также вы получите квалифицированную поддержку в момент запуска, и после истечения гарантийного срока. Поверьте: сохранность данных того стоит. Это как раз тот случай, когда эксперименты обходятся дорого.

Если у вас еще остались вопросы по эксплуатации СХД, вы всегда можете задать их нашим специалистам. Закажите консультацию, и мы предоставим вам всю требуемую информацию.

Подключение Multipath LUN СХД к Windows Server 2008 и Windows Server 2012

В предыдущей статье мы рассматривали «Подключение Multipath LUN СХД к VMware ESXi и Debian GNU/Linux». В данной статье продолжаем. Напомню, что используется конфигурация с двумя SAN-свитчами, к каждому из которых, СХД подключена двумя линками.

Подключение Multipath LUN СХД к Windows Server 2012

Multipath Input Output — это система многопутевого подключения блочных устройств. Требуется она для дублирования каналов подключения в целях повышения отказоустойчивости и производительности за счет того, что сервер может обращаться к устройству по нескольким каналам.

Вот так система видит LUN’ы без поддержки MPIO:

Если MPIO по какой-либо причине отключен, требуется включить. Для этого в «панели мониторинга» выбираем меню «управление» и пункт «добавить роли и компоненты».

В «мастере добавления ролей и компонентов» переходим к пункту «компоненты» и выбираем в списке «Multipath I/O», после чего нажимаем виртуальную кнопку «установить».

После этого переходим в систему управления дисковыми массивами в «диспетчере серверов» и через меню «средства» вызываем диалог MPIO:

На вкладке «Обнаружение многопутевых устройств» видим нужные нам LUN’ы и нажимаем кнопку «добавить».

Система предложит перезагрузиться. Соглашаемся. После перезагрузки все LUN’ы доступны как MPIO устройства:

Теперь их требуется подключить к системе, после чего можно создавать тома:

Готово. Теперь созданные тома доступны в системе:

Подключение Multipath LUN СХД к системе Windows Server 2008

Выше мы рассмотрели как подключить LUN к системе Windows Server 2012. В системе Windows Server 2008 процедура несколько отличается.

После загрузки системы, запускаем «Диспетчер сервера»:

В меню «Действие» выбираем пункт «Добавить компоненты»:

В списке активируем переключатель «Многопутевой ввод-вывод» и проходим все этапы установки:

Готово. Теперь нужно активировать распознавание путей. Для этого переходим на «Панель управления» и переключаемся на режим просмотра «Мелкие значки:

Вызываем панель конфигурации „MPIO“:

Где переходим на вкладку „Обнаружение многопутевых устройств“. В списке „Код оборудования“ будут представлены нужные LUN’ы. Нажимаем виртуальную кнопку „Добавить“:

Система предложит перезагрузиться. Соглашаемся:

После перезагрузки в „Диспетчере сервера“ переходим по пунктам „Хранилище“ → „Управление дисками“ и видим LUN’ы как Multipath устройства:

Теперь можно создать тома и подключить к системе:

Готово. Теперь диск доступен в системе. Чтобы убедиться, можно открыть „Мой компьютер“:

Источник

Установка и настройка MPIO в Windows Server 2016/2012R2

В этой статье мы рассмотрим особенности реализации, установки и настройки MPIO в Windows Server 2016/2012 R2. MPIO (Multi—Path Input Output) или многопутевой ввод-вывод, это технология для построения отказоустойчивого транспорта к системе хранения данных (СХД) или выполняющему эти функции серверу за счет использования избыточных путей. Дополнительные пути между сервером и хранилищем создаются с использованием избыточных физических компонентов (коммутаторы, кабели, адаптеры или сетевые карты). Обратная сторона такой избыточности – операционная система может видеть один и тот же LUN по разным путям и считать их разными устройствами.

На следующем скриншоте видно (список подключенных дисков можно вывести с помощью get-disk), что Windows видит без MPIO видит 2 диска по разным путям, которые по факту являются одним LUN:

Если ОС поддерживает MPIO, она будет видеть каждый из презентованных ей дисков в одном экземпляре. При включенном MPIO сервер может обращаться к данным на СХД по нескольким путям, что увеличивает скорость доступа к подключенному LUN и позволяет задействовать для доступа несколько сетевых или HBA-адаптеров.
MPIO может задействовать альтернативный логический путь при выходе из строя одного/нескольких компонентов, заставив операционную систему использовать для доступа к логическому диску (LUN) резервный маршрут, сохраняя непрерывность доступа к данным. Таким образом MPIO является важным компонентом при реализации отказоустойчивой системы доступа к данным, кроме того входящие в состав MPIO модули позволяют распределять нагрузку между различными путями к одному и тому же LUN-у.

Установка MPIO в Windows Server 2016/2012R2

Windows Server поддерживает многопутевой ввод-вывода MPIO начиная с версии Windows Server 2008 R2. Технология Microsoft MPIO позволяет обеспечить высокую доступность и балансировку нагрузки посредством возможности организации нескольких подключений к СХД, не зависит от протоколов и поддерживает подключение дисковых массивов и хранилищ по iSCSI, Fiber Channel и хранилищ SAS.

MPIO-модуль в Windows Server по умолчанию не включен. Установить его в Windows Server 2016 можно двумя способами:

Установка MPIO с помощью консоли Server Manager

Установка MPIO с помощью Powershell

Запустите консоль PowerShell с правами администратора и для установки компонента выполните команду:

Чтобы убедиться, что модуль MPIO установлен в вашем Windows Server, выполните:

Настройка MPIO в Windows Server 2016

После установки MPIO модуля, необходимо активировать его для LUN, которые доступны по нескольким путям. По умолчанию ОС видит каждое подключение к диску как разные логические диски (LUN).

Разрешите модулю DSM от Microsoft (MSDSM) автоматически объединять SAN диски в зависимости от типа подключений. MSDSM автоматически определяет наличие LUN, имеющих несколько путей к СХД и поддерживает большинство популярных систем хранения.

Сделать это можно из командной строки:

Также вы можете включить DSM через графический интерфейс. Откройте консоль управления Server Manager и в меню Tools выберите пункт MPIO (или выполните команду mpiocpl).

Перейдите на вкладку Discover Multi—Paths, включите опцию Add support for SAS devices (или Add support for iSCSI devices, если вы используете iSCSI хранилище) и нажмите Add. После этого перезагрузите сервер.

После перезагрузки откройте диспетчер устройств или диспетчер дисков и убедитесь, что количество подключенных дисков (LUN), доступных серверу уменьшилось в 2 раза (при наличии подключений к СХД по двум путям).

Вы можете управлять списком устройств, для которых включена поддержка MPIO на вкладке MPIO Devices (или командой Get-MSDSMSupportedHw ).

Вы можете добавить новые MPIO устройства, нажав кнопку Add или из PowerShell:

Если вы подключаете iSCSI таргет по 2 путям и хотите использовать MPIO для этого подключения, нужно при подключении Target выбрать iSCSI LUN, нажать кнопку Connect и включить опцию Enable multi—path.

Затем нажмите на кнопку Advanced и привяжите разные IP адреса инициатора к разным IP адресами target.

С помощью PowerShell можно получить текущие настройки MPIO:

Можно изменить настройки MPIO таймеров так (например, установим рекомендованные настройки для flash массива):

Доступны следующие политики балансировки MPIO:

Чтобы задать политику балансировки (например, Round Robin):

Также политику балансировки можно изменить в свойствах подключенного LUN на вкладке MPIO. В этом примере для массива выбрана политика Round Robin.

Чтобы увидеть полный список PowerShell команд, доступных в модуле MPIO, выполните команду:

Get-Command –Module Mpio

SAN Policy

В Windows имеется специальная политика дисков (SAN Policy), которая определяет, нужно ли автоматически монтировать диски при их подключении к хосту.

Текущую настройку SAN Policy можно получить с помощью diskpart. По умолчанию используется SAN политика Offline Shared.

Чтобы автоматически монтировать диски, нужно изменить значение SAN Policy на OnlineAll.

Источник

Подключение СХД Qsan к серверам в среде Windows Server и Hyper-V

Мы продолжаем цикл публикаций из серии How To для пользователей СХД Qsan. В данной статье пойдет речь о подключении СХД к серверам на базе Windows Server, в том числе при использовании функционала виртуализации Hyper-V.

В статье мы будем рассматривать подключения СХД Qsan с использованием блочных протоколов доступа iSCSI и Fibre Channel. Сам процесс подключения можно разделить на несколько основных этапов:

В статье приведены скриншоты настройки операционной системы Windows Server 2016/2019 с нелокализованным интерфейсом. Часть описания, не относящаяся напрямую к ОС, взята из нашего предыдущего обзора по настройке ESXi.

Физическая и логическая коммутация

Совокупность оборудования и линий связи между СХД и серверами образуют так называемую SAN сеть. Отказоустойчивое подключение участников SAN сети подразумевает постоянное наличие хотя бы одного пути между инициатором (хост) и таргетом (СХД). Т.к. СХД сейчас практически поголовно имеют минимум два контроллера, каждый сервер должен иметь связь с каждым из них. В простейшем варианте серверы подключаются к СХД напрямую. Такой режим работы называют Direct Attach. СХД Qsan поддерживают такой режим работы. В этом случае каждый сервер должен иметь двухпортовую HBA для соединения с каждым контроллером СХД. Т.е. между сервером и СХД будет 2 пути. При наличии максимального количества опциональных портов в таком режиме к СХД можно подключить до 10 серверов через iSCSI или до 8 серверов через Fibre Channel.

В большинстве случаев серверы соединяются с СХД через коммутаторы. Для большей надежности их должно быть два (в общем случае их, конечно же, может быть больше, но это они все равно делятся на две группы – фабрики). Этим выполняется защита от выхода из строя самого коммутатора, линка и порта контроллера СХД/HBA. В этом случае каждый сервер и каждый контроллер СХД подключается к каждому коммутатору. Т.е. между каждым сервером и СХД будет 4 пути (в случае двух коммутаторов).

Для Qsan параметр MTU меняется на каждом порту каждого контроллера в меню iSCSI Ports

В Windows Server параметр MTU меняется в настройках драйвера адаптера:
Control PanelNetwork and InternetNetwork Connections → Свойства конкретного адаптера → Configure → Advanced → Jumbo Packet (у некоторых адаптеров этот пункт может называться что-то типа Large Packets)

Для получения инструкций по изменению MTU у физических коммутаторов рекомендуем обратиться к документации конкретного производителя.

Действия на стороне СХД

Необходимые настройки на СХД можно разделить на два этапа:

Настраивать интерфейсы требуется в основном в случае использования протокола iSCSI: необходимо задать IP адреса портов на вкладке iSCSI Ports. IP адреса портов должны быть из разных подсетей, чтобы однозначно маршрутизировался трафик на стороне хоста.

В случае использования интерфейса Fibre Channel ничего настраивать, как правило, не нужно.

Далее необходимо создать пространство хранения. Сначала создается пул – группа физических накопителей, работающих совместно. Пулов в пределах СХД может быть несколько. Накопители внутри пула объединяются в соответствии с выбранным при его создании уровнем RAID, обеспечивая заданную надежность. Пулы создаются на вкладке Pools → Create Pool, где запускается пошаговый мастер.

Помимо обычных пулов Qsan поддерживает создание AutoTiering пулов при условии активации соответствующей лицензии. С принципом работы таких пулов можно ознакомиться в отдельной статье.

После создания пула(ов) необходимо создать тома (volume): Volumes → Create volumes. Также запустится пошаговый мастер создания тома.

Необходимо задать требуемый размер тома, тип тома выбирается как RAID volume. Рассмотрим их более подробно.

Заключительным этапом в настройке СХД является публикация томов для доступа к ним со стороны хостов через функционал LUN mapping → Map LUN.

Действия на стороне хоста

Первоначально необходимо один раз установить на сервере компонент Multipath IO, который обеспечивает работу многопутевого ввода/вывода. Данное действие производится через стандартный диалог Add Roles and Features

При использовании протокола iSCSI необходимо выполнить:

При использовании протокола Fibre Channel все гораздо проще: достаточно выполнить Rescan для обнаружения нового тома. В нашем примере это том с LUN доступный по 4 путям. Как и в случае с iSCSI следует убедиться, что для диска установлена политика Round Robin, при которой все доступные пути до СХД будут использоваться равномерно.

Важное замечание касательно конфигурирования MPIO. По умолчанию Windows видит дисковые устройства по отдельности, т.е. каждый путь к устройству – это отдельный диск.

Чтобы ОС «склеила» все одинаковые диски в единое устройство, необходимо в стандартной оснастке MPIO добавить новое устройство как многопутевое. Для iSCSI устройств устанавливается отдельное разрешение. По окончании настройки потребуется перезагрузить сервер. Данную настройку необходимо произвести однократно для каждой СХД. После чего все вновь презентованные диски будут опознаваться ОС как многопутевые.

В случае использования кластера из нескольких хостов Windows Server, действия, описанные выше, необходимо повторить на каждом из хостов. После чего диски, появившиеся в системе, можно добавлять в дисковые ресурсы кластера.

В рамках этой статьи были рассмотрены преимущественно базовые операции, необходимые для подключения серверов Windows Server к СХД Qsan. Для получения более полной информации настоятельно рекомендуется ознакомиться с руководствами пользователей, предоставляемыми обоими вендорами.

Источник

Настройка виртуального адаптера Fibre Channel Hyper-V в структуре хранилища VMM

Поддержка этой версии Virtual Machine Manager (VMM) прекращена. Рекомендуем перейти на VMM 2019.

В этой статье описывается настройка виртуального адаптера Fibre Channel Hyper-V в структуре хранилища System Center Virtual Machine Manager (VMM).

Виртуальный адаптер Fibre Channel позволяет виртуальным машинам Hyper-V напрямую подключаться к хранилищу на основе Fibre Channel. Hyper-V предоставляет порты Fibre Channel в операционных системах на виртуальных машинах, что позволяет виртуализировать приложения и рабочие нагрузки, которые имеют зависимости от хранилища Fibre Channel. Кроме того, можно кластеризовать операционные системы на виртуальных машинах по Fibre Channel.

Перед началом работы

Вам потребуется следующее.

Развертывание виртуального адаптера Fibre Channel

Необходимо сделать следующее:

Обнаружение и классификация структур Fibre Channel

Создание виртуальных сетей хранения данных (vSAN) и назначение адаптеров шины

Вы можете создать виртуальные сети хранения данных и назначить для них адаптеры шины. На каждом узле может быть создана одна или несколько виртуальных сетей хранения данных. Каждая виртуальная сеть хранения данных может содержать только адаптеры шины, принадлежащие одной и той же структуре.

Виртуальные адаптеры шины, представляющие виртуализацию адаптеров шины Fibre Channel, используются виртуальными машинами для подключения к виртуальным сетям хранения данных. Каждый виртуальный адаптер шины имеет имя узла в Интернете (WWNN), отличающееся от WWNN адаптера шины узла. С помощью NPIV адаптер шины главного компьютера можно сопоставить с несколькими виртуальными адаптерами шины. Порты адаптеров шины, назначенные виртуальной сети хранения данных, при необходимости могут добавляться или удаляться.

Создание шаблона виртуальной машины

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

После развертывания виртуальной машины в узле можно соотнести зоны массива хранения данных виртуального адаптера Fibre Channel с виртуальной машиной. Затем необходимо создать LUN и зарегистрировать его (снять маску) на виртуальной машине.

Создание зон

Зоны используются для подключения массива Fibre Channel к узлу или виртуальной машине. Целевые порты массива хранения данных сопоставляются с портами адаптеры шины на узле или портами виртуального адаптера шины на виртуальной машине. Вы можете создать зоны для узла, виртуальной машины или их обоих. Для отказоустойчивых кластеров Hyper-V зона необходима для каждого узла в кластере. Обратите внимание на следующее.

Настройте зоны следующим образом.

Создание и регистрация LUN

Для доступа к ресурсам массивов хранения данных узла, виртуальной машины или уровня службы узла на них должны быть созданы и зарегистрированы (сняты маски) номера LUN.

Создание и развертывание уровня службы

Дальнейшие действия

Настройте хранилище для узлов и кластеров Hyper-V.

Источник

База знаний wiki

Продукты

Статьи

Содержание

fc подключение к схд сервера под windows

Задача:

Как подключиться к LUN выделенному на системе хранения

Решение:

Обновите операционную систему, скачайте с сайта, извлеките из архива, установите пакет QConvergeConsole CLI for Windows и пакет UltraPath for Windows.

2. Выбрать пакет для загрузки:

3. Установку пакета выполнять в режиме Custom:

4. Отключить все кроме драйвераFC и консольных утилит QConvergeConsole CLI:

5. Скачать и установить пакет UltraPath for Windows. Ссылку для скачивания последней версии пакета вам должен передать служба технической поддержки.

Сервер подключается к СХД по такой схеме:

Многопутевой ввод-вывод (Multipath I/O)

Использовать много-путевой доступ необходимо даже в том случае если на вашем сервере используется 1 порт.

Иначе, например, в случае обновления прошивки на одном из контроллеров СХД произойдет временное отключение вашего сервера от СХД и данные на вашем LUN могу быть повреждены.

Многопутевой ввод-вывод (Multipath I/O) — технология подключения узлов сети хранения данных с использованием нескольких маршрутов. В случае отказа одного из контроллеров, операционная система будет использовать другой для доступа к устройству. Это повышает отказоустойчивость системы и позволяет распределять нагрузку.

Multipath устройства объединяются в одно устройство с помощью специализированного программного обеспечения в новое устройство. Multipath обеспечивает выбор пути и переключение на новый маршрут при отказе текущего. Это происходит невидимо для программ и процессов использующих это устройство. Кроме того Multipath способен распределять передачу данных по разным путям посредством различных алгоритмов, например:

Без Ultrapath ваша система будет видеть 4 устройства вместо одного.

Преимущества Huawei UltraPath

6. После перезагрузки системы в менеджере устройств (Секция Storage Controllers)убедитесь что установлена актуальная версия драйвера Qlogic и Ultra-Path support

7. Запустить консоль Ultra-Path, зайти в меню System > Global Settings и установить параметры как на этом снимке:

8. Зайдите в менеджер дисков, активируйте диск, создайте раздел с файловой системой.

9. В консоли Ultra-Path выберите все пути (1), запустите Performance Monitor (2), выберите тип измерений / measurement (3), запустите мониторинг (4), дайте нагрузку на диск и убедитесь что данные передаются по всем путям.

Источник

Алгоритм подключения системы хранения данных к хосту, техническая информация и рекомендации.

---

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

Создание SAN является сложной задачей. Если это ваш первый опыт, обратитесь к специалистам ВИСТЛАН за консультацией, помощью в проектировании системы и подборе оборудования

Подключение СХД к хосту делится на два этапа:

1. Физическое соединение.

2. Настройка.

Перед началом внимательно ознакомьтесь с документацией производителя на полку. Она подробно описывает все действия.
Пример документации от Oracle.

Техническая информация

SAN состоит из нескольких HDD и контроллеров. Для равномерного распределения нагрузки и обеспечения надёжности стараются использовать два HBA (Host Bus Adapter), несколько путей ввода-вывода, как минимум два интерфейса.

Главным правилом подключения СХД к хосту является использование как минимум двух связей и путей для каждого устройства.

Свичи обеспечивают для серверов доступ только к предназначенным им ресурсам. Для этого в SAN каждому интерфейсу и каждому LUN-у присваивается World Wide Name (WWN) — подобие MAC-адреса.

LUN — Logical UNit — с точки зрения контроллера — это аналог раздела на жёстком диске. Сервер видит их как физические диски. Можно подключить все хосты к одному диску или раздать LUN-ы по серверам.

Распределение выполняется в Disk Manager конкретного сервера или с помощью утилит (LAN Mapping, SAN Mapping и т.п) хосту принудительно запрещается видеть LUN.

Не вешайте все LUN-ы на один контроллер. Разделите особо нагруженные LUN-ы по разным.

При создании SAN можно использовать разные типы HDD. Помедленнее и подешевле, типа SAS или SATA, — для ОС сервера и файловых ресурсов; FC — для скоростных приложений и баз данных.

Алгоритм подключения

1. В сервер установите HBA-контроллер.

2. Подключите СХД с помощью кабелей соответствующих интерфейсам, установленным на дисковой хранилище (FC, SAS, SCSI) по вашей схеме.

3. Проведите настройку сети, правильно установите типы используемых портов для оптической сети.

4. Скачайте с сайта производителя ПО. Однако, оно может идти в комплекте, но это не обязательно.

5. Установите ПО. Пройдите регистрацию, если требуется.

6. Включите HBA хоста и дисковую полку в одну подсеть на одном физическом коммутаторе.

7. Выключите файрволл.

8. Запустите утилиту сканирования SAN для определения топологии. Она покажет все устройства и их номера.

9. Зарегистрируйте хост на полке. Это можно сделать с помощью утилиты или вручную через веб-интерфейс полки. Автоматически — корректней.

10.  Введите в браузере IP-адрес хоста и сделайте привязку полки. При первом подключении может понадобиться создать пароль админа.

11.  Зайдите в систему управления дисками на хосте, убедитесь, что подключенные диски видны. Они выглядят там как обычные SCSI.

12.  Перейдите по IP-адресу СХД в браузере. Проверьте наличие серверов, регистрация которых уже выполнена.

13.  Найдите вкладку с инициаторами, связывающими хосты с блоками СХД. Проверьте IP-адреса. Если нужно, перенастройте их вручную.

14.  Свяжите LUN-ы и хосты. Действия типа: Create -> Connect LUNs -> Connect Hosts.

15.  Посмотрите наличие отметки около HBA, сигнализирующей о корректности подключения.

На этом настройка полки закончена.

1. Нарежьте диски на LUN-ы. Их можно сделать много. Оставьте около 1 Гб свободного места

2. Переведите диски в режим онлайн. Буквы не присваивайте.

3. Отформатируйте диски в нужный формат, например, NTFS.

4. Установите драйверы HBA (FC, SAS или SCSI).

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

Рекомендации

Если СХД только создаётся, имеет смысл использовать оборудование одного производителя, чтобы избежать проблем с совместимостью устройств.

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

Это можно не делать, если у вас в штате есть несколько опытных и толковых администраторов, у которых много свободного времени. Хотя, по деньгам вы здесь вряд ли выиграете, так как их работа оплачивается, а также нужно будет приобретать нужные комплектующие и пытаться их «подружить».

Дисковая полка конструктивно состоит из жёстких дисков и источника бесперебойного питания. Его основная функция — не питать систему в случае отключения электричества, а предоставление возможности СХД корректно завершить все операции ввода-вывода при выключении полки. Поэтому, для защиты сторейджа по питанию устанавливайте ИБП.

По FC можно подключиться к коммутатору и тем самым расширить количество используемых устройств. На SAS нельзя повесить серверов больше, чем есть портов на массиве.

Покупайте полку сразу с дисками.

Не подключайте несколько хостов к одному LUN-у, если у вас не кластер. Такое соединение создает несогласованность записи, что приведёт к повреждению данных.

Сервис — очень важная вещь в СХД. Так как стоимость и масштаб потерь велики, не скупитесь, заключите договор с интегратором на обслуживание. В результате вы сэкономите время, нервы и, как ни странно, деньги.

Самому выбрать правильную конфигурацию под свои задачи не очень просто. ВИСТЛАН, имея большой опыт работы в этом направлении, поможет принять правильное решение и подобрать конфигурацию и оборудование для неё. Это тот случай, когда эксперименты обходятся дорого.

Имеем удалённую площадку с одним хостом виртуализации на базе гипервизора 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, в которой определяем перечень устройств (из HANDLERDEVICE) с номерами 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