Когда-то давно, в одной хорошей Фирме мне довелось работать с файловым сервером, собранным на базе Sun Enterprise S3500 и нескольких массивов Sun A1000.

Было это ещё до того, как Sun "изобрёл" файловую систему ZFS, поэтому массивы из 12-16 SCSI-дисков, собранные в аппаратный RAID-5, были отформатированы в нативную UFS, а том, на котором позарез была необходима квота на пользовательские директории - в VxFS.

Подавляющую часть времени железо работало вполне надёжно, но процесс восстановления после сбоев внушал ужас - холодная загрузка сервера "с ключа" занимала не менее 15 минут, а проверка файловой системы (а самый большой том вмещал около 900ГБайт!) могла затянуться на целую ночь.
И - да, всё это действительно работало на шине SCSI c аппаратными терминаторами, ограничениями на длину кабеля и количество устройств. В машине было 2 сетевых карты - встроенная 100Мбит Ethernet и дополнительная на 1 гигабит - которая и использовалась.

Требования Фирмы росли, парк машин расширялся, пользователи повадились запускать распределённые расчёты с сохранением результатов на общем сетевом диске, а апгрейдить старую машину было практически невозможно, поэтому сначала в помощь старичку, а потом и на смену пришло новое поколение файлеров - Sun Fire 280R с FC-адаптером на 2 гигабита и массивами Sun 3510 (который на самом деле Dot Hill) по космической на тот момент технологии FC AL.

Какое-то время инфраструктура масштабировалась исключительно горизонтально - росло количество массивов и файлеров, появился Sun 6140 (который на самом деле StorageTek), появилась пара оптических коммутаторов Brocade SilkWorm.

Сеть вместо 100мбит стала 1 гигабит до каждой расчётной машины, и даже массовые вычисления (действительно массовые - ведь инженеры уже имели кластер из аж 100 процессоров!) большой проблемы не создавали - гораздо страшнее была нехватка места. Так что в скором времени в помощь "взрослым" файлерам под управлением Solaris встали самосборные сервера Supermicro с медленными, но объёмными SATA-дисками в аппаратных RAID-5 и c Linux на борту.

А затем что-то внезапно изменилось - вроде бы и кластер вырос не сильно и инженеров прибавилось немного, возможно немного изменился инженерский софт - но производительности стало регулярно и катастрофически не хватать. Катастрофически - это когда команда ls на нагруженном томе выполняется 1-2-3 секунды, и даже банальный текстовый редактор при наборе текста беспощадно лагает (в момент сохранения .bak-файла) за компанию с оконным менеджером (в момент сохранения файла с расположением окон на экране).

К тому времени ZFS уже появилась, и даже пошла в продакшн и даже использовалась для сцепления 2 массивов по терабайту в один большой, двухтерабайтный, но дальнейшая конвертация была невозможна из-за нехватки места для временного хранения данных с конвертируемых массивов.
А из головного офиса пришла команда - ставить NetApp согласно корпоративному стандарту. Удовольствие не из дешёвых, но сдвоенный контролер, счетверенная сеть, FC-диски большой ёмкости.... Управлять NetApp'ом после Solaris'а было довольно тоскливо, но его производительности хватило на все нужды с запасом. И хватило бы ещё надолго, если бы Фирма не увлеклась процессами поглощения и оптимизации. Дооптимизировалась до того, что всю приличную технику увезли в заграничный вычислительный центр, а местный филиал пересадили на "удалёнку" - удаленный рабочий стол через VPN из местного офиса в зарубежный датацентр.


В следующей Конторе всё пришлось начинать практически с самого начала, только с поправкой - в виду её госбюджетной природы денег на роскошь типа NetApp не было - а было нужно выжимать производительность из того, что было - вот такая невесёлая тавтология. 
А "было" там свежекупленный массив IBM DS3550 (на самом деле LSI) из SATA-дисков, да ещё и сконфигурированный в аппаратный RAID6. Не удивительно, что даже при десятке параллельных расчётов всё начинало лагать.

И вот тут на помощь должен был придти Solaris (к тому времени уже версии 11.1) с ZFSом. И это даже было построено, только по каким-то неведомым соображениям в продакшн за 3 года так и не дошло. А должно было получиться неплохо - сдвоенный 10гигабитный линк, прямое подключение корзины с SAS-дисками и даже SSD-кешем к файлеру. В аффилированной конторке тоже пришлось построить нечто аналогичное, только совсем уж дёшево - на базе FreeNAS да и то, только под угрозой смерти старого массива Sun у которого из 2 контроллеров один уже отъехал в лучший мир, а второй мог в любой момент отправиться вдогонку, а заменить нечем.

Когда же бороться с ветхим игровым железом, используемым в конторке для запуска симуляторов стало окончательно невмоготу, произошло Чудо - "Компания, Не Жалеющая Денег На Оборудование" пригласила к себе на работу по тому же профилю.

Чтобы понять масштаб бедствия, достаточно сказать, что в "Компании, Не Жалеющей Денег На Оборудование" уже имелся NetApp на SATA-дисках, который к тому моменту лагал так же успешно, как IBM DS3550 в предыдущей Конторе, при том, что кластером для распределённых вычислений тут пока ещё и не пахло, но уже очень хотелось. Тем более, что в Компанию перешло довольно много людей с Фирмы, где они видели - как оно бывает "в лучших домах Европы".
Поскольку Компания не жалела денег на оборудование - через пару лет её кластер в 10 раз переплюнул по количеству ядер кластер Фирмы, а по производительности и сравнивать бесполезно.

В итоге в роли файлеров оказались сервера Dell под управлением Solaris 11.3 c SAS-контроллерами LSI, к которым через коммутаторы SAS было подключено изрядное количество полок с 2.5" SAS-дисками 10000rpm и некоторым количеством SAS-SSD в роли кэша и журнала. Потом наиболее часто употребляемую кучу мелких файликов переложили на массив, состоящий полностью из SSD, а в особо привилегированные сервера в дополнение к 10Gbit Ethernet воткнули 40Gbit Infiniband.

За нагрузкой эпизодически пристально следили, даже основали что-то наподобие секты свидетелей больших IOPSов. Замерять производительность по кошерной технологии, со сбросом кэша клиента и стандартными паттернами нагрузки было особо некогда - и безо всяких синтетических тестов в рабочее время можно было увидеть 150000 NFS IOPS, а в пики нагрузки и 300000.
Проблема была в том, что в моменты восстановления после аварий, связанных со штормом запросов, файлеры выдавали показатели на уровне 600-700 тысяч NFS IOPS - видимо таков предел производительности на данных процессорах с данными сетевыми картами и драйверами. При этом собственно трафика передавалось немного - безумные IOPSы состояли по всей видимости из одних операций типа getattr, т.е. команд ls. Таким образом перспективы увеличения масштаба (например за счёт роста числа сотрудников или за счёт усиления интенсивности их расчётов) были довольно нерадужны - всего в два раза и снова здравствуйте лаги, давно не виделись.

При этом озадачивало то, что нагрузка в ночное время и в часы пик при массовом запуске расчётов различалась не очень сильно - всего раза в 1.5-2, а должна бы в десятки. Небольшое расследование показало, что стандартный Linux-клиент с графическим рабочим столом расточает ресурсы файлера в никуда путём генерации запросов ls как периодически, так и при каждом чихе. После выпиливания с клиентов службы "gam-сервер" нагрузка понизилась до 15000 в обычное время, 30-50000 в нагруженное время и 100-150000 в моменты особой активности, т.е. от предела производительности по IOPS удалось отступить.

Тем временем аппетиты пользователей росли как на дрожжах: параллельный запуск 100 задач (на человека) давно стал атрибутом серых будней, к выходным и по праздникам люди требовали уже по 300-400 расчётов (каждому) и уже интересовались, а когда уже появится возможность одному человеку выдать 1500 ядер. Масла в огонь подливало существование особого класса задач, начинающихся с размножения файла весом больше 10 гигабайт и последующего внесения в него изменений. Просто сотня-другая операций копирования в параллель, просто куча клиентов, просто большой Bandwidth, только на одном сервере, в пределах одного zpool'а, на одной файловой системе, хоть и размазанной по нескольким raid-группам.

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

За основу берём Dell R740xd, ставим терабайт памяти (чтоб кеш ZFS прямо совсем не стеснялся), два 18-ядерных процессора по 3.1ГГц,  два контроллера LSI SAS-3 с четырьмя счетверенными портами по 12 гигабит на каждом - для подключения внешних полок с дисками.
Запихиваем 10-гигабитные сетевые карты Intel XL710 (одна onboard и одна дополнительная) и Intel DA520 общим числом портов 10 и ещё двухпортовую карту Infiniband на 56 гигабит - итого занято 6 PCIe слотов, два осталось свободными. В сам сервер диски ставятся только для операционной системы. 24 SSD-диска под данные стоят в отдельной полке Supermicro с двумя SAS-экспандерами на борту.

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

Осталось понять, как всё это сконфигурировать, сколько мы с этого реально сможем снять производительности и на сколько клиентов нам этого хватит?

продолжение следует