Превращаем старый сервер в iSCSI Target с помощью Enterprise Storage OS (ESOS)

Enterprise Storage OS (ESOS)Продолжая тему полезного использования старого серверного оборудования, на этот раз поговорим об использовании сервера модели IBM System x3200 4362 в качестве сетевого хранилища, доступного по протоколу iSCSI в качестве iSCSI Target. В прошлый раз мы уже рассматривали такой сервер в роли хранилища резервных копий виртуальных машин с программной дедупликацией от Quadstor. Однако в нашем случае ситуация усугубилась тем, что на некоторых удалённых площадках, где была развёрнута описанная конфигурация, виртуальные машины, подвергавшиеся резервному копированию, со временем получили дополнительный диск под хранение контента для точки распространения SCCM. А, как известно, содержимое дисков, которые используются под распространение контента в SCCM может временами очень активно меняться (загружаются новые обновления SUP, удаляются просроченные обновления, загружается какое-либо ПО для развёртывания и т.п.). Поэтому, учитывая то обстоятельство, что используемое ПО Veeam Backup Free Edition не позволяет исключать из резервной копии виртуальных машины отдельные виртуальные диски, принадлежащие этой ВМ, пришлось решать вопрос об увеличении дискового пространства на этих самых серверах IBM. Параллельно встал вопрос о полезности дедупликации, которая в случае часто меняющееся контента теряет свой КПД.

"Вишенкой на торте" в описанной ситуации стало то, что в сервере, который используется в нашем случае в качестве iSCSI Target (из реализации Quadstor), очень скромная дисковая корзина – всего 4 слота SAS/SATA форм-фактора 3.5", два из которых заняты под хостовую ОС Linux.

Здесь мы рассмотрим один из возможных вариантов решения совокупности описанных проблем и ограничений, который заключается в замене полноценной инсталляции ОС Linux на загружаемый с USB-накопителя и работающий в оперативной памяти специализированный Linux-дистрибутив проекта Enterprise Storage OS (ESOS). По своей сути ESOS это оптимизированное под работу в ОЗУ современное Linux-ядро с интегрированным ПО проекта SCST, пример использования которого, мы уже рассматривали ранее.

Общий план мероприятий будет выглядеть так:

  • Убираем из дисковой корзины диски малой ёмкости, на которых установлена хостовая ОС, и ставим на это место диски большей ёмкости (все диски в корзине станут одинаковой ёмкости)
  • На уровне аппаратного RAID-контроллера определяем каждый из четырёх дисков, подключённых к дисковой корзине, как самостоятельное устройство.
  • Подготавливаем загрузочный USB-накопитель с ESOS
  • Загружаем сервер с ESOS и создаём программный RAID-массив из всех дисков корзины.
  • Конфигурируем в ESOS iSCSI Target и подключаем диск на стороне сервера iSCSI Initiator
  • Настраиваем дополнительное сетевое подключение между серверами и включаем Multipath

 

Конфигурация серверов

В нашем примере будет рассмотрено построение простейшей конфигурации с использование iSCSI из двух серверов, один из которых выполняет роль цели iSCSI Target на базе ESOS v 1.3.5, а другой выполняет роль хоста-инициатора iSCSI Initiator на базе Windows Server 2012 R2. Для улучшения доступности и производительности между целью и хостом-инициатором будет организовано многопутевое подключение (multi-path). Для отделения трафика iSCSI от трафика управления серверами в каждый сервер установлен дополнительный двух-портовый сетевой адаптер.

1) Сервер под роль iSCSI Target (KOM-AD01-ESOS01)

Сервер модели IBM System x3200 4362 с дисковой корзиной на 4 диска LFF HDD SAS/SATA и дополнительно установленным сетевым адаптером HP NC380T PCI Express Dual Port Multifunction Gigabit Server Adapter (394795-B21). На этом сервере будет выполняться загружаемая с USB-накопителя система ESOS. Все 4 диска из дисковой корзины сервера будут использованы в ESOS для организации программного RAID-массива, который в свою очередь будет презентован на хост-инициатор.

2) Сервер под роль iSCSI Initiator (KOM-AD01-VM01)

Сервер модели HP ProLiant DL380 G5, выполняющий роль хоста виртуализации Hyper-V на базе ОС Windows Server 2012 R2 Standard. Помимо базовой комплектации в сервер дополнительно установлен сетевой адаптер HP NC380T PCI Express Dual Port Multifunction Gigabit Server Adapter (394795-B21). Подключаемый к данному серверу с сервера ESOS по протоколу iSCSI диск будет использоваться под задачи резервного копирования виртуальных машин Hyper-V.

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

Scheme of connections for the iSCSI

 

Конфигурация RAID-контроллера на сервере IBM

Безотносительно используемой в нашем случае модели сервера и RAID-контроллера, можно сказать, что использование дистрибутива ESOS, не требующего для своей работы выделенного диска, в любой дисковой конфигурации позволит использовать под полезный дисковый объём все ресурсы дисковой корзины. В некоторых ситуациях этот аргумент может иметь существенное значение.

В нашем примере в дисковую корзину установлено 4 одинаковых диска SATA 7200 1TB.

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

LSI Logic SAS1064ET controller device configuration

Некоторые RAID-контроллеры, например HP Smart Array, не позволяют транслировать подключённые диски, как самостоятельные дисковые устройства. В таких случаях потребуется создать отдельный том RAID-0 для каждого отдельно взятого диска. В нашем случае всё проще, так как установленный в нашем сервере контроллер LSI Logic SAS1064ET довольно примитивен и показывает все диски, как отдельные устройства, если эти диски не включены в аппаратный RAID-массив.

 

