iSCSI хранилище для небогатых

Доброго времени суток, уважаемое сообщество!

В этой статье я хотел бы поделится опытом создания дискового хранилища, который вылился во множество экспериментов, проб, ошибок, находок, приправленных горькими разочарованиями. И, наконец, завершился в неком интересном, относительно бюджетном и быстром хранилище.

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

Пролог

Итак, недавно перед нашим отделом встала задача обеспечить кластер из гипервизоров VMware ESXi 5.1 хранилищем большого обьема. На нем же мы запланировали расположить шифрованный maildir для dovecot и “облачное” файловое хранилище. Обязательным условием выделения бюджета было обеспечение места для хранения критически важной для компании информации, причем этот раздел должен быть зашифрован.

Железо

К сожалению, а может и к счастью, под такие амбициозные задачи большим бюджетом нас не обременили. Поэтому позволить себе какое-либо брендовое хранилище мы, как настоящие поклонники максимализма, не могли, и в рамках выделенных материальных ресурсов выбрали следующее железо:

• Серверный корпус Supermicro CSE-836BE16-R920B
  Тут было много рассуждений, выбирали количество юнитов, размер жестких дисков, их скорость, корпус или сразу платформа, пересмотрели множество вариантов, покурили интернетов и в итоге остановились на этом варианте, как на оптимальном под наши задачи.
• Материнская плата Supermicro MBD-X9DRI-F-O
  Главным условием было наличие 4 портов PCI-E x8.
• Процессоры Intel Xeon E5-2603
  Выбор был прост — на что хватило денег. Вдобавок пришлось ставить 2 процессора сразу, а не сначала один, потом, если надо будет, то докупить, ибо с одним занятым слотом работает только 3 PCI-E, а нам надо было 4.
• Диски Seagate Constellation ES.3 ST3000NM0033
  SATA потому что дешевле, и в те же деньги мы получали многократно большее количество свободного места, нежели при использовании SAS.
• RAID контроллер Adaptec ASR-7805Q
  Раз уж это СХД, то с контроллером мелочиться не стали. У этой серии есть SSD кэширование, которое очень бы нам пригодилось, и есть BBU сразу в комплекте, что тоже весьма полезная опция.
• SSD диски Intel SSDSC2CW240A310
  Они нужны были исключительно для того, чтобы работал MaxCache (он же SSD кэш).
• Сетевые карты Intel X520 DA2
  Чтобы избежать узкого места на сетевых интерфейсах, надо было обеспечить 10Gb линк между нодами ESXi и СХД. После изучения предложений рынка мы пришли может и к не самому элегантному, но зато к подходящему по цене и скорости варианту с использованием 10 гигабитных сетевых карт.

Все это обошлось нам примерно в 200 тысяч рублей.

Реализация

Выдавать таргеты, то бишь выделять ресурсы СХД потребителям, мы решили при помощи iSCSI и NFS. Наиболее разумным и быстрым решением, конечно, было бы использовать FCoE, чтобы не влезать в TCP с соответствующими ему накладными расходами, что, в общем-то можно было бы сделать с нашими сетевыми картами, но, к сожалению, у нас нет SFP свитча с поддержкой FCoE, купить его не было возможности, так как это стоило бы нам 500 т.р. сверху.
Еще раз покурив интернеты, нашли выход из этого в технологии vn2vn, но ESXi научится работать с vn2vn только к 6.x версии, поэтому, не думая дальше, приступили к тому, что есть.

Наш корпоративный стандарт для Linux серверов — CentOS, но в текущем ядре (2.6.32-358) шифрование работает очень медленно, поэтому пришлось использовать в качестве ОС Fedora. Конечно это полигон Red Hat, но в последних ядрах Linux данные шифруются практически “на лету”, а остальное нам, вроде бы, и не нужно.
К тому же текущая 19 версия будет использована как основа для RHEL 7, а следовательно позволит нам в будущем безболезненно перейти на CentOS 7.

Таргеты

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

От таргета мы хотели получить следующее:

• правильно работающее кеширование — диски довольно медленные, выжать из себя они могут только 2000 iops;
• максимально высокую скорость работы непосредственно дисковой подсистемы в целом, читай (даешь как можно больше iops).

Встречайте, вот они.

LIO

linux-iscsi.org
С Linux ядром 3.10.10 он показал мне 300 МБ/сек записи и 600 МБ/сек чтения в режиме blockio. Эти же цифры он показал с fileio и также с RAM диском. На графиках было видно, что скорость записи очень сильно скачет, вероятно это вызвано тем, что инициатор ESXi требует синхронизации записи. По этой же причине количество IOPS на запись было одинаково с fileio и blockio.
В меиллистах реккомендовали отключить emulate_fua_write, но к каким-либо измениям это не привело. Причем с ядром 3.9.5 он показывает лучшие результаты, что тоже заставляет задуматься о его будущем.
LIO, судя по описанию, умеет еще много чего, но большинство фич доступно только в коммерческой версии. Сайт, который, по моему мнению должен быть в первую очередь источником информации, пестрит рекламными объявлениями, что вызывает негатив. В итоге решили отказаться.

istgt

www.peach.ne.jp/archives/istgt
Используется в FreeBSD.
Таргет работает достаточно хорошо, за исключением нескольких но.
Во-первых, он не умеет blockio, во-вторых, не может использовать разные MaxRec и MaxXtran, по крайней мере мне этого не удалось. При небольших значениях MaxRec скорость последовательной записи не превышала 250 МБ/сек, а чтения была на вполне высоком уровне — 700 МБ/сек. Примерно по 40K иопсов я получил при рандомной записи 4к с глубиной очереди 32. При увеличении MaxRec скорость записи повышается до 700 МБ/сек, чтение падает до 600 МБ/сек. Иопсы падают до на чтение 30К и 20К на запись.
То есть как-то можно было бы найти золотую середину, меняя настройки, но как-то это показалось не трувей.

STGT

stgt.sourceforge.net
С этим таргетом возникли проблемы с настройкой интерфейса с гипервизором. ESXi постоянно путал LUN — принимал одни за другие, либо переставал видеть совсем. Было подозрение на проблему в некорректной привязке серийных номеров, но прописывание их в конфигах не помогло.
Скорость также не порадовала. Добится от него больше 500 МБ/сек ни на чтение, ни на запись не удалось. Количество IOPS на чтение — 20К, на запись примерно 15К.
В итоге — проблемы с конфигом и невысокие показатели в скорости. Отказать.

IET

iscsitarget.sourceforge.net
Работал практически безукоризненно. Чтение и запись 700МБ/сек. IOPS на чтение порядка 30K, на запись 2000.
Инициатор ESXi заставлял таргет записывать данные на диск сразу же, без использования кеша системы. Также несколько напугали отзывы о нем в maillists — многие докладывали о нестабильной работе под нагрузкой.

SCST

scst.sourceforge.net
И наконец добрались до лидера нашей гонки.
После пересборки ядра и минимальной настройки самого таргета мы получили 750МБ/сек чтения и 950МБ/сек записи. IOPS в режиме fileio — 44K на чтение и 37K на запись. Сразу, почти без бубна.
Этот таргет показался мне идеальным выбором.

iSCSI для VMWare ESXi 5.1 на SCST и Fedora

И теперь, собственно, то, ради чего мы все тут собрались.
Небольшая инструкция по настройке таргета и инициатора ESXi. Я не сразу решил попробовать написать статью на Хабр, поэтому инструкция будет не пошаговой — восстанавливаю по памяти, но в ней будут основные моменты настройки, которые позволили добиться нужных результатов.

Подготовка ESXi 5.1

В гипервизоре произведены следующие настройки:

• в настройках iSCSI инициатора отключен Delayed ACK для всех таргетов. Сделано в соответствии с: kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1002598
• параметры инициатора изменены в соответствии с параметрами таргета:

  InitialR2T=No
  ImmediateData=Yes
  MaxConnections=1
  MaxRecvDataSegmentLength=1048576
  MaxBurstLength=1048576
  FirstBurstLength=65536
  DefaultTime2Wait=0
  DefaultTime2Retain=0
  MaxOutstandingR2T=32
  DataPDUInOrder=No
  DataSequenceInOrder=No
  ErrorRecoveryLevel=0
  HeaderDigest=None
  DataDigest=None
  OFMarker=No
  IFMarker=No
  OFMarkInt=Reject
  IFMarkInt=Reject

Потребуется отключить Interrupt Moderation и LRO для сетевых адаптеров. Сделать это можно командами:

ethtool -C vmnicX rx-usecs 0 rx-frames 1 rx-usecs-irq 0 rx-framesirq 0
esxcfg-advcfg -s 0 /Net/TcpipDefLROEnabled
esxcli system module parameters set -m ixgbe -p "InterruptThrottleRate=0"

Причины по которым это стоит сделать:
www.odbms.org/download/vmw-vfabric-gemFire-best-practices-guide.pdf
www.vmware.com/files/pdf/techpaper/VMW-Tuning-Latency-Sensitive-Workloads.pdf

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

/etc/rc.local.d/local.sh

Подготовка Fedora

Скачиваем и устанавливаем в минимальном варианте последнюю версию Fedora.

Обновим систему и перезагрузимся:

[root@nas ~]$ yum -y update && reboot

Система будет работать только в локальной сети, поэтому я отключил файервол и SELinux:

[root@nas ~]$ systemctl stop firewalld.service
[root@nas ~]$ systemctl disable firewalld.service 
[root@nas ~]$ cat /etc/sysconfig/selinux
SELINUX=disabled
SELINUXTYPE=targeted

Настроим сетевые интерфейсы и отключим сервис NetworkManager.service. Он не совместим с BRIDGE интерфейсами, а это было необходимо для NFS.

[root@nas ~]$ systemctl disable NetworkManager.service 
[root@nas ~]$ chkconfig network on 

На сетевых картах отключено LRO.

[root@nas ~]$ cat /etc/rc.d/rc.local
#!/bin/bash
ethtool -K ethX lro off

По рекомендациям от Intel измененны следующие параметры системы:

[root@nas ~]$ cat /etc/sysctl.d/ixgbe.conf
net.ipv4.tcp_sack = 0
net.ipv4.tcp_timestamps = 0

net.ipv4.tcp_rmem = 10000000 10000000 10000000
net.ipv4.tcp_wmem = 10000000 10000000 10000000
net.ipv4.tcp_mem = 10000000 10000000 10000000

net.core.rmem_max = 524287
net.core.wmem_max = 524287
net.core.rmem_default = 524287
net.core.wmem_default = 524287
net.core.optmem_max = 524287
net.core.netdev_max_backlog = 300000

Подготовка таргета

Для использования SCST рекомендуется добавить патчи в ядро. Это необязательно, но с ними производительность выше.
Во время создания хранилища последняя версия ядра была — 3.10.10-200. К моменту когда вы будете читать статью ядро уже может обновиться, но не думаю, что это сильно повлияет на процесс.

Создание rpm пакета с измененным ядром подробно описанно тут:
fedoraproject.org/wiki/Building_a_custom_kernel/ru

Но для того, чтобы не возникло трудностей опишу подготовку подробно.

Создадим юзера:

[root@nas ~]$ useradd mockbuild

Перейдем в его среду:

[root@nas ~]$ su mockbuild
[mockbuild@nas root]$ cd

Установим пакеты для сборки и подготовим исходники ядра:

[mockbuild@nas ~]$ su -c 'yum install yum-utils rpmdevtools'
[mockbuild@nas ~]$ rpmdev-setuptree
[mockbuild@nas ~]$ yumdownloader --source kernel
[mockbuild@nas ~]$ su -c 'yum-builddep kernel-3.10.10-200.fc19.src.rpm'
[mockbuild@nas ~]$ rpm -Uvh kernel-3.10.10-200.fc19.src.rpm
[mockbuild@nas ~]$ cd ~/rpmbuild/SPECS
[mockbuild@nas ~]$ rpmbuild -bp --target=`uname -m` kernel.spec

Теперь потребуются сами патчи. Скачаем SCST из svn репозитория:

[mockbuild@nas ~]$ svn co https://scst.svn.sourceforge.net/svnroot/scst/trunk scst-svn

Скопируем необходимые пачти в ~/rpmbuild/SOURCES/

[mockbuild@nas ~]$ cp scst-svn/iscsi-scst/kernel/patches/put_page_callback-3.10.patch ~/rpmbuild/SOURCES/
[mockbuild@nas ~]$ cp scst-svn/scst/kernel/scst_exec_req_fifo-3.10.patch ~/rpmbuild/SOURCES/

Добавляем строчку в конфиг ядра:

[mockbuild@nas ~]$ vim ~/rpmbuild/SOURCES/config-generic
...
CONFIG_TCP_ZERO_COPY_TRANSFER_COMPLETION_NOTIFICATION=y
...

Приступим к редактированию kernel.spec.

[mockbuild@nas ~]$ cd ~/rpmbuild/SPECS
[mockbuild@nas ~]$ vim kernel.spec

Изменяем:

#% define buildid .local

На:

%define buildid .scst

Добавляем наши патчи, желательно после всех остальных:

Patch25091: put_page_callback-3.10.patch
Patch25092: scst_exec_req_fifo-3.10.patch

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

ApplyPatch put_page_callback-3.10.patch
ApplyPatch scst_exec_req_fifo-3.10.patch

После всех действий запускаем сборку rpm пакетов ядра с включенными файлами firmware:

[mockbuild@nas ~]$ rpmbuild -bb --with baseonly --with firmware --without debuginfo --target=`uname -m` kernel.spec

После завершения сборки устанавливаем ядро firmware и заголовочные файлы ядра:

[mockbuild@nas ~]$ cd ~/rpmbuild/RPMS/x86_64/
[mockbuild@nas ~]$ su -c 'rpm -ivh kernel-firmware-3.10.10-200.scst.fc19.x86_64.rpm kernel-3.10.10-200.scst.fc19.x86_64.rpm kernel-devel-3.10.10-200.scst.fc19.x86_64.rpm kernel-headers-3.10.10-200.scst.fc19.x86_64.rpm'

Перезагружаемся.

После успешной, надеюсь, загрузки перейдите в каталог с исходниками SCST и уже пользователем root соберите сам таргет:

[root@nas ~]$ make scst scst_install iscsi iscsi_install scstadm scstadm_install

После сборки добавьте сервис в автозапуск:

[root@nas ~]$ systemctl enable "scst.service"

И настройте конфиг в /etc/scst.conf. К примеру мой:

[root@nas ~]$ cat /etc/scst.conf
HANDLER vdisk_fileio {
                DEVICE mail {
                filename /dev/mapper/mail
                nv_cache 1
        }
                DEVICE cloud {
                filename /dev/sdb3
                nv_cache 1
        }
                DEVICE vmstore {
                filename /dev/sdb4
                nv_cache 1
        }
}

TARGET_DRIVER iscsi {
	enabled 1

	TARGET iqn.2013-09.local.nas:raid10-ssdcache {
                LUN 0 mail
                LUN 1 cloud
                LUN 2 vmstore

		enabled 1
	}
}

Создайте файлы, разрешающие или запрещающие подключения к таргетам с определенных адресов, если вам это необходимо:

[root@nas ~]$ cat /etc/initiators.allow
ALL 10.0.0.0/24
[root@nas ~]$ cat /etc/initiators.deny
ALL ALL

После настройки файлов конфигураци запустите SCST:

[root@nas ~]$ /etc/init.d/scst start

Если все было сделано правильно, то в ESXi появится соответствующий таргет.

Спасибо, что дочитали до конца!