Продолжая тему полезного использования старого серверного оборудования, на этот раз поговорим об использовании сервера модели IBM System x3200 4362 в качестве сетевого хранилища, доступного по протоколу iSCSI в качестве iSCSI Target . В мы уже рассматривали такой сервер в роли хранилища резервных копий виртуальных машин с программной дедупликацией от Quadstor . Однако в нашем случае ситуация усугубилась тем, что на некоторых удалённых площадках, где была развёрнута , виртуальные машины, подвергавшиеся резервному копированию, со временем получили дополнительный диск под хранение контента для точки распространения SCCM . А, как известно, содержимое дисков, которые используются под распространение контента в SCCM может временами очень активно меняться (загружаются новые обновления , удаляются просроченные обновления, загружается какое-либо ПО для развёртывания и т.п.). Поэтому, учитывая то обстоятельство, что используемое ПО Veeam Backup Free Edition не позволяет исключать из резервной копии виртуальных машины отдельные виртуальные диски, принадлежащие этой ВМ, пришлось решать вопрос об увеличении дискового пространства на этих самых серверах IBM. Параллельно встал вопрос о полезности дедупликации, которая в случае часто меняющееся контента теряет свой КПД.
"Вишенкой на торте" в описанной ситуации стало то, что в сервере, который используется в нашем случае в качестве iSCSI Target (из реализации Quadstor), очень скромная дисковая корзина – всего 4 слота SAS/SATA форм-фактора 3.5", два из которых заняты под хостовую ОС Linux.
Здесь мы рассмотрим один из возможных вариантов решения совокупности описанных проблем и ограничений, который заключается в замене полноценной инсталляции ОС Linux на загружаемый с USB-накопителя и работающий в оперативной памяти специализированный Linux-дистрибутив проекта Enterprise Storage OS (ESOS ). По своей сути ESOS это оптимизированное под работу в ОЗУ современное Linux-ядро с интегрированным ПО проекта , пример использования которого, мы уже .
Общий план мероприятий будет выглядеть так:
- Убираем из дисковой корзины диски малой ёмкости, на которых установлена хостовая ОС, и ставим на это место диски большей ёмкости (все диски в корзине станут одинаковой ёмкости)
- На уровне аппаратного 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.
Простейшая схема подключения сетевых интерфейсов серверов будет выглядеть следующим образом:
Конфигурация RAID-контроллера на сервере IBM
Безотносительно используемой в нашем случае модели сервера и RAID-контроллера, можно сказать, что использование дистрибутива ESOS, не требующего для своей работы выделенного диска, в любой дисковой конфигурации позволит использовать под полезный дисковый объём все ресурсы дисковой корзины. В некоторых ситуациях этот аргумент может иметь существенное значение.
В нашем примере в дисковую корзину установлено 4 одинаковых диска SATA 7200 1TB.
Для того, чтобы отвязать себя от весьма скромных возможностей аппаратного RAID-контроллера, которым оснащён наш сервер, и в дальнейшем воспользоваться возможностями построения программного RAID-массива на базе ESOS, нам потребуется, чтобы для ESOS каждый диск выглядел, как отдельное физическое устройство. Поэтому во встроенной утилите управления RAID-контроллером удаляем все имеющиеся логические RAID-диски, чтобы каждый диск был представлен как отдельное устройство.
Некоторые 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 и больше.
Учётные данные, используемые по умолчанию:
- Имя пользователя: root
- Пароль: esos
При входе в систему автоматически запускается специальная оболочка Text-based User Interface (TUI ), максимально упрощающая работу с системой. В верхней области TUI имеется основное функциональное меню, которое позволяет выполнять все основные задачи по конфигурации сервера в качестве хранилища для сетей SAN.
Первоочередными задачами начальной настройки являются смена стандартного пароля пользователя root и настройка сети, для возможности удалённой работы с системой.
Переходим в пункты меню System > Change Password и задаём новый пароль для пользователя root .
Затем перейдём в System > Network Settings и выберем пункт настройки основных параметров сети General Network Settings
В открывшейся форме укажем имя хоста, имя DNS-домена, IP адрес шлюза по умолчанию и адреса DNS-серверов.
После изменения сетевых настроек, ESOS будет предлагать перезагрузку службы сети, для вступления внесённых изменения в силу. Пока мы не произвели всех минимальных настроек сети, можем отказаться от рестарта службы сети.
Снова вернёмся в System > Network Settings , выберем сетевой адаптер, который будет использоваться для удалённого управления ESOS и настроим параметры IP. В нашем примере используется статическая конфигурация и интерфейсу управления ESOS задан IP адрес 10.1.2.201/24 . Маску сети и адрес широковещания, как я понял, указывать обязательно, иначе при сохранении настроек могут возникать ошибки.
После сохранения сделанных изменений мы снова получим вопрос о перезагрузке сети. Теперь на этот вопрос ответим утвердительно.
Сеть будет перезапущена и, в случае успешного применения заданных настроек, у нас появится возможность удалённого подключения к ESOS по протоколу SSH.
В рамках этой заметки, мы пропускаем прочие настройки, имеющиеся в ESOS, такие как настройка времени, конфигурация отсылки почты, управление дополнительными пользователями и т.д. Вместо этого мы сосредоточимся лишь на тех моментах, которые имеют значение в контексте нашей задачи. Тем не менее, прежде чем подключаться к нашему серверу ESOS по протоколу SSH, мне хочется сделать маленькое косметическое отступление относительно цветовой схемы TUI.
В интерфейсе TUI ESOS есть две цветовых схемы – стандартная светлая, выдержанная в голубых и бирюзовых тонах, что на скриншотах выше, и альтернативная - тёмная, выдержанная в лучших традициях "подземелья со свечкой". Ни тот ни другой вариант, на мой взгляд, удачными не являются, так как при удалённом подключении к консоли сервера при пониженной цветопередаче (например при подключении через функцию ), в некоторых местах TUI наблюдается эффект сливающегося с фоном текста. А если подключаться к TUI ESOS SSH-клиентом PuTTy с Windows-системы, то стандартные цветовые схемы вообще превращаются, на мой взгляд, во что-то "кислотное".
Так как работать с ESOS мы будем в основном конечно же с использованием удалённого SSH подключения, то, в частности, для клиента PuTTy есть простое решение – использование настраиваемых цветовых схем на стороне SSH-клиента на любой вкус и цвет. Примеры такой настройки мы рассматривали ранее в заметке . Далее, для работы с ESOS через SSH мы будем использовать схему PuTTy – Twilight .
Создание программного RAID-массива в ESOS
Завершив первичную базовую настройку ESOS, переходим к конфигурации дисковой системы сервера. Выполним создание программного RAID-массива (реализовано на базе Linux Software RAID /mdraid ) из 4 имеющихся в нашем распоряжении дисков. Для этого перейдём в меню Software RAID > Add Array
В перечне доступных для включения в программный RAID блочных устройств отметим диски, из которых будем создавать RAID-массив.
Выбрав диски нажмём Enter . Откроется экран настройки RAID-массива. Присвоим массиву имя в традициях mdraid , например md0 . Выберем уровень RAID (в нашем случае это RAID5) и размер блока. В нашем случае массив собирается под задачи резервного копирования больших файлов дисков виртуальных машин, поэтому размер блока мы выбрали самый большой.
После нажатия кнопки OK будет запущена процедура инициализации RAID-массива. Переходим в меню навигации в Software RAID > Linux MD Status и проверяем статус созданного RAID-массива.
Здесь мы можем дождаться полного завершения построения RAID-массива, либо можно продолжить настройку нашего сервера, так как фактически дисковая ёмкость массива нам уже доступна.
Конфигурация iSCSI Target
Чтобы созданную нами дисковую ёмкость RAID-массива можно было презентовать на хост виртуализации по сети по протоколу iSCSI, на сервере ESOS нужно создать iSCSI Target . Для этого а меню навигации перейдём в Targets > Add iSCSI Target . В форме создания цели укажем имя iSCSI Qualified Name (IQN ).
В нашем случае использовано предлагаемое по умолчанию имя в формате iqn.2018-03.esos.<имя сервера>: .Единственное, что я изменил в имени – убрал двоеточие в конце имени.
После сохранения информация о цели iSCSI Target появится на главном экране ESOS, но данная цель будет находится в выключенном состоянии.
Чтобы активировать цель, перейдём в меню навигации в Targets > Enable /Disable Target , из списка целей выберем только что созданную нами цель и поменяем в её свойствах Disabled на Enabled .
Убедимся в том, что на главном экране TUI информация о состоянии цели изменилась.
Из перечня режимов трансляции устройств, описание которых можно найти в документе 36_Devices_and_Mappings - SCST I/O Modes , выбираем интересующий нас режим. В нашем примере используется режим vdisk_blockio , который обеспечивает прямой доступ к блочным устройствам и исключает использование промежуточных механизмов кеширования Linux.
После выбора режима откроется окно выбора возможных для этого режима блочных устройств. Выбираем наш RAID-массив.
После этого откроется форма настройки параметров SCST для виртуального блочного устройства vdisk_blockio . Укажем любое короткое и понятное нам имя устройства. Это имя будет в дальнейшем отображаться на стороне хоста виртуализации, выполняющего роль iSCSI Initiator, в диспетчере устройств. Поэтому в качестве имени я использовал сокращённое имя хоста и RAID-устройства - ESOS01-MD0 . Остальные параметры можно оставить в значениях по умолчанию.
Сохраняем настройки виртуального блочного устройства и переходим к описанию хостов, которым разрешено подключаться к созданной нами цели iSCSI Target. Но прежде чем описать хосты, необходимо создать группу хостов. Переходим в меню Hosts > Add Group
Выбираем ранее созданную нами цель iSCSI Target, к которой будет относится создаваемая группа хостов.
Задаём любое имя группы хостов, например Group1 , и жмём Enter
Итак, группа хостов создана и привязана к цели iSCSI Target. Теперь нам нужно описать каждый хост, который будет выступать в качестве iSCSI Initiator с назначением этого хоста на созданную группу хостов. В нашем случае такой хост будет всего один – наш хост виртуализации Hyper-V на базе ОС Windows Server 2012 R2 .
Прежде чем добавить в ESOS хост-инициатор, выясним его имя Initiator Name на нашем хосте виртуализации. Найти (и при желании изменить) это имя можно в Панели управления Windows Server, вызвав апплет iSCSI Initiator и открыв вкладку Configuration
Как видим, в нашем случае имя хоста-инициатора - iqn.1991-05.com.microsoft:kom-ad01-vm01.holding.com .
Возвращаемся в TUI ESOS и добавляем хост-инициатор в меню Hosts > Add Initiator
При этом нас спросят к какой цели SCST Target относится добавляемый хост. Выбираем единственную ранее созданную и включённую нами цель.
Затем выбираем созданную ранее группу хостов, к которой будет привязан добавляемый хост-инициатор.
И наконец вводим IQN хоста-инициатора, которое мы выяснили ранее, и жмём Enter
Итак, на данном этапе в ESOS мы уже имеем созданную цель SCST (в нашем случае iSCSI Target), имеем виртуальное блочное устройство SCST (транслируется программный RAID-массив), нами описана группа хостов и к этой группе привязан хост-инициатор (iSCSI Initiator). Теперь нам только остаётся примапить виртуальное блочное устройство SCST к группе хостов. Для этого переходим в меню навигации в Devices > Map to Host Group .
Выбираем виртуальное блочное устройство SCST.
Выбираем цель SCST.
Выбираем группу хостов, в которую был включен хост-инициатор.
Далее откроется форма настройки LUN -а, который будет транслироваться в сеть. Укажем номер LUN-а (по умолчанию первому транслируемому LUN-у присваивается номер 0 ) и сохраним настройки, нажав ОК .
Посмотреть итоговую конфигурацию трансляции виртуальных устройств SCST можем перейдя в меню 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 и выбрав соответствующий сетевой адаптер.
Зададим на этом интерфейсе статический IP-адрес 192.168.168.1/29 , укажем маску подсети, адрес широковещания и увеличенный размер MTU – 9000 (технология Jumbo Frame должна поддерживаться сетевым адаптером) для улучшения производительности при передаче больших объёмов данных.
При сохранении настроек на вопрос о перезагрузке сети ответим утвердительно (все сетевые соединения с ESOS будут временно потеряны).
По завершению процедуры перезагрузки сети мы получим сводную информацию о статусе применения новых настроек
Теперь переходим к настройке на стороне хоста-инициатора.
Конфигурация iSCSI Initiator
На стороне нашего хоста виртуализации на базе Windows Server, на который мы будем принимать по протоколу iSCSI дисковую ёмкость с сервера ESOS, настроим выделенный сетевой адаптер для использования в работе с протоколом iSCSI.
Отключим все, кроме того что может потребоваться нам на этом выделенном интерфейсе при работе с iSCSI. Например, оставим только поддержку протокола TCP /IPv4 и QoS .
Выбрав протокол TCP /IPv4 по кнопке Properties зададим IP-адрес из сети, которую мы определили под трафик iSCSI, например 192.168.168.3/29 . Адрес шлюза по умолчанию и DNS-серверов оставляем пустыми. Откроем расширенные настройки кнопкой Advanced .
На вкладке DNS отключим включённую по умолчанию опцию регистрации в DNS, а на вкладке WINS отключим поддержку LMHOST и NetBIOS over TCP /IP .
Вернёмся на основную вкладку свойств сетевого интерфейса и вызовем диалог настройки параметров сетевого адаптера по кнопке Configure .
В открывшейся форме на вкладке расширенных настроек Advanced найдём опцию поддержки больших пакетов Jumbo Packet и выберем максимально возможное значение (в нашем примере это 9014 ). На вкладке Power Management отключим возможность отключения системой данного сетевого адаптера в режимах энергосбережения – Allow the computer to turn off this device to save mode .
Закроем все окна с сохранением кнопкой ОК .
Теперь проверим доступность сервера ESOS через выделенный сетевой интерфейс. Сначала утилитой tracert , чтобы убедиться в том, что маршрутизация трафика идёт между серверами напрямую.
tracert -d 192.168.168.1Затем с помощью утилиты ping , включив флаг запрета фрагментации (опция -f ) и указав размер передаваемых пакетов (опция -l )
ping 192.168.168.1 -f -l 8000
В случае если где-то, например на коммутаторе, к которому подключены серверы ESOS и наш хост-инициатор, не включена поддержка Jumbo Frame , мы можем получить сообщения "Packet needs to be fragmented but DF set. " В нашем случае проверка прошла успешно, поэтому можно переходить к процедуре подключения iSCSI диска.
Перейдём в Панель управления Windows Server, вызовем апплет iSCSI Initiator и открыв вкладку Discovery нажмём кнопку Discover Portal . В окне настроек обнаружения укажем IP адрес сервера ESOS из сети для трафика iSCSI и нажмём кнопку Advanced .
В форме расширенных настроек обнаружения в качестве локального адаптера выберем Microsoft iSCSI Initiator и настроенный ранее IP адрес из сети для трафика iSCSI – 192.168.168.3 . Сохраним настройки, нажимая OK до тех пор, пока не вернёмся в главное окно апплета.
После этого перейдём на вкладку Targets
, где в разделе Discovered targets
должен появится ранее упомянутый IQN
нашего сервера ESOS со статусом Inactive
. То есть система его обнаружила, но он пока не подключен. Для того, чтобы произвести подключение к iSCSI Target воспользуемся кнопкой Connect
.
В открывшемся окне подключения обратим внимание на то, чтобы был включен признак добавления подключаемой цели в список избранных целей - Add this connection to the list of Favorite Targets (для последующего автоматического подключения к цели в случае перезагрузки сервера). Нажмём кнопку Advanced .
В форме расширенных настроек подключения явно укажем сетевые интерфейсы из сети для трафика iSCSI, которые должны быть задействованы для передачи iSCSI трафика для данного сессионного подключения. То есть в качестве Initiator IP выберем из списка адрес выделенного на нашем хосте iSCSI-интерфейса 192.168.168.3 , а в качестве Target portal IP выберем из списка адрес выделенного на сервере ESOS iSCSI-интерфейса - 192.168.168.1 .
Закроем с сохранением окна Advanced Settings и Connect to Target и удостоверимся в том, что статус подключения изменился на Connected
Заглянем на вкладку Favorite Targets и убедимся в том, что подключенная цель попала в список избранных.
Убедимся в том, что в консоли управления “Диспетчер устройств”/Device Manager (devmgmt.msc ) в разделе Disk drives появился дополнительный SCSI-диск с именем, которое ранее мы определяли на сервере ESOS для виртуального блочного устройства SCST.
Следующим шагом нам нужно выполнить инициализацию подключенного по протоколу iSCSI диска. Для этого перейдём в консоль управления дисками Disk Management (diskmgmt.msc ), выберем соответствующий диск и переведём его в состояние Online .
После того как диск успешно изменит свой статус, проведём инициализацию диска и отформатируем его “по вкусу”, например в файловую систему NTFS, задав любую понятную нам метку тома. С этого момента в графическом интерфейсе Windows данный диск станет нам доступен для стандартных файловых операций.
На данном этапе, если мы заглянем в консоль сервера ESOS, то увидим в нижней части TUI информацию о сессии подключения хоста-инициатора.
На этом основную настройку простейшей конфигурацией iSCSI можно считать законченной.
Простейшая проверка производительности
После подключения диска по iSCSI желательно провести хотя бы какие-то нехитрые замеры производительности, чтобы понимать то, что у нас получилось в конечном итоге и то, чего можно ожидать от такого диска.
Полагаться на цифры, которые при копировании больших файлов с локального диска сервера на iSCSI диск показывает нам проводник Windows особо не стоит, так как объективной информации мы там не увидим. Например, в моём случае при копировании нескольких больших ISO-файлов (с разным содержимым) скорость обозначилась в районе 150-160 MB/s, что отличается в большую строну от реальной допустимой скорости iSCSI-линка между двумя моими серверами в 1Gbit/s (~ 125MB/s). К тому же более или менее похожая на правду скорость отображается при копировании первого файла, а при копировании последующих файлов она несколько увеличивается (возможно включается в работу кеш файловой системы и прочие другие кеши разных уровней).
Для разного рода замеров всегда хочется использовать какие-то “родные” инструменты, не требующие установки дополнительного ПО, но к сожалению это далеко не всегда возможно. В клиентских системах Windows для оценки производительности разных подсистем, в том числе и дисковой, используется утилита WinSAT
(winsat disk
), однако в составе Windows Server 2012 R2 этой утилиты я не обнаружил. Поэтому
я скопировал с имеющейся по рукой клиентской ОС Windows 10 x64 два файла - WinSAT.exe и WinSATAPI.dll из каталога %windir%\System32 в аналогичный каталог сервера. Теперь можно попробовать воспользоваться этой утилитой, запустив её из командной строки с правами администратора.
Здесь после ключевого слова disk в опции –drive указывается имя буквы диска, который мы желаем протестировать, а в опции –count указывается количество циклов тестирования.
Как я понял, данная утилита не позволяет проводить тестирование оперируя большими блоками данных (более 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, поэму именно такой размер блока мы и будем использовать при тестировании.
Для сравнения проведём ещё раз тест с тем же набором условий, но увеличим его продолжительность до 5 минут
Здесь хорошо видно, что при длительной нагрузке показатели заметно проседают. Могу предположить, что связано это с тем что “бутылочное горлышко” в этом случае перемещается из области сетевой подсистемы в область медленных дисков, используемых у нас на стороне сервера ESOS.
Для любителей графических инструментов для проведения подобных поверхностных тестов производительности дисковой подсистемы на Windows может пригодиться ещё одна простая бесплатная утилита ATTO Disk Benchmark . Загрузить её можно по ссылке: 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 и переходим к настройке дополнительного сетевого адаптера на стороне хоста-инициатора, то есть нашего сервера на базе Windows Server с iSCSI Initiator.
Настраиваем по аналогии с первым второй iSCSI-интерфейс, задав ему IP 192.168.168.4/29
Отключим ранее настроенный интерфейс c адресом 192.168.168.3 (iSCSI диск при этом у нас отвалится) и убедимся в том, что дополнительно настроенные iSCSI-интерфейсы сервера ESOS и хоста-инициатора видят друг друга.
В апплете Панели управления iSCSI Initiator на вкладке Discovery добавим дополнительный путь обнаружения, указав связку 192.168.168.2 - 192.168.168.4
Так как ранее мы создали iSCSI подключение к цели без включённого признака multi-path , то теперь нам будет правильней деактивировать это подключение и создать его заново, но уже с включенным признаком multi-path .
Сначала удалим созданное ранее подключение из автозагрузки на вкладке Favorite Targets
Теперь перейдём на вкладку Targets и выполним отключение (инициализированный и подключенный в системе iSCSI диск при этом исчезнет из Windows)
Затем выполним повторное подключение цели iSCSI, но на этот раз уже с включённой опцией Enable multi-path (и не забываем по кнопке Advanced произвести явную связку интерфейсов 192.168.168.1 - 192.168.168.3 )
Убедившись в том, что цель снова перешла в состояние Connected откроем её свойства, чтобы добавить второе подключение по дополнительному выделенному интерфейсу
На вкладке Targets зайдём по кнопке Properties в свойства подключенной цели, и воспользуемся кнопкой Add session , чтобы настроить второе подключение.
Кстати, здесь по кнопке MCS мы сможем убедится в том, что первая установленная сессия действительно использует заданный нами выделенный сетевой интерфейс.
Итак, используя кнопку Add session добавим дополнительное подключение к iSCSI Target указав в качестве интерфейсов дополнительную пару интерфейсов, которую мы настроили ранее (192.168.168.2 - 192.168.168.4 )
Теперь в списке сессий должна появиться запись о второй сессии.
Также созданную дополнительную сессию мы увидим и на стороне сервер ESOS.
На стороне хоста-инициатора заглянем в оснастку “Диспетчер устройств”/Device Manager (devmgmt.msc ) и убедимся в том, что в разделе Disk drives появился дополнительный SCSI-диск с тем же именем (ESOS01-MD0 ).
То есть сейчас, на стороне Windows-сервера мы фактически видим один и тот же диск, как два отдельных устройства. Чтобы система смогла работать с этим диском, как с единым устройством, используя оба сетевых линка iSCSI до сервера ESOS, нам потребуется включить поддержку MPIO для iSCSI . Для этого переходим в Панель управления Windows, открываем апплет MPIO и на вкладке Discover Multi-Paths включаем опцию Add support for iSCSI devices . После этого нажимаем кнопку Add и утвердительно отвечаем на вопрос о перезагрузке сервера.
После перезагрузки снова заглянем в консоль Device Manager и убедимся в том, что теперь наш iSCSI диск отображается, как единое устройство и имеет имени …Multi-Path Disk Device . Откроем свойства диска и на вкладке MPIO проверим то, что диск доступен по двум путям.
Более подробную информацию о маршрутах подключения можем увидеть в апплете панели управления iSCSI Initiator .
Здесь по кнопке MPIO мы увидим информацию об используемых подключениях.
На этом базовую настройку Multipath можно считать законченной.
Теперь для того, чтобы оценить изменения в скорости работы с iSCSI-диском, которые мы получили в результате организации второго линка и настройки Multipath проведем простой тест линейной записи больших файлов на диск по аналогии с тем, что делали ранее:
Diskspd.exe -d60 -b1M -s -w100 -t1 -c100G T:\io1.dat T:\io2.dat
Судя по тому, что нам показывает Diskspd в данном случае, в среднем в каждый из файлов запись прошла со скоростью ~225MB/s, что равно 1800Mb/s. То есть в итоге мы получаем скорость приближенную к суммарной пропускной способности двух организованных линков iSCSI.
Тот же тест, но более продолжительный по времени (5 минут):
Diskspd.exe -d300 -b1M -s -w100 -t1 -c100G T:\io1.dat T:\io2.dat
Средняя величина в ~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
После этого желательно перезагрузить сервер и убедиться в том, что с нового USB-накопителя система запускается успешно. В процессе первой загрузки с заменённого USB-накопителя ESOS выполнит некоторые служебные процедуры и уже буквально через несколько минут сервер будет готов к работе, подгрузив ранее настроенную нами конфигурацию.
Судя по описанию документа 13_Upgrading , точно таким же нехитрым образом выполняется обновление сервера ESOS на более новую версию, что существенно облегчает обслуживание такой системы.
Заключение
В заключении хочу сказать, что в нашем примере, благодаря системе ESOS, нам удалось выжать максимум из дисковой корзины устаревшего во всех отношениях сервера и получить на хосте виртуализации вполне сносную по производительности дисковую ёмкость под задачу резервного копирования виртуальных машин. И мне остаётся только поблагодарить разработчика ESOS за проделанный труд и пожелать проекту дальнейшего успешного развития.
По прошествии пяти лет работы с сетями хранения данных Fibre Channel (SAN), я был сильно озадачен появлением iSCSI: тем, что делает этот протокол и, что более важно, как он работает и как можно использовать iSCSI для решения реальных проблем пользователей. Итак, после нескольких напряженных месяцев общения со многими специалистами по этой теме, я представляю в этой статье несколько собственных взглядов на iSCSI.
Что же такое, на самом деле, iSCSI?
iSCSI посылает SCSI команды в IP пакетах. Более подробно - iSCSI создан как протокол для инициатора хранилищ (обычно сервер), с целью посылать SCSI команды исполнителю (обычно лента или диск) через IP.Иные протоколы: FCIP - посылает блоки Fibre Channel через IP, по существу расширяя соединения Fibre Channel; на самом деле не имеет никакого отношения к SCSI. С другой стороны iFCP - обеспечивает преобразование (mapping) FCP (последовательный SCSI через Fibre Channel) в и из IP. Другими словами, он предлагает протокол маршрутизации между сетями Fibre Channel (fabric), позволяющий осуществлять соединение через IP.
Иначе говоря, iSCSI - это протокол SCSI через IP, связывающий сервер с хранилищем данных. Другие протоколы обеспечивают соединение Fibre Channel - Fibre Channel с различной степенью интеллектуальности.
Каким образом устройства iSCSI находят друг друга?
В случае обычных SCSI соединений и петель Fibre Channel, способ обнаружения устройств достаточно примитивен. Для сетей Fibre Channel (fabric) существует необходимый сервис, называемый сервер простых доменных имен (Simple Name Server), или просто - сервер доменных имен, работающий с сотнями или тысячами устройств. Но в IP, теоретически, может быть несколько миллионов устройств.В настоящее время в мире IP используется два механизма обнаружения устройств iSCSI. Первый - SLP (service locator protocol) - протокол семейства TCP/IP, позволяющий осуществлять автоматическую настройку различных ресурсов. Этот протокол обнаружения сервисов уже существует в мире IP некоторое время. Однако недавно многие производители, включая Microsoft, стали разрабатывать новый протокол -- Internet Simple Name Server. Попросту говоря, за основу были приняты принципы сервера простых доменных имен для Fibre Channel и затем увеличены до той степени, которая позволяет справляться с размерами IP сетей, в то же время не теряя особенностей работы с хранилищами, в отличие от SLP.
Как можно использовать iSCSI?
Существует три основных способа использования iSCSI:- Специализированный iSCSI сервер, обращающийся к специализированному iSCSI хранилищу.
- Специализированный iSCSI сервер, обращающийся к хранилищу, подсоединенному к Fibre Channel, через маршрутизатор iSCSI-to-Fibre Channel.
- Fibre Channel сервер, обращающийся к iSCSI хранилищу через маршрутизатор Fibre-Channel-to-iSCSI.
Итак, что наиболее вероятно и/или практично для использования? Для ответа на этот вопрос, нужно немного отступить назад и вспомнить, что сетевое хранение данных требует гибкости, использования продуктов различным образом. Сегодня, использование iSCSI в серверах - сравнительно ново, но просто, с учетом поддержки Microsoft для Windows Server 2000 и 2003.
По этой причине, одним из способов использования iSCSI является использование iSCSI серверов, присоединенных к существующему хранилищу Fibre Channel через маршрутизатор iSCSI-to-Fibre Channel, вероятнее всего в Fibre Channel SAN. Это означает, что те же порты тех же массивов хранения могут обеспечивать сервис по хранению данных как для серверов Fibre Channel, так и для серверов iSCSI. Посему это позволяет вам получить больше преимуществ от использования хранилищ SAN и Fibre Channel, чем вы имеете, и вы можете сделать это прямой сейчас - рынок предлагает все необходимые продукты.
По моим предположениям подобные события произойдут и на рынке NAS, на самом деле они уже происходят. Поскольку NAS устройства уже подключают диски к IP-сетям, разделяя сервисы через сетевую файловую систему (NFS) и/или общий протокол доступа к файлам интернет (CIFS), то для NAS достаточно просто передавать данные на уровне блока через те же порты с помощью iSCSI, что опять позволяет вам использовать существующие решения хранения данных по-новому.
Есть еще несколько иных - интересных и нестандартных решений, дожидающихся появления специализированного исключительно на iSCSI хранилища, которые могут отлично работать на новом месте, где еще не проводилась консолидация хранилищ, и существуют только продукты одного решения.
Кто будет использовать iSCSI?
Как эксперт, проработавший несколько лет в области Fibre Channel, я, к сожалению, должен указать миру Fibre Channel, что iSCSI может работать на скорости физического соединения (wire speed) и определенно может работать так же быстро, как и любой нормальный сервер, выполняющий задачи любого нормального приложения. Для IP сообщества необходимо отметить значительную распространенность Fibre Channel, особенно сравнивая их количество с количеством 1 Гб сетевых портов, нежели с количеством остальных сетевых портов. Сообществу Fibre Channel необходимо отметить, что, несмотря на то, что множество хранилищ и даже значительное количество мощных серверов подключены к Fibre Channel, существует некоторое количество неподключенных Unix серверов и огромное количество Intel серверов, не работающих с Fibre Channel.Итак, iSCSI может работать на каждого, но, возможно, наиболее большой потенциальный рынок представляют собой серверы Intel, а также высокоплотные и сверхтонкие серверы (Intel или иные). Кроме того, iSCSI иногда может быть использован для высокопроизводительных серверов, в случае удаленых офисов для обращения к центральному центру данных через SAN и в иных случаях, где пока еще рано использовать Fibre Channel, в конце концов, существует еще много неподключенных к сети серверов и хранилищ данных.
NIC, TOE и HBA: В каких случаях их нужно использовать?
В заключение, существует три подхода к подключению сервера:- Стандартная интерфейсная карта (NIC) с драйвером iSCSI
- TOE (TCP Offload Engine - механизмы разгрузки TCP) NIC с драйвером iSCSI
- Адаптеры шины узла HBA (Host Bus Adapter), созданные для iSCSI традиционными производителями Fibre Channel адаптеров.
Ключевой момент здесь состоит в том, что в отличие от Fibre Channel адаптеров, ценовые рамки iSCSI варьируются от низкой (бесплатно) до высокой производительности (акселераторы) и таким образом могут быть подобраны в соответствие с требованиями приложений. Также нагрузочная способность по выходу (fan-out или oversubscription) позволяет использовать более экономичные порты Ethernet (как быстрые, так и GE) вместо портов специализированных FC коммутаторов, что еще более снижает издержки. С картами iSCSI TOE, стоимостью 300 долларов или меньше, издержки присоединения к хосту значительно ниже, чем с FC, даже для производительности TOE.
Поскольку FC может работать на 2Gbps, использование Fibre Channel более предпочтительно для высокопроизводительных серверов (2 Гб Ethernet не существует), хотя, честно говоря, не много существует серверов, использующих такую пропускную способность, даже на Fibre Channel. Безусловно, с точки зрения хранилищ использование 2Gbps более вероятно до тех пор, пока мы не увидели 10 Гб FC или даже 10 Гб Ethernet/iSCSI портов. iSCSI открывает двери для сотен и тысяч серверов, особенно систем Intel, многие из которых могут быть менее требовательными, и огромное количество которых еще только будет приносить выгоды от использования сетевого хранения.
Только время покажет, что именно случится, хотя в одном можно быть уверенным - это будет очень интересный год для сетевого хранения и для iSCSI.
Пишу в первую очередь для себя, но если кому то будет полезным тоже хорошо.
Задача, организовать теневое копирование на файлообменном сервере, объем раздела 1Тб. Для создания теневых копий, необходим еще один раздел минимум в 1Тб, но это нужно выискивать средства, покупать жесткие диски в стойку, в общем не быстро, а нужно уже вчера. Есть сетевое хранилище Netgear ReadyNAS с RAID-5 на борту и кучей свободного места. Нюанс лишь в том, что в для создания теневых копий нужен именно локальный том, а не сетевой диск. И тут нам на помощь приходит iSCSI , что это такое я описывать не буду, кому надо прочитают в википедии , да и кому надо думаю и так знают, что это. В двух словах протокол позволяет сетевой диск сделать локальным томом.
Итак для начала, заходим в админку ReadyNAS и на вкладке iSCSI жмем Создать новый LUN
Стоит обратить внимание на параметр Предоставление
вариант Thick - толстый, выделит сразу весь объем для LUN, вариант Thin - тонкий, будет выделять по мере заполнения. Первый вариант быстрее, второй удобнее, но решать вам.
После того как мы создали LUN, на той же вкладке жмем Создать новую группу
. Задаем имя группы и целевой ресурс.
Небольшее отступление
Идентификатор IQN - это специальное имя формата iqn. . :
, которое является уникальным для каждого iSCSI-устройства в сети хранения данных. Где:
year-mo
- год регистрации доменного имени;
reversed_domain_name
-доменное имя, записанное наоборот;
unique_name
- уникальное имя устройства, например таргет здесь будет содержать указанное вами имя, а инициатор имя хоста.
Чтобы узнать имя целевого ресурса, переместимся на сервер к которому ходим подключить диск. Далее Панель управления - Инициатор iSCSI
. В появившемся окне переходим на вкладку Конфигурация
и копируем от туда имя инициатора.
Возвращаемся и заполняем поле. После этого заходим в свойства группы, жмем на плюсик, чтобы создать инициатора, далее вводим имя инициатора, которое мы копировали, чуть раньше, чтобы составить имя целевого ресурса.
В поле пароль вводим пароль, по которому будет авторизоваться Инициатор iSCSI
. Жмем создать и устанавливаем галку разрешить
.
Снова возвращаемся к серверу-инициатору, переходим на вкладку Обнаружение
, жмем обнаружить портал, в появившемся поле записываем адрес нашего ReadyNAS.
В том же окне(где вводим адрес), жмем Дополнительно на вкладке Общие вводим Имя из предыдущего шага и Секрет - это пароль из предыдущего шага.
На той же вкладке можно выбрать адаптер с помощью которого происходит подключение, адрес инициатора и адрес конечного портала (у меня он серый, потому что делал скриншот на уже настроенной системе, у вас он будет активным).
После того как мы настроили портал и авторизацию на вкладке Конечные объекты
можно будет увидеть наш LUN, жмем Подключить
, если он еще не подключен и переходим на вкладку Тома и устройства
.
Нажимаем там Автонастройка и наш LUN добавляется в качестве локального тома. Все можно переходить в Управление дисками и настраивать его как Вам угодно.
Инструментарий для построения сетей хранения данных сам по себе достаточно обширный. Однако некоторые стандарты и технологии снискали большую популярность. Вслед за Fibre Channel вторым по популярности протоколом является iSCSI.
Общая информация о iSCSI
iSCSI – первые буквы от словосочетания Internet Small Computer System Interface . Иногда это буквосочетание расшифровывают как Internet SCSI или IP SCSI, и, несмотря на то что такие интерпретации не полностью совпадают с первоначальной, они вполне имеют право на жизнь, так как весьма точно описывают суть iSCSI – протокол из стека TCP/IP для подключения внешних сетевых систем хранения данных в режиме блочного доступа.
Как уже было сказано выше, в основу метода заложена трансляция команд SCSI посредством IP-сети. В процессе работы используются порты TCP/IP, по умолчанию 860 и 3260. В принципе iSCSI – это своего рода транспорт вроде эскалатора для переамещения SCSI-инструкций и данных через внешнее сетевое подключение. Конечная реализация представляет собой среду для эмуляции локальной шины SCSI посредством внешней сети Ethernet и т.д.
В отличие от многих других протоколов (FCIP , FCoE и так далее), являющихся, по сути, ответвлением от Fibre Channel, протокол iSCSI является независимой реализацией и представляет собой разработанный с нуля стандарт для работы через TCP/IP.
iSCSi target и iSCSi initiator
Для организации любой сети хранения данных требуется три составляющие: система хранения данных, клиентская часть и среда передачи данных. В случае iSCSI для описания первых двух составляющих применяются термины «target » и «initiator » соответственно.
Target, или целевое устройство , – проще говоря, основа системы хранения, может иметь программную реализацию в чистом виде, программно-аппаратную и полностью аппаратную.
Initiator – модуль, чаще всего программа, реже аппаратное решение со своим firmware, позволяющее создавать (инициировать) соединение и обеспечивающее нужный функционал на стороне клиента – передачу SCSI-команд и данных по IP-сети.
Адресация iSCSI target
Для осуществления успешной безошибочной работы системы хранения, подключенные к сети, обязаны иметь уникальный сетевой адрес. Например, сети хранения данных на базе протокола Fibre Channel используют специальные адреса WWWN. SAN на основе iSCSI также имеют свою собственную систему адресации IQN (iSCSI Qualified Name ).
Каждый такой адрес является уникальным идентификатором, служащим для точного определения устройств хранения. Как же достигается подобная уникальность? Рассмотрим формат IQN.
Допустим, у нас имеется iSCSI target с адресом: iqn.2017– 02.com.example:storage:diskarrays-sn-a9786410.
Что это означает при более подробном рассмотрении:
> iqn
– префикс, указывающий на принадлежность адреса к формату IQN.
>
Далее следует указатель даты вида «yyyy-mm» («год-месяц»), чаще всего указывают дату создания таргета. > Зарезервированное доменное имя, чаще всего вендора оборудования.
>
После двоеточия следует собственно уникальный ID iSCSI target.
Эта система является довольно удобным решением. Прочитав IQN, можно легко получить дополнительную информацию о времени создания, типе оборудования и/или вендоре.
Примечание. По аналогии с Fibre Channel служба iSNS (Internet Storage Name Service ) позволяет управлять, в том числе, и сетями iSCSI. Это дает возможность использовать iSNS в роли единой централизованной точки входа для работы SAN.
Варианты реализации iSCSI target
Программная реализация
В качестве примера программной реализации можно привести программный продукт StarWind iSCSI Target Software , который обеспечивает реализацию iSCSI target на обычных серверах под управлением операционных систем семейства MS Windows. Достаточно только установить программу, провести небольшие настройки, и готово блочное хранилище начального уровня для подключения к другому серверу.
Аппаратная реализация
В качестве аппаратной реализации можно представить специализированные устройства, например от компании HP – HP P2000 MSA , со специальной прошивкой, специализированными интерфейсами со специальным чипом и Firmware, которые берут на себя большую часть функций обработки трафика.
Программно-аппаратная реализация
Это своего рода компромиссное решение – например, обычный сервер на базе платформы Intel x86_64 , но со специализированными сетевыми адаптерами (TOE) и адаптированной операционной системой, к примеру NexentaStor , позволяющей организовать iSCSI target , что называется, «сразу из коробки».
Что такое iSCSI HBA?
Иногда можно встретить устойчивое выражение iSCSI HBA (Host Bus Adapter) . В действительности речь идет о специальных аппаратных сетевых модулях, позволяющих разгрузить процессор, передав часть функционала сетевому адаптеру.
Разделяют два типа таких устройств:
> TCP Offload Engines
, сокращенно TOE. Данные устройства можно встретить там, где необходимо увеличить производительность и одновременно снизить нагрузку на общую систему (процессор и так далее). Данное устройство способно взять на себя только операции по поддержке TC/IP, но не способно использовать все остальные возможности по увеличению производительности iSCSI-систем.
> Full offload iSCSI HBA представляет собой комплексное решение, включающее в себя передачу выполнения функций по поддержке TCP/IP и iSCSI на данное устройство. Это считается лучшим выбором по обеспечению производительности, но стоит, разумеется, дороже, чем TOE.
Впрочем, что больше подходит для того или иного конкретного случая, лучше определять практическими тестами. Примечание. Многие современные сетевые адаптеры 10 Gigabit Ethernet включают в себя поддержку протокола iSCSI. Поэтому при выборе сетевого адаптера для построения iSCSI SAN следует ориентироваться не только на цену комплектующих, но и на дополнительный функционал. Соответствующие характеристики стоит уточнить на сайте производителя оборудования.
Различия File Extent и Device Extent
Помимо систем передачи трафика, существуют различные подходы при сохранении данных непосредственно внутри хранилища.
Участок системы хранения, отвечающий за размещение данных, доступ к которым осуществляется по протоколу iSCSI, называется Extent.
File Extent или файл-контейнер
Этот метод встречается наиболее часто в силу его достаточно простой реализации. Суть его заключается в использовании специального файла большого размера, в котором, как в контейнере, размещаются данные клиента. Наиболее близкий аналог – виртуальный диск (например, создаваемый системой виртуализации), который доступен как очередной жесткий диск или съемный носитель. Другие аналоги – архивный файл, в который данные записываются «на лету», или файл-контейнер, создаваемый программой шифрования данных в качестве защищенного хранилища.
При таком подходе сначала физический диск или дисковый массив форматируется под определенную файловую систему, в этой файловой системе создается огромный файл-контейнер, внутри него – своя внутренняя файловая система, и уже на ней размещаются данные клиента (см. рис. 1).
Разумеется, когда создается каждый новый слой, определенная часть дискового объема расходуется на запись служебной информации. В итоге конечный объем iSCSI на базе File Extent будет всегда меньше объема логического тома, при этом общие потери могут быть весьма ощутимы.
Именно так работает большинство реализаций iSCSI target . Такой метод хранения, мягко говоря, является довольно рискованным. Малейшая ошибка файловой системы при записи этого громадного файла – и все данные на нем будут утеряны. Подобные ошибки легко возникают при несанкционированной холодной перезагрузке, некорректной работе RAID-контроллера (особенно это касается RAID-контроллеров, встроенных в материнскую плату) и так далее. Не спасут никакие проверки ни программой типа CheckDisk, ни каким-либо другим способом. Вся надежда только на своевременно созданную резервную копию.
Помимо невысокой защищенности и расхода свободного пространства, такой метод является, мягко говоря, не слишком производительным. Метод работы «все-в-один-файл» является прямым аналогом работы программы архиватора.
Накладные расходы также сопоставимы с бесконечной работой программы архиватора в активном режиме.
Device Extent
Данный метод представляет собой более простое и экономичное решение. Из названия следует, что для сохранения используется не отдельный файл, а целиком все устройство. В таком случае нет нужды создавать своеобразную «матрешку»: внешняя файловая система – файл-контейнер – внутренняя файловая система. Вместо этого данные пишутся напрямую на дисковый том в RAW-формате. Это позволяет значительно снизить накладные расходы и избежать потенциальных ошибок, например, из-за «холодной перезагрузки».
Device Extent позволяет обеспечить большую производительность при передаче данных, а также избежать множества проблем, связанных с особенностями работы той или иной операционной системы, конкретной реализацией iSCSI-инициатора и так далее. Разумеется, все эти преимущества будут доступны, если есть подходящий драйвер для аппаратной реализации iSCSI target . В противном случае устройство просто не будет работать.
Device Extent можно встретить в системах на платформе BSD – FreeBSD и ее производных: FreeNAS и NAS4Free.
Обеспечение безопасности при построении iSCSI SAN
Поклонники протокола Fibre Channel при обсуждении вопросов реализации безопасности подключений обязательно вспоминают Zoning – механизм, присутствующий в сетях FC. Аналогичные механизмы существуют и в iSCSI SAN.
Ограничение доступа по сети средствами iSCSI target
Практически во всех реализациях iSCSI target присутствует возможность программно ограничить доступ со всех адресов за исключением небольшой группы серверов, которые нуждаются в ресурсах СХД. Данный метод можно сравнить с software zoning в Fibre Channel, когда в качестве атрибута используется адрес порта (устройства): IP-адрес для iSCSI или WWWN для Fibre Channel.
Ограничение доступа по сети внешними средствами
Еще одна возможность, на мой взгляд, более удачная, – использование внешних систем для ограничения сетевого доступа. Так, в большинстве случаев сети iSCSI строятся на базе Ethernet, выделение некоторых сегментов посредством VLAN является хорошей практикой для обособления iSCSI SAN, эффективно защищая от несанкционированного доступа. В принципе VLAN для iSCSI можно сравнить с Hardware Zoning для Fibre Channel. И в одном, и в другом случае ограничение доступа производится исходя из портов, к которым подключаются устройства.
Проверка подлинности CHAP
Чаще всего для проверки легитимности подключения iSCSI initiator c iSCSI target применяется протокол CHAP (Challenge Handshake Authentication Protocol) . Основу данного метода составляет совместное использование клиентом и сервером секретного ключа (аналогичного паролю).
В большинстве реализаций iSCSI target
могут применяться следующие реализации CHAP:
Обычная или однонаправленная CHAP-аутентификация (one-way CHAP authentication
). В данном случае подлинность инициатора контролируется только iSCSI target. Для подключения всех инициаторов применяется определенный идентификатор, например пароль.
Двунаправленная CHAP-аутентификация (mutual CHAP authentication). Данный метод предполагает, что и iSCSI target, и iSCSI initiator
контролируют подлинность друг друга. При этом для участника обмена данными создается отдельный уникальный дескриптор (например, логин и пароль).Проверка подлинности RADIUS
Примечание. Данный протокол реализован для поддержки аутентификации, авторизации и получения информации об использованных ресурсах. Применялся, в том числе, и для систем тарификации услуг, которые были предоставлены пользователю, – то есть для биллинга (billing).
Особенностью данного решения является то, что в отличие от CHAP проверка достоверности RADIUS выполняется между сервером RADIUS и клиентом RADIUS. Когда initiator запрашивает доступ к ресурсам iSCSI target , клиент отправляет запрос пользователя на подключение на сервер RADIUS. Ответственность за проверку аутентификации берет на себя RADIUS-сервер . Аналогичным образом проверяется обмен данными и служебной информацией между iSCSI initiator и iSCSI target.
Разумеется, чтобы реализовать данную схему обеспечения безопасности, необходимо иметь хотя бы один RADIUS сервер в сети.
Проверка подлинности с использованием шифрования
Помимо вышеописанных способов – аутентификация и ограничение доступа по сети, – для обеспечения повышенной безопасности при работе с iSCSI можно использовать различные виды шифрования. Стоит отметить, что вовсе не обязательно выбирать какой-либо один метод проверки подлинности. Например, можно использовать и шифрование, и проверку подлинности при помощи CHAP или RADIUS.
Наиболее известным методом является использование протокола IPsec – протокола, выполняющего принудительную проверку подлинности и шифрование данных на уровне IP-пакетов. При использовании IPsec все IP-пакеты подвергаются шифрованию и проверке. Соответственно, все участники сетевого обмена должны иметь общий ключ для проверки подлинности друг друга и шифрования пакетов.
Также неплохо зарекомендовала себя возможность шифрования iSCSI-ресурсов как дисковых разделов. Такой том можно подключить только через специальную программуагента с обязательным вводом пароля и подключением соответствующего сертификата.
Области применения iSCSI
В принципе области применения устройств хранения на базе iSCSI такие же, что и для Fibre Channel, как, впрочем, для любых других типов СХД, предоставляющих ресурсы в режиме блочного доступа.
Однако до недавнего времени из-за невысокой пропускной способности сети Gigabit Ethernet применение iSCSI было довольно ограничено. Ситуация кардинально поменялась с выходом стандарта 10 Gigabit Ethernet и началом массового выпуска соответствующего оборудования.
iSCSI традиционно используется для систем удаленной загрузки, резервного копирования, создания систем хранения класса С.
В то же время неплохие возможности сетевого оборудования 10 Gigabit Ethernet позволяют использовать iSCSI SAN и при построении систем виртуализации, и для хранения баз данных, словом, для всех задач, где раньше господствовал стандарт Fibre Channel.
С какой скоростью работает iSCSI?
В отличие от внутренней шины SCSI, которая обеспечивает непосредственный доступ к устройствам, передача пакетов iSCSI происходит посредством потенциально ненадежного сетевого соединения. Для обеспечения стабильной работы, контроля обмена данными и SCSI-командами в данных условиях в работе протокола iSCSI применяется избыточность. Эта избыточность выражается в передаче дополнительной служебной информации, которая используется для мониторинга блочной передачи, проверки корректности завершения операций ввода/вывода и обработки ошибок. Также служебная информация необходима для системы идентификации устройства посредством соответствующих имен. Еще одна задача, решаемая при обмене данными, – обеспечение безопасности. Разумеется, все это вкупе с процессом инкапсуляции – деинкапсуляции ведет к дополнительным накладным расходам (см. рис. 2).
Для того чтобы продемонстрировать перспективы реального использования данной технологии, в качестве примера выполним небольшой расчет.
Допустим, у нас используется одиночное подключение по сети Gigabit Ethernet (1 Gb/s) . Переведя в мегабайты в секунду, получим: 1024/8 = 128 Mb/s.
Чтобы получить пропускную способность с учетом всех накладных расходов, пусть и в довольно грубом приближении, разделим полученную величину на 2: 128 / 2 = 64 Mb/s.
Полученное значение сопоставимо со скоростью передачи данных старых IDE PATA жестких дисков стандарта UDMA66 (66 Mb/s).
Примечание. Стоит отметить, что даже объединение двух линков, например, по протоколу LACP не дает в 100% случаев удвоения производительности. Большую роль играет конкретная программная реализация системы передачи данных. В реальности стоит ожидать коэффициент увеличения ширины канала в диапазоне 1,4-1,7 от первоначальной величины.
Действительно ли системы хранения iSCSI так дешевы?
В свое время стандарт iSCSI получил прозвище «Fibre Channel для бедных». В то время, в самом начале развития, считалось, что достаточно всего лишь приобрести несколько сетевых карт и простой коммутатор и можно построить сеть хранения данных. Впоследствии оказалось, что это не совсем так.
Во-первых, пропускная способность сетей семейства Ethernet довольно долго ограничивалась максимальной скоростью 1 Gb/s . В то время Fibre Channel уже поддерживал сети SAN в 2 и 4 Gb/s
Во-вторых, практически вся нагрузка для обеспечения работы iSCSI ложится на конечные устройства на iSCSI target и iSCSI initiator. Поэтому применение iSCSI требует дополнительных системных ресурсов. Именно это побудило к созданию устройств для «разгрузки» вычислительных мощностей – TOE и Full iSCSI HBA .
В-третьих, не следует забывать, что использование iSCSI требует дополнительных ресурсов в виде сетевого оборудования. Сетевые адаптеры, коммутаторы, патчпанели – все это стоит денег. Например, стоимость сетевой карты 10 Gigabit Ethernet сопоставима со стоимостью FC HBA 8 или даже 16 Gb/s
Из всего этого следует вывод, что не существует универсальных решений по принципу «бери вот это – будет дешево и сердито». Каждый вариант, будь то сеть хранения данных на базе iSCSI или Fibre Channel , требует тщательного изучения как с технической, так и с финансовой точки зрения.
С другой стороны, применение оборудования и протокола iSCSI на начальном этапе значительно проще, чем создание с нуля SAN на основе Fibre Channel. Достаточно иметь подходящий сервер с сетевыми адаптерами, сетевое оборудование и программное обеспечение для установки iSCSI target и iSCSI initiator. При этом не нужно обучаться на дорогих курсах или приобретать весьма недешевую литературу для изучения специфичного оборудования и ПО.
Как ускорить работу iSCSI SAN?
- Используйте выделенный коммутатор. При работе iSCSI target «в общей сети» коммутаторы, помимо доступа к СХД, вынуждены обслуживать множество конкурентных транзакций, например, между и офисными компьютерами, что снижает фактическую скорость сетевого обмена. Также выделенный коммутатор является отличной мерой безопасности (см. ниже).
- Не используйте излишние средства безопасности. Чем больше механизмов безопасности используется, тем медленнее работает СХД в целом. Да, современные iSCSI-хранилища позволяют применять одновременно программное ограничение сетевого доступа, двунаправленную аутентификацию и шифрование IPsec. Но насколько все это необходимо в обычной ситуации? При решении простых задач достаточно просто использовать выделенный коммутатор.
- Используйте самую быструю сеть. Однако следует помнить: самая скоростная сеть будет бесполезна, если используются другие комплектующие слабой или устаревшей конфигурации, например старенький процессор или отживший контроллер дисковой подсистемы.
- Найдите узкое место и проведите модернизацию оборудования СХД (iSCSI target) . Не забывайте про возможности применения сетевых адаптеров со встроенными функциями поддержки iSCSI.
- По возможности используйте Device Extent для снижения накладных расходов при работе с дисковой подсистемой iSCSI target.
- Следите за свободным пространством. Избегайте заполнения подключаемых iSCSI-томов более чем на 75-80% от их объема во избежание деградации производительности. Помните, любая система хранения, будь то жесткий диск или SAN-хранилище, после превышения указанного предела будет работать медленнее.
- Не создавайте очень больших дисковых томов. Большие дисковые разделы, подключаемые по сети в режиме блочного доступа, могут вызывать падение производительности из-за проблем в индексации, поиске и размещении информации на дисковом разделе. Также следует понимать, что при пропадании сети возможно появление ошибок на файловой системе подключаемых блочных ресурсов. Проверить огромный том на наличие ошибок может оказаться крайне сложной задачей.
Использование стандартов и технологий iSCSI позволяет быстро подключить систему хранения данных в качестве устройств блочного доступа. Однако при дальнейшем развитии ИТ-инфраструктуры необходимы определенные финансовые и технические ресурсы для обеспечения надежности и приемлемой скорости передачи данных.
Сетевым накопителем поддерживается встроенная служба iSCSI (Internet Small Computer System Interface) для использования в серверных кластерах и виртуализированных средах.
На этой странице пользователи могут включать/отключать службу iSCSI, изменять порт портала iSCSI, включать/отключать службу iSNS и перечислять и управлять всеми целями iSCSI и LUN. NAS поддерживает несколько целей iSCSI и несколько LUN для одной цели. Для определенной цели можно монтировать и размонтировать iSCSI LUN. В этой главе представлены следующие разделы.
В приведенной ниже таблице представлены функции, поддерживаемые блочными LUN и файловыми LUN.
Файловый LUN (старого типа) |
||
Полное копирование по VAAI |
Поддерживается |
Поддерживается |
Обнуление блоков по VAAI |
Поддерживается |
Поддерживается |
Блокировка на аппаратном уровне по VAAI |
Поддерживается |
Поддерживается |
Тонкое конфигурирование и высвобождение пространства по VAAI |
Поддерживается |
Не поддерживается |
Динамическое выделение емкости |
Поддерживается |
Поддерживается |
Высвобождение пространства |
Поддерживается (по VAAI или в Windows 2012/Windows 8) |
Не поддерживается |
Microsoft ODX |
Поддерживается |
Не поддерживается |
Резервное копирование LUN |
Поддерживается |
|
Моментальная копия LUN |
Поддерживается |
1 Моментальный снимок |
Учтите, что блочные LUN обычно обеспечивают более высокую производительность системы, и поэтому рекомендуется там, где это возможно, использовать блочные LUN.
Имеется два способа выделения LUN: «тонкое» конфигурирование и мгновенное выделение.
Можно создать до 256 целей iSCSI и LUN. Например, если на NAS создано 100 целей, то максимальное количество доступных для создания LUN составляет 156. Для каждой цели можно создать несколько LUN. Однако максимальное количество одновременных подключений к целям iSCSI, поддерживаемое NAS, отличается в зависимости от сетевой инфраструктуры и производительности приложения. Слишком большое количество одновременных подключений может оказать влияние на производительность NAS.
Мастер быстрой настройки iSCSI
Чтобы настроить службу цели iSCSI на сетевом накопителе, выполните следующие действия.
| 6. | Укажите параметры проверки подлинности и нажмите кнопку "Далее". При включении параметра "Использовать авторизацию CHAP" целью iSCSI будет выполняться проверка подлинности только для инициатора, и для доступа к цели пользователям инициаторов будет выдаваться запрос на ввод указанных здесь имени пользователя и пароля. При включении параметра "Совместный CHAP" активируется режим двусторонней проверки подлинности между целью и инициатором iSCSI. Цель осуществляет проверку подлинности инициатора с использованием первого набора имени пользователя и пароля. Инициатор осуществляет проверку подлинности цели с использованием параметров, указанных в разделе "Совместный CHAP". Для имени пользователя и пароля в обоих полях имеются описанные ниже ограничения. |
Создание целей iSCSI
Для создания цели iSCSI выполните следующие действия.
| 5. | Укажите имя пользователя и пароль для параметра "Использовать авторизацию CHAP" и (или) "Совместный CHAP" и нажмите кнопку "Далее". При включении параметра "Использовать авторизацию CHAP" целью iSCSI будет выполняться проверка подлинности только для инициатора, и для доступа к цели пользователям инициаторов будет выдаваться запрос на ввод указанных здесь имени пользователя и пароля. При включении параметра "Совместный CHAP" активируется режим двусторонней проверки подлинности между целью и инициатором iSCSI. Цель осуществляет проверку подлинности инициатора с использованием первого набора имени пользователя и пароля. Инициатор осуществляет проверку подлинности цели с использованием параметров, указанных в разделе "Совместный CHAP". |
Создание iSCSI LUN
Для создания LUN для цели iSCSI выполните следующие действия.
Для создания непривязанного iSCSI LUN выберите на шаге 4 параметр "Не привязывать к цели".
Будет создан непривязанный LUN, который будет отображен в списке непривязанных iSCSI LUN.
В приведенной ниже таблице представлено описание всех целей iSCSI и состояний LUN.
Позиция |
Состояние |
Описание |
Цель iSCSI |
Готово |
Цель iSCSI находится в состоянии готовности, однако ни одного инициатора к ней не подключено. |
Подключен |
К цели iSCSI подключен инициатор. |
|
Отключен |
Подключения к цели iSCSI были разорваны. |
|
Автономно |
Цель iSCSI отключена, подключения со стороны инициаторов невозможны. |
|
Включено |
LUN активирован для подключения и виден авторизованным инициаторам. |
|
Выключено |
LUN деактивирован и не виден инициаторам. |
В приведенной ниже таблице описаны действия, доступные для управления целями iSCSI и LUN (кнопка "Действие").
Действие |
Описание |
Отключить |
Отключение цели, находящейся в состоянии «Готов» или «Подключено». Учтите, что все подключения от инициаторов будут разорваны. |
Активировать |
Активация цели, находящейся в состоянии «Офлайн». |
Изменить |
Изменение настроек цели: псевдонима цели, информации CHAP и настроек контрольной суммы. Изменение настроек LUN: выделение LUN, имя, каталог дискового тома и т. д. |
Удалить |
Удаление цели iSCSI. Все подключения будут разорваны. |
Отключить |
Отключение LUN. Все подключения будут разорваны. |
Включить |
Включение LUN. |
Отвязать |
Отмена привязки LUN к цели. Учтите, что перед отвязкой LUN его сначала следует отключить. При нажатии этой кнопки LUN будет перемещен в список непривязанных виртуальных iSCSI LUN. |
Привязать |
Привязка LUN к цели iSCSI. Эта функция доступна только для списка непривязанных iSCSI LUN. |
Показать подключения |
Просмотр состояния подключения цели iSCSI. |
Переключение iSCSI LUN между целями
Для переключения iSCSI LUN между целями выполните следующие действия.
После создания целей iSCSI и LUN на NAS для подключения к цели iSCSI и LUN, а также использования дисковых томов в качестве виртуальных дисков на компьютере можно использовать инициатор iSCSI, установленный на компьютере (ПК с Windows, Mac или Linux).
Увеличение объема iSCSI LUN
NAS поддерживает функцию увеличения объема для iSCSI LUN. Для этого выполните следующие действия.