Подготовка загрузочного USB-накопителя ESOS

Загружаем последнюю актуальную версию ESOS стабильной ветки (branch 1.x.x) со страницы проекта ESOS - Package Downloads. На этой же странице можно найти описание других веток ESOS (master – разрабатываемая и 0.1.x - устаревшая).

В процессе написания этой статьи использовалась версия 1.3.5 (25.01.2018), доступная по ссылке esos-1.3.5.zip. К моменту публикации мне уже удалось поработать с более новой версией 1.3.6 (12.04.2018).

Так как ESOS, это ориентированная на ОЗУ система, запускаться она будет с подключаемого через обычный USB-порт внешнего накопителя. То есть нам потребуется USB-накопитель размером от 4GB и более. Если Вы планируете использовать ветку master branch, то для успешного обновления между версиями, согласно рекомендаций документа Upgrading, на USB-накопителе может потребоваться до 5GB дополнительного пространства. В нашем случае для ESOS успешно использовались накопители разной степени "подвальности" размером от 8GB и больше.

В документации о подготовке USB-накопителя рассматриваются варианты для Linux, Windows и MacOS. Вариант c MacOS оставим для гламурных сектантов Apple. Вариант для Windows у меня не заработал (попытка предпринималась на Windows 10, задача подготовки накопителя завершалась мутной ошибкой и в итоге загрузка с накопителя не работала). Поэтому мы остановимся на варианте подготовки накопителя на платформе Linux. 

Итак, в качестве системы, на которой выполняется подготовка загрузочного USB-накопителя ESOS, в нашем примере используется Debian GNU/Linux 9, поэтому нам предварительно потребуется поставить пакет rpm2cpio:

# apt-get install rpm2cpio

Распаковываем загруженный с сайта ESOS архив во временный каталог и запускаем скрипт подготовки накопителя:

# mkdir ~/ESOS
# cd ~/ESOS
# unzip esos-1.3.5.zip
# cd esos-1.3.5/
# ./install.sh

Скрипт выдаст список всех обнаруженных дисковых устройств. На первый заданный вопрос о выборе диска введём путь к дисковому устройству, которое ассоциировано в системе с нашим USB-накопителем. В нашем примере это /dev/sdax. Здесь важно не промахнуться и не указать какой-нибудь другой диск с полезными данными, в противном случае эти данные могут быть утеряны.

Перед форматированием накопителя нас переспросят о наших намерениях. Вводим yes

ESOS installation

Всё содержимое накопителя будет удалено и на него будет записан загружаемый раздел. По окончании процесса, скрипт предложит нам либо нажать Enter для добавления утилит управления аппаратными RAID-контроллерами (поддерживаются инструменты, упомянутые в Supported Hardware), либо завершить процедуру подготовки накопителя, нажав Ctrl+C. В нашем случае будет использоваться программный RAID-массив, поддержка которого уже заложена в ESOS, поэтому мы жмём Ctrl+C.

 

Первая загрузка ESOS и первичная настройка

Устанавливаем подготовленный ранее накопитель в USB порт нашего сервера IBM, а в настройках BIOS сервера включаем загрузку с этого накопителя.

Дожидаемся успешного окончания первой загрузки ESOS. Первая загрузка может занять 5-10 минут, так как в её ходе на накопителе выполняется ряд первичных служебных процедур. Последующие загрузки ESOS с этого же накопителя будут проходить значительно быстрей.

Описание процедур первичной настройки ESOS можно найти в документе Initial System Configuration

Учётные данные, используемые по умолчанию:

  • Имя пользователя: root
  • Пароль: esos

ESOS login

При входе в систему автоматически запускается специальная оболочка Text-based User Interface (TUI), максимально упрощающая работу с системой. В верхней области TUI имеется основное функциональное меню, которое позволяет выполнять все основные задачи по конфигурации сервера в качестве хранилища для сетей SAN.

ESOS TUI

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

Переходим в пункты меню System > Change Password и задаём новый пароль для пользователя root.

ESOS change password

Затем перейдём в System > Network Settings и выберем пункт настройки основных параметров сети General Network Settings

ESOS General Network Settings

В открывшейся форме укажем имя хоста, имя DNS-домена, IP адрес шлюза по умолчанию и адреса DNS-серверов. ESOS Hostname

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

ESOS restart networking

Снова вернёмся в System > Network Settings, выберем сетевой адаптер, который будет использоваться для удалённого управления ESOS и настроим параметры IP. В нашем примере используется статическая конфигурация и интерфейсу управления ESOS задан IP адрес 10.1.2.201/24. Маску сети и адрес широковещания, как я понял, указывать обязательно, иначе при сохранении настроек могут возникать ошибки.

ESOS Network Interface configuration

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

ESOS Network Restart

Сеть будет перезапущена и, в случае успешного применения заданных настроек, у нас появится возможность удалённого подключения к ESOS по протоколу SSH.

В рамках этой заметки, мы пропускаем прочие настройки, имеющиеся в ESOS, такие как настройка времени, конфигурация отсылки почты, управление дополнительными пользователями и т.д. Вместо этого мы сосредоточимся лишь на тех моментах, которые имеют значение в контексте нашей задачи. Тем не менее, прежде чем подключаться к нашему серверу ESOS по протоколу SSH, мне хочется сделать маленькое косметическое отступление относительно цветовой схемы TUI.

