Является ли использование вложенного RAID 6 + 1 + 0 хорошей идеей?
В настоящее время у меня есть 24 диска по 500 ГБ, и я хотел бы создать более крупный вложенный RAID, используя сервер Dell Power Edge R730, имеющий 4-кратный RAID 6 с 6-кратным размером 500 ГБ каждый, поверх них я хочу добавить RAID 1 и RAID 0 на высоте в целом.
У меня вопрос: это безопасно? Стоит ли создавать такой большой массив?
Я знаю, что у меня будет потрясающая скорость, но обслуживание и отработка отказа будут стоить мне.
Смотрите предлагаемую картинку (на картинке 48 дисков).
Учитывая только концепции, задействованные на каждом уровне стека, а не конкретную реализацию, для некоторых приложений может иметь смысл разделить все эти три режима RAID на уровни.
Однако расположение на изображенной схеме имеет серьезный недостаток. Вы неправильно заказали слои. Для достижения оптимальной производительности и надежности вы должны поменять местами уровни RAID-1 и RAID-6.
Обычно RAID-6 настроен на потерю двух дисков. Таким образом, ожидается, что RAID-6 выйдет из строя после потери трех дисков. Это означает, что в худшем случае потеря трех из 48 дисков приведет к отказу одного из компонентов RAID-6.
Ваши данные переживут этот инцидент, но вам придется создать новый RAID-6 из 9 исправных дисков и 3 новых дисков. После того, как это будет сделано, вам нужно будет синхронизировать вновь созданный RAID-6, а также реплицировать уровень RAID-1 с другого RAID-6 на RAID-6, который в настоящее время синхронизируется. Это действительно тяжелая операция ввода-вывода.
Таким образом, случай потери 3 дисков требует и внимания администратора для восстановления, и большого количества операций ввода-вывода.
Вместо этого вы можете сначала сгруппировать 24 диска в 12 пар, используя RAID-1, а затем объединить эти 12 RAID-1 в RAID-6.
Таким образом, потерю отдельного диска всегда можно восстановить на уровне RAID-1, что намного эффективнее восстановления на уровне RAID-6. И даже в случае потери 5 дисков вы гарантированно сохраните уровень RAID-6.
В обоих случаях ваши данные переживут потерю 5 дисков, но есть разница в скорости восстановления.
В обоих случаях ваши данные могут быть потеряны из-за потери 6 дисков, но риск намного выше в изображенном вами сценарии, чем если бы слои поменялись местами.
Детали реализации
Чем больше слоев вы используете, тем выше риск столкнуться с проблемами при обработке конкретной реализации. Следует иметь в виду один вопрос: можно ли разделить горячее резервирование между различными ветвями структуры. Другой вопрос - насколько будет автоматизировано восстановление после потери одного из суб-RAID. Например, если вы потеряли оба диска в одном из RAID-1 на самом нижнем уровне, может ли он автоматически создать новый RAID-1 из двух «горячих» резервов и использовать его в качестве запасного для следующего уровня?
Я думаю, что это раздвигает границы концепции RAID, и вы столкнетесь с проблемами: позволит ли контроллер PERC добавлять виртуальные диски в другой массив? Разве у каждого из них не будет своя собственная политика записи и кеширования, каков размер кеша на вашем контроллере - в любом случае, если производительность такая, какая вам нужна, то смотрели ли вы на Ceph? - он сертифицирован для работы на R730, но вам понадобится диск журнала SSD - все записи происходят на SSD и позже перемещаются в массив, он не требует рейда для избыточности и предлагает хранилище объектов, блоков и файлов и кодирование стирания
Я думаю, что архитектура, которую вы имеете в виду, слишком сложна без какой-либо причины, о которой я мог подумать. По сути, вы тратите 28 дисков из 48 дискового массива для избыточности. Причина изобретения RAID6 заключается в том, что многие считают RAID1 / RAID10 слишком расточительным, но вы идете еще дальше, применяя RAID10 поверх RAID6.
Я бы порекомендовал либо полностью использовать RAID10, если вам действительно нужна вся эта избыточность, либо использовать RAID6 + RAID0 (он же RAID60).
Кроме того, имейте в виду, что разумный размер массива RAID6 составляет 8-20 дисков, причем 12-16 являются наиболее распространенными. Превышение этого технически возможно, но непрактично из-за кропотливо длительного времени восстановления.