Когда я в прошлом посте написал, что Snapshots были, на момент появления систем NetApp их главной «фичей», я отчасти слукавил (а отчасти просто забыл), так как у них, на тот момент, была как минимум еще одна особенность, радикально выделяющая их из ряда «традиционных» систем хранения — это «RAID тип 4».
Это тем более интересно, так как никто больше такой тип RAID для использования в дисковых системах хранения данных не использует.
Почему же был выбран именно такой тип, в чем его преимущества, и почему никто больше такой тип RAID сегодня не использует?

Для тех, кто далек от теории рэйдостроения, напомню, что из шести стандартных типов RAID, описанных в научной работе, положившей начало их использованию, RAID тип 2 (с защитой кодом Хэмминга) не применялся в «живой природе», оставшись забавным теоретическим упражнением, RAID-1 (и его вариант RAID-10, или, иногда, как RAID-0+1) это защита данных автоматическим синхронным зеркалированием на паре (или нескольких парах) физических дисков, а RAID-3, 4 и 5 (позже к ним добавился RAID тип 6) — это так называемые «RAID с чередованием и четностью». Между собой они отличаются способом организации и хранения данных четности, а также порядком чередования данных. В обычно хорошо известном всем RAID-5, данные чередуются по дискам вместе с информацией parity, то есть parity специального диска не занимает.
В RAID-3 и 4 для информации parity выделен отдельный диск (Между же 3 и 4 разница в размере блока чередования — сектор в type 3 и группа секторов, блок — в type 4).



У RAID-4, то есть «RAID с блочным чередованием и четностью на выделенном диске», есть одно важное достоинство. Его можно увеличивать в размерах, просто добавляя в RAID физические диски, и при этом нет необходимости перестраивать полностью весь RAID, как, например, обстоит дело в случае RAID-5. Если вы используете 5 дисков под данные (и один под parity) в RAID-4, то для того, чтобы увеличить его емкость, вы можете просто добавить в него один, два, и так далее дисков, и емкость RAID-массива немедленно увеличится на объем добавленных дисков. Никакого длительного процесса перестроения недоступного для использования RAID-массива, как в случае RAID-5, не нужно. Очевидное, и очень удобное на практике преимущество.



Отчего же тогда RAID-4 не применяют повсеместно вместо RAID-5?
Он имеет одну, но очень серьезную проблему — производительность на записи.
Дело в том что каждая операция записи блока на дисках RAID, сопровождается записью для обновления блока parity на диске Parity. Это означает, что сколько мы ни добавим к наш массив дисков, между которыми будет распараллелен ввод-вывод, он все равно весь упрется в один единственный диск — диск parity. По сути производительность RAID-4, в «классическом» его применении, ограничена производительностью диска Parity. Пока на этом диске не прошла запись обновления содержимого лежащих на нем блоков parity, все остальные диски, хранящие данные, крутятся и ждут завершения этой операции.

Отчасти эта проблема была решена в RAID-5, где блоки parity также распараллеливаются по дискам, как и блоки данных, и проблема «бутылочного горла» в отношении диска parity была отчасти решена, что, впрочем, не означает, что RAID-5 лишен всех недостатков, скорее наоборот, это, на сегодня, наихудший тип RAID из всех широко применяемых, страдающий и от ненадежности, и от низкой производительности, о чем я писал в статье «Почему RAID-5 — mustdie?».

Особо останавливаясь на вопросах производительности (о надежности читайте статью выше) следует отметить, что RAID-5 имеет одну, но очень серьезную «родовую травму», изначально конструктивно присущую этому типу RAID вообще (типов 3,4,5 и 6 — «чередование с четностью») — малой производительности на произвольной (random) записи. Этот аспект в реальной жизни очень важен, так как объемы произвольной, случайной по характеру, записи в общем трафике хранения довольно значительны (достигая 30-50%), и падение производительности на записи напрямую влияет на производительность хранилища вообще.

Этой проблемой «болеют», повторюсь, все «классические» системы хранения, использующие RAID такого типа (3, 4, 5 и 6).
Все, кроме NetApp.

Каким образом NetApp удалось решить сразу и проблему «бутылочного горла» с диском parity, и проблему низкой производительности при random write?
Тут нам опять придется вспомнить структуру WAFL, о которой я уже писал ранее.
Как сказал по этому поводу инженер NetApp Kostadis Roussos: «Почти любая файловая система сегодня лежит поверх того или иного RAID. Но только WAFL и RAID на NetApp при этом знают друг о друге столько, чтобы взаимно использовать возможности, и компенсировать недостатки друг друга». Это действительно так, ведь для WAFL уровень RAID есть просто еще один логический уровень data layout внутри самой файловой системы. Напомню, что NetApp не использует аппаратные RAID-контроллеры, предпочитая строить RAID средствами своей файловой системы (аналогичный подход позже выбрала ZFS со свои RAID-Z)