В интерфейсе TUI ESOS есть две цветовых схемы – стандартная светлая, выдержанная в голубых и бирюзовых тонах, что на скриншотах выше, и альтернативная - тёмная, выдержанная в лучших традициях "подземелья со свечкой". Ни тот ни другой вариант, на мой взгляд, удачными не являются, так как при удалённом подключении к консоли сервера при пониженной цветопередаче (например при подключении через функцию Remote Control в IBM RSA), в некоторых местах TUI наблюдается эффект сливающегося с фоном текста. А если подключаться к TUI ESOS SSH-клиентом PuTTy с Windows-системы, то стандартные цветовые схемы вообще превращаются, на мой взгляд, во что-то "кислотное".

Так как работать с ESOS мы будем в основном конечно же с использованием удалённого SSH подключения, то, в частности, для клиента PuTTy есть простое решение – использование настраиваемых цветовых схем на стороне SSH-клиента на любой вкус и цвет. Примеры такой настройки мы рассматривали ранее в заметке Пара приёмов работы с TUI через PuTTy. Далее, для работы с ESOS через SSH мы будем использовать схему PuTTy – Twilight.

 

Создание программного RAID-массива в ESOS

Завершив первичную базовую настройку ESOS, переходим к конфигурации дисковой системы сервера. Выполним создание программного RAID-массива (реализовано на базе Linux Software RAID/mdraid) из 4 имеющихся в нашем распоряжении дисков. Для этого перейдём в меню Software RAID > Add Array

ESOS Software RAID - Add Array

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

ESOS Software RAID - Add Array

Выбрав диски нажмём Enter. Откроется экран настройки RAID-массива. Присвоим массиву имя в традициях mdraid, например md0. Выберем уровень RAID (в нашем случае это RAID5) и размер блока. В нашем случае массив собирается под задачи резервного копирования больших файлов дисков виртуальных машин, поэтому размер блока мы выбрали самый большой.

ESOS Software RAID - Add Array

После нажатия кнопки OK будет запущена процедура инициализации RAID-массива. Переходим в меню навигации в Software RAID > Linux MD Status и проверяем статус созданного RAID-массива.

ESOS Software RAID - Array Status

Здесь мы можем дождаться полного завершения построения RAID-массива, либо можно продолжить настройку нашего сервера, так как фактически дисковая ёмкость массива нам уже доступна.

 

Конфигурация iSCSI Target

Чтобы созданную нами дисковую ёмкость RAID-массива можно было презентовать на хост виртуализации по сети по протоколу iSCSI, на сервере ESOS нужно создать iSCSI Target. Для этого а меню навигации перейдём в Targets > Add iSCSI Target. В форме создания цели укажем имя iSCSI Qualified Name (IQN).

ESOS Targets - Add iSCSI Target

В нашем случае использовано предлагаемое по умолчанию имя в формате iqn.2018-03.esos.<имя сервера>:.Единственное, что я изменил в имени – убрал двоеточие в конце имени. 

После сохранения информация о цели iSCSI Target появится на главном экране ESOS, но данная цель будет находится в выключенном состоянии.

ESOS Targets

Чтобы активировать цель, перейдём в меню навигации в Targets > Enable/Disable Target, из списка целей выберем только что созданную нами цель и поменяем в её свойствах Disabled на Enabled.

ESOS Targets - Enable iSCSI Target

Убедимся в том, что на главном экране TUI информация о состоянии цели изменилась.

ESOS Targets - iSCSI Target

Далее нам нужно описать дисковое устройство, которое будет транслироваться через созданную цель iSCSI Target. Для этого меню навигации перейдём в Devices > Add Device

ESOS Devices - Add Device

Из перечня режимов трансляции устройств, описание которых можно найти в документе 36_Devices_and_Mappings - SCST I/O Modes, выбираем интересующий нас режим. В нашем примере используется режим vdisk_blockio, который обеспечивает прямой доступ к блочным устройствам и исключает использование промежуточных механизмов кеширования Linux.

ESOS Devices - SCST Device Handler

После выбора режима откроется окно выбора возможных для этого режима блочных устройств. Выбираем наш RAID-массив.

ESOS Devices - SCST Device - Block Device

После этого откроется форма настройки параметров SCST для виртуального блочного устройства vdisk_blockio. Укажем любое короткое и понятное нам имя устройства. Это имя будет в дальнейшем отображаться на стороне хоста виртуализации, выполняющего роль iSCSI Initiator, в диспетчере устройств. Поэтому в качестве имени я использовал сокращённое имя хоста и RAID-устройства - ESOS01-MD0. Остальные параметры можно оставить в значениях по умолчанию.

ESOS Devices - SCST Device

Сохраняем настройки виртуального блочного устройства и переходим к описанию хостов, которым разрешено подключаться к созданной нами цели iSCSI Target. Но прежде чем описать хосты, необходимо создать группу хостов. Переходим в меню Hosts > Add Group

ESOS Hosts - Add Group

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

ESOS Hosts - Add Group

Задаём любое имя группы хостов, например Group1, и жмём Enter

ESOS Hosts - Add Group

Итак, группа хостов создана и привязана к цели iSCSI Target. Теперь нам нужно описать каждый хост, который будет выступать в качестве iSCSI Initiator с назначением этого хоста на созданную группу хостов. В нашем случае такой хост будет всего один – наш хост виртуализации Hyper-V на базе ОС Windows Server 2012 R2.

