Iscsi portal что это

Обновлено: 06.07.2024

iSCSI протокол базируется на TCP/IP и разработан для установки взаимодействия и управления системами хранения данных, серверами и клиентами.

В терминах iSCSI, сервер предоставляющий ресурсы хранилища называется target , а клиент подключённый к серверу и использующий эти ресурсы initiator .

Основные термины

IQN WWID (iSCSI Qualified Name) - уникальный идентификатор устройства.

LUN - номер «части» диска, к которому идёт обращение. Ближайший аналог — раздел на жёстком диске.

Portal - несколько target’ов, которые анонсируются одним сервером.

Установка пакетов

Установим необходимые пакеты для работы iSCSI

Запустим сервис и добавим в автозагрузку:

Добавим правила на Firewall:

Первоначальная очистка настроек в случае наличия прошлых установок:

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

Просмотрим существующие ресурсы:

Подключаем блочное устройство к iSCSI ресурсу:

Отключение устройства выполняется командой:

Создание iSCSI таргета

Удаление ресурса выполняется командой:

Создание портала

Подключение устройств в качестве логических «юнитов» (LUNs):

Определение имён iSCSI-ресурсов (IQN) для узлов кластера:

Host-01

Host-02

Создаем список доступа (ACL) для узлов:

Подключение на стороне клиента (Initiator)

Установим необходимые пакеты:

Найдем доступные iSCSI устройства:

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

Запустим сервис и добавим в автозагрузку:

Проверяем состояние на ноде:

Для удаления связи используем команду:

Для закрытия сессии:

Для удаления доступных записей:

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

Конфигурация с CHAP авторизацией

Повторяем предыдущие действия. На шаге настроек списков доступа настриваем авторизацию по логину и паролю.

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

Настроим клиент для работы с CHAP, для этого изменим конфигурационный файл /etc/iscsi/iscsid.conf :

Для снижения вычислительных затрат на создание и обработку SCSI-команд был создан TCP/IP offload engine (TOE). Для достижения наилучшей производительности рекомендуется использовать iSCSI-адаптеры, в которых кроме TOE аппаратно реализован и уровень iSCSI

Бездисковая загрузка по технологии iSCSI

Начну из далека. Как часто вы встречаете организации использующие «Подключение к удаленному рабочему столу» как основной способ работы в офисе? Я стал встречать такие все чаще и мое личное мнение — это удобно! Удобно для сотрудников, удобно для системных администраторов, а самой компании это позволяет сократить IT расходы. А нередко это даже необходимость для комфортной многопользовательской работы в некоторых программах (пример — ПО 1С).

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

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

Вики гласит:
iSCSI (англ. Internet Small Computer System Interface) — протокол, который базируется на TCP/IP и разработан для установления взаимодействия и управления системами хранения данных, серверами и клиентами.

Для понимания происходящего определимся с терминологией:

iSCSI Target: (Цель iSCSI) — программа или аппаратный контроллер (HBA), осуществляющие эмуляцию диска и выполняющие запросы iSCSI. подробнее

iSCSI Initiator: (Инициатор iSCSI) — Клиентская программа или аппаратный контроллер, который взаимодействует с iSCSI Target.

IQN: (iSCSI Qualified Name) — Уникальный идентификатор (имя) iSCSI Target'a или iSCSI Initiator'а.

LUN: (Logical Unit Number) — Адрес блочного устройства в диапазоне 0-127. подробнее

Инициатор iSCSI

Прелесть в том, что Windows 7, Windows Server 2008 и всё что старше умеют устанавливаться напрямую на iSCSI target. Проблема только в том, как инициализировать удаленное блочное устройство при включении ПК.
Все современные сетевые карты умеют работать по технологии PXE, а вот с iSCSI дружат только дорогущие серверные сетевые карты например intel

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

Лично я использую gPXE, я его нашел первым, к тому-же у них на сайте есть очень удобный генератор rom-o-matic

Есть много способов как загрузиться через gPXE. Для рабочего варианта я вшивал её ROM вместо PXE загрузчика в BIOS метеринки. Рисковый вариант, можно остаться без материнки, забегая вперед это позволит уменьшить время загрузки на

