Балансировка нагрузки в нескольких аппаратных raid-массивах - soft raid 0 приемлемо?

У нас есть центральный сервер хранения (PowerEdge R720), который обслуживает общие файлы для кластера HPC, и к нему подключены два аппаратных RAID-контроллера (PERC H810, каждый из которых содержит 2 корпуса MD1200, заполненных дисками по 7200 об / мин по 4 ТБ). Как и в случае типичной рабочей нагрузки HPC, ожидается, что шаблон доступа будет представлять собой параллельные последовательные операции чтения / записи. Я полагаю, что чередование файлов в двух массивах даст лучшую общую пропускную способность, но идея программного RAID 0 поверх аппаратного RAID звучит для меня безумно.

Я придумал два варианта:

  1. NFS на XFS на программном RAID 0 на аппаратном RAID 6
  2. блеск на каждом аппаратном RAID 6

Плюсы XFS: квота проекта.

Недостатки XFS: NFS в XFS показала очень плохую производительность метаданных (могла бы ухудшиться до почти непригодной для использования при большой пропускной способности, не так ли я настроил?).

Блестящие плюсы: значительно лучшая производительность метаданных.

блеск минусов (?): у нас нет выделенного устройства метаданных, нужно разделить массив. Похоже, не рекомендуется практика.

Мы рассматривали производительность метаданных, потому что, в то время как последовательная R/W является основной рабочей нагрузкой, у нас есть некоторые программы, работающие с чем-то вроде ~40k 1GB файлов. Интерактивное управление этими файлами требует приемлемой производительности метаданных.

И, наконец, вопрос, какие размеры полос использовать на аппаратном и программном обеспечении?

Источник

1 ответ

Мы остановились на этой настройке:

  • Аппаратный RAID-6 в каждом корпусе MD1200
  • Два LVM LV на четырех аппаратных массивах, каждый из которых объединяет два массива на двух картах без чередования
  • XFS на двух LV, варианты чередования такие же, как для аппаратных массивов
  • Объёмный объем на двух кирпичах, без полос

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

Хотя производительность метаданных этой настройки хуже, чем у блеска (примерно наполовину), она не ухудшается при большой пропускной способности. Это оказалось приемлемым.

Gluster настраивает квоты для каталогов, плюс его гораздо проще настроить, чем блеск, поэтому требует значительно меньше усилий по администрированию, чем блеск. В моих (грубых) тестах последовательная пропускная способность этой установки была на одном уровне с блеском, поэтому мы решили обменять эту часть на производительность метаданных для упрощения администрирования.

Источник
Другие вопросы по тегам