Прежде чем добавить в ESOS хост-инициатор, выясним его имя Initiator Name на нашем хосте виртуализации. Найти (и при желании изменить) это имя можно в Панели управления Windows Server, вызвав апплет iSCSI Initiator и открыв вкладку Configuration

Windows Server IQN

Как видим, в нашем случае имя хоста-инициатора - iqn.1991-05.com.microsoft:kom-ad01-vm01.holding.com.

Возвращаемся в TUI ESOS и добавляем хост-инициатор в меню Hosts > Add Initiator

ESOS Hosts - Add Initiator

При этом нас спросят к какой цели SCST Target относится добавляемый хост. Выбираем единственную ранее созданную и включённую нами цель. ESOS Hosts - Add Initiator for Target

Затем выбираем созданную ранее группу хостов, к которой будет привязан добавляемый хост-инициатор.

ESOS Hosts - Add Initiator for Group

И наконец вводим IQN хоста-инициатора, которое мы выяснили ранее, и жмём Enter

ESOS Hosts - Add Initiator IQN

Итак, на данном этапе в ESOS мы уже имеем созданную цель SCST (в нашем случае iSCSI Target), имеем виртуальное блочное устройство SCST (транслируется программный RAID-массив), нами описана группа хостов и к этой группе привязан хост-инициатор (iSCSI Initiator). Теперь нам только остаётся примапить виртуальное блочное устройство SCST к группе хостов.  Для этого переходим в меню навигации в Devices > Map to Host Group.

ESOS Devices - Map to Host Group Выбираем виртуальное блочное устройство SCST.

ESOS Devices - Map to Host Group

Выбираем цель SCST.

ESOS Devices - Map to Host Group

Выбираем группу хостов, в которую был включен хост-инициатор.

ESOS Devices - Map to Host Group

Далее откроется форма настройки LUN-а, который будет транслироваться в сеть. Укажем номер LUN-а (по умолчанию первому транслируемому LUN-у присваивается номер 0) и сохраним настройки, нажав ОК.

ESOS Devices - Mapping SCST device

Посмотреть итоговую конфигурацию трансляции виртуальных устройств SCST можем перейдя в меню Devices > LUN/Group Layout

ESOS Devices - LUN Group Layout

ESOS Devices - LUN Group Layout

Теперь определимся с отделением сетевого трафика iSCSI от трафика управления самим сервером ESOS. Сделаем так, чтобы полностью разделить эти виды трафика по разным сетевым интерфейсам.

Для этого настроим на стороне сервера ESOS и на стороне клиента iSCSI Initiator отдельные сетевые интерфейсы с IP-адресацией отличной от адресации, используемой для управления серверами. Например, в нашем случае для управления серверами используется сеть 10.1.2.0/24, поэтому для отделения трафика iSCSI мы используем небольшую выделенную подсеть на 6 хостов - 192.168.168.0/29 (на уровне сетевого оборудования дополнительно можно изолировать данную сеть в отдельный VLAN).

Сначала настроим выделенный под iSCSI сетевой интерфейс на стороне сервера ESOS, перейдя в меню навигации в System > Network Settings и выбрав соответствующий сетевой адаптер.

ESOS System - Network Settings

Зададим на этом интерфейсе статический IP-адрес 192.168.168.1/29, укажем маску подсети, адрес широковещания и увеличенный размер MTU 9000 (технология Jumbo Frame должна поддерживаться сетевым адаптером) для улучшения производительности при передаче больших объёмов данных.

ESOS System - Network Settings - Interface

При сохранении настроек на вопрос о перезагрузке сети ответим утвердительно (все сетевые соединения с ESOS будут временно потеряны).

ESOS Restart networking

По завершению процедуры перезагрузки сети мы получим сводную информацию о статусе применения новых настроек

ESOS Restart networking

Теперь переходим к настройке на стороне хоста-инициатора.

 

Конфигурация iSCSI Initiator

На стороне нашего хоста виртуализации на базе Windows Server, на который мы будем принимать по протоколу iSCSI дисковую ёмкость с сервера ESOS, настроим выделенный сетевой адаптер для использования в работе с протоколом iSCSI.

Отключим все, кроме того что может потребоваться нам на этом выделенном интерфейсе при работе с iSCSI. Например, оставим только поддержку протокола TCP/IPv4 и QoS.

Windows Server iSCSI network interface settings

Выбрав протокол TCP/IPv4 по кнопке Properties зададим IP-адрес из сети, которую мы определили под трафик iSCSI, например 192.168.168.3/29. Адрес шлюза по умолчанию и DNS-серверов оставляем пустыми. Откроем расширенные настройки кнопкой Advanced.

Windows Server iSCSI network interface settings

На вкладке DNS отключим включённую по умолчанию опцию регистрации в DNS, а на вкладке WINS отключим поддержку LMHOST и NetBIOS over TCP/IP.

Windows Server iSCSI network interface settings

Вернёмся на основную вкладку свойств сетевого интерфейса и вызовем диалог настройки параметров сетевого адаптера по кнопке Configure.

Windows Server iSCSI network interface settings

В открывшейся форме на вкладке расширенных настроек Advanced найдём опцию поддержки больших пакетов Jumbo Packet и выберем максимально возможное значение (в нашем примере это 9014). На вкладке Power Management отключим возможность отключения системой данного сетевого адаптера в режимах энергосбережения – Allow the computer to turn off this device to save mode.

Windows Server iSCSI network interface settings

Закроем все окна с сохранением кнопкой ОК.

