СХД Gladius Storage L и настройка MPIO для iSCSI в Windows Server 2012

Пошаговое руководство: поднимаем iSCSI таргет под СХД True System Gladius L (бюджетная СХД на базе Linux для хранения бэкапов) и настраиваем MPIO (multipath IO) для iSCSI в Microsoft Windows Server 2012.
Обычно мы используем СХД на базе CentOS или Fedora в качестве репозиториев для Veeam Backup&Replication, но иногда стоит задача обеспечить резервную СХД с блочным доступом. В этом случае удобнее всего использовать targetcli под Fedora. Targetcli - достаточно удобный инструмент для управления lio-target, ставшего стандартом в ядре Linux (начиная с 2.6.38). Данный пост, как всегда, предназначен для тех случаев, когда первоисточник читать некогда и нужна простая пошаговая инструкция.

Зачем нужен MPIO

MPIO (multipath input/output, многопутевой ввод-вывод) применительно к хранению данных используется для масштабирования производительности и увеличения надежности. Принцип работы очевиден из названия: используется несколько путей от хоста к блочному устройству. Целью является повышение надежности соединения за счет отсутствия единых точек отказа в виде HBA на стороне инициатора, контроллеров на стороне таргета и прочих компонентов: трансиверов, кабелей, коммутаторов и т.д. На нижеприведенной схеме мы видим классический пример отказоустойчивого подключения: 2-контроллерную СХД с подключением к двух хостам через два коммутатора. Для каждого хоста в данном случае существует 8 путей: линк через 1-й коммутатор -> 1-й линк к первому контроллеру, линк через 1-й коммутатор -> 2-й линк к первому контроллеру и т.д. При правильной настройке многопутевого доступа мы можем сохранить доступ к СХД (а значит, избежать возможной потери данных при аварийном отключении) до тех пор, пока есть хотя бы один путь. Задетый кабель, выход из строя одного из коммутаторов, запланированное (например, для обновления прошивки) отключение отдного из контроллеров, задетый кабель — все это не приведет к отключению и простоям.

Работа с блочным устройством через MPIO обеспечивается средствами операционной системы, особенности работы зависят от конкретной ОС и используемого оборудования. Может использоваться стандартная реализация MPIO в ОС, при необходимости с использованием специальных модулей (DSM в случае Windows), учитывающих специфику работы СХД, например, существование оптимальных и неоптимальных путей для ALUA.

Алгоритм использования путей доступа определяется политиками MPIO, штатно реализованными в ОС или в сторонних DSM для Windows/Linux, PSP для VMware ESXi. Некоторые из политик, например Round Robin (циклическое переключение путей), обеспечивают балансировку нагрузки между путями. С описанием политик MPIO для Windows Server 2008R2/2012 можно ознакомиться тут.

Общие рекомендации по использованию iSCSI

Основное и важное правило: не используейте аггрегацию портов с iSCSI. Для повышения отказоустойчивости и масштабирования полосы пропускания используйте только MPIO. Для некоторых случаев есть возможность использования такой специфичной для iSCSI технологии как MCS (Multiple Connections per Session).

Gladius Storage L и Gladius Storage RTS

Различие между этими платформами заключается в том, что в Gladius Storage RTS используется RTS OS, коммерческий дистрибутив Linux от компании RisingTide Systems, разработчика LIO Target для ядра Linux. В RTS OS есть поддержка VAAI, active/passive кластеров и прочего полезного функционала. Gladius Storage L — это Fedora Linux, со свободной реализацией утилиты управления для LIO Target — targetcli, как уже упоминалось выше, для использования в качестве основной СХД не рекомендуется, только в качестве резервной или использования совместно с Veeam Backup&Replication, в роли backup repository.

LVM

Для привязывания к LUN'ам можно использовать несколько видов т.н. backstores:

• block (в RTS OS - iblock). Блочное устройство. Обеспечивает максимальную производительность.
• fileio. Обычный файл.
• pscsi. Режим проброса SCSI команд напрямую к блочному устройству. Предназначен исключительно для тестовых целей.
• ramdisk. Как и следует из названия — это рамдиск, блочное устройство, эмулироемое в ОЗУ. Можно использовать для выявления узких мест в используемых HBA или коммутаторах.

В качестве backstore удобно использовать не непосредственно блочное устройство (например, массив, презентуемый RAID контроллером), а том LVM. Прежде всего мы получаем удобный способ управления емкостью томов, во-вторых — снапшоты.

Инициализируем физический том:

[root@localhost ~]# pvcreate /dev/sdb
  Physical volume "/dev/sdb" successfully created

Создаем группу томов vg00:

[root@localhost ~]# vgcreate vg00 /dev/sdb
  Volume group "vg00" successfully created

Создаем логический том lv00 размером в 20ГиБ: lvcreate -L 20GiB vg00 -n lv00

На выходе получаем блочное устройство /dev/vg00/lv00.

targetcli

Предполагается, что у вас уже настроены два сетевых интерфейса 10.12.12.3 и 10.12.12.4.

Запускаем targetcli. Это оболочка, позволяющая управлять бэксторами, таргетами, правами и другими настройками для таргетов и LUNов. Вместо громоздкого конфигурационного файла вы работаете с наглядной древовидной структуров объектов, выводится она по команде ls:

