Tags: iscsi

404

scst VS iet

Я долго мучался с тем, как их сравнивать в blockio.

Решение, на самом деле, оказалось до крайности простое: берём приличный массив, берём scst, берём iet, по-очереди экспортируем его, локально подключаем, запускаем тест (fio iodepth=32, blocksize=4k, rw=randwrite).

Цифры говорят сами за себя:

fio на локальный массив (без iscsi): 5.5kIOPS
fio на scst: 5.5kIOPS
fio на iet: 4.7kIOPS

Точное значение цифр не важно (оно зависит от массива дисков), важно различие между local, scst и iet.
404

scst

Пока что главным его недостатком является процесс установки.

Имеем: ихние deb'ы для дебиана имеют ужасный conffile, который "едва-едва" не сносит /etc, в любом случае, без ручной правки оно не устанавливается.

ubunt'овские пока в процессе исследования.

make install работает нормально (но это порнография).
попытка его обвернуть в dh_make натыкается на кривоватый makefile.

Чую, ещё недельку я его проковыряю. (И не стать ли мне под шумок мейнтейнером этой цацы в дебиане?)
404

scst

Надо сказать, что пока что он ведёт себя лучше iet. Даже оставляя в стороне то, что самый свежий iet выносится с помощью тривиального bonnie++, в администрировании он лучше. Например, для iet'а нам пришлось писать свой супер-хак для сноса существующих target'ов, если к ним подцепленны инициаторы. В рассылке IET'а сказали, что такие target'ы нельзя удалить, мол, занято.

scst честно предупреждает, но сносит конфиг в памяти на раз-два (что является критичным, если нужно, например, поправить этот самый конфиг).

По производительности (понятно, что линейные тесты брешут ещё больше статистики) оно примерно в два раза быстрее (я смог с единственного инициатора выжать аж 2.5 гигабита, в сравнении с гигабитом у IET). Сейчас оно усё упирается в скудный тестовый комплект (ssd АДИН ШТУКА) и производительность драйверов в dom0, в гостях я вижу вполне приличествующие 300+ Мб/с.

PS А istgt я выкинул, потому что он в три раза тормознутее iet'а. Хотя и милый юзерспейс.
404

istgt

Я его, конечно, завёл (это портированный в линукс из бзди iscsi target в юзерспейсе). Но оно отвратительно - конфиги в example несоответствуют друг другу (то есть в одном конфиге test user в другом, который с первым связан "с обратной стороны сокета" - testuser и т.д.), размер target'а ему надо обязательно указывать руками (спасибо, что в байтах, а не в цилиндрах), логгинг отвратительный.

Ща буду смотреть, стоило ли оно времени на подъём (сравню производительность с IET'ом).
404

Разгон tcp и iscsi

Любопытно: если подмонтировать диск по iscsi (речь про 10G, то есть условия, в которых сеть быстрее дисковой подсистемы, пусть и мегаразогнанной сложной десяткой), то можно наблюдать вот такую картинку:
dd if=/dev/zero of=/dev/sdd bs=1M seek=1000000 count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 2.59695 seconds, 40.4 MB/s
dd if=/dev/zero of=/dev/sdd bs=1M seek=1000000 count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.855485 seconds, 123 MB/s
dd if=/dev/zero of=/dev/sdd bs=1M seek=1000000 count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.653804 seconds, 160 MB/s
dd if=/dev/zero of=/dev/sdd bs=1M seek=1000000 count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.584863 seconds, 179 MB/s
dd if=/dev/zero of=/dev/sdd bs=1M seek=1000000 count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.452039 seconds, 232 MB/s

Заметим, эту картинку можно наблюдать только на относительно малых count, на больших скорость стабилизируется.

Я могу этому дать только одну интерпретацию - "разгон" TCP после монтирования по iscsi. С одной стороны, в условиях медленной сети - благо (защита от congnession), с другой - в условиях избыточной сети - явный источник неявных трудноотлаживаемых тормозов.

Вижу два варианта: попытаться протюнить tcp для отказа от мягкого старта или начать-таки пилить ataoe.
404

ietd

Всё-таки грамматика его конфига меня убивает. Сейчас написал Target= вместо Target (пробел) - всё ок, никаких ошибок. Только нихрена не работает и пароль не принимает на этапе -t st.

Третий случай, между прочим - его конфиг это ад и погибель. Не дай бог где лишний пробел - интерпретация содержимого содержимого меняется на 100%.
404

Never believe X.0 is stable

Торвальдс клялся, что 3.0 - это такая переименованная 2.6.40, и ничего они ломать не будут.

Однако, все виртуальные пакеты 2.6 (например, linux-headers-2.6) оказались в глупом положении. Предоставлять 3.0 как 2.6 нельзя, а у многих kernel modules (тот же iscsi target, то бишь iscsitarget-dkms) в депенденсах прописан виртуальный пакет...

Вроде никто не виноват, однако, поломали. Типичный синдром нулевой версии, кстати.
404

Сложный вопрос по multipath

0) (простой вопрос) В природе есть maillist'ы multipathd users?
1) (сложный вопрос) Каким образом можно задать политику упорядочивать используемые path-groups (повторю, не path внутри path group, а path groups) в произвольном порядке? Я всё-таки со скепсисом отношусь к наивному load ballance'ингу, хочется всё-таки, чтобы каждый хост работал только с одним путём, переключаясь на альтернативный только в случае сбоя первого. И хочется, чтобы "первым" у каждого хоста был свой путь.



(random from deviantart)


... Или писать ещё один патч на ISCSISR с рандомизацией порядка подключения target'ов? В принципе, сама идея "подключать target'ы в случайном порядке, а не по списку", правильная, т.к. даже на target'ы (если будут кеширующие отростки) при этом будет меньшая (и более распределённая) нагрузка.