Теперь проверим доступность сервера ESOS через выделенный сетевой интерфейс. Сначала утилитой tracert, чтобы убедиться в том, что маршрутизация трафика идёт между серверами напрямую.

tracert -d 192.168.168.1

Затем с помощью утилиты ping, включив флаг запрета фрагментации (опция -f) и указав размер передаваемых пакетов (опция -l)

ping 192.168.168.1 -f -l 8000

Windows Server iSCSI network check ping

В случае если где-то, например на коммутаторе, к которому подключены серверы ESOS и наш хост-инициатор, не включена поддержка Jumbo Frame, мы можем получить сообщения "Packet needs to be fragmented but DF set." В нашем случае проверка прошла успешно, поэтому можно переходить к процедуре подключения iSCSI диска.

Перейдём в Панель управления Windows Server, вызовем апплет iSCSI Initiator и открыв вкладку Discovery нажмём кнопку Discover Portal. В окне настроек обнаружения укажем IP адрес сервера ESOS из сети для трафика iSCSI и нажмём кнопку Advanced.

Windows Server iSCSI Initiator Discovery

В форме расширенных настроек обнаружения в качестве локального адаптера выберем Microsoft iSCSI Initiator и настроенный ранее IP адрес из сети для трафика iSCSI – 192.168.168.3. Сохраним настройки, нажимая OK до тех пор, пока не вернёмся в главное окно апплета.

Windows Server iSCSI Initiator DiscoveryПосле этого перейдём на вкладку Targets, где в разделе Discovered targets должен появится ранее упомянутый IQN нашего сервера ESOS со статусом Inactive. То есть система его обнаружила, но он пока не подключен. Для того, чтобы произвести подключение к iSCSI Target воспользуемся кнопкой Connect.

Windows Server iSCSI Initiator Discovery Targets

В открывшемся окне подключения обратим внимание на то, чтобы был включен признак добавления подключаемой цели в список избранных целей - Add this connection to the list of Favorite Targets (для последующего автоматического подключения к цели в случае перезагрузки сервера). Нажмём кнопку Advanced.

Windows Server iSCSI Initiator Discovery

В форме расширенных настроек подключения явно укажем сетевые интерфейсы из сети для трафика iSCSI, которые должны быть задействованы для передачи iSCSI трафика для данного сессионного подключения. То есть в качестве Initiator IP выберем из списка адрес выделенного на нашем хосте iSCSI-интерфейса 192.168.168.3, а в качестве Target portal IP выберем из списка адрес выделенного на сервере ESOS iSCSI-интерфейса - 192.168.168.1.

Windows Server iSCSI Initiator Discovery Target

Закроем с сохранением окна Advanced Settings и Connect to Target и удостоверимся в том, что статус подключения изменился на Connected

Windows Server iSCSI Initiator connected to Target

Заглянем на вкладку Favorite Targets и убедимся в том, что подключенная цель попала в список избранных.

Windows Server iSCSI Initiator - Favorite Targets

Убедимся в том, что в консоли управления “Диспетчер устройств”/Device Manager (devmgmt.msc) в разделе Disk drives появился дополнительный SCSI-диск с именем, которое ранее мы определяли на сервере ESOS для виртуального блочного устройства SCST.

Следующим шагом нам нужно выполнить инициализацию подключенного по протоколу iSCSI диска. Для этого перейдём в консоль управления дисками Disk Management (diskmgmt.msc), выберем соответствующий диск и переведём его в состояние Online.

Windows Server iSCSI - Device Manager

После того как диск успешно изменит свой статус, проведём инициализацию диска и отформатируем его “по вкусу”, например в файловую систему NTFS, задав любую понятную нам метку тома. С этого момента в графическом интерфейсе Windows данный диск станет нам доступен для стандартных файловых операций.

Windows Server iSCSI Disk

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

ESOS Sessions

На этом основную настройку простейшей конфигурацией iSCSI можно считать законченной.

 

Простейшая проверка производительности

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

Полагаться на цифры, которые при копировании больших файлов с локального диска сервера на iSCSI диск показывает нам проводник Windows особо не стоит, так как объективной информации мы там не увидим. Например, в моём случае при копировании нескольких больших ISO-файлов (с разным содержимым) скорость обозначилась в районе 150-160 MB/s, что отличается в большую строну от реальной допустимой скорости iSCSI-линка между двумя моими серверами в 1Gbit/s (~ 125MB/s). К тому же более или менее похожая на правду скорость отображается при копировании первого файла, а при копировании последующих файлов она несколько увеличивается (возможно включается в работу кеш файловой системы и прочие другие кеши разных уровней).

Windows Server iSCSI perfomance testing by Explorer

Для разного рода замеров всегда хочется использовать какие-то “родные” инструменты, не требующие установки дополнительного ПО, но к сожалению это далеко не всегда возможно. В клиентских системах Windows для оценки производительности разных подсистем, в том числе и дисковой, используется утилита WinSAT (winsat disk), однако в составе Windows Server 2012 R2 этой утилиты я не обнаружил. Поэтому
я скопировал с имеющейся по рукой клиентской ОС Windows 10 x64 два файла - WinSAT.exe и WinSATAPI.dll из каталога %windir%\System32 в аналогичный каталог сервера. Теперь можно попробовать воспользоваться этой утилитой, запустив её из командной строки с правами администратора.

winsat disk -drive T -count 3

Здесь после ключевого слова disk в опции –drive указывается имя буквы диска, который мы желаем протестировать, а в опции –count указывается количество циклов тестирования.

