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 появится соответствующий таргет.

Спасибо, что дочитали до конца!
Поделиться публикацией

Похожие публикации

Комментарии 30

    0
    А рассматривался вариант Win Storage server/ ISCSI Target?
      0
      Нет не рассматривался, по трем причинам:
      — стоит денег;
      — не уверен в скорости шифрования;
      — часть сервера отдается как NFS с файловой системой XFS.
      • НЛО прилетело и опубликовало эту надпись здесь
      0
      Спасибо за статью!

      Скажите пожалуйста, а почему не стали использовать файлсервер с поддержкой iSCSI и шифрованием на клиентской стороне?

      Под файлсервером я имею в виду NAS типа Synology или чего-то подобного.
      • НЛО прилетело и опубликовало эту надпись здесь
          0
          Насколько я знаю, NAS все идут с linux-прошивкой и для предоставления iscsi-таргетов точно также используют что-то из протестированного автором списка. Скорее всего это STGT.
          Да и процы на NAS решениях слабоваты мне кажется, чтоб нормально тянуть кучу таргетов, это не говоря о шифровании. В NAS обычно iscsi есть по принципу «чтобы было», ну вдруг кому понадобится 1 или 2 таргета, ну или поиграться-потестить.
          0
          Дело как раз на клиентской стороне. Мы(на всякий случай) шифруем maildir dovecot, стоит он на сервере с CentOS. А как я писал в статье скорость шифрования в текущем ядре CentOS удручает.
          Вторую причину уже написал в своем комментарии SyavaSyava.
            0
            Подскажите пожалуйста, какое шифрование использовали? Если это LUKS/dm-crypt, то наши тесты показывали достаточно неплохие результаты — где-то + 5-10 % оверхед.
              0
              Используется LUKS/dm-crypt с алгоритмом aes-xts и ключом 256b. Шифрование — 886,0 MiB/s, дешифрация — 894,0 MiB/s. На CentOS скорость не поднималась выше 300 MiB/s.
              У вас на CentOS были результаты выше?
          0
          Нет, 2х10 я не видел, у меня используется 2х1, получается около 200-300Мб/с.
          Я не увидел в вашей статье количества клиентов, поэтому предположил что 20Гб — это просто страховка.
            0
            Клиенты — 3 гипервизора ESXi и 1 Windows Server. Конечно ни один из клиентов не загружает сутки на пролет 10ГБ канал, но оптика минимизирует задержки, а цена карт показалась приемлемой.
              0
              О, вот это показалось мне очень интересным. Действительно правда что в оптике кадры ethernet летят со скоростью света, а в меди — еле ползут?
                0
                Есть ESXi хост подключенный по 1ГБ меди. На нем расположено 6 виртуальных машин, которые редко обращаются к диску. В среднем задержки чтения/записи на хосте 2-2,5 ms. На хостах подключенных по оптике машин больше, обращаются они к диску чаще, а задержки меньше.
                  0
                  Ну вот, чуда не случилось :(
                  Думал оптические 10 победили медные 10. :)
            0
            А из-за NFS проблем в продакшене и под нагрузкой не было?
              0
              С NFS проблемы были, карточки надо объединять в BRIDGE(иначе ESXi считает их разными шарами со всеми вытекающими), а как оказалось BRIDGE с включенным LRO на этих картах приводит к Kernel panic. Были и другие проблемы, но в последствие были решены.
              Под нагрузкой NFS с XFS работали нормально — тестировал разнообразными конфигурациями fio.
              Но в продакшене пока не используется. SCST дает значительно большую производительность, виртуальные машины работают на разделах выдающихся через него. NFS оставлен на тот случай если ESXi с новым обновлением сломает у себя iSCSI(такое уже случалось).
                0
                Еще хотел полюбопытствовать, почему не Nexenta, например?
                  0
                  Попробовать Nexenta хотел, но не удалось — железо не подошло. Плюс оттолкнула покупка лицензии на 20ТБ, так как использование Community Edition в продакшене запрещено.
                  И если уже брать Nexenta, то надо использовать ZFS со всеми ее плюсами и минусами.
              0
              А как у вас с поддержкой VAAI?
                0
                В SCST поддержки VAAI, к сожалению, нет. Возможно она появится в будущих версиях.
                Поддержка VAAI есть в других таргетах, но сейчас от этой технологии пользы получить мы не можем — купленная лицензия VMware vSphere идет без Storage vMotion.
              0
              "… встала задача обеспечить кластер из гипервизоров VMware ESXi 5.1 хранилищем большого обьема" Никогда не понимал, ЗАЧЕМ все по привычке из кожи вон лезут, чтобы подцепить к VMWare блочный доступ… тем более если делают всё на nix и за бесплатно — используйте NFS.
                0
                кстати проверяйте одну вещь, набейте на том штук 20-30 виртуалок рабочих, что бы они диском шевелили. И начните импортировать или экспортировать виртуалки, что бы были операции за запись по 20-50Гб за раз. и делайте так параллельно в 2-3 потока. Если таргет выдержит, значит годный. Но часто просто iSCSI просто отвалится от хостов на этом месте и таргет окажется непригодным к коммерции
                .
                  0
                  Кстати сталкивался с подомной проблемой, только это оказалась беда VMWare, т.к. Hyper-V кластер смотрящий в ту же СХД не испытывал никаких подобных проблем.
                    0
                    Было что-то подобное с таргетом IET. Но с SCST такого не наблюдал, работает уже 2 месяца без каких-либо проблем.
                    0
                    я бы еще перед сборкой запустил бы

                    make debug2perf
                    

                    меньше мусора в dmesg и, по идее, быстрее работает.

                    А почему решили не использовать аутентификацию таргетов и хостов?
                      0
                      инициаторы и таргет расположены в физически выделенной сети, поэтому аутентификацию решили не использовать.
                      0
                      А Jumbo Frame не пробовали?
                      У меня в старом проекте когда-то были Promise vTrac на iSCSI с гигабитными линками получалось выжимать около 850 мегабит чистыми c фреймом 9к
                        0
                        Jumbo Frame включен на 10ГБ картах, на 1ГБ включать не понадобилось — ~100 MiB/s показалось достаточно.

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

                        Самое читаемое