Полоса ZFS поверх аппаратного RAID 6. Что может пойти не так?

У меня 36 * 4 ТБ HDD SAN Rack. RAID-контроллер не поддерживает RAID60 и не более 16 жестких дисков в одной группе RAID. Поэтому я решил сделать 2 группы RAID6 из 16 HDD или 4 из 8 HDD. Я хочу получить все хранилище как один раздел.

Итак, что может пойти не так, если я буду использовать пул zfs поверх аппаратного RAID6? Да, я знаю, что настоятельно рекомендуется использовать родные жесткие диски или сквозной режим. Но у меня нет этого варианта.

Или я должен держаться подальше от ZFS и программных рейдов в этой ситуации? (Меня больше всего интересуют компрессии и снимки)

Поэтому я решил сделать 2 группы RAID6 из 16 HDD или 4 из 8 HDD.

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

Идеальный размер для массива RAID5 / 6 должен быть таким, чтобы точное кратное количество данных, которое «охватывает» массив, соответствовало размеру блока файловой системы, построенной поверх него.

Массивы RAID5 / 6 работают как блочные устройства - один блок данных охватывает диски в массиве, и этот блок также содержит данные о четности. Большинство RAID-контроллеров записывают порцию данных размером два с каждого диска в массиве - точное значение которого можно конфигурировать в более совершенных системах RAID - и ваше устройство Dot Hill является одной из таких «более совершенных систем RAID». Это важно

Таким образом, для охвата массива требуется N x (количество данных, хранимых на дисковый блок), где N - количество дисков с данными. Массив RAID5 с 5 дисками имеет 4 диска с данными, а массив RAID6 с 10 дисками имеет 8 дисков с данными.

Потому что, когда данные записываются в массив RAID5 / 6, если блок данных таков, что он достаточно большой, чтобы охватить весь массив, для этих данных вычисляется четность - обычно в памяти контроллера - тогда вся полоса записывается в диск. Просто и быстро.

Но если порция записываемых данных недостаточно велика, чтобы охватить весь массив, что должен делать контроллер RAID для вычисления новых данных четности? Подумайте об этом - для пересчета новых данных о четности нужны все данные во всей полосе .

Таким образом, если вы создаете массив RAID6 из 16 дисков с порцией по умолчанию 512 КБ на диск, это означает, что для «расширения» массива требуется 7 МБ.

ZFS работает в блоках по 128 Кб, как правило.

Таким образом, ZFS записывает блок 128 КБ - в массив RAID6 с 16 дисками. В предлагаемой конфигурации это означает, что RAID-контроллеру необходимо прочитать почти 7 МБ из массива и пересчитать паритет между этими 7 МБ. Затем перепишите все 7 МБ обратно на диск.

Если вам повезет, это все в кеше, и вы не получите огромный удар по производительности. (Это одна из основных причин, по которой позиция «не использовать RAID5 / 6» имеет следующее: RAID1 [0] не страдает от этого.)

Если вам не повезло и вы не правильно выровняли разделы файловой системы, этот блок 128 КБ охватывает две полосы RAID, которых нет в кэше, и контроллер должен прочитать 14 МБ, пересчитать четность, а затем записать 14 МБ. Все, чтобы написать один блок 128 КБ.

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

Но при большой нагрузке записи блоков по 128 КБ в случайные места есть очень хороший шанс, что производительность массива RAID6 с 16 дисками и размером полосы 7 МБ будет абсолютно ужасной.

Для ZFS «идеальные» базовые логические модули RAID5 / 6 для файловой системы общего назначения, где большинство обращений являются фактически случайными , имели бы размер полосы, равный делителю 128 кБ, например, 32 кБ, 64 кБ или 128 кБ. В этом случае это ограничивает количество дисков данных в массиве RAID5 / 6 до 1 (что бессмысленно - даже если это возможно настроить, лучше просто использовать RAID1 [0]), 2, 4 или 8. Наилучшая производительность в лучшем случае было бы использовать полосу размером 128 КБ для массивов RAID5 / 6, но лучший вариант не часто встречается в файловых системах общего назначения - часто потому, что файловые системы не хранят метаданные так же, как они хранить данные файла.