Windows Server iSCSI perfomance testing by WinSAT

Как я понял, данная утилита не позволяет проводить тестирование оперируя большими блоками данных (более 1MB), то есть она больше подходит для тестирования ситуаций с большим количеством мелких файлов. У нас же ситуация обратная – резервное копирование дисков виртуальных машин предполагают малое количество файлов существенного размера.

Ещё одним простым инструментом является утилита Diskspd (DiskSpd: A Robust Storage Performance Tool), пришедшая на замену утилите SQLIO Disk Subsystem Benchmark Tool (SQLIO). Скачиваем утилиту, распаковываем на сервере и запускаем с набором параметров, отвечающим контексту нашей задачи.

cd /d C:\Tools\Diskspd-v2.0.17\amd64fre\
Diskspd.exe -d60 -b1M -s -w100 -t1 -c100G T:\io1.dat T:\io2.dat

Используемые нами параметры означают:
-d60 : Время выполнения теста 60 секунд
-b1M : Оперировать блоками по 1MB
-s  : Выполнять операции с последовательным доступом
-w100 : Выполнять полный тест на запись (тест на чтение не выполняется)
-t1 : Количество потоков работы с целью (с файлом T:\io.dat)
-c100G : Создавать файлы размером 100GB
В конце перечислены имена генерируемых для теста файлов.

Немного отклоняясь, отмечу, что на момент написания статьи для задачи резервного копирования виртуальных машин Hyper-V у нас используется ПО Veeam Backup & Replication, поэтому при выборе размера блока для проведения тестов я буду отталкиваться от специфики этого ПО. Как я понял из документа Data Compression and Deduplication, VBR в операциях резервного копирования на SAN использует блоки по 1024MB, поэму именно такой размер блока мы и будем использовать при тестировании.

Windows Server iSCSI perfomance testing via Diskspd

Для сравнения проведём ещё раз тест с тем же набором условий, но увеличим его продолжительность до 5 минут

Diskspd.exe -d300 -b1M -s -w100 -t1 -c100G T:\io1.dat T:\io2.dat

Windows Server iSCSI perfomance testing via Diskspd

Здесь хорошо видно, что при длительной нагрузке показатели заметно проседают. Могу предположить, что связано это с тем что “бутылочное горлышко” в этом случае перемещается из области сетевой подсистемы в область медленных дисков, используемых у нас на стороне сервера ESOS.

Для любителей графических инструментов для проведения подобных поверхностных тестов производительности дисковой подсистемы на Windows может пригодиться ещё одна простая бесплатная утилита ATTO Disk Benchmark. Загрузить её можно по ссылке: Disk Benchmark. Интерфейс утилиты прост и понятен и комментировать по ней, пожалуй, нечего.

Windows Server iSCSI perfomance testing via ATTO Disk Benchmark

О каких-то более сложных инструментах тестирования, как например IOMeter, я не говорю, так как в рамках нашей задачи нет цели заниматься бенчмарками как таковыми. А показатели простых инструментов получаются лишь для того, чтобы иметь базу для сравнения в дальнейшем, когда между сервером ESOS и хостом Hyper-V у нас будет не один линк, как на данном этапе настройки, а два линка и задействованный механизм Multipath.

 

Настройка Multipath

Итак, мы имеем подключенный по iSCSI диск и некие базовые показатели тестов производительности, от которых можем отталкиваться. Теперь попробуем улучшить эти показатели, добавив на сервер ESOS и хост-инициатор ещё по одному гигабитному сетевому адаптеру и объединив их работу с помощью механизма Multipath на стороне хоста-инициатора.

Начнём с настройки сервера ESOS. В главном меню навигации перейдём в System > Network Settings, выберем дополнительный сетевой адаптер, который будет использоваться для ещё одного подключения по протоколу iSCSI и настроим параметры IP. В нашем примере используется статическая конфигурация и дополнительному iSCSI-интерфейсу ESOS задан IP адрес 192.168.168.2/29, а также дополнительно увеличен размер MTU.

ESOS Network Interface settings

Сохраняем настройки сети в ESOS и переходим к настройке дополнительного сетевого адаптера на стороне хоста-инициатора, то есть нашего сервера на базе Windows Server с iSCSI Initiator.

Настраиваем по аналогии с первым второй iSCSI-интерфейс, задав ему IP 192.168.168.4/29

Windows Server iSCSI network interface settings

Отключим ранее настроенный интерфейс c адресом 192.168.168.3 (iSCSI диск при этом у нас отвалится) и убедимся в том, что дополнительно настроенные iSCSI-интерфейсы сервера ESOS и хоста-инициатора видят друг друга.

Windows Server iSCSI testing via ping

В апплете Панели управления iSCSI Initiator на вкладке Discovery добавим дополнительный путь обнаружения, указав связку 192.168.168.2 - 192.168.168.4

Windows Server iSCSI Initiator Discovery

Так как ранее мы создали iSCSI подключение к цели без включённого признака multi-path, то теперь нам будет правильней деактивировать это подключение и создать его заново, но уже с включенным признаком multi-path.

Сначала удалим созданное ранее подключение из автозагрузки на вкладке Favorite Targets

Windows Server iSCSI Initiator - Remove Target

Теперь перейдём на вкладку Targets и выполним отключение (инициализированный и подключенный в системе iSCSI диск при этом исчезнет из Windows)

Windows Server iSCSI Initiator - Disconnect Target