Расскажу лучше о простом и безопасном для оборудования способе под названием PXE chainloading подробно (англ.) . Суть такова — с помощью PXE загрузчика загружаем gPXE, который в свою очередь выступает iSCSI инициатором и передает управление диску. Для этого нам нужен TFTP сервер (я не стал прибегать к стороннему софту, сделал как тут) и правильная настройка DHCP сервера.
Вот так выглядит DHCP параметры у меня:

Обратите внимание на параметр «175 gPXE_Options», инкапсулированное значение «08 01 01 ff» означает опцию keep_san = 1, которая заставляет gPXE не удалять регистрацию диска в случае неудачной загрузки с него (это необходимо для установки операционной системы).

В параметре «017 Корневой путь» самый просто синтаксис будет iscsi:<Айпи iSCSI target>. <IQN цели>

Настройки iSCSI инициатора на этом закончены.

Цель iSCSI

Настройки цели крайне простые и интуитивные.


Создаём новое или импортируем существующий VHD диск:


Далее создаём цель:


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


На этом настройка цели почти закончена. Осталось только добавить IQN(или любой другой тип индификатора: MAC, IP) инициатора(ов) который имеет доступ к этой цели.

Если после этого при загрузке клиентского ПК в gPXE промелькнут надписи:
Registered as BIOS drive 0x80
Booting from BIOS drive 0x80
Значит у нас получилось. И можно приступать к установке ОС.

Установка ОС или Epic Fail

Уже с ностальгией вспоминаю тот момент, когда первый раз я дошел до этого этапа и… поначалу меня постигало кучу разочарований. Забегая вперед скажу, что причиной многому была неудачная материнская плата GYGABYTE GA-425TUD.

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

30 — 40 минут на пустой флешке, куда были переписаны исключительно дрова для нужной сетевухи, заставлял меня думать что ОС виснет и раз 5-10 я так и не дожидался окончания поиска, выключал, перезагружал, менял опции gPXE. Так сложилось, что однажды я таки дождался пока драйвера были найдены, и радовался как ребенок обнаружив что в меню выбора появился так желанный мне диск.
Радость тут-же омрачилась тем что ОС сообщила мне о невозможности установиться на этот диск и любезно попросила меня проверить включен ли в моём BIOS контроллер этого диска.

Решение было найдено довольно быстро вот тут в самом низу. Если коротко то ребята советовали включать/выключать SATA контроллер, менять режим его работы IDE, ACHI и даже попробовать подключить реальный диск на время установки, но установку проводить на iSCSI диск. Для меня сработало подключение реального диска в режиме ACHI. Теперь установка пошла на iSCSI диск без проблем. Однако после перезагрузки ОС (один из этапов установки) я постоянно ловил BSOD на classpnp.sys.

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

Решением стало отключение LWF фильтра в ОС на сетевухе.

В этом варианте у меня заработало даже на проблемной материнке.
После этого я пробовал еще 2 или 3 материнки, установка проходила гладко изначально (нужно было лишь подгрузить сетевые драйвера).

Тесты

Интересно на сколько будет заметно что мой HDD где-то там в 100 метрах от меня? На глаз вообще не отличить! Но я даже не надеялся что вы поверите моему глазу по этому приведу результаты тестов.

Наши герои:

Seagate ST500DM002 — будет работать локально, как у людей ;D
iSCSI SSD Patriot 128 PYROSE — на сервере, будет работать через iSCSI, сетевой канал 1ГБ.
iSCSI RAID 10 4xSeagate ST500DM002 — на сервере, будет работать через iSCSI, сетевой канал 1ГБ.

(Локальный)Seagate ST500DM002




iSCSI SSD Patriot 128 PYROSE




iSCSI RAID 10 4xSeagate ST500DM002




Свод и выводы




На мой взгляд вполне заслуживающая внимания технология, как видно из тестов даже на 1ГБ сети имеет хороший КПД. При текущих ценах на HDD позволит экономить как минимум 2500р с рабочей станции и облегчает задачу резервирования данных. У меня в организации все сотрудники работают в терминале, еще вот открыли учебный класс на 8 рабочих мест, именно там в качестве теста я и внедрял эту технологию.

iSCSI хранилище для небогатых

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

Если у вас есть подобная задача или вас просто заинтересовал заголовок, то добро пожаловать под хабракат.

Пролог