Я бы порекомендовал установить либо 5-дисковые RAID5-массивы, либо 10-дисковые RAID6-массивы, при этом размер блока на диск был достаточно мал, чтобы объем данных, охватывающих всю полосу массива, составлял 64 КБ (да, я сделал это раньше для ZFS - много раз). Это означает, что для RAID-массива с 4 дисками данных размер порции на диск должен составлять 16 КБ, в то время как для RAID-массива с 8 дисками размер порции на диск должен составлять 8 КБ.

Затем разрешите ZFS использовать весь массив - не разбивайте его. ZFS будет правильно совмещаться со всем диском, будь то диск с простым диском или массив RAID, представленный контроллером RAID.

В этом случае, не зная ваших точных требований к пространству и производительности, я бы порекомендовал установить три массива RAID6 с 10 накопителями или шесть массивов RAID5 с 5 накопителями с полосой размером 64 КБ, настроить пару «горячих» резервов и сохранить четыре ваших диски для всего, что придет в будущем. Потому что что-то будет.

Я бы наверняка не использовал эту дисковую систему в режиме JBOD - это полностью совместимое с NEBS Level 3 устройство, которое обеспечивает значительную защиту надежности и доступности, встроенную прямо в аппаратное обеспечение. Не выбрасывайте это только потому, что "ZFS !!!!". Если это дешевый товар, который вы собираете по частям? Да, лучше всего использовать JBOD-режим с ZFS для работы с RAID - но это НЕ аппаратное обеспечение, которое у вас есть. ИСПОЛЬЗУЙТЕ функции, которые предоставляет аппаратное обеспечение.

Хорошо, я укушу ...

Это неправильное оборудование для приложения. Настройка DotHill имеет те же ограничения, что и HP StorageWorks MSA2000 / P2000, поскольку в одной группе массивов можно использовать только 16 дисков.

ZFS поверх аппаратного RAID или экспортированного SAN LUN не обязательно является проблемой.

Однако чередование ZFS LUN с неизвестными межсоединениями на шасси расширения может представлять некоторый риск.

• Например, вы используете многопутевой SAS в кольцевой топологии с двумя контроллерами?
• Есть ли у вас избыточные кабели обратно на сервер?
• Распределяли ли вы диски по вертикали между корпусами таким образом, чтобы снизить вероятность сбоя одного шасси / кабеля / контроллера и предотвратить разрушение части полосы RAID0?

Серьезно, возможно, стоит оценить, нужно ли вам все это хранилище в одном пространстве имен ...

Если вам НЕОБХОДИМ такой тип емкости в одном креплении, вам следует использовать выделенный корпус JBOD, подключенный к HBA, и, возможно, несколько головных устройств с упругой кабельной разводкой и разумной компоновкой.

Вы должны ПРЯМО подключить все диски к коробке с ZFS. Получить SAS HBA и подключить диски к ZFS-совместимому блоку (например, запуск OmniOS или SmartOS). Затем вы можете поделиться пространство через NFS, SMB, iScsi ...

Причина, по которой ZFS поверх логических томов HW RAID является ОЧЕНЬ ПЛОХОЙ , заключается в том, что для правильной работы ZFS требуется доступ на уровне блоков. Да, его можно будет использовать, но функциональность не будет полной, пока вы не подключите диски непосредственно к ОС через HBA или прямые соединения SATA. Одним из примеров является то, что в предлагаемой вами конфигурации ZFS не может разумно защитить ваши данные от изменений данных, указанных ниже (на другой стороне HW RAID-контроллера), и, как таковая, не может гарантировать безопасность ваших данных . Это одна из ПЕРВИЧНЫХ причин, по которой ZFS используется, в дополнение к тому, что он очень быстрый.

ZFS - потрясающая технология, и я очень рекомендую это. Но вам нужно пересмотреть свою структуру, чтобы правильно ее использовать. А именно ZFS создает логические тома (vdevs) непосредственно из дисков.

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