Мы продолжаем публикацию статей в стиле how-to касательно использования систем хранения данных (СХД) Qsan в различных типовых задачах. На сей раз рассмотрим первичную настройку серверов на базе операционных систем (ОС) семейства Linux при подключении блочных томов со стороны СХД.

Как показывает практика, пользователи ОС на базе Linux являются более подкованными в плане навыков, нежели их коллеги, работающие на ОС других семейств. Однако все когда‑то были начинающими специалистами и были вынуждены узнавать много нового для себя. И хотя исторически Linux сообщество максимально открыто, что подтверждается широким выбором документации и форумов для общения/помощи, мы считаем, что еще одна тематическая статься уж точно не повредит. Тем более, что все больше людей приходит в мир Linux, в том числе и не по своей воле из‑за текущих событий в мире, как политических, так и экономических.

В качестве примера использования мы будем рассматривать подключение блочных СХД Qsan серии XCubeSAN с помощью интерфейсов Fibre Channel и iSCSI к серверам на базе ОС семейства Linux. В нашем случае — это РЕД ОС 8, под капотом которой скрывается старый добрый CentOS. Для ОС Linux других типов приведенный далее текст также подходит, поскольку идея в этапах настройки полностью совпадает. Отличия могут быть лишь в несколько ином синтаксисе команд. Сразу отметим, что приведенные далее команды должны выполняться от имени суперпользователя (root). Часть текста касательно общих правил (где это применимо) взята из наших предыдущих публикаций в отношении настройки VMware ESXi и Microsoft Windows.

Итак, в целом процесс настройки можно разделить на несколько основных этапов:

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

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

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

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

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

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

Важные замечания по поводу параметров SAN сети:

  • Фабрики между собой не соединяются для изоляции в случае возникновения ошибок в сети;

  • Если протокол iSCSI делит использование коммутаторов с другими сервисами, то весь трафик iSCSI должен быть помещен в изолированный VLAN;

  • Для протокола Fibre Channel необходимо настроить на коммутаторах зонирование по принципу «один инициатор — один или несколько таргетов» для исключения влияния серверов друг на друга;

  • Для iSCSI соединений рекомендуется включить поддержку кадров большого размера (MTU=9000) с целью увеличения производительности. Важно помнить, что необходимо изменить MTU у всех участников сети: порты контроллера СХД, физические коммутаторы, физические и виртуальные порты сетевых карт серверов.

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

На стороне хоста параметр MTU также меняется для каждого сетевого порта в отдельности:

  • С помощью команды ifconfig выводим список сетевых адаптеров

  • Командой ifconfig eth0 mtu 9000 устанавливаем значение MTU, например, для адаптера eth0

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

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

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

  • Настройка интерфейсов

  • Настройка пространства хранения

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

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

  • Необходимо выбрать тип пула: thick (место выделяется сразу) или thin (место выделяется по мере заполнения). Отметим, что thick пулы являются более производительными. Также имеется возможность выбрать тип пула Auto Tiering при заранее активированной лицензии и наличии дисков разного типа.

  • Выбрать конкретные диски

  • Задать уровень RAID и ряд его параметров, если это применимо к данному уровню

    • Subgroups — количество дисков в подгруппе в случае использования RAID 50/60

    • Spares — количество дисков Spare внутри группы в случае использования RAID EE

Затем создаются тома (Volumes) в рамках текущего мастера, либо позднее. Здесь единственной опцией является размер блока. Важно учитывать, что невозможно установить размер блока меньше, чем имеется у физического накопителя. Рекомендуется оставить значение по умолчанию 512B (для дисков 512N/512e) или 4KB (для дисков 4KN) как наиболее оптимальное.

Заключительным этапом в настройке СХД является публикация томов для доступа к ним со стороны хостов через функционал LUN mapping. Для этого в СХД создаются хост группы (Host group), которые объединяют в себе набор хостов и набор томов, к которым эти хосты должны иметь доступ. Создание хост группы всегда начинается с указания типа интерфейса, с которым она будет работать: iSCSI или Fibre Channel. Далее указываются хосты, входящие в группу. По умолчанию доступ открыт для всех (*). Но крайне рекомендуется указывать конкретные хосты с целью предотвращения несанкционированного доступа и случайного повреждения данных. Для iSCSI хосты задаются вручную в виде их IQN. Для этого необходимо их добавить по кнопке Add host (сделать это достаточно однократно в рамках одной группы, после чего список хостов будет доступен на глобальном уровне). Для FC хосты обнаруживаются автоматически в SAN сети на основе их WWPN.