Итак, недавно перед нашим отделом встала задача обеспечить кластер из гипервизоров VMware ESXi 5.1 хранилищем большого обьема. На нем же мы запланировали расположить шифрованный maildir для dovecot и “облачное” файловое хранилище. Обязательным условием выделения бюджета было обеспечение места для хранения критически важной для компании информации, причем этот раздел должен быть зашифрован.

Железо

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

  • Серверный корпус Supermicro CSE-836BE16-R920B
    Тут было много рассуждений, выбирали количество юнитов, размер жестких дисков, их скорость, корпус или сразу платформа, пересмотрели множество вариантов, покурили интернетов и в итоге остановились на этом варианте, как на оптимальном под наши задачи.
  • Материнская плата Supermicro MBD-X9DRI-F-O
    Главным условием было наличие 4 портов PCI-E x8.
  • Процессоры Intel Xeon E5-2603
    Выбор был прост — на что хватило денег. Вдобавок пришлось ставить 2 процессора сразу, а не сначала один, потом, если надо будет, то докупить, ибо с одним занятым слотом работает только 3 PCI-E, а нам надо было 4.
  • Диски Seagate Constellation ES.3 ST3000NM0033
    SATA потому что дешевле, и в те же деньги мы получали многократно большее количество свободного места, нежели при использовании SAS.
  • RAID контроллер Adaptec ASR-7805Q
    Раз уж это СХД, то с контроллером мелочиться не стали. У этой серии есть SSD кэширование, которое очень бы нам пригодилось, и есть BBU сразу в комплекте, что тоже весьма полезная опция.
  • SSD диски Intel SSDSC2CW240A310
    Они нужны были исключительно для того, чтобы работал MaxCache (он же SSD кэш).
  • Сетевые карты Intel X520 DA2
    Чтобы избежать узкого места на сетевых интерфейсах, надо было обеспечить 10Gb линк между нодами ESXi и СХД. После изучения предложений рынка мы пришли может и к не самому элегантному, но зато к подходящему по цене и скорости варианту с использованием 10 гигабитных сетевых карт.
Реализация

Выдавать таргеты, то бишь выделять ресурсы СХД потребителям, мы решили при помощи iSCSI и NFS. Наиболее разумным и быстрым решением, конечно, было бы использовать FCoE, чтобы не влезать в TCP с соответствующими ему накладными расходами, что, в общем-то можно было бы сделать с нашими сетевыми картами, но, к сожалению, у нас нет SFP свитча с поддержкой FCoE, купить его не было возможности, так как это стоило бы нам 500 т.р. сверху.
Еще раз покурив интернеты, нашли выход из этого в технологии vn2vn, но ESXi научится работать с vn2vn только к 6.x версии, поэтому, не думая дальше, приступили к тому, что есть.

Наш корпоративный стандарт для Linux серверов — CentOS, но в текущем ядре (2.6.32-358) шифрование работает очень медленно, поэтому пришлось использовать в качестве ОС Fedora. Конечно это полигон Red Hat, но в последних ядрах Linux данные шифруются практически “на лету”, а остальное нам, вроде бы, и не нужно.
К тому же текущая 19 версия будет использована как основа для RHEL 7, а следовательно позволит нам в будущем безболезненно перейти на CentOS 7.

Таргеты

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

  • правильно работающее кеширование — диски довольно медленные, выжать из себя они могут только 2000 iops;
  • максимально высокую скорость работы непосредственно дисковой подсистемы в целом, читай (даешь как можно больше iops).
istgt
iSCSI для VMWare ESXi 5.1 на SCST и Fedora

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

Подготовка ESXi 5.1
InitialR2T=No
ImmediateData=Yes
MaxConnections=1
MaxRecvDataSegmentLength=1048576
MaxBurstLength=1048576
FirstBurstLength=65536
DefaultTime2Wait=0
DefaultTime2Retain=0
MaxOutstandingR2T=32
DataPDUInOrder=No
DataSequenceInOrder=No
ErrorRecoveryLevel=0
HeaderDigest=None
DataDigest=None
OFMarker=No
IFMarker=No
OFMarkInt=Reject
IFMarkInt=Reject

Потребуется отключить Interrupt Moderation и LRO для сетевых адаптеров. Сделать это можно командами:

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

Подготовка Fedora

Скачиваем и устанавливаем в минимальном варианте последнюю версию Fedora.

Обновим систему и перезагрузимся:

Система будет работать только в локальной сети, поэтому я отключил файервол и SELinux:

