У нас есть центральный сервер хранения (PowerEdge R720), обслуживающий общие файлы в кластере HPC, и к нему подключены два аппаратных RAID-контроллера (PERC H810, каждый из которых управляет двумя полками MD1200, заполненными дисками емкостью 4 ТБ со скоростью 7200 об / мин). Как и в случае с типичной рабочей нагрузкой HPC, ожидается, что шаблон доступа будет представлять собой высокопараллельное последовательное чтение / запись. Я полагаю, что разделение файлов на два массива дало бы лучшую общую пропускную способность, но идея программного RAID 0 поверх аппаратного RAID кажется мне безумной.
Я придумал два варианта:
Плюсы XFS: квота на проект.
Минусы XFS: NFS на XFS показала очень плохую производительность метаданных (будет практически непригодной для использования при большой пропускной способности, я настроил ее неправильно?).
Плюсы блеска: значительно лучшая производительность метаданных.
блеск против (?): у нас нет выделенного устройства метаданных, мы должны разбивать массив. Похоже, это не рекомендуется.
Мы рассматривали производительность метаданных, потому что, хотя последовательное чтение / запись является основной рабочей нагрузкой, у нас есть некоторые программы, работающие примерно с файлами размером ~ 40 КБ размером 1 ГБ. Для интерактивного управления этими файлами требуется приемлемая производительность метаданных.
И напоследок вопрос, какие размеры полосок использовать на аппаратном и программном обеспечении?
Мы остановились на такой настройке:
Мы исследовали все приложения наших пользователей и обнаружили, что все они работают с множеством файлов. Таким образом, это не та ситуация, когда многие клиенты обращаются к одному большому файлу, где желательно чередование на уровне блеска; вместо этого простое случайное распределение файлов по блокам может обеспечить достаточную общую пропускную способность.
Хотя производительность метаданных в этой настройке хуже, чем у блеска (примерно половина), она не ухудшается при большой пропускной способности. Получилось приемлемо.
Gluster настраивает квоты для каталогов, к тому же его намного проще настроить, чем lustre, поэтому требуется значительно меньше усилий администратора, чем lustre. В моих (грубых) тестах последовательная пропускная способность этой установки находится на одном уровне с блеском, поэтому мы решили обменять эту часть на производительность метаданных для упрощения администрирования.