Со стороны РЕД ОС IQN и WWPN хоста можно узнать при помощи команд

cat /etc/iscsi/initiatorname.iscsi

cat /sys/class/fc_host/host?/port_name

На следующем шаге задаются физические порты СХД, через которые будет осуществляться ввод/вывод (только в случае iSCSI)

И, наконец, указывается список томов, к которым будет предоставлен доступ.

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

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

service multipathd start

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

[root@localhost admin]# find /sys -iname 'scan'

/sys/devices/pci0000:80/0000:80:03.0/0000:82:00.0/host1/scsi_host/host1/scan

/sys/devices/pci0000:80/0000:80:03.0/0000:82:00.1/host2/scsi_host/host2/scan

/sys/devices/pci0000:00/0000:00:03.2/0000:04:00.0/host0/scsi_host/host0/scan

В нашем случае это – первые две строчки (легко опознается по близкому ID, т.к. это физически единый HBA с двумя портами). После чего выполняем Rescan

[root@localhost admin]# echo "- - -" > /sys/devices/pci0000:80/0000:80:03.0/0000:82:00.0/host1/scsi_host/host1/scan

[root@localhost admin]# echo "- - -" > /sys/devices/pci0000:80/0000:80:03.0/0000:82:00.1/host2/scsi_host/host2/scan

В результате найдено два новых дисковых устройства размером в 77ГБ (в нашем случае сервер подключен напрямую двумя линками)

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

[root@localhost admin]# iscsiadm -m discovery -t st -p 192.168.2.1

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

[root@localhost admin]# iscsiadm  -m node -T iqn.2004-08.com.qsan:xs3226-000d60af8:dev0.ctr1 -p 192.168.2.1 -l

[root@localhost admin]# iscsiadm  -m node -T iqn.2004-08.com.qsan:xs3226-000d60af8:dev0.ctr1 -p 192.168.3.1 -l

Проверить список активных сессий можно с помощью

[root@localhost admin]# iscsiadm -m session

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

Теперь запускаем multipath и видим, что диски, соответствующие одному и тому же дисковому устройству, «склеились»

По умолчанию multipath использует только один из доступных путей для ввода/вывода. Остальные пути находятся в режиме ожидания. Чтобы использовать их все сразу с целью балансирования нагрузки, необходимо включить режим round robin. Для этого потребуется исправить содержимое файла конфигурации /etc/multipath.conf

Пример файла (wwid для этого дисков берется из результатов вывода предыдущей команды):

Пример

multipaths {

        multipath {

                wwid 3201b0013780ffac0

                alias Qsan-iSCSI

                path_selector "round-robin 0"

                path_grouping_policy multibus

                failback imediate

                rr_weight priorities

                no_path_retry 5

                rr_min_io 1

                  }

        multipath {

                wwid 3201c0013780ffac0

                alias Qsan-FC

                path_selector "round-robin 0"

                path_grouping_policy multibus

                failback imediate

                rr_weight priorities

                no_path_retry 5

                rr_min_io 1

                  }

}

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

Теперь остается только отформатировать и примонтировать новые диски для дальнейшего использования.

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

Комментарии (3)


  1. ildarz
    12.07.2024 08:43

    Если протокол iSCSI делит использование коммутаторов с другими сервисами, то весь трафик iSCSI должен быть помещен в изолированный VLAN;

    А зачем? :)


    1. Skilline Автор
      12.07.2024 08:43

      Как показывает практика, изоляция в отдельном VLAN улучшает общую производительность и стабильность. Это в целом - общие best practice для работы с iSCSI у большинства вендоров.


      1. ildarz
        12.07.2024 08:43
        +3

        Ну просто в других рекомендациях вы хотя бы указали, зачем они, а тут просто "так надо". :) Так-то рекомендуют не только отдельные изолированные вланы (желательно даже немаршрутизируемые), но и отдельные физические порты, а если отдельные порты по какой-то причине нежелательны или невозможны, то хотя бы QoS с гарантированной полосой. Но, с другой стороны, если нет каких-то прям очень жестких требований к производительности и/или безопасности, на практике можно совершенно спокойно совмещать iSCSI трафик с другим и никто от этого не пострадает.