Linux Network Administration — iSCSI: почти взрослый SAN

Продолжение статей о всяческих SAN-технологиях. В прошлой серии я рассказал вам о AoE. Но если малыш AoE вызывает вопросы, основной из них - "а зачем он вообще нужен?", то с iSCSI таких вопросов вы, скорее всего, задавать не станете. iSCSI - уже совсем не малыш. только спецификация протокола занимает 257 страниц (пруф), сравните с AoE (12 :).
Протокол iSCSI (Internet Small Computer System Interface), в отличие от AoE, базируется на TCP/IP, что означает, что нам доступна куча плюшек - от маршрутизации до QoS. Так же как и AoE, он предназначен для экспорта в сеть блочных устройств (файлов), но, при этом, он имеет гораздо больше возможностей. Более того, iSCSI в определенный момент даже замахнулся на рынок FCP, но, к сожалению или к счастью, особенно из этого ничего не получилось. Более подробно об iSCSI вы можете прочитать здесь: http://www.ixbt.com/storage/iscsi.shtml.
А пока я вам расскажу об установке (что просто) и настройке (что интересно) iSCSI-target на Gentoo.


Убедитесь, что у вас в ядре включен CRC32c CRC algorithm (Cryptographic options -> Cryptographic API -> CRC32c CRC algorithm в menuconfig) и приступайте:

-
#echo sys-block/iscsitarget >> /etc/portage/package.keywords

-
#emerge -av iscsitarget

Собственно и всех делов. Помните, что каждый раз при пересборке ядра вам нужно будет пересобирать и iscsitarget для сборки модулей.

При старте сервиса вы обнаружите кучу страшных матюков:
-
# /etc/init.d/ietd start
* Caching service dependencies ... < ok >
* net.core.rmem_max (108544) is lower than recommended 1048576
* net.core.rmem_default (108544) is lower than recommended 1048576
* net.core.wmem_max (108544) is lower than recommended 1048576
* net.core.wmem_default (108544) is lower than recommended 1048576
* net.ipv4.tcp_mem:min (44640) is lower than recommended 1048576
* net.ipv4.tcp_mem:default (59520) is lower than recommended 1048576
* net.ipv4.tcp_mem:max (89280) is lower than recommended 1048576
* net.ipv4.tcp_rmem:min (4096) is lower than recommended 1048576
* net.ipv4.tcp_rmem:default (87380) is lower than recommended 1048576
* net.ipv4.tcp_wmem:min (4096) is lower than recommended 1048576
* net.ipv4.tcp_wmem:default (16384) is lower than recommended 1048576
* Loading iSCSI-Target modules - iscsi_trgt ... < ok >
* Starting iSCSI Enterprise Target ...

Это связано с тем, что протокол весьма грузный и для нормальной производительности дефолтных настроек ядра просто не хватает. Работать конечно будет, но меееееееееедленно. Итак, открываем /etc/sysctl.conf и дописываем туда:

net.core.rmem_max = 1073741824
net.core.wmem_max = 1073741824

net.ipv4.tcp_rmem = 1048576 16777216 1073741824
net.ipv4.tcp_wmem = 1048576 16770216 1073741824
net.ipv4.tcp_mem = 1048576 16770216 1073741824

После чего или перезагружаем машинку, или вручную задаем параметры:

-
#echo 1073741824 >> /proc/sys/net/core/rmem_max

-
#echo 1073741824 >> /proc/sys/net/core/wmem_max

-
#echo 1048576 16777216 1073741824 >> /proc/sys/net/ipv4/tcp_rmem

-
#echo 1048576 16777216 1073741824 >> /proc/sys/net/ipv4/tcp_wmem

-
#echo 1048576 16777216 1073741824 >> /proc/sys/net/ipv4/tcp_mem

Для того чтобы наша карточка пропускала Jumbo-кадры нужно увеличить на ней MTU до 9000:

временно:
#ifconfig eth0 mtu 9000

или надолго - пишем в /etc/conf.d/net:
mtu_eth0="9000"

Первичные настройки готовы. А теперь самое вкусное: /etc/ietd.conf.

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

