Домашний стораджбокс: производительность iSCSI/SRP, FreeBSD/Linux

Как и обещал, привожу результаты тестирования перформанса нового дискового ящика.

Помня о весенних результатах (когда тестировался доступ по Infiniband к RAM-диску), я не стал тратить много времени на Samba (хотя и померял, см. ниже) и вдумчиво тестировал только iSCSI/SRP варианты.

Hardware

Клиент: Intel i7-2600K без оверклока, 16Gb RAM (DDR3-1600), Windows7. Файрволл выключен, антивирус деинсталлирован (с антивирусом получается весело, но результаты невоспроизводимы).

Сервер: Intel i5-2400 без оверклока, 8GB RAM, Adaptec ASR-5805, 6x Seagate Barracuda ES.2 SAS 1Tb + 2 WD RE4 SATA 1Tb, объединены в RAID-6 (контроллер ругается, что SAS и SATA смешаны в одном томе, а мне плевать).

Сеть: Mellanox Infinihost Ex III (MHEA28-XTC), 10(8) Gbit/s, две карты соединены кабелем.

Сетевые протоколы: iSCSI (по IPoIB), SRP (SCSI RDMA Protocol).

Серверный софт:

  1. Ubuntu Server 12.04, драйвера Infiniband и iscsitarget из поставки, scst из гнезда (trunk), при установке scst ядро патчилось согласно инструкции.
  2. FreeBSD 9.1 Prerelease (свежий cvsup), istgt из портов.
SRP поддерживается только scst, остальные два варианта работали по iscsi.

Клиентский софт: iSCSI initiator из комплекта Win7. Infiniband SRP Initiator из комплекта Infiniband-драйверов openfabrics.org (OFED 3.1).

IPoIB Connected Mode у OFED 3.1 работает только Windows-Windows (в 3.0 работало Windows-Linux). Возможно, причина не в Windows-стороне, а в других драйверах с Linux-стороны, детально не разбирался, жил с MTU 2044.

Бенчмарка

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

Короткие файлы

  • Порождаем 163840 файлов длиной 16384 байта каждый, разложенных в 256 каталогов (16 верхнего уровня, в каждом 16 подкаталогов). Файлы размазаны по каталогам round-robin. В файлы пишутся псевдорандом-данные. На всякий случай.
  • Сбрасываем кэш (вручную: размонтированием диска или перезагрузкой), затем читаем вышеописанные файлы в том же порядке.
Этап записи малочувствителен к количеству файлов, первые 16к пишутся примерно с той же скоростью, что и вторые. С чтением иначе: первые ~10-20к файлов читаются медленно (пока насосется кэш MFT), остальные значительно (в разы) быстрее. Несмотря на это, тестирование чтения дает повторяемые результаты с приемлемым разбросом (5-8%).

Длинные файлы

  • Пишем 40 гигабайт файла (псевдорандом-данные) кусками по 1Gb.
  • Читаем их же. Сразу, без перезагрузки/размонтирования.
  • И на чтение и на запись файлы открываются мимо кэша (FILE_FLAG_NO_BUFFERING у CreateFile()), без этого мы тестируем клиентский кэш и результаты очень разные.

Результаты

Все цифры в таблице - в мегабайтах (220 байт) в секунду. Short read/write можно перевести в файлы в секунду умножением на 64.
Система/ПО Long write Long read Short write Short read
FreeBSD, iSCSI 435 657 56 33
Linux, iSCSI 650 630 63 19
Linux, SRP 654 636 131 45
Linux, Samba 3.6 604 260 15 20
Samba приведена для сравнения, что будет медленно - и так было понятно по результатам предыдущих тестов. У меня нет идей, почему длинное чтение на Samba такое медленное: каких-то особых узких мест не видно, smbd жрет около 30% CPU, диск недогружен, все свободно. Возможно, есть какой-то упор в RTT на сети, не знаю.

Второе удивление медленная запись на FreeBSD. Объяснений у меня нет, UFS2 на этом же разделе диска дает писать в себя со скоростью 585Mb/sec. Тоже, помедленнее Linux/Win7 на локальном диске, но не 450 Mb/sec же. Оверхед на чтение, как видим, у istgt - низкий.

В остальном же все примерно как и ожидалось: SRP сильно быстрее на коротких операциях и примерно такой же (как и iSCSI over IPoIB) на длинных.

P.S. Пойду запихивать драйвера Infiniband в recovery-сидюк... ничего не вышло за 10 минут, оказалось проще поднять лишний гигабитный ethernet-линк, чисто для рекавери.

P.P.S. scst маленько кривоват, поэтому если перегрузили сервер, то придется рестартовать SRP storage driver на клиенте. Неудобно, да.

Comments

А если запустить tcpdump и посмотреть? Samba случайно не 4K блоками читает?

SAS с SATA мешать таки не стоит. Random r/w должен быть быстрее на SAS only array.

Ну, казалось бы, самба примерно одинаковая на FreeBSD/Linux?

Да фиг там был. Она как-то очень заточена на Linux и наоборот. У меня samba на FreeBSD вообще неясно во что утыкается -- работает медленней и сети и дисков и всего на свете.

Вот с нового сторадж-бокса на старый:

На старом боксе - FreeBSD, ZFS и Samba, упирается, судя по всему, в тамошние диски (5 медленных сигейтовских 3Tb в RAIDZ).

Ну то есть это вторая попытка, чтобы оно на самом деле брало источник из кэша, но запись - честная. На первой попытке - ~250-290 шло.

Но, да, медленнее и сети (10G) и дисков (430 в dd), но не так и намного.

А как было бы nfs по сравнению с samba?

Вот как было на 10G ether:

Прогонял на Myricom-е, получил ужасное какое-то говно. Не помню результат, в разы медленнее самбы.

Но у меня виндовый клиент (Win7) и никакие другие клиенты на практике не интересуют т.е. Linux-Linux не стал тестировать

http://blog.lexa.ru/2012/02/25/10g_doma_infiniband_linux_samba_iscsi_srp...

Меня ещё очень интересует, чем его охлаждать. И сильно ли оправдан в плане охлаждения (кол-ва вентиляторов, шума) вынос в отдельную коробку.
Хотя бы в двух словах можно про это? Лично мне очень интересно, такое же запилить себе есть думаю.

У меня основная причина выноса - это не шум (в семье с тремя детьми к шуму привыкаешь :), а время перезагрузки и то что с RAID не работал слип. Засыпало и не просыпалось. Люто, бешено, раздражало: время доступности компьютера не неск. секунд, а несколько минут.
А без быстрого стораджа - тоже никак. И бэкап долго идет и вообще любые конкурентные операции все кладут.

А охлаждать - я не понял вопроса. Охлаждение корпуса - штатное. Охлаждение шкафа - пока не решил, или компьютерные вентиляторы поставлю или которые от 220.

Как оно себя ведет со штатным охлаждением в шкафу - я вот написал сегодня: http://blog.lexa.ru/2012/09/03/ob_okhlazhdenii.html

Add new comment