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