9 сентября 2011 в 17:56

Администрирование → Настройка ISCSI initiator в linux

Abstract: как работает open-iscsi (ISCSI initiator в linux), как его настраивать и чуть-чуть про сам протокол ISCSI.

Лирика: В интернете есть множество статей довольно хорошо объясняющих, как настроить ISCSI target, однако, почему-то, практически нет статей про работу с инициатором. Не смотря на то, что target технически сложнее, административной возни с initiator больше — тут больше запутанных концепций и не очень очевидные принципы работы.

ISCSI

Перед тем, как рассказать про ISCSI — несколько слов о разных типах удалённого доступа к информации в современных сетях.

NAS vs SAN

Существует два метода доступа к данным, находящимся на другом компьютере: файловый (когда у удалённого компьютера запрашивают файл, а какими файловыми системами это сделано — никого не волнует), характерные представители NFS, CIFS (SMB); и блочный — когда у удалённого компьютера запрашивают блоки с дискового носителя (аналогично тому, как их читают с жёсткого диска). В этом случае запрашивающая сторона сама себе делает на блочном устройстве файловую систему, а сервер, отдающий блочное устройство, знать не знает про файловые системы на нём. Первый метод называют NAS (network attached storage), а второй — SAN (storage area network). Названия вообще указывают на другие признаки (SAN подразумевает выделенную сеть до хранилищ), но так сложилось, что NAS — это файлы, а SAN — это блочные устройства по сети. И хотя все (?) понимают, что это неправильные названия, чем дальше, тем больше они закрепляются.

scsi over tcp

Одним из протоколов доступа к блочным устройствам является iscsi. Буква 'i' в названии относится не к продукции эппл, а к Internet ~~Explorer~~. По своей сути это 'scsi over tcp'. Сам протокол SCSI (без буквы 'i') — это весьма сложная конструкция, поскольку он может работать через разные физические среды (например, UWSCSI — параллельная шина, SAS — последовательная — но протокол у них один и тот же). Этот протокол позволяет делать куда больше, чем просто «подтыкать диски к компьютеру» (как это придумано в SATA), например, он поддерживает имена устройств, наличие нескольких линков между блочным устройством и потребителем, поддержку коммутации (ага, SAS-коммутатор, такие даже есть в природе), подключение нескольких потребителей к одному блочному устройству и т.д. Другими словами, этот протокол просто просился в качестве основы для сетевого блочного устройства.

Терминология

В мире SCSI приняты следующие термины:
target — тот, кто предоставляет блочное устройство. Ближайший аналог из обычного компьютерного мира — сервер.
initiator — клиент, тот, кто пользуется блочным устройством. Аналог клиента.
WWID — уникальный идентификатор устройства, его имя. Аналог DNS-имени.
LUN — номер «кусочка» диска, к которому идёт обращение. Ближайший аналог — раздел на жёстком диске.

ISCSI приносит следующие изменения: WWID исчезает, на его место приходит понятие IQN (iSCSI Qualified Name) — то есть чистой воды имя, сходное до степени смешения с DNS (с небольшими отличиями). Вот пример IQN: iqn.2011-09.test:name.

IETD и open-iscsi (сервер и клиент под линукс) приносят ещё одну очень важную концепцию, о которой чаще всего не пишут в руководствах по iscsi — portal. Portal — это, если грубо говорить, несколько target'ов, которые анонсируются одним сервером. Аналогии с www нет, но если бы веб-сервер можно было попросить перечислить все свои virtualhosts, то это было бы оно. portal указывает список target'ов и доступные IP, по которым можно обращаться (да-да, iscsi поддерживает несколько маршрутов от initiator к target).

target

Статья не про target, так что даю очень краткое описание того, что делает target. Он берёт блочное устройство, пришлёпывает к нему имя и LUN и публикет его у себя на портале, после чего позволяет всем желающим (авторизация по вкусу) обращаться к нему.

Вот пример простенького файла конфигурации, думаю, из него будет понятно что делает target (файл конфигурации на примере IET):

Target iqn.2011-09.example:data
        IncomingUser username Pa$$w0rd
        Lun 0 Path=/dev/md1

(сложный от простого отличается только опциями экспорта). Таким образом, если у нас есть target, то мы хотим его подключить. И тут начинается сложное, потому что у initiator'а своя логика, он совсем не похож на тривиальное mount для nfs.

Initiator

В качестве инициатора используется open-iscsi. Итак, самое важное — у него есть режимы работы и состояние. Если мы дадим команду не в том режиме или не учтём состояние, результат будет крайне обескураживающий.

Итак, режимы работы:

Поиск target'ов (discovery)
Подключение к target'у
Работа с подключенным target'ом

Из этого списка вполне понятен жизненный цикл — сначала найти, потом подключиться, потом отключиться, потом снова подключиться. Open-iscsi держит сессию открытой, даже если блочное устройство не используется. Более того, он держит сессию открытой (до определённых пределов, конечно), даже если сервер ушёл в перезагрузку. Сессия iscsi — это не то же самое, что открытое TCP-соединение, iscsi может прозрачно переподключаться к target'у. Отключение/подключение — операции, которыми управляют «снаружи» (либо из другого ПО, либо руками).