Настроим сетевые интерфейсы и отключим сервис NetworkManager.service. Он не совместим с BRIDGE интерфейсами, а это было необходимо для NFS.

На сетевых картах отключено LRO.

По рекомендациям от Intel измененны следующие параметры системы:

Подготовка таргета

Для использования SCST рекомендуется добавить патчи в ядро. Это необязательно, но с ними производительность выше.
Во время создания хранилища последняя версия ядра была — 3.10.10-200. К моменту когда вы будете читать статью ядро уже может обновиться, но не думаю, что это сильно повлияет на процесс.

Но для того, чтобы не возникло трудностей опишу подготовку подробно.


Перейдем в его среду:


Установим пакеты для сборки и подготовим исходники ядра:


Теперь потребуются сами патчи. Скачаем SCST из svn репозитория:


Скопируем необходимые пачти в


Добавляем строчку в конфиг ядра:


Приступим к редактированию kernel.spec.


Добавляем наши патчи, желательно после всех остальных:

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


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

После успешной, надеюсь, загрузки перейдите в каталог с исходниками SCST и уже пользователем root соберите сам таргет:


После сборки добавьте сервис в автозапуск:


И настройте конфиг в /etc/scst.conf. К примеру мой:


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


После настройки файлов конфигураци запустите SCST:


Если все было сделано правильно, то в ESXi появится соответствующий таргет.

iSCSI и другие

С появлением Fibre Channel и SAN, построенных на нем, мир storage сделал ставку на сетевой доступ к системам хранения. Практически все в один голос заявили, что за сетями хранения данных — будущее. На протяжении нескольких лет FC интерфейс оставался безальтернативным стандартом для их построения, но уже сегодня многие понимают, что наступает время перемен. В SAN на основе FC есть пара серьёзных недостатков — это цена и проблемы доступа к географически (на расстоянии больше сотен км) отдаленным устройствам. В последнее время возник ряд инициатив, которые находятся на этапе стандартизации и призваны решить или же обойти указанные проблемы. Интереснейшая из них — iSCSI.

Sun стала в оппозицию к ІP Storage

Sun стала в оппозицию к IP Storage. Sun Microsystems не будет выпускать систем хранения данных с доступом по IP. Марк Канепа, вице-президент Sun, ответственный за производство всех систем хранения данных, заявил на днях, что IP Storage был всего лишь «мечтой», сообщает Byte and Switch.

Канепа сказал, что «непрактично применять TCP/IP для организации SAN из-за большей задержки в таких сетях. Даже если у сетей хранения на основе IP есть будущее, то наступит оно через три-пять лет, а возможно, не наступит никогда. Поток от систем хранения данных не может работать поверх стека протоколов общего назначения, у него есть особые потребности. Технологические трудности внедрения TCP/IP намного более велики, чем многие думают. Именно поэтому мы в Sun делаем ставку на Fibre Channel», сказал он. До сих пор никто из производителей систем хранения данных не занимал столь четкой позиции против IP Storage. Конкуренты Sun, компании Hewlett-Packard и IBM, более или менее активно поддерживают эти технологии.

HP обещает поддержку iSCSI

«Окончательная версия новой технологии должна появиться в первом квартале 2002 года, — сообщил руководитель подразделения систем сетевого хранения HP Марк Томпсон. Корпорация намеревается представить широкий спектр продуктов, которые поддерживают стандарт, іSCSI, предназначенный для объединения систем хранения в ІP-сетях…»

В HP признают, что пользователи систем Fibre Channel чувствуют себя достаточно комфортно и большее тяготеют к модернизованной технологии FCIP, чем к іSCSI. Но, в то же время, в HP верят, что опыт работы с решениями, основанными на протоколе ІP, и в особенности с Ethernet, сделает продукты іSCSI привлекательными для многих заказчиков.

IBM выпускает продукт на базе iSCSI

IBM TotalStorage IP Storage 200i обеспечивает прямое подключение накопителей Ethernet LAN. Эта высокоскоростная система хранения данных поддерживает новый промышленный стандарт iSCSI, что обеспечивает передачу SCSI протокола поверх IP.

iSCSI