Затем выполним повторное подключение цели iSCSI, но на этот раз уже с включённой опцией Enable multi-path (и не забываем по кнопке Advanced произвести явную связку интерфейсов 192.168.168.1 - 192.168.168.3)

Windows Server iSCSI Initiator - Add Target with multi-path

Убедившись в том, что цель снова перешла в состояние Connected откроем её свойства, чтобы добавить второе подключение по дополнительному выделенному интерфейсу

Windows Server iSCSI Initiator - Target properties

На вкладке Targets зайдём по кнопке Properties в свойства подключенной цели, и воспользуемся кнопкой Add session, чтобы настроить второе подключение.

Windows Server iSCSI Initiator - Target sessions

Кстати, здесь по кнопке MCS мы сможем убедится в том, что первая установленная сессия действительно использует заданный нами выделенный сетевой интерфейс.

Итак, используя кнопку Add session добавим дополнительное подключение к iSCSI Target указав в качестве интерфейсов дополнительную пару интерфейсов, которую мы настроили ранее (192.168.168.2 - 192.168.168.4)

Windows Server iSCSI Initiator - Add Target with multi-path

Теперь в списке сессий должна появиться запись о второй сессии.

Windows Server iSCSI Initiator - Target multi-path sessions

Также созданную дополнительную сессию мы увидим и на стороне сервер ESOS.

ESOS Sessions

На стороне хоста-инициатора заглянем в оснастку “Диспетчер устройств”/Device Manager (devmgmt.msc) и убедимся в том, что в разделе Disk drives появился дополнительный SCSI-диск с тем же именем (ESOS01-MD0).

Windows Server iSCSI Initiator - multi-path disk

То есть сейчас, на стороне Windows-сервера мы фактически видим один и тот же диск, как два отдельных устройства. Чтобы система смогла работать с этим диском, как с единым устройством, используя оба сетевых линка iSCSI до сервера ESOS, нам потребуется включить поддержку MPIO для iSCSI. Для этого переходим в Панель управления Windows, открываем апплет MPIO и на вкладке Discover Multi-Paths включаем опцию Add support for iSCSI devices. После этого нажимаем кнопку Add и утвердительно отвечаем на вопрос о перезагрузке сервера.

Windows Server - Enable MPIO for iSCSI

После перезагрузки снова заглянем в консоль Device Manager и убедимся в том, что теперь наш iSCSI диск отображается, как единое устройство и имеет имени …Multi-Path Disk Device . Откроем свойства диска и на вкладке MPIO проверим то, что диск доступен по двум путям.

Windows Server iSCSI Initiator - multi-path disk

Более подробную информацию о маршрутах подключения можем увидеть в апплете панели управления iSCSI Initiator.

Windows Server iSCSI Initiator - Devices and MPIO

Здесь по кнопке MPIO мы увидим информацию об используемых подключениях.

Windows Server iSCSI Initiator - multi-path sessions

На этом базовую настройку Multipath можно считать законченной.

Теперь для того, чтобы оценить изменения в скорости работы с iSCSI-диском, которые мы получили в результате организации второго линка и настройки Multipath проведем простой тест линейной записи больших файлов на диск по аналогии с тем, что делали ранее:

Diskspd.exe -d60 -b1M -s -w100 -t1 -c100G T:\io1.dat T:\io2.dat

Windows Server iSCSI test perfomance with MPIO via Diskspd

Судя по тому, что нам показывает Diskspd в данном случае, в среднем в каждый из файлов запись прошла со скоростью ~225MB/s, что равно 1800Mb/s. То есть в итоге мы получаем скорость приближенную к суммарной пропускной способности двух организованных линков iSCSI.

Тот же тест, но более продолжительный по времени (5 минут):

Diskspd.exe -d300 -b1M -s -w100 -t1 -c100G T:\io1.dat T:\io2.dat

Windows Server iSCSI test perfomance with MPIO via Diskspd

Средняя величина в ~48.5 MB/s, полученная при работе с каждым файлом, выглядит ощутимо лучше, чем полученные ранее 16 MB/s на одном линке iSCSI.

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

 

Горячая замена USB-накопителя ESOS

Учитывая то, что собирая бюджетное решение, описанное в рамках нашего примера, мы могли использовать дешёвые USB-накопители, в некоторых случаях может возникнуть потребность в замене этого накопителя (например при его выходе из строя). Учитывая то, что ESOS это Linux-система полностью адаптированная к работе в оперативной памяти, замена USB-накопителя является очень простой операцией, корректная обработка которой реализована разработчиком этой системы.

Фактически выполняется замена накопителя в несколько простых действий:

  • На уже загруженной и работающей системе ESOS в любой момент времени извлекаем USB-накопитель (накопитель, который нужно заменить), с которого эта система была загружена.
  • Подготавливаем новый USB-накопитель с ESOS стандартным методом, описанным выше в разделе “Подготовка загрузочного USB-накопителя ESOS”, и устанавливаем этот накопитель в работающий сервер ESOS.
  • Вызываем процедуру синхронизации работающей в оперативной памяти конфигурации ESOS с файловой системой на USB-накопителе. Пункт меню System > Sync Configuration

ESOS Sync configuration to new USB-drive

ESOS Sync configuration to new USB-drive

После этого желательно перезагрузить сервер и убедиться в том, что с нового USB-накопителя система запускается успешно. В процессе первой загрузки с заменённого USB-накопителя ESOS выполнит некоторые служебные процедуры и уже буквально через несколько минут сервер будет готов к работе, подгрузив ранее настроенную нами конфигурацию.