Что же это за «взаимные возможности»?
Как вы помните из моего рассказа про WAFL, она устроена таким образом, что данные на ней, однажды записанные, в дальнейшем не перезаписываются. В случае же необходимости внести изменения содержимого внутри уже записанного файла, выделяется место в пространстве свободных блоков, запись измененного блока проводится туда, а затем указатель на содержимое старого блока переставляется на новый блок, бывший пустым, а теперь несущий новое содержимое.

Такая стратегия записи позволяет нам превратить случайную (random) запись в последовательную (sequental). А раз так, мы можем делать запись максимально эффективным способом — «полным страйпом» предварительно подготовив его, и собрав все «перезаписи», нацеленные в разные участки дисков, в одну удобную для записи область. То есть вместо перезаписи отдельных блоков, записывая в один прием готовую, сформированную «полосу» данных, разом на все диски RAID, включая и предварительно вычисленную parity всего страйпа на соответствующий ему диск. Вместо трех операций чтения-записи — одна.
Ни для кого не секрет, что sequental операции значительно быстрее и удобнее для системы, чем операции типа random.





Запись «полным страйпом», то есть на все диски RAID с чередованием, это максимально желанный алгоритм записи для такого типа RAID. Именно для этого на RAID-контроллерах наращивают объемы кэш-памяти, достигающих на high-end системах весьма впечатляющих размеров (и стоимости). Чем больше кэш на запись в традиционных массивах, и чем дольше в нем «зависает» блок данных, пришедший с сервера на запись на диск, тем больше шансов на то, что в этом кэше однажды соберется из таких блоков «полный страйп», и его можно будет слить на диски максимально выгодно.
Именно поэтому write-back кэши RAID-контроллеров стремятся сливать (flush) данные на диски пореже, и обязательно нуждаются в автономном питании своей памяти от батарейки для сохранения блоков данных, ожидающих своей очереди в кэше.

С ростом объемов дисков NetApp, как и все другие, столкнулась с необходимостью обеспечить повышенную надежность хранения данных RAID. Именно по этой причине, начиная с 2005 года, именно RAID-DP, NetApp-овская реализация RAID-6, является рекомендуемой, предпочтительной, и вообще «конфигурацией по умолчанию». В этом NetApp также первенствует, так как RAID -DP, защищая, как и RAID-6, от потери данных при потере двух дисков разом (например, сбое во время ребилда ранее отказавшего диска), не ухудшает показатели производительности, в отличие от RAID-6, в сравнении с RAID-5 или RAID-10.

Причины этому все те же. Ситуация у «других вендоров» с RAID-6, по сравнению с RAID-5 еще более ухудшается. Принято считать, что производительность RAID-6 падает по сравнению с RAID-5 на 10-15%, а по сравнению с RAID-10 на 25-35%. Теперь надо проводить не только чтение-запись одного блока parity, но надо делать это для двух разных групп блоков.
Однако RAID-DP по прежнему не нуждается в этом, причины этому все те же — случайная запись в произвольное место массива превращается в нем усилиями WAFL в последовательную запись в заранее выделенное пространство, а такая запись осуществляется гораздо быстрее и выгоднее.

Подтверждение того, что использование RAID-4 (и его варианта — RAID-DP, аналога RAID-6) на системах NetApp объективно не приводит к ухудшению производительности — авторитетные тесты производительности дисковых систем SAN (Storage Performance Council, SPC-1/SPC-1E) и NAS (SPECsfs2008), которые NetApp демонстрирует на RAID-4 (и RAID-DP с 2005 года).
Более того, системы NetApp с RAID-DP на равных соревнуются там с системами с RAID-10, то есть показывают производительность значительно выше привычной для «RAID с чередованием и четностью», сохраняя высокую эффективность использования пространства, ведь, как вы знаете, на RAID-10 можно использовать под данные всего 50% от купленной емкости, в то время, как на RAID-DP, при более высокой надежности, но сравнимом c RAID-10 быстродействии, и для стандартного размера группы, получается доступного места для данных свыше 87%.

Таким образом, остроумное использование совместно двух «фич» — RAID-4 и режима записи в WAFL, позволило получить преимущества от них обоих, одновременно избавившись от их недостатков. А дальнейшее развитие RAID-4 в RAID-DP, обеспечивающего защиту от двойного дискового сбоя, позволило повысить надежность хранения данных не жертвуя при этом традиционно высокой производительностью. А это непросто. Достаточно сказать, что использование RAID-6 (аналога RAID-DP, с эквивалентно высоким уровнем защиты), по причине низкой производительности на записи не практикуется и не рекомендуется для primary data больше никем из производителей систем хранения.

Как стать одновременно богатым, сильным и здоровым (и чтобы за это ничего не было)? Как обеспечить высокую степень защиты данных от сбоя, при этом не пожертвовав ни высокой производительностью, ни объемом дискового пространства?
Ответ знает NetApp.
Обращайтесь к его компаниям-партнерам ;)

UPD: в главной роли на фото в заставке статьи — NetApp FAS2020A из хозяйства хабраюзера foboss.