«iSCSI (Internet Small Computer System Interface) — это протокол, который базируется на TCP/IP и разработан для установления взаимодействия и управления системами хранения данных, серверами и клиентами».

  • Транспортный протокол для SCSI, который работает поверх TCP
  • Новый механизм инкапсуляции SCSI команд в IP сети
  • Протокол для новой генерации систем хранения данных, которые будут использовать «родной» TCP/IP

Сразу возникает негодование, хочется все разложить по отдельным кучкам. Как говорил один мой преподаватель: «Котлеты отдельно, мухи отдельно». Дело в том, что правила доставки пакетов в IP и SCSI абсолютно противоположные. В IP пакеты доставляются получателю без соблюдения строгой последовательности, он же и восстанавливает данные, на что затрачиваются определенные ресурсы. В то же время, по спецификации SCSI, как канального интерфейса, все пакеты должны передаваться один за другим без задержки, а нарушение этого порядка приводит к потере данных. Несмотря на то, что, по мнению некоторых специалистов, эта проблема вносит неоднозначность в практическое использование технологии iSCSI, на сегодня уже реализован ряд устройств, которые подтверждают ее жизнеспособность. Инженеры, которые работали над iSCSI, смогли определенным образом решить эту проблему. Спецификация iSCSI требует увеличения размеров заголовка пакета. В заголовок включается дополнительная информация, которая значительно ускоряет сборку пакетов.

По мнению одного из болельщиков iSCSI, Хеймора, старшего системного инженера университета штата Юта, основным препятствием для распространения Ethernet как базовой технологии построения сетей хранения данных является относительно большое время задержки (близкое к 75 микросекундам), которое возникает из-за особенностей стека TCP/ІР. В High-End системах при одновременном обращении к тысячам файлов это может стать серьезной проблемой.

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

iSCSI развивается очень быстро. Потребность в новом стандарте ощущалась так сильно, что буквально за 14 месяцев с момента предложения по созданию iSCSI, с которым в феврале 2000 года выступила IETF, появилось достаточно много устройств, чтобы продемонстрировать возможности по их взаимодействию. В июле 2000-го был опубликован Draft 0 по iSCSI, который стал началом работ по реализации технологии. В январе 2001 года в рамках SNIA (Storage Networking Industry Association) был создан IP Storage форум, который через полгода уже насчитывал 50 членов, а в апреле этого же года был представлен продукт, который в скором времени выиграл награду «Enterprise Networking Product».

Что же такого замечательного в iSCSI, что он находит поддержку среди грандов компьютерной индустрии, не считаясь с существующими внутри стандартам противоречиями.

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

    · Консолидация систем хранения данных · Резервирование данных · Кластеризация серверов · Репликация (дублирование) · Восстановление в аварийных ситуациях
    · Географическое распределение SAN · QoS · Безопасность
    · Обеспечивается единая технология для подсоединения систем хранения, серверов и клиентов в рамках LAN, WAN, SAN · Наличие значительного опыта индустрии в Ethernet и SCSI технологиях · Возможность значительного географического отдаления систем хранения · Возможность использовать средства управления TCP/IP сетями

Причем, для передачи данных на storage с интерфейсом iSCSI можно использовать не только носители, коммутаторы и маршрутизаторы существующих сетей LAN/WAN, но и обычные сетевые карточки на стороне клиента. Правда, при этом возникают значительные накладные расходы процессорной мощности на стороне клиента, который использует такую карточку. По утверждению разработчиков, программная реализация iSCSI может достичь скоростей среды передачи данных Gigabit Ethernet при значительной, до 100% загрузке современных CPU. В связи с чем, рекомендуется использование специальных сетевых карточек, которые будут поддерживать механизмы разгрузки CPU от обработки стека TCP. На момент написания статьи (Июнь 2002 года), такие карточки производила компания Intel.

Intel PRO/1000T IP Storage Adapter предлагается компанией Intel по цене 700USD за штуку. Это устройство содержит мощный процессор Xscale, 32M памяти и осуществляет передачу вычислений, связанных с протоколами iSCSI и TCP/IP, а также расчет контрольных сумм кадров TCP, IP на интегрированный процессор. Его быстродействие, согласно внутренним тестам компании, может достигать 500Mbit/s при 3-5% загрузке CPU host системы.

Давайте рассмотрим iSCSI повнимательней



Рисунок 1. IP сеть с использованием iSCSI устройств

