Настройка ISCSI initiator в linux

[@mark_ablov]

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

[@amarao]

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

[@morozsm]

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

[@JStingo]

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

[@akshakirov]

Всё же зависит от нагрузки, мониторьте загрузку сети. Если нет денег на 10G, можно использовать Etherchannel из нескольких 1G линков.

[@amarao]

Кстати, в случае с iscsi лучше не городить лишнего, а сделать просто multipath через два обычных гигабитных линка. И надёжнее, и проще, и линейно масштабируется (не хватает? две сетевухи по 2 головы на гигабит дадут аж 4 гигабита...)

[@amarao]

Мои наблюдения показывают, что реальная нагрузка редко упирается в сеть. Два гигабитных линка с правильным multipath (то есть в режиме round-robin) обычно покрывают все потребности.

[@akshakirov]

А почему мультипаф, а не LACP?

[@amarao]

Потому что multipath честнее, правила у него понятнее, да и в стек устройств оно вписывается лучше. «Не важно, как оно тут очутилось, если диски одинаковые — можно объединять». В частности, можно подключать/удалять на ходу линки (и multipathd их найдёт и включит в path-group), можно определять правила failover'а и возврата на него, тип балансировки и т.д.

Среди всего околодискового, с чем я работал, только multipathd/dm_multipath ни разу не вызвали у меня ощущения «тут кривовато». Идеальная работа, идеальная надёжность (по-крайней мере, IET я ронял, drbd я ронял, nfs я ронял, а вот dm_multipath ни разу не падал, не смотря на самые изощрённые издевательства).

[@akshakirov]

Спасибо огромное за ответы!

[@Hulo]

А кто-нибудь shared sas использовал? Типа Dell MD3200, который с двумя контроллерами и двумя БП стоит около $7000, плюс подключение проще — не нужно свитчей, только HBA-адаптеры. Правда, не масштабируется (ограниченно 4 серверами, далее нужны те самые SAS-коммутаторы).

[@amarao]

Зачем? Надёжность при этом не сильно возрастает (если уж заниматься резервированием, то сразу же делать кластер), два БП — стандартно для серверов. А необходимость делать свою проводную инфраструктуру (то есть запрет на использование обычной 5E/оптики) — плохо.

[@omnimod]

DAS (на SAS или SCSI) дешевле FC и быстрее iSCSI. В маленьких инфраструктурах, где не требуется масштабируемость — самое оно.

[@Hulo]

В маленьких инфраструктурах может быть 2-3 сервера и требования к надежности. Если поставить shared storage, а операционные системы — на гипервизор, то можно использовать live migration/high availability.

[@giner]

Какая связь между multipath, IET, drbd и nfs?
Как вы роняли DRBD? NFS?

[@amarao]

Связь очень простая — это штуки, связанные с дисковыми устройствами и имеющие модули в ядре.

По списку:

drbd 8.4 срёт трейсами если исчезает указанное в DISK блочное устройство.
nfs срёт трейсами если указать в exports симлинк на каталог.

[@giner]

Если клиент Windows или Linux, то работает пристойно даже на 100MBit/s. Если же клиент VMware со своим VMFS, то даже на 1GBit/s будет медленно. Дело в том, что VMFS не использует кэш ни на чтение, ни на запись by design, и, как результат, тайминги сетевого доступа вносят большие задержки. При использовании Openfiler проблему отчасти позволяет решить использование fileio вместо blockio. В этом случае активно используется кэш на стороне target-а, но производительности сравнимой, например, с Proxmox, всё равно не получается.

[@amarao]

Слушайте, я аж загуглил от удивления. Ничего из вышеперечисленного не является приложением — это просто названия сборок софта. Внутри там либо iet, либо STGT/LIO. Кто из них лучше — вот это вопрос. А кто там какие интерфейсы ему пишет…

После некоторого времени с IET'ом, я пришёл к выводу, что динамические target'ы удобнее, чем статика, не то, что «добрый дядя из коробки скрипты собрал».

[@giner]

Прошу прощения, но я не понял о чём вы.
В linux я в качестве initiator использовал open-iscsi (в Proxmox вроде бы он же), в Windows официальный «Microsoft iSCSI Software Initiator», но проблема с VMware не в initiator на, в проприетарной файловой системе VMFS, которая не использует кэширование.

[@JStingo]

А кеширование не должно происходить на уровне файловых систем гостевых ОС? Или я как-то не так понимаю проблему?

[@giner]

О гостях даже речи не идёт. Тормозит уже на связке ESXi <-> iSCSI. Т.е. iSCSI LUN монтируется в /vmfs/xxxxxxxxxx и операции записи в этой директории идут очень медленно.

[@amarao]

Можно и там, и там. iet поддерживает очень умное кеширование с барьерами (для записи), что есть быть очень гуд.

[@amarao]

Вы говорите «proxmox», как будто это iscsi target. А это не iscsitarget, это дистрибутив специализированный. Ну всё равно, как если бы два человека обсуждали, где лучше ext4 — в ubuntu или в debian.

[@giner]

Да нет, Proxmox выступает в качестве клиента.