Немного о состоянии. После discovery open-iscsi запоминает все найденные target'ы (они хранятся в /etc/iscsi/), другими словами, discovery — операция постоянная, совсем НЕ соответствующая, например, dns resolving). Найденные target можно удалить руками (кстати, частая ошибка — когда у open-iscsi, в результате экспериментов и настройки, пачка найденных target'ов, при попытке логина в которые выползает множество ошибок из-за того, что половина target'ов — старые строчки конфига, которые уже давно не существуют на сервере, но помнятся open-iscsi). Более того, open-iscsi позволяет менять настройки запомненного target'а — и эта «память» влияет на дальнейшую работу с target'ами даже после перезагрузки/перезапуска демона.

Блочное устройство

Второй вопрос, который многих мучает по-началу — куда оно попадает после подключения? open-iscsi создаёт хоть и сетевое, но БЛОЧНОЕ устройство класса SCSI (не зря же оно «я сказя»), то есть получает букву в семействе /dev/sd, например, /dev/sdc. Используется первая свободная буква, т.к. для всей остальной системы это блочное устройство — типичный жёсткий диск, ничем не отличающийся от подключенного через usb-sata или просто напрямую к sata.

Это часто вызывает панику «как я могу узнать имя блочного устройства?». Оно выводится в подробном выводе iscsiadm (# iscsiadm -m session -P 3).

Авторизация

В отличие от SAS/UWSCSI, ISCSI доступно для подключения кому попало. Для защиты от таких, есть логин и пароль (chap), и их передача iscsiadm'у — ещё одна головная боль для начинающих пользователей. Она может осуществляться двумя путями — изменением свойств уже найденного ранее target'а и прописываем логина/пароля в файле конфигурации open-iscsi.
Причина подобных сложностей — в том, что пароль и процесс логина — это атрибуты не пользователя, а системы. ISCSI — это дешёвая версия FC-инфраструктуры, и понятие «пользователь» в контексте человека за клавиатурой тут неприменимо. Если у вас sql-база лежит на блочном устройстве iscsi, то разумеется, вам будет хотеться, чтобы sql-сервер запускался сам, а не после минутки персонального внимания оператора.

Файл конфигурации

Это очень важный файл, потому что помимо логина/пароля он описывает ещё поведение open-iscsi при нахождении ошибок. Он может отдавать ошибку «назад» не сразу, а с некоторой паузой (например, минут в пять, чего достаточно для перезагрузки сервера с данными). Так же там контролируется процесс логина (сколько раз пробовать, сколько ждать между попытками) и всякий тонкий тюнинг самого процесса работы. Заметим, эти параметры довольно важны для работы и вам нужно обязательно понимать, как поведёт ваш iscsi если вынуть сетевой шнурок на 10-20с, например.

Краткий справочник

Я не очень люблю цитировать легконаходимые маны и строчки, так что приведу типовой сценарий употребения iscsi:

сначала мы находим нужные нам target, для этого мы должны знать IP/dns-имя инициатора: iscsiadm -m discovery -t st -p 192.168.0.1 -t st — это команда send targets.

iscsiadm -m node (список найденного для логина)
iscsiadm -m node -l -T iqn.2011-09.example:data (залогиниться, то есть подключиться и создать блочное устройство).
iscsiadm -m session (вывести список того, к чему подключились)
iscsiadm -m session -P3 (вывести его же, но подробнее — в самом конце вывода будет указание на то, какое блочное устройство какому target'у принадлежит).
iscsiadm - m session -u -T iqn.2011-09.example:data (вылогиниться из конкретной )
iscsiadm -m node -l (залогиниться во все обнаруженные target'ы)
iscsiadm -m node -u (вылогиниться из всех target'ов)
iscsiadm -m node --op delete -T iqn.2011-09.example:data (удалить target из обнаруженных).

mulitpath

Ещё один вопрос, важный в серьёзных решениях — поддержка нескольких маршрутов к источнику. Прелесть iscsi — в использовании обычного ip, который может быть обычным образом обработан, как и любой другой трафик (хотя на практике обычно его не маршрутизируют, а только коммутируют — слишком уж великая там нагрузка). Так вот, iscsi поддерживает multipath в режиме «не сопротивляться». Сам по себе open-iscsi не умеет подключаться к нескольким IP одного target'а. Если его подключить к нескольким IP одного target'а, то это приведёт к появлению нескольких блочных устройств.

Однако, решение есть — это multipathd, который находит диски с одинаковым идентифиатором и обрабатывает их как положено в multipath, с настраиваемыми политиками. Эта статья не про multipath, так что подробно объяснять таинство процесса я не буду, однако, вот некоторые важные моменты:

При использовании multipath следует ставить маленькие таймауты — переключение между сбойными путями должно происходить достаточно быстро
В условиях более-менее быстрого канала (10G и выше, во многих случаях гигабит) следует избегать параллелизма нагрузки, так как теряется возможность использовать bio coalesing, что в некоторых типах нагрузки может неприятно ударить по target'у.

Самое читаемое Администрирование

Комментарии (58)

mark_ablov 9 сентября 2011 в 18:08

> IQN (internet query name? не уверен в расшифровке)
iSCSI Qualified Name

amarao 9 сентября 2011 в 18:13

0

спасибо, поправил.

morozsm 9 сентября 2011 в 20:25

Спасибо, отличная статья!

JStingo 9 сентября 2011 в 20:59

У меня такой вопрос. Реально использовать iSCSI на 1GigE для использования как хранилища для виртуальных машин, или обязательно иметь 10GigE или FC? Я понимаю, что все зависит от задачи, которые выполняют виртуалки, но все же, есть ли запас прочности у iSCSI на 1GbitE?

akshakirov 9 сентября 2011 в 21:03

0

Всё же зависит от нагрузки, мониторьте загрузку сети. Если нет денег на 10G, можно использовать Etherchannel из нескольких 1G линков.
- amarao 9 сентября 2011 в 22:01
  
  0
  
  Кстати, в случае с iscsi лучше не городить лишнего, а сделать просто multipath через два обычных гигабитных линка. И надёжнее, и проще, и линейно масштабируется (не хватает? две сетевухи по 2 головы на гигабит дадут аж 4 гигабита...)
amarao 9 сентября 2011 в 21:16

0

Мои наблюдения показывают, что реальная нагрузка редко упирается в сеть. Два гигабитных линка с правильным multipath (то есть в режиме round-robin) обычно покрывают все потребности.
- akshakirov 9 сентября 2011 в 21:26
  
  0
  
  А почему мультипаф, а не LACP?
  - amarao 9 сентября 2011 в 21:33
    
    +2
    
    Потому что multipath честнее, правила у него понятнее, да и в стек устройств оно вписывается лучше. «Не важно, как оно тут очутилось, если диски одинаковые — можно объединять». В частности, можно подключать/удалять на ходу линки (и multipathd их найдёт и включит в path-group), можно определять правила failover'а и возврата на него, тип балансировки и т.д.
    
    Среди всего околодискового, с чем я работал, только multipathd/dm_multipath ни разу не вызвали у меня ощущения «тут кривовато». Идеальная работа, идеальная надёжность (по-крайней мере, IET я ронял, drbd я ронял, nfs я ронял, а вот dm_multipath ни разу не падал, не смотря на самые изощрённые издевательства).
    - akshakirov 9 сентября 2011 в 21:34
      
      0
      
      Спасибо огромное за ответы!
    - Hulo 10 сентября 2011 в 00:58
      
      0
      
      А кто-нибудь shared sas использовал? Типа Dell MD3200, который с двумя контроллерами и двумя БП стоит около $7000, плюс подключение проще — не нужно свитчей, только HBA-адаптеры. Правда, не масштабируется (ограниченно 4 серверами, далее нужны те самые SAS-коммутаторы).
      - amarao 10 сентября 2011 в 15:01
        
        0
        
        Зачем? Надёжность при этом не сильно возрастает (если уж заниматься резервированием, то сразу же делать кластер), два БП — стандартно для серверов. А необходимость делать свою проводную инфраструктуру (то есть запрет на использование обычной 5E/оптики) — плохо.
        
        omnimod 10 сентября 2011 в 15:22
        
        0
        
        DAS (на SAS или SCSI) дешевле FC и быстрее iSCSI. В маленьких инфраструктурах, где не требуется масштабируемость — самое оно.
        
        Hulo 11 сентября 2011 в 21:11
        
        0
        
        В маленьких инфраструктурах может быть 2-3 сервера и требования к надежности. Если поставить shared storage, а операционные системы — на гипервизор, то можно использовать live migration/high availability.
    - giner 10 сентября 2011 в 05:35
      
      0
      
      Какая связь между multipath, IET, drbd и nfs?
      Как вы роняли DRBD? NFS?
      - amarao 10 сентября 2011 в 14:59
        
        0
        
        Связь очень простая — это штуки, связанные с дисковыми устройствами и имеющие модули в ядре.
        
        По списку:
        
        drbd 8.4 срёт трейсами если исчезает указанное в DISK блочное устройство.
        nfs срёт трейсами если указать в exports симлинк на каталог.
giner 9 сентября 2011 в 21:36

+1

Если клиент Windows или Linux, то работает пристойно даже на 100MBit/s. Если же клиент VMware со своим VMFS, то даже на 1GBit/s будет медленно. Дело в том, что VMFS не использует кэш ни на чтение, ни на запись by design, и, как результат, тайминги сетевого доступа вносят большие задержки. При использовании Openfiler проблему отчасти позволяет решить использование fileio вместо blockio. В этом случае активно используется кэш на стороне target-а, но производительности сравнимой, например, с Proxmox, всё равно не получается.
- amarao 9 сентября 2011 в 22:06
  
  +1
  
  Слушайте, я аж загуглил от удивления. Ничего из вышеперечисленного не является приложением — это просто названия сборок софта. Внутри там либо iet, либо STGT/LIO. Кто из них лучше — вот это вопрос. А кто там какие интерфейсы ему пишет…
  
  После некоторого времени с IET'ом, я пришёл к выводу, что динамические target'ы удобнее, чем статика, не то, что «добрый дядя из коробки скрипты собрал».
  - giner 9 сентября 2011 в 22:43
    
    +1
    
    Прошу прощения, но я не понял о чём вы.
    В linux я в качестве initiator использовал open-iscsi (в Proxmox вроде бы он же), в Windows официальный «Microsoft iSCSI Software Initiator», но проблема с VMware не в initiator на, в проприетарной файловой системе VMFS, которая не использует кэширование.
    - JStingo 9 сентября 2011 в 23:20
      
      +1
      
      А кеширование не должно происходить на уровне файловых систем гостевых ОС? Или я как-то не так понимаю проблему?
      - giner 9 сентября 2011 в 23:27
        
        0
        
        О гостях даже речи не идёт. Тормозит уже на связке ESXi <-> iSCSI. Т.е. iSCSI LUN монтируется в /vmfs/xxxxxxxxxx и операции записи в этой директории идут очень медленно.
      - amarao 10 сентября 2011 в 00:10
        
        0
        
        Можно и там, и там. iet поддерживает очень умное кеширование с барьерами (для записи), что есть быть очень гуд.
    - amarao 10 сентября 2011 в 00:07
      
      0
      
      Вы говорите «proxmox», как будто это iscsi target. А это не iscsitarget, это дистрибутив специализированный. Ну всё равно, как если бы два человека обсуждали, где лучше ext4 — в ubuntu или в debian.
      - giner 10 сентября 2011 в 00:30
        
        0
        
        Да нет, Proxmox выступает в качестве клиента.
- multagor 9 сентября 2011 в 23:42
  
  +1
  
  У кого есть деньги на VmWare купит себе СХД с кешом. Таймингов сетевого доступа при грамотной архитектуре не заметил.
  - giner 10 сентября 2011 в 00:35
    
    0
    
    Не скажу про 10Gbit/s, но с 1Gbit/s даже при прямом соединении получается не очень если сравнивать с тем, что работало у нас до VMware.
    - JStingo 10 сентября 2011 в 22:41
      
      0
      
      Как я понял, это личная проблема iSCSI target'а, которые не может прокачать данные.
- Zx48k 10 сентября 2011 в 11:01
  
  0
  
  Ну логика работы vmfs понятна — необходимость целостности данных: если ОС в виртуальной машине записала данные на диск, пусть и виртуальный, то они (данные) должны быть на диске.

akshakirov 9 сентября 2011 в 21:02

Скажите пожалуйста, выбирая iSCSI сравнивали ли его с ATAoE?

amarao 9 сентября 2011 в 21:17

0

Не сравнивал. Основная проблема — ataoe как-то наколеночно выглядит. В перспективах «посмотреть» есть желание, но накладные расходы на target (10-80% одного CPU) выглядят терпимо.
- akshakirov 9 сентября 2011 в 21:25
  
  0
  
  Основные фишки это то что работает оно на L2 уровне, т.е. нет оверхедов на tcp/udp. Мультипаф у него из коробки. Begun её использует в продакшне.
  - amarao 9 сентября 2011 в 21:30
    
    0
    
    multipath «из коробки» вызывает скепсис (потому что у меня нет ни одной претензии к dm_multipath, который с iscsi'евыми дисками работает как с обычными SCSI/SATA, что даёт весьма и весьма широкие возможности по тюнингу «под себя»).
    
    L2 совершенно не является проблемой, потому что на более-менее быстрых линках скорость канала выше скорости дисков, а оверхед от TCP (в процессоре) во многом решается с помощью LRO/GRO/checksumm offload и т.д. на сетевых картах.

qmax 9 сентября 2011 в 22:36

Что происходит и как разруливается ситуация подключения нескольких инициаторов к одному таргету (к одному LUNу)?

giner 9 сентября 2011 в 23:19

0

Судя по всему так же как и SCSI. Если к одному LUN-у, то на в на этом LUN должна быть файловая система обеспечивающая конкурентный доступ или что-то типа LVM, например.
past 9 сентября 2011 в 23:29

0

В этом случае будет неоьходимо обеспечить блокировку, либо кластерным lvm, либо спец. фс типа gfs или ocfs2, либо внешними средствами, как это делает proxmox.
- qmax 9 сентября 2011 в 23:54
  
  0
  
  тоесть на уровне протокола никакой защиты от таких подключений не предусмотрено?
  - amarao 10 сентября 2011 в 00:06
    
    0
    
    это не функция протокола, это фича некоторых серверов. См. ниже.
- amarao 10 сентября 2011 в 00:10
  
  0
  
  Кстати, XCP обходится обычным LVM поверх ISCSI, а блокировки разруливает административными средствами вне хранилища.
  - past 10 сентября 2011 в 08:06
    
    0
    
    Как и proxmox.
  - Breaker 13 сентября 2011 в 10:59
    
    0
    
    Ожидал большего от XCP. В стандартной админилке можно только приатачить сторедж и всё, даже моунта нет. Я уже не говорю про создание ВМ (оффтопик ибо :)). Сделано с закосом под энтерпрайз, но до него еще пилить и пилить(
    - amarao 13 сентября 2011 в 22:55
      
      0
      
      «Стандартная админка» XCP называется 'xe', и она позволяет очень многое. Графические нашлёпки не имеют смысла, т.к. некоторые типы отношений очень плохо визуализируются.
      - Breaker 13 сентября 2011 в 23:53
        
        0
        
        Согласен, но я ожидал что тривиальные задачи там будут реализованы, такие как создание диска/образа под vm, собственно создание самих vm и т.п.
        
        Хотел у вас спросить, если есть не очень глупые вопросы по xen/xcp, можно их вал н-р в личку задать?)
amarao 10 сентября 2011 в 00:06

0

Никак. В смысле, ISCSI поддерживает SCSI-команды, включая блокировки и персистентные блокировки. Соответственно, если те, кто подключаются, к такому сценарию готовы, то ок. Если нет (например, идиот-админ, ext3, которую подключили к двум серверам одновременно), то данные херятся.

Сам протокол вообще такими вопросами не занимается, большинство target'ов позволяет ограничить число инициаторов на target. Соответственно, если выставить в ограничении единицу, то второй просто не сможет подключиться.
- qmax 17 сентября 2011 в 13:14
  
  0
  
  А если залогиниться на таргет несколькими инициаторами, но не монтировать разделы в системе (и вообще не совершать никаких действий с /dev/sdX) — приведёт ли это к каким-нить последствиям?
  
  Происходит ли при логине что-то, кроме операций обнаружения/проверки размера/чтения partition?
  - amarao 18 сентября 2011 в 02:21
    
    0
    
    Происходит где? На инициаторе? Всё, что захочется сделать udev'у (в частности, да, чтение в поисках разных видов разделов). На target'е всё что может быть плохого, происходит на этапе создания target'а.

merlin-vrn 10 сентября 2011 в 15:22

Расскажите, а каким образом нужно конфигурировать ядро? За что отвечают опции ISCSI_TCP (комментарий там такой, будто это и есть сам инициатор), SCSI_ISCSI_ATTRS, ISCSI_IBFT, ISCSI_BOOT_SYSFSISCSI_IBFT_FIND?

В каком направлении копать, если хочется сделать на этом протоколе совсем бездисковую машину?

amarao 10 сентября 2011 в 16:05

+1

Я не уверен, что там вообще нужно что-то особенное. open-iscsi свой модуль грузит, этого достаточно.

Дальше по bootp скачивается initrd в котором сказано «подмонтировать target, рут на нём» и всё.

Сам я с бездисковыми станциями особо не возился, но каких-то специфичных проблем не вижу.

nanodesu 11 сентября 2011 в 05:33

Интересно, почему не видно домашних хранилищ с поддержкой iscsi, по идее более низкий уровень и требования к ЦП ниже.
Нашла QNAP TS-119, но это скорее традиционный комбайн с торрентокачалкой, да и цена соответствующая — 9.5к без диска.

amarao 11 сентября 2011 в 10:46

0

У iscsi нагрузка на процессор на target выше, чем у SMB/NFS, это связано с довольно сложной интерпретацией scsi-команд.

Плюс, нужно понимать, что в отсутствие кластеризованных файловых систем, у диска будет монопольное использование, то есть никакого «файлы доступны и с ноута, и с лэптопа».
- nanodesu 11 сентября 2011 в 18:44
  
  0
  
  Понимаю, но мне бы это вполне подошло — везде линукс, поддержка ФС всегда есть.
  - amarao 12 сентября 2011 в 23:44
    
    0
    
    Кластеризованные FS это сложнее, чем «общая шара». В этом и вечная проблема SAN/NAS — в случае файлового доступа всё просто для клиента, но сложно для сервера (какой-нибудь fsck на шаре на 300-500 пользователей — дохлый номер дождаться завершения), блочный доступ — просто для сервера, просто для клиента, непросто обеспечивать взаимодействие.
cadmi 12 сентября 2011 в 16:55

0

У меня стоит Synology, из самых младших (210j) — iscsi работает нормально. У меня там несколько target'ов используются.

Стоит, конечно, примерно столько же. Но я тогда не понимаю, что такое «домашнее хранилище». Куда уж «домашнее» то? :)

pazhitnov 12 сентября 2011 в 16:41

Спасибо за статью! Вот уже год меня мучает (пока) теоретический вопрос: есть линукс-машина с пишущим SATA DVD-RW. Можно ли посредством iSCSI-over-WiFi писать диски с нетбука с установленной Windows XP?

qmax 16 сентября 2011 в 15:46

Что-то недогоняю я.

На одном target может быть несколько LUN (разделов диска, LV).
iscsi-инициатор логинится на таргет и тутже создаёт блочное устройство.
какой LUN при этом коннектится?

qmax 16 сентября 2011 в 16:10

0

ага.
каждый lun образует отдельное блочное устройство.
не совсем очевидно из статьи…
amarao 17 сентября 2011 в 04:14

0

А вот это очень интересный вопрос. Я никогда с многолуновыми target не работал. У меня есть две версии: либо будет создано несколько блочных устройств (по числу lun'ов), либо его нужно (как-то?) указать при создании.
- qmax 17 сентября 2011 в 13:11
  
  0
  
  Вот меня смутило то, что lun нигде никак не указывается и вообще не фигурирует в документации (и в статье).
  Методом тыка уже разобрался — при логине target подключает все свои LUNы, и кадый образует свой sdX.
  
  Как я понял, это как раз нормальная практика — делать отдельный target на каждый раздел.
  Так удобнее и в плане идентификации, и в плане возможности подключаться к разделам разными инициаторами.
  - amarao 18 сентября 2011 в 02:22
    
    0
    
    Ага. LUN'ы — это тяжкое наследие древних SCSI и юниксов, когда LVM не существовало и нормально разделы было не порезать. Точнее, они нужны были для того, чтобы разные приложения/ОС работали с разными блочными устройствами (находясь на одном) и не портили друг другу нервы.
    
    В условиях iscsi это атавизм.

mark_ablov 9 сентября 2011 в 18:08

+1

> IQN (internet query name? не уверен в расшифровке)
iSCSI Qualified Name
- amarao 9 сентября 2011 в 18:13
  
  0
  
  спасибо, поправил.
morozsm 9 сентября 2011 в 20:25

0

Спасибо, отличная статья!
JStingo 9 сентября 2011 в 20:59

0

У меня такой вопрос. Реально использовать iSCSI на 1GigE для использования как хранилища для виртуальных машин, или обязательно иметь 10GigE или FC? Я понимаю, что все зависит от задачи, которые выполняют виртуалки, но все же, есть ли запас прочности у iSCSI на 1GbitE?
- akshakirov 9 сентября 2011 в 21:03
  
  0
  
  Всё же зависит от нагрузки, мониторьте загрузку сети. Если нет денег на 10G, можно использовать Etherchannel из нескольких 1G линков.
  - amarao 9 сентября 2011 в 22:01
    
    0
    
    Кстати, в случае с iscsi лучше не городить лишнего, а сделать просто multipath через два обычных гигабитных линка. И надёжнее, и проще, и линейно масштабируется (не хватает? две сетевухи по 2 головы на гигабит дадут аж 4 гигабита...)
- amarao 9 сентября 2011 в 21:16
  
  0
  
  Мои наблюдения показывают, что реальная нагрузка редко упирается в сеть. Два гигабитных линка с правильным multipath (то есть в режиме round-robin) обычно покрывают все потребности.
  - akshakirov 9 сентября 2011 в 21:26
    
    0
    
    А почему мультипаф, а не LACP?
    - amarao 9 сентября 2011 в 21:33
      
      +2
      
      Потому что multipath честнее, правила у него понятнее, да и в стек устройств оно вписывается лучше. «Не важно, как оно тут очутилось, если диски одинаковые — можно объединять». В частности, можно подключать/удалять на ходу линки (и multipathd их найдёт и включит в path-group), можно определять правила failover'а и возврата на него, тип балансировки и т.д.
      
      Среди всего околодискового, с чем я работал, только multipathd/dm_multipath ни разу не вызвали у меня ощущения «тут кривовато». Идеальная работа, идеальная надёжность (по-крайней мере, IET я ронял, drbd я ронял, nfs я ронял, а вот dm_multipath ни разу не падал, не смотря на самые изощрённые издевательства).
      - akshakirov 9 сентября 2011 в 21:34
        
        0
        
        Спасибо огромное за ответы!
      - Hulo 10 сентября 2011 в 00:58
        
        0
        
        А кто-нибудь shared sas использовал? Типа Dell MD3200, который с двумя контроллерами и двумя БП стоит около $7000, плюс подключение проще — не нужно свитчей, только HBA-адаптеры. Правда, не масштабируется (ограниченно 4 серверами, далее нужны те самые SAS-коммутаторы).
        
        amarao 10 сентября 2011 в 15:01
        
        0
        
        Зачем? Надёжность при этом не сильно возрастает (если уж заниматься резервированием, то сразу же делать кластер), два БП — стандартно для серверов. А необходимость делать свою проводную инфраструктуру (то есть запрет на использование обычной 5E/оптики) — плохо.
        
        omnimod 10 сентября 2011 в 15:22
        
        0
        
        DAS (на SAS или SCSI) дешевле FC и быстрее iSCSI. В маленьких инфраструктурах, где не требуется масштабируемость — самое оно.
        
        Hulo 11 сентября 2011 в 21:11
        
        0
        
        В маленьких инфраструктурах может быть 2-3 сервера и требования к надежности. Если поставить shared storage, а операционные системы — на гипервизор, то можно использовать live migration/high availability.
      - giner 10 сентября 2011 в 05:35
        
        0
        
        Какая связь между multipath, IET, drbd и nfs?
        Как вы роняли DRBD? NFS?
        
        amarao 10 сентября 2011 в 14:59
        
        0
        
        Связь очень простая — это штуки, связанные с дисковыми устройствами и имеющие модули в ядре.
        
        По списку:
        
        drbd 8.4 срёт трейсами если исчезает указанное в DISK блочное устройство.
        nfs срёт трейсами если указать в exports симлинк на каталог.
- giner 9 сентября 2011 в 21:36
  
  +1
  
  Если клиент Windows или Linux, то работает пристойно даже на 100MBit/s. Если же клиент VMware со своим VMFS, то даже на 1GBit/s будет медленно. Дело в том, что VMFS не использует кэш ни на чтение, ни на запись by design, и, как результат, тайминги сетевого доступа вносят большие задержки. При использовании Openfiler проблему отчасти позволяет решить использование fileio вместо blockio. В этом случае активно используется кэш на стороне target-а, но производительности сравнимой, например, с Proxmox, всё равно не получается.
  - amarao 9 сентября 2011 в 22:06
    
    +1
    
    Слушайте, я аж загуглил от удивления. Ничего из вышеперечисленного не является приложением — это просто названия сборок софта. Внутри там либо iet, либо STGT/LIO. Кто из них лучше — вот это вопрос. А кто там какие интерфейсы ему пишет…
    
    После некоторого времени с IET'ом, я пришёл к выводу, что динамические target'ы удобнее, чем статика, не то, что «добрый дядя из коробки скрипты собрал».
    - giner 9 сентября 2011 в 22:43
      
      +1
      
      Прошу прощения, но я не понял о чём вы.
      В linux я в качестве initiator использовал open-iscsi (в Proxmox вроде бы он же), в Windows официальный «Microsoft iSCSI Software Initiator», но проблема с VMware не в initiator на, в проприетарной файловой системе VMFS, которая не использует кэширование.
      - JStingo 9 сентября 2011 в 23:20
        
        +1
        
        А кеширование не должно происходить на уровне файловых систем гостевых ОС? Или я как-то не так понимаю проблему?
        
        giner 9 сентября 2011 в 23:27
        
        0
        
        О гостях даже речи не идёт. Тормозит уже на связке ESXi <-> iSCSI. Т.е. iSCSI LUN монтируется в /vmfs/xxxxxxxxxx и операции записи в этой директории идут очень медленно.
        
        amarao 10 сентября 2011 в 00:10
        
        0
        
        Можно и там, и там. iet поддерживает очень умное кеширование с барьерами (для записи), что есть быть очень гуд.
      - amarao 10 сентября 2011 в 00:07
        
        0
        
        Вы говорите «proxmox», как будто это iscsi target. А это не iscsitarget, это дистрибутив специализированный. Ну всё равно, как если бы два человека обсуждали, где лучше ext4 — в ubuntu или в debian.
        
        giner 10 сентября 2011 в 00:30
        
        0
        
        Да нет, Proxmox выступает в качестве клиента.
  - multagor 9 сентября 2011 в 23:42
    
    +1
    
    У кого есть деньги на VmWare купит себе СХД с кешом. Таймингов сетевого доступа при грамотной архитектуре не заметил.
    - giner 10 сентября 2011 в 00:35
      
      0
      
      Не скажу про 10Gbit/s, но с 1Gbit/s даже при прямом соединении получается не очень если сравнивать с тем, что работало у нас до VMware.
      - JStingo 10 сентября 2011 в 22:41
        
        0
        
        Как я понял, это личная проблема iSCSI target'а, которые не может прокачать данные.
  - Zx48k 10 сентября 2011 в 11:01
    
    0
    
    Ну логика работы vmfs понятна — необходимость целостности данных: если ОС в виртуальной машине записала данные на диск, пусть и виртуальный, то они (данные) должны быть на диске.
akshakirov 9 сентября 2011 в 21:02

0

Скажите пожалуйста, выбирая iSCSI сравнивали ли его с ATAoE?
- amarao 9 сентября 2011 в 21:17
  
  0
  
  Не сравнивал. Основная проблема — ataoe как-то наколеночно выглядит. В перспективах «посмотреть» есть желание, но накладные расходы на target (10-80% одного CPU) выглядят терпимо.
  - akshakirov 9 сентября 2011 в 21:25
    
    0
    
    Основные фишки это то что работает оно на L2 уровне, т.е. нет оверхедов на tcp/udp. Мультипаф у него из коробки. Begun её использует в продакшне.
    - amarao 9 сентября 2011 в 21:30
      
      0
      
      multipath «из коробки» вызывает скепсис (потому что у меня нет ни одной претензии к dm_multipath, который с iscsi'евыми дисками работает как с обычными SCSI/SATA, что даёт весьма и весьма широкие возможности по тюнингу «под себя»).
      
      L2 совершенно не является проблемой, потому что на более-менее быстрых линках скорость канала выше скорости дисков, а оверхед от TCP (в процессоре) во многом решается с помощью LRO/GRO/checksumm offload и т.д. на сетевых картах.
qmax 9 сентября 2011 в 22:36

0

Что происходит и как разруливается ситуация подключения нескольких инициаторов к одному таргету (к одному LUNу)?
- giner 9 сентября 2011 в 23:19
  
  0
  
  Судя по всему так же как и SCSI. Если к одному LUN-у, то на в на этом LUN должна быть файловая система обеспечивающая конкурентный доступ или что-то типа LVM, например.
- past 9 сентября 2011 в 23:29
  
  0
  
  В этом случае будет неоьходимо обеспечить блокировку, либо кластерным lvm, либо спец. фс типа gfs или ocfs2, либо внешними средствами, как это делает proxmox.
  - qmax 9 сентября 2011 в 23:54
    
    0
    
    тоесть на уровне протокола никакой защиты от таких подключений не предусмотрено?
    - amarao 10 сентября 2011 в 00:06
      
      0
      
      это не функция протокола, это фича некоторых серверов. См. ниже.
  - amarao 10 сентября 2011 в 00:10
    
    0
    
    Кстати, XCP обходится обычным LVM поверх ISCSI, а блокировки разруливает административными средствами вне хранилища.
    - past 10 сентября 2011 в 08:06
      
      0
      
      Как и proxmox.
    - Breaker 13 сентября 2011 в 10:59
      
      0
      
      Ожидал большего от XCP. В стандартной админилке можно только приатачить сторедж и всё, даже моунта нет. Я уже не говорю про создание ВМ (оффтопик ибо :)). Сделано с закосом под энтерпрайз, но до него еще пилить и пилить(
      - amarao 13 сентября 2011 в 22:55
        
        0
        
        «Стандартная админка» XCP называется 'xe', и она позволяет очень многое. Графические нашлёпки не имеют смысла, т.к. некоторые типы отношений очень плохо визуализируются.
        
        Breaker 13 сентября 2011 в 23:53
        
        0
        
        Согласен, но я ожидал что тривиальные задачи там будут реализованы, такие как создание диска/образа под vm, собственно создание самих vm и т.п.
        
        Хотел у вас спросить, если есть не очень глупые вопросы по xen/xcp, можно их вал н-р в личку задать?)
- amarao 10 сентября 2011 в 00:06
  
  0
  
  Никак. В смысле, ISCSI поддерживает SCSI-команды, включая блокировки и персистентные блокировки. Соответственно, если те, кто подключаются, к такому сценарию готовы, то ок. Если нет (например, идиот-админ, ext3, которую подключили к двум серверам одновременно), то данные херятся.
  
  Сам протокол вообще такими вопросами не занимается, большинство target'ов позволяет ограничить число инициаторов на target. Соответственно, если выставить в ограничении единицу, то второй просто не сможет подключиться.
  - qmax 17 сентября 2011 в 13:14
    
    0
    
    А если залогиниться на таргет несколькими инициаторами, но не монтировать разделы в системе (и вообще не совершать никаких действий с /dev/sdX) — приведёт ли это к каким-нить последствиям?
    
    Происходит ли при логине что-то, кроме операций обнаружения/проверки размера/чтения partition?
    - amarao 18 сентября 2011 в 02:21
      
      0
      
      Происходит где? На инициаторе? Всё, что захочется сделать udev'у (в частности, да, чтение в поисках разных видов разделов). На target'е всё что может быть плохого, происходит на этапе создания target'а.
merlin-vrn 10 сентября 2011 в 15:22

+1

Расскажите, а каким образом нужно конфигурировать ядро? За что отвечают опции ISCSI_TCP (комментарий там такой, будто это и есть сам инициатор), SCSI_ISCSI_ATTRS, ISCSI_IBFT, ISCSI_BOOT_SYSFSISCSI_IBFT_FIND?

В каком направлении копать, если хочется сделать на этом протоколе совсем бездисковую машину?
- amarao 10 сентября 2011 в 16:05
  
  +1
  
  Я не уверен, что там вообще нужно что-то особенное. open-iscsi свой модуль грузит, этого достаточно.
  
  Дальше по bootp скачивается initrd в котором сказано «подмонтировать target, рут на нём» и всё.
  
  Сам я с бездисковыми станциями особо не возился, но каких-то специфичных проблем не вижу.
nanodesu 11 сентября 2011 в 05:33

0

Интересно, почему не видно домашних хранилищ с поддержкой iscsi, по идее более низкий уровень и требования к ЦП ниже.
Нашла QNAP TS-119, но это скорее традиционный комбайн с торрентокачалкой, да и цена соответствующая — 9.5к без диска.
- amarao 11 сентября 2011 в 10:46
  
  0
  
  У iscsi нагрузка на процессор на target выше, чем у SMB/NFS, это связано с довольно сложной интерпретацией scsi-команд.
  
  Плюс, нужно понимать, что в отсутствие кластеризованных файловых систем, у диска будет монопольное использование, то есть никакого «файлы доступны и с ноута, и с лэптопа».
  - nanodesu 11 сентября 2011 в 18:44
    
    0
    
    Понимаю, но мне бы это вполне подошло — везде линукс, поддержка ФС всегда есть.
    - amarao 12 сентября 2011 в 23:44
      
      0
      
      Кластеризованные FS это сложнее, чем «общая шара». В этом и вечная проблема SAN/NAS — в случае файлового доступа всё просто для клиента, но сложно для сервера (какой-нибудь fsck на шаре на 300-500 пользователей — дохлый номер дождаться завершения), блочный доступ — просто для сервера, просто для клиента, непросто обеспечивать взаимодействие.
- cadmi 12 сентября 2011 в 16:55
  
  0
  
  У меня стоит Synology, из самых младших (210j) — iscsi работает нормально. У меня там несколько target'ов используются.
  
  Стоит, конечно, примерно столько же. Но я тогда не понимаю, что такое «домашнее хранилище». Куда уж «домашнее» то? :)
pazhitnov 12 сентября 2011 в 16:41

0

Спасибо за статью! Вот уже год меня мучает (пока) теоретический вопрос: есть линукс-машина с пишущим SATA DVD-RW. Можно ли посредством iSCSI-over-WiFi писать диски с нетбука с установленной Windows XP?
qmax 16 сентября 2011 в 15:46

0

Что-то недогоняю я.

На одном target может быть несколько LUN (разделов диска, LV).
iscsi-инициатор логинится на таргет и тутже создаёт блочное устройство.
какой LUN при этом коннектится?
- qmax 16 сентября 2011 в 16:10
  
  0
  
  ага.
  каждый lun образует отдельное блочное устройство.
  не совсем очевидно из статьи…
- amarao 17 сентября 2011 в 04:14
  
  0
  
  А вот это очень интересный вопрос. Я никогда с многолуновыми target не работал. У меня есть две версии: либо будет создано несколько блочных устройств (по числу lun'ов), либо его нужно (как-то?) указать при создании.
  - qmax 17 сентября 2011 в 13:11
    
    0
    
    Вот меня смутило то, что lun нигде никак не указывается и вообще не фигурирует в документации (и в статье).
    Методом тыка уже разобрался — при логине target подключает все свои LUNы, и кадый образует свой sdX.
    
    Как я понял, это как раз нормальная практика — делать отдельный target на каждый раздел.
    Так удобнее и в плане идентификации, и в плане возможности подключаться к разделам разными инициаторами.
    - amarao 18 сентября 2011 в 02:22
      
      0
      
      Ага. LUN'ы — это тяжкое наследие древних SCSI и юниксов, когда LVM не существовало и нормально разделы было не порезать. Точнее, они нужны были для того, чтобы разные приложения/ОС работали с разными блочными устройствами (находясь на одном) и не портили друг другу нервы.
      
      В условиях iscsi это атавизм.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.