Судя по описанию документа 13_Upgrading, точно таким же нехитрым образом выполняется обновление сервера ESOS на более новую версию, что существенно облегчает обслуживание такой системы.

 

Заключение

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

Всего комментариев: 9 Комментировать

  1. AlektroNik /

    Алексей, спасибо за очередную детальную статью.
    Есть несколько вопросов (возможно я что-то упустил):
    1. Есть меню "Hardware RAID", почему Вы выбрали именно "Software RAID"? У Вас же есть железка для рейда.
    2. Умеет ли данная сборка NFS? Я не нашел упоминания ни в тексте ни на скринах.
    3. Если нет ни NFS, ни дедуплекации, ни других фишек кроме установки на флешку, что в принципе и другие умеют, то в чем же тогда ее "Enterprise"???

    Еще раз спасибо за труды. Это единственный сайт, на который я подписан и всегда читаю по тематике ИТ :).

    1. Алексей Максимов / Автор записи

      Здравствуйте, AlektroNik.

      1. Контроллер в моём сервере IBM (SAS1064ET) слишком примитивен. Он умеет только либо страйп, либо зеркало. Мне нужен RAID5. К тому же mdraid позволяет использовать ресурсы системы под кэши RAID-массива. В общем mdraid в моей ситуации самое годное решение.
      2. О том, что вообще ESOS умеет, лучше почитать на сайте проекта. Я не ставил себе задачи рассказать о его прелестях, а лишь пошагово описал вариант решения отдельно взятой задачи с помощью этой системы. Говоря конкретно о NFS, как я понимаю, он у них в Roadmap
      3. NFS есть в других свободно распространяемых продуктах. Никто не говорит про то, что ESOS это какой-то универсальный солдат. На мой взгляд, одну из своих задач - упрощённое управление SCST, продукт выполняет вполне хорошо. Дедупликация это вообще отдельная и очень ресурсоёмкая тема. На 4GB ОЗУ, что является минимумом для ESOS, такое вероятней всего просто не организовать. А о том, почему продукт назван именно так наверно лучше спросить того, кто его так назвал.

  2. Dan Yasny /

    Красивые интерфейсы это чудесно, но если бы я строил сервер для роли iscsi target, я бы взял CentOS7.5 с VDO, и стандартный LIO (а не SCST как многие используют).

    Так будет и нарезка лунов, и pooling и дедупликация и поддержка scsi-3-pr

    1. Алексей Максимов / Автор записи

      C LIO связываться после моего опыта построения на нём FC Target (мы как-то с Вами переписывались на эту тему в Facebook) желания больше не возникает. Особенно учитывая тот факт, что их "саппорт" мне так ничего и не ответил. Это глухая стена. Как iSCSI Target, возможно, LIO и годен, не могу ничего сказать по этому поводу. В своё время перечитал массу холиваров на тему LIO vs SCST. SCST немного более сложен в настройке, на мой взгляд, но он по расхожему мнению эффективней потребляет ресурсы и более стабилен в работе. К тому же разработчики SCST на вопросы в мейл-листе отвечают и оказывают помощь. Поэтому не удивительно, что многие используют SCST.

      CentOS это конечно хорошо, но у меня в первую очередь задача стояла - избавиться от хостовой ОС, работающей на дисках, чтобы освободить слоты корзины. VDO выглядит интересно, но вроде бы он совсем свежий и вступать в ряды бета-тестеров как-то не очень хочется :)

      1. Dan Yasny /

        несколько нюансов:
        1. LIO да и вообще обычная ОС как FC таргет это дикая импровизация которую я вообще нигде не видел за 25 лет карьеры. Так что я очень сомневаюсь что такой вариант особо сильно тестируется и кого либо интересует
        2. Насчет потребления ресурсов не знаю, но знаю что SCST популярен у производителей appliance-образных дистров просто потому что мнго легаси кода на него заточено и менять они не хотят.
        3. VDO это совсем не новая технология, а недавно открытый код который до сих пор был проприетарным (RH купили фирму которая этим занималась до сих пор), и основа VDO работает в продакшене по всему миру.

        Вообще, если в RHEL ввели что либо не как tech preview а именно как поддерживаемую технологию, там все уже оттестировано по полной.

        1. Алексей Максимов / Автор записи

          "все уже оттестировано по полной"... Дмитрий, я прямо ждал, когда Вы это скажете :)
          Так и вспоминается история, когда, прочитав в документации к RHEL про нововведение NIC Teaming, бросился его разворачивать в режиме LACP и поняв, что перестроение тима в случае отказа одного из интерфейсов приводит к провалам в несколько секунд, поплевался, и вернулся обратно на LACP Bonding.

          1. Dan Yasny /

            тиминг был взят из ядерных наработок в апстриме, а VDO это открытый код Permabit Albireo, выпущенный еще в 2010 в проприетарном виде, и используемый в Dell EMC, Hitachi Data Systems, IBM, NEC и NetApp. В 2016 они начали предлагать этот стек и для линуксов, а не только для больших SAN, и год спустя RH их перекупили со всеми технологиями и разработчиками. Так что системя эта разрабатывается и тестируется уже 8 лет, из которых 2 года в полном продакшене конкретно на линуксах

          2. Алексей Максимов / Автор записи

            Понятно. Тогда буду присматриваться по мере возможности к VDO. Спасибо за информацию.

  3. Андрей /

    Надеюсь сервер из которого делается СХД на поддержке, т.к. делать СХД из старой железяки в продуктиве это мягко говоря "смело"

Добавить комментарий