Target iqn.2090-04.local.gravitsapa:storage.winxp.sp3.buhgalter
Lun 0 Path=/var/iscsi/buhlalter.img,Type=fileio,IOMode=ro
Alias buhgalter
MaxSessions 1

Далее идут параметры файла конфигурации с моими комментариями

Итак:
Всё, что в конфиге идет до описания первого таргета принадлежит к глобальным настройкам.

Параметр "iSNSServer" - iSNS сервер, на котором вы хотите зарегистрирвоать свой портал таргетов.
Параметр "iSNSAccessControl" - предназначен для предоставления контроля доступа инициаторов через iSNS сервер
Параметр "IncomingUser" определяет логин и пароль, которые должен предоставить инициатор - пар логин/пароль может быть несколько.
Если используется взаимная авторизация, "OutgoingUser" определяет логин/пароль, которые таргет предоставляет инициатору. Очевидно, разрешена только одна пара OutgoingUser.

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

1 2 3 4 5

#iSNSServer 192.168.1.16 #iSNSAccessControl No #IncomingUser joe secret #OutgoingUser jack 12charsecret

Описание таргета начинается с ключевого слова "Target" и его имени. Имя должно быть уникальным. Стандарт определяет имя таргета следующим образом: iqn.yyyy-mm.server.name<:identifier>

"yyyy-mm" - дата, до которой домен считается действительным, не уделяйте этому особого внимания и свободно указывайте год, до которого собираетесь дожить.
server.name - доменное имя вашего сервера в обратном порядке, например local.company.server
:identifier имя для вашего таргета, например :storage.boot.fedora

1	#Target iqn.2001-04.com.example:storage.disk2.sys1.xyz

Пользователи конкретного таргета:
Правила ровно такие же как и у глобальных настроек. Если не хотите использовать аутентификацию, просто оставьте эти строчки закомментированными.

1 2	#IncomingUser joe secret #OutgoingUser jim 12charpasswd

Описание LUN'ов
В качестве экспортируемых блочных устройств вы можете указать собственно блочные устройства, обычные файлы (только в режиме fileio), LVM и RAID.

1	#Lun 0 Path=/dev/sdc,Type=fileio,IOMode=ro

LUN - Logical unit number - номер (адрес) блочного устройсва в таргете. должен начинатся с 0. У каждого таргета должен быть как минимум Lun 0.
Path путь к файлу или блочному устройству
Type указывает тип отношений между таргетом и указанным устройством
Type может быть:
fileio (используется по умолчанию). В этом случае в качестве устройства вы можете указать любой файл, виртуальное (LVM, программный RAID) или блочное устройство
В режиме blockio таргет работает с блочными устройствами напрямую, минуя кэш. Это даёт возможность эффективной обработки нелинейной передачи секторов (в виртуальных окружениях) и передачи больших блоков (медиа-серверы).Этот режим идеально подходит для работы с высокопроизводительными устройствами и для приложений, которые не требуют кэширования между приложением и диском или требуют высокой пропускной способности.
Существует так же режим nullio, в котором таргет работает с неким безымянным вирутальным устройством указанного размера (параметр Size). Полезным это может быть только для оценки скорости работы. Все записи на это устройсво будут потеряны, а при чтении вы получите случайные данные.

IOMode По умолчанию, LUN находится в режиме записи/чтения, но, указав этот параметр вы можете изменить эту досадную оплошность. IOMode имеет несколько режимов:
ro - LUN находится в режиме "только для чтения"
wb - режим отложенной записи. т.е. сначала вся запись производится в кэш. Этот режим не работает в случае, если тип утройства утановлен в blockio, так как он не поддерживает режим кэширования. Нужно быть достаточно осторожным, потому как, в случае проблем с питанием, данные, оставшиеся в кеше, не будут записаны.

1	#Alias Test

Псевдоним для таргета (Почти никогда не используется)

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

1	#MaxConnections 1

#Количество соединений на сессию. Пока поддерживается только 1

1	#MaxSessions 0

# Количество сессий на таргет, 0 = ограничение отсутствует