[@multagor]

У кого есть деньги на VmWare купит себе СХД с кешом. Таймингов сетевого доступа при грамотной архитектуре не заметил.

[@giner]

Не скажу про 10Gbit/s, но с 1Gbit/s даже при прямом соединении получается не очень если сравнивать с тем, что работало у нас до VMware.

[@JStingo]

Как я понял, это личная проблема iSCSI target'а, которые не может прокачать данные.

[@Zx48k]

Ну логика работы vmfs понятна — необходимость целостности данных: если ОС в виртуальной машине записала данные на диск, пусть и виртуальный, то они (данные) должны быть на диске.

[@akshakirov]

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

[@amarao]

Не сравнивал. Основная проблема — ataoe как-то наколеночно выглядит. В перспективах «посмотреть» есть желание, но накладные расходы на target (10-80% одного CPU) выглядят терпимо.

[@akshakirov]

Основные фишки это то что работает оно на L2 уровне, т.е. нет оверхедов на tcp/udp. Мультипаф у него из коробки. Begun её использует в продакшне.

[@amarao]

multipath «из коробки» вызывает скепсис (потому что у меня нет ни одной претензии к dm_multipath, который с iscsi'евыми дисками работает как с обычными SCSI/SATA, что даёт весьма и весьма широкие возможности по тюнингу «под себя»).

L2 совершенно не является проблемой, потому что на более-менее быстрых линках скорость канала выше скорости дисков, а оверхед от TCP (в процессоре) во многом решается с помощью LRO/GRO/checksumm offload и т.д. на сетевых картах.

[@qmax]

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

[@giner]

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

[@past]

В этом случае будет неоьходимо обеспечить блокировку, либо кластерным lvm, либо спец. фс типа gfs или ocfs2, либо внешними средствами, как это делает proxmox.

[@qmax]

тоесть на уровне протокола никакой защиты от таких подключений не предусмотрено?

[@amarao]

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

[@amarao]

Кстати, XCP обходится обычным LVM поверх ISCSI, а блокировки разруливает административными средствами вне хранилища.

[@past]

Как и proxmox.

[@Breaker]

Ожидал большего от XCP. В стандартной админилке можно только приатачить сторедж и всё, даже моунта нет. Я уже не говорю про создание ВМ (оффтопик ибо :)). Сделано с закосом под энтерпрайз, но до него еще пилить и пилить(

[@amarao]

«Стандартная админка» XCP называется 'xe', и она позволяет очень многое. Графические нашлёпки не имеют смысла, т.к. некоторые типы отношений очень плохо визуализируются.

[@Breaker]

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

Хотел у вас спросить, если есть не очень глупые вопросы по xen/xcp, можно их вал н-р в личку задать?)

[@amarao]

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

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

[@qmax]

А если залогиниться на таргет несколькими инициаторами, но не монтировать разделы в системе (и вообще не совершать никаких действий с /dev/sdX) — приведёт ли это к каким-нить последствиям?

Происходит ли при логине что-то, кроме операций обнаружения/проверки размера/чтения partition?

[@amarao]

Происходит где? На инициаторе? Всё, что захочется сделать udev'у (в частности, да, чтение в поисках разных видов разделов). На target'е всё что может быть плохого, происходит на этапе создания target'а.

[@merlin-vrn]

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

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

[@amarao]

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

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

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

[@nanodesu]

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

[@amarao]

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

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

[@nanodesu]

Понимаю, но мне бы это вполне подошло — везде линукс, поддержка ФС всегда есть.

[@amarao]

Кластеризованные FS это сложнее, чем «общая шара». В этом и вечная проблема SAN/NAS — в случае файлового доступа всё просто для клиента, но сложно для сервера (какой-нибудь fsck на шаре на 300-500 пользователей — дохлый номер дождаться завершения), блочный доступ — просто для сервера, просто для клиента, непросто обеспечивать взаимодействие.

[@cadmi]

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

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

[@pazhitnov]

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

[@qmax]

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

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

[@qmax]

ага.
каждый lun образует отдельное блочное устройство.
не совсем очевидно из статьи…

[@amarao]

А вот это очень интересный вопрос. Я никогда с многолуновыми target не работал. У меня есть две версии: либо будет создано несколько блочных устройств (по числу lun'ов), либо его нужно (как-то?) указать при создании.

[@qmax]

Вот меня смутило то, что lun нигде никак не указывается и вообще не фигурирует в документации (и в статье).
Методом тыка уже разобрался — при логине target подключает все свои LUNы, и кадый образует свой sdX.

Как я понял, это как раз нормальная практика — делать отдельный target на каждый раздел.
Так удобнее и в плане идентификации, и в плане возможности подключаться к разделам разными инициаторами.

[@amarao]

Ага. LUN'ы — это тяжкое наследие древних SCSI и юниксов, когда LVM не существовало и нормально разделы было не порезать. Точнее, они нужны были для того, чтобы разные приложения/ОС работали с разными блочными устройствами (находясь на одном) и не портили друг другу нервы.

В условиях iscsi это атавизм.