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