Постараюсь объяснить схему общения между таргетом и инициатором.
Исходящие данные протокола iSCSI (пользовательские даные от инициатора к таргету или управляющие комманды) могут передаваться по запросу (синхронизированные данные) или без (соответсвенно, несинхронизированные).
R2T - это пакеты. которые обчеспечивают синхронизацию общения между инициатором и таргетом. По запросу данные отправляются в ответ на R2T пакеты. Без запроса данные могут отправляться вместе с уже сформированным пакетом (ImmediateData) или отдельным пакетом.
Инициатор может отправлять ImmediateData размером не превышающим установленный параметром FirstBurtsLength.
Разрешение отправки несинхронизировннаых данных позволит вам уменьшить задержки при передаче (инициатор не будет ждать R2T пакета чтобы отправить данные). Плюс ко всему, вы уменьшите накладные расходы протокола как по пропускной способности канала, так и по скорости выполнения.

Параметр InitialR2T
Этот параметр используется для отключения включенного по умолчанию использования R2T. Отключение этого параметра позволит инициатору отправлять комманды таргету так, как будто он уже получил R2T пакет. Отключение работает по взаимному НЕсогласию, т.е. только в том случае, если и у инициатора и у таргета этот параметр установлен в No. Когда этот параметр включен, несинхронизированные данные можно отправить только вместе с уже сформированным пакетом данных.

1	#InitialR2T Yes

Параметр ImmediateData
Работает по взаимному согласию. Чтобы иметь возможность отправлять ImmediateData и у инициатора и у таргета этот параметр должен быть установлен в Yes.

1	#ImmediateData Yes

Комбинации вышеописанных параметров и их эффект:
1. ImmediateData = No, InitialR2T = No
Несинхронизировнные данные отправлять можно, но только отдельными пакетами
2. ImmediateData = Yes, InitialR2T = No
Несинхронизированные данные можно отправлять как отдельно так и с уже сформироваными пакетами (ImmediateData)
3. ImmediateData = No, InitialR2T = Yes
Несинхронизированные данные отправлять нельзя
4. ImmediateData = Yes, InitialR2T = Yes (По умолчанию)
Несинхронизированные даные можно отправлять ТОЛЬКО с уже сформированными пакетами

Для закрепления пройденного материала вот вам табличка.
+----------+-------------+------------------+--------------+
|InitialR2T|ImmediateData| Unsolicited |Immediate Data|
| | | Data Out PDUs | |
+----------+-------------+------------------+--------------+
| No | No | Yes | No |
+----------+-------------+------------------+--------------+
| No | Yes | Yes | Yes |
+----------+-------------+------------------+--------------+
| Yes | No | No | No |
+----------+-------------+------------------+--------------+
| Yes | Yes | No | Yes |
+----------+-------------+------------------+--------------+
Дальше всё немного проще и понятнее:

1	#MaxRecvDataSegmentLength 8192

# максимальный размер данных в получаемых фрагментах

1	#MaxXmitDataSegmentLength 8192

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

1	#MaxBurstLength 262144

# максимальный размер данных, готовых к отправке

1	#FirstBurstLength 65536

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

1	#DefaultTime2Wait 2

# Сколько секунд ждать инициатор до дисконнекта
# Не используется

1	#DefaultTime2Retain 20

# Сколько секунд сохранять комманды после дисконнекта
# Не используется

1	#DataPDUInOrder Yes

# Данные во фрагментах упорядочены?
# Поддерживаются только упорядоченные данные

1	#DataSequenceInOrder Yes

# Фрагмены в последовательностях упорядочены:
# Поддерживаются только упорядоченные

1	#ErrorRecoveryLevel 0

# Поддерживается только 0 уровень

1	#HeaderDigest None,CRC32C

# список алгоритмов контрольной суммы заголовков фрагментов.Возможны варианты None или CRC32C или оба через запятую. Если указан только один, инициатор должен согласиться с этим, иначе соединение будет разорвано.

1	#DataDigest None,CRC32C

# Список алгоритмов контрольной суммы данных во фрагментах. Логика такая же как и у параметра выше.

1	#NOPInterval 0

# Интервал пинга в секундах (0 - не пинговать)

1	#NOPTimeout 0

# Таймаут ответа на пинг. Если 0 или больше чем NOPInterval, используется NOPINterval

1	#Wthreads 8

# Количество потоков ввода-вывода

1	#QueuedCommands 32

# Количество комманд в очереди