/> ls
o- / .......................................................................................... [...]
  o- backstores ............................................................................... [...]
  | o- block ................................................................... [Storage Objects: 0]
  | o- fileio .................................................................. [Storage Objects: 0]
  | o- pscsi ................................................................... [Storage Objects: 0]
  | o- ramdisk ................................................................. [Storage Objects: 0]
  o- iscsi ............................................................................. [Targets: 0]
  o- loopback .......................................................................... [Targets: 0]
  o- vhost ............................................................................. [Targets: 0]

Все изменения сохраняются при выходе из targetcli автоматически (в RTS OS по умолчанию — только вручную, по команде saveconfig). Если сохраненная конфигурация не загружается при запуске сервера, проверьте, запущен ли сервис target, при необходимости активируйте его:

systemctl enable targetcli.service
systemctl start targetcli.service

Создаем backstore

Добавляем созданный логический том в качестве бэкстора:

/> /backstores/block create disk00 /dev/vg00/lv00
Created block storage object disk00 using /dev/vg00/lv00.

Создаем iSCSI порталы и LUNы

/> /iscsi create
Created target iqn.2003-01.org.linux-iscsi.localhost.x8664:sn.147e78151036.
Created TPG 1.

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

Создаем два портала, соответствующих двум сетевым интерфейсам:

/> /iscsi/iqn.2003-01.org.linux-iscsi.localhost.x8664:sn.147e78151036/tpg1/portals create 10.12.12.3
/> /iscsi/iqn.2003-01.org.linux-iscsi.localhost.x8664:sn.147e78151036/tpg1/portals create 10.12.12.4

Создаем LUN, привязанный к ранее созданному бэкстору:

/> /iscsi/iqn.2003-01.org.linux-iscsi.localhost.x8664:sn.147e78151036/tpg1/luns create /backstores/block/disk00

Далее правила хорошего тона предписывают задать права доступа для LUN'а, настроить CHAP, ведь повреждение данных при случайном подключении и использовании не того LUN'а — обычное дело. Для целей тестирования это можно временно пропустить:

/> /iscsi/iqn.2003-01.org.linux-iscsi.localhost.x8664:sn.147e78151036/tpg1 set attribute authentication=0 demo_mode_write_protect=0 generate_node_acls=1 cache_dynamic_acls=1

Проверяем дерево объектов:

/> ls
o- / .......................................................................................................... [...]
  o- backstores ............................................................................................... [...]
  | o- block ................................................................................... [Storage Objects: 1]
  | | o- disk00 ..................................................... [/dev/vg00/lv00 (20.0GiB) write-thru activated]
  | o- fileio .................................................................................. [Storage Objects: 0]
  | o- pscsi ................................................................................... [Storage Objects: 0]
  | o- ramdisk ................................................................................. [Storage Objects: 0]
  o- iscsi ............................................................................................. [Targets: 1]
  | o- iqn.2003-01.org.linux-iscsi.localhost.x8664:sn.147e78151036 ........................................ [TPGs: 1]
  |   o- tpg1 ................................................................................... [gen-acls, no-auth]
  |     o- acls ........................................................................................... [ACLs: 0]
  |     o- luns ........................................................................................... [LUNs: 1]
  |     | o- lun0 ................................................................... [block/disk00 (/dev/vg00/lv00)]
  |     o- portals ..................................................................................... [Portals: 2]
  |       o- 10.12.12.3:3260 ................................................................................... [OK]
  |       o- 10.12.12.4:3260 ................................................................................... [OK]
  o- loopback .......................................................................................... [Targets: 0]
  o- vhost ............................................................................................. [Targets: 0]

Мы видим, что у нас есть один LUN (lun0), привязанный к блочному бэкстору /dev/vg00/lv00. Этот LUN мы отдаем по iSCSI, у нас есть два портала в группе с адресами 10.12.12.3 и 10.12.12.4.

Устанавливаем MPIO

Предполагается, что для iSCSI настроены два сетевых интерфейса 10.12.12.1 и 10.12.12.2.

Добавляем поддержку MPIO в Windows Server и перезагружаемся:

Подключаемся к таргету

Далее нужно подключиться к таргету по одному из путей прежде чем активировать MPIO для iSCSI. Открываем свойства iSCSI-инициатора и на вкладке Discovery добавляем оба адреса порталов:

Переходим на вкладку Targets, в списке должен отображаться таргет с нашей СХД. Подключаемся к нему, отметив пункт Enable multi-path:

Статус таргета должен смениться в случае успешного подключения на Connected, LUN должен появится в Disk Manager'е:

Включаем поддержку MPIO для iSCSI

Открываем свойства MPIO. На вкладке Discover Multi-paths жмем Add support for iSCSI Drives и Add. После перезагрузки штатный инициатор iSCSI должен появится в списке устройств, работающих через MPIO:

Добавляем пути

Осталось добавить остальные пути, всего их будет 4:

• 10.12.12.1->10.12.12.3
• 10.12.12.1->10.12.12.4
• 10.12.12.2->10.12.12.3
• 10.12.12.2->10.12.12.4

Для этого просто добавляем сессии в свойствах таргета:

Список путей и назначенную политику MPIO можно видеть в свойствах устройства через свойства таргета или через Disk Manager:

Остается проверить работоспособность простым способом: запускаем нагрузку (например, через IOmeter), дергаем один из кабелей. Путей остается только два, но диск не теряется: