Считавшийся ранее лидером в области СХД NetAPP (есть мнение, что сейчас желтая майка лидера перешла к Huawey OceanStor Dorado) показывал замечательные результаты в тестах SPC-1 как в абсолютных цифрах, так и в удельных значениях производительности на ватт, на доллар итд.
Вот только тестируемый образец конфигурируется под среднеайтишную нагрузку, которая довольно таки дружелюбна к хранилищу. Красивые рекордные показатели NFS operations/sec достигаются, когда в испытуемой системе есть много шпинделей, объединенных в RAID-группы рекомендованного размера, на которых создано достаточно много агрегатов, чтобы распределить их между всеми контроллерами хранилища, а в агрегатах нарезано достаточно много лунов, в которые и целятся генераторы нагрузки. В итоге все компоненты хранилища загружаются практически равномерно.
А в нашем самом тяжелём случае, увы, один пользователь запускает массовые расчёты, настроенные практически идентично.
Т.е. в кластере практически синхронно запускается чтение файлов из одной и той же директории, а потом запись модифицированных файлов опять таки в одну и ту же директорию.
А значит, вся нагрузка с нескольких десятков хостов приходится (в случае NetAPP) на один и тот же лун, который, находится в одном-единстренном агрегате, который целиком принадлежит одному контроллеру.
В результате получается, что пиковая нагрузка приходится на единственный контроллер. При том что даже старшие модели имеют довольно ограниченный размер кэша и количество сетевых интерфейсов на один контроллер.
В случае использования в качестве файлера сервера с операционной системой Solaris и файловой системой ZFS вместо NetAPP мы получаем возможность построить как бы отдельный контроллер с запредельными характеристиками.
Расплачиваться за это придётся главным образом отсутствием High Availability и некоторыми отличиями в администрировании - в ZFS невозможно изменить размер RAID-группы и отсутствуют Qtree, зато можно манипулировать файлами напрямую на сервере и использовать любые средства автоматизации и мониторинга. Терабайт ОЗУ под кеш позволяет после подготовки первого же расчета отдавать данные не с дисков, а из памяти. А большое количество сетевых интерфейсов позволяет в разы отодвинуть фундаментальную проблему масштабируемости сети - при массовой синхронной записи со стороны вычислительных узлов на файлер вероятность одновременного прихода кадров ethernet крайне велика, что приведёт к крайне неприятным последствиям:
- если в сети применяются низколатентный коммутаторы Cut Through - они мгновенно превратятся в обычные Store And Forward
- затем начнётся агрессивное использование буферов портов, к которым подключен файлер
- при исчерпании ёмкости буферов пакеты начнут пропадать со всеми вытекающими неприятными последствиями
Хорошо если архитектура сетевого коммутатора предусматривает для буферов общую память, динамически перераспределяемую между отдельными портами - тогда можно побарахтаться немного подольше за счёт того, что бОльшая часть буферной памяти будет работать на самые нагруженные порты.
Только вот производители коммутаторов так делать не очень любят - производительность падает. Да и латентность прохождения кадра при размере буфера в 768 мегабайт и скорости порта 1 гигабит (Arista 7048T)..... Да даже если поделить на 48 портов.....
И самое печальное, что полноценный мониторинг утилизации буферной памятии присутствует только в коммутаторах экстра-класса (например Arista 7150), т.е. узнать насколько мы близки к катастрофе и насколько ещё можно повысить параллелизм агрессивных к вводу-выводу задач, можно только купив дорогущее сетевое оборудование. Либо экспериментальным путём, доводя систему до потери кадров.
Возможность взять в качестве файлера сервер с большИм количеством PCIe-слотов и напихать туда сетевых карт, объединив их в LACP, (в нашем случае 10*10гигабит) даёт возможность не столько прокачивать 100 гигабит, сколько не терять кадры и не мучать TCP при скорости в 40гигабит.
Для некоторых задач особо ценна возможность воспользоваться протоколом NFS over RDMA, реализованном на Infiniband без участия Ethernet и TCP. Существенно более низкая латентность Infiniband и отсутствие промежуточных буферов в реализации сетевого стека Ethernet-TCP позволяет в разы ускорить работу приложений, которые работают с большим количеством мелких файлов, например визуализацей в график или таблицу результатов расчётов, хранящихся во множестве файлов, сформированных с помощью множества параллельно работающих симуляторов.
Что