В примере, изображенном на рисунке 1, каждый сервер, рабочая станция и накопитель поддерживают Ethernet интерфейс и стек протокола iSCSI. Для организации сетевых соединений используются IP маршрутизаторы и Ethernet коммутаторы.

С внедрением SAN мы получили возможность использовать SCSI протокол в сетевых инфраструктурах, обеспечивая высокоскоростную передачу данных на уровне блоков между множественными элементами сети хранения данных.

Internet Small Computer System Interface тоже обеспечивает блочный доступ к данным, но не самостоятельно, а поверх сетей TCP/IP.

Архитектура обычного SCSI базируется на «клиент»/«серверной» модели. «Клиент», например сервер, или рабочая станция, инициирует запросы на считывание или запись данных с исполнителя — «сервера», например системы хранения данных. Команды, которые выдает «клиент» и обрабатывает «сервер» помещаются в Command Descriptor Block (CDB). «Сервер» выполняет команду, а окончание ее выполнения обозначается специальным сигналом. Инкапсуляция и надежная доставка CDB транзакций между инициаторами и исполнителями через TCP/IP сеть и есть главная задача iSCSI, причем ее приходится осуществлять в нетрадиционной для SCSI, потенциально ненадежной среде IP сетей.

Перед вами модель уровней протокола iSCSI, которая дает возможность понять порядок инкапсуляции SCSI команд для передачи их через физический носитель.



Рисунок 2. Модель нижних уровней протокола iSCSI

iSCSI протокол осуществляет контроль передачи блоков данных и обеспечивает подтверждение достоверности завершения операции ввода/вывода. Что, в свою очередь, обеспечивается через одно или несколько TCP соединений.

  • Управление именами и адресами (iSCSI Address and Naming Conventions).
  • Управление сеансом (iSCSI Session Management).
  • Обработка ошибок (iSCSI Error Handling).
  • Безопасность (iSCSI Security).
Управление именами и адресами

Так как iSCSI устройства являются участниками IP сети, они имеют индивидуальные Сетевые Сущности (Network Entity). Сетевая Сущность может содержать одних или несколько iSCSI Узлов.



Рисунок 3. Модель сетевых сущностей

Управление сеансом

iSCSI сессия состоит из фаз аутентификации (Login Phase) и фазы обмена (Full Feature Phase), которая звершается специальной командой.

Фаза аутентификации iSCSI аналогична процессу Fibre Channel Port Login (PLOGI). Она используется для того, чтобы согласовать разнообразные параметры между двумя Сетевыми Сущностями и подтвердить право доступа инициатора. Если фаза аутентификации iSCSI завершается успешно, исполнитель подтверждает login инициатору, иначе логин не подтверждается, а TCP соединение закрывается.

Как только login подтвердится, iSCSI сессия переходит к фазе обмена. Если было установлено более одного соединения TCP, iSCSI требует, чтобы каждая пара команда/ответ проходила через одно TCP соединение. Такая процедура гарантирует, что каждая отдельная команда считывания или записи будет осуществляться без необходимости дополнительно отслеживать каждый запрос по поводу его прохождения по разным потокам. Однако разные транзакции могут одновременно передаваться через разные TCP соединения в рамках одной сессии.



Рисунок 4. Пример iSCSI Write

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

В случае необходимости закрыть сессию, используется команда iSCSI logout, которая передает информацию о причинах завершения сессии. Она также может передать информацию о том, какое соединение следует закрыть в случае возникновения ошибки соединения, чтобы закрыть проблемные TCP связи.

Обработка ошибок

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

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

    На наиболее низком уровне — определение ошибки и восстановление данных на уровне SCSI задачи, например, повторение передачи утраченного или поврежденного PDU.

Безопасность

В связи с использованием iSCSI в сетях, где возможен несанкционированный доступ к данным, спецификация предусматривает возможность использования разнообразных методов для повышения безопасности. Такие средства шифрования, как IPSec, которые используют нижние уровни, не требуют дополнительного согласования, так как являются прозрачными для верхних уровней, в том числе для iSCSI. Для аутентификации могут использоваться разнообразные решения, например такие, как Kerberos, или обмен Частными Ключами, в качестве репозитария ключей может использоваться iSNS сервер.

Другие (iFCP, FCIP)

  • iSCSI (Internet Small Computer Systems Interface)
  • FCIP (Fibre Channel over TCP/IP)
  • iFCP (Internet Fibre Channel Protocol)
  • iSNS (Internet Storage Name Service)

А также, как уже отмечалось, в январе 2001 в рамках SNIA (Storage Networking Industry Association) был организован IP Storage форум. Сегодня форум включает три подгруппы: FCIP, iFCP, iSCSI. Каждая из которых представляет протокол, который находится под протекцией IETF.

FCIP — созданный на базе TCP/IP туннельный протокол, функцией которого является соединение географически отдаленных FC SAN без какого-либо влияния на FC и IP протоколы.

iFCP — созданный на базе TCP/IP протокол для соединения FC систем хранения данных FC сетей хранение данных, используя IP инфраструктуру совместно или вместо FC коммутационных и маршрутизирующих элементов.

iSCSI — рассматривается выше…

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



Рисунок 5. Блок-схема IP Storage сетей

Fibre Channel over IP

Наименее революционным из трех названых выше является протокол Fibre Channel over IP. Он не вносит практически никаких изменений в структуру SAN и в организацию самых систем хранения данных. Главная идея этого протокола — реализация возможности объединения географически отдаленных сетей хранения данных.

Вот так выглядит стек протокола FCIP:



Рисунок 6. Нижние уровни протокола FCIP

FCIP помогает эффективно решить задачу территориального распределения, и объединения SAN на больших расстояниях. Его основными преимуществами является то, что этот протокол полностью прозрачен для существующих FC SAN сетей и ориентирован на использование инфраструктуры современных MAN/WAN сетей. Таким образом, для обеспечения новой функциональности пользователям, которые ищут возможности связать между собою географически отдаленные FC SAN, будет нужен всего лишь FCIP шлюз и подключение к MAN/WAN сети. Географически распределенная SAN, построенная с помощью FCIP, воспринимается SAN устройствами как обычная FC сеть, а для MAN/WAN сети, к которой она подключенная, она представляет обычный IP трафик.

  • правила инкапсуляции FC кадров для передачи через TCP/IP;
  • правила использования инкапсуляции для создания виртуальной связи между FC устройствами и элементами FC сети;
  • окружение TCP/IP для поддержки создания виртуальной связи и обеспечение тунелирования FC трафика через IP сеть, включая безопасность, целостность данных и вопрос скорости передачи данных.

Среди прикладных задач, которые можно качественно решить с использованием FCIP протокола: удаленное резервирование, восстановление данных и общий доступ к данным. При использовании высокоскоростных MAN/WAN коммуникаций можно также с успехом применять: синхронное дублирование данных и общий распределенный доступ к системам хранения данных.

Internet Fibre Channel Protocol — это протокол, который обеспечивает передачу FC трафика поверх TCP/IP транспорта между шлюзами iFCP. В этом протоколе, транспортный уровень FC замещается транспортом IP сети, трафик между FC устройствами маршрутизируется и коммутируется средствами TCP/IP. Протокол iFCP предоставляет возможность подключать существующие FC системы хранения данных к IP сети с поддержкой сетевых сервисов, которые нужны этим устройствам.

Стек протокола iFCP имеет такой вид:



Рисунок 7. Нижние уровни протокола iFCP

Важной особенностью iFCP является то, что этот протокол обеспечивает FC device-to-device связь (связь между устройствами) через IP сеть, которая является значительно более гибкой схемой, если сравнивать ее со связью SAN-to-SAN. Так, например, если iFCP имеет TCP связь между парами портов N_Port двух FC устройств, такая связь может иметь свой собственный уровень QoS, который будет отличаться от уровня QoS другой пары FC устройств.

Заключение

Подводя итоги, хочется выразить свою твёрдую уверенность в том, что Fibre Channel в ближайшее время никуда не исчезнет, рынок FC SAN будет расти и развиваться. В то же время, IP Storage протоколы предоставят возможность эффективно использовать сети хранения данных в тех прикладных задачах, для которых FC не может обеспечить эффективной реализации. Используя протоколы FCIP и iFCP, сети хранения данных станут географически распределенными. А внедрение iSCSI в свою очередь, даст возможность использования преимуществ SAN в сферах, которые до сих пор остаются нереализованными, или реализуются неэффективно в рамках распространенных сегодня технологий.

Можно с уверенностью утверждать, что концепция построения всемирной сети хранения данных идеально вписывается в развитие современных технологий IP Storage.

Читайте также: