about NetApp

Одной из вечных тем FUD-а конкурентов NetApp является “проблема” с фрагментаций данных в WAFL.
Оставим сейчас в стороне вопрос, насколько фрагментация действительно проявляется в практической жизни (я на эту тему уже писал ранее). Рассмотрим только вопрос того, насколько такой эффект вообще имеет место быть в теории.

Алекс Макдональд, инженер NetApp, в своем блоге привел любопытную модель, оценивающую влияние фрагментации на эффективность, в случае случайного (random) по характеру доступа.

Он заполнил таблицу из ста строк сотней случайных чисел, взятых с random.org, в первом столбце, которые изображают фрагментированные данные, затем второй столбец также случайными числами, изображающими то, какой блок программа запросила, в случае рандомного доступа к данным. И наконец он сравнил суммарное расстояние “seek” в случае считывания запрошенных данных (второй столбец) из максимально фрагментированного массива (первый столбец) и упорядоченного (то есть просто от 1 до 100).

С точки зрения “здравого смысла” мы бы ожидали, что фрагментированный столбец даст значительно (или хотя бы заметно) большую величину “seek”, по сравнению с упорядоченным, однако этого не произошло! Более того, столбец со случайно заполненными данными, из которого столь же случайно “запрашиваются” числа имел даже чуть меньший “seek” чем полностью упорядоченный! (Впрочем, ясно видно, что на достаточно большом интервале эти числа будут стремиться сравняться, так что можно просто принять их равными).

Несколько неожиданный для “здравого смысла” результат, однако, поразмыслив, нельзя не признать его правильным. “Случайное” помноженное на “случайное”  не дает “случайное в квадрате”. :)

Отсюда немного парадоксальный вывод: В случае случайного (random) по характеру доступа к данным, а именно такой тип нагрузки обычно и принято тестировать в первую очередь, так как он наилучшим образом соответствует работе современных многозадачных серверных систем и баз данных OLTP, фрагментация (случайность их размещения) данных на диске практически не увеличивает количество “вредоносного” seek distance по сравнению со случайным чтением упорядоченных данных, и не ухудшает характеристики производительности!

Нет времени писать на этой неделе большие трактаты. Поэтому отделаюсь маленькими заметками.

Не так давно я писал о том неожиданном эффекте, к которому приводит рост объемов. Так, например, рост объема жестких дисков практически лишает пригодности RAID-5, который использовался раньше повсеместно годами.

В одном из прошлых постов я привлекал внимание к проблеме разницы между “двоичными” и “десятичными” байтами. Ну вы помните, “программист думает, что в километре – 1024 метра”. Мы привыкли к тому, что разница эта есть, но она невелика настолько, что, как правило, ее можно проигнорировать. Подумаешь, всего 24 байта на целую тысячу!

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

Неожиданно выясняется, что разница между “Гибибайтом” и “Гигабайтом” превышает 7 процентов, а между “Тебибайтом” и “Терабайтом” – почти 10%!
Это уже более чем существенно!

Игнорировать 10-процентный эффект разницы уже нельзя. Так, например, если вы рассчитываете на 4-гигабитном канале передачи данных, скорость которого рассчитана из “двоичных байт” передавать хранимый на дисках объем данных, исчисленный из “десятичных байт”, вы получите “результат” отличающийся на более чем 7%, на каждом переданном гигабайте, просто по причине набегания этой ошибки.

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

Решил сделать пост на специальную тему, порождающую много недопониманий и сложностей при конфигурировании сложных систем NetApp. В свое время, в бытность мою пресейлом, также много крови выпило. Поэтому решил написать "резюмирующий пост", вдруг кому пригодится.

Контроллеры систем хранения NetApp современных серий приходят с определенным числом встроенных портов FC (2 на контроллер на FAS2000, по 4 на FAS3×00, по 8 на FAS6000). Для кластерных (двухконтроллерных) систем количество удваивается. Кроме этого все модели (за исключением FAS2020 и 2040) имеют слоты расширения, куда можно установить те или иные интерфейсные карты. Однако существует ряд правил, определяющих возможные конфигурации.

Для начала о терминах.
Порты FC могут находиться в следующих состояниях:
Initiator - сторона "сервера". То, на чем работает использующее дисковый ресурс приложение, то, что “инициирует” процесс чтения или записи данных.
Target - сторона "диска". То, на чем создается и раздается дисковый ресурс, то что является “целью” для процессов чтения и записи данных, хранит их, и отвечает на запросы инициатора процесса.

В случае NetApp:
Target – a fibre channel port used for connecting LUNs to hosts or servers.
Initiator – a fibre channel port used for connecting disk shelves to the storage controller or to VTL

1. Можно ли смешивать в одном контролере карты расширения FC target(для подключения серверов) и карты расширения FC initiator, например для подключения ленточной библиотеки или дисков?

ДА

Карты расширения могут быть как target (в которые включаются хосты), так и initiator (в которые включаются дисковые полки). Обязательно проверьте по Configuration Guide, совместимость желаемых карт с вашей системой, допустимое количество устанавливаемых карт расширения определенного типа, и разрешенные для установки соответствующих типов карт слоты расширения.

2. Можно ли использовать FC-карты расширения И порты FC на контроллере для подключения к ним дисковых полок (и те и другие в режиме Initiator)?

ДА

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

3. Можно ли использовать FC-карты расширения как target (для подключения серверов) И одновременно использовать как target какие-то из портов FC на контроллере?

НЕТ

Использование как target-ов портов на картах расширения запрещает использование как target-ов встроенных портов контроллера. Их можно при этом продолжать использовать только как initiator-ы( подключать к ним дисковые полки).

4. Можно ли сконфигурировать часть портов многопортовой карты расширения FC как target (для подключения к ним серверов), а часть этих портов - как initiator (для подключения к ним дисковых полок)?

НЕТ

Каждая физическая карта расширения может находиться либо в режиме target, либо в режиме initiator только целиком.

5. Можно ли подключиться к части портов FC на карте расширения на скорости 2Gb/s, а к другим - на 4Gb/s?

НЕТ

Каждая многопортовая карта расширения может находиться в определенном режиме скорости FC только целиком.

6. Можно ли подключиться к портам одной карты расширения на скорости 2Gb/s, а к портам другой карты расширения - на 4Gb/s?

ДА

Разные физические карты расширения могут находиться в разных режимах скорости FC.

7. Могу ли я использовать часть встроенных FC-портов контролера как target (для подключения серверов), а другую часть - как initiator (подключить к ним дисковые полки)?

ДА, но:
Если в системе нет карт расширения FC-target.

Встроенные порты FC на контроллере могут произвольно находиться как в target-, так и в initiator-mode, по выбору админа. Однако установка платы расширения в target-mode запрещает использование target-mode на всех встроенных портах целиком.

8. Могу ли я использовать часть встроенных FC-портов контролера как target (для подключения серверов), а другую часть - как initiator (подключить к ним дисковые полки) даже если оба этих порта работают на одном FC-чипе (ASIC)?

ДА, но:
Если в системе нет карт расширения FC-target.

Встроенные порты 0a и 0b (а также 0c и 0d, 0e/0f, 0g/0h) обслуживаются одним ASIC-чипом на пару этих портов. Совмещать режимы для встроенных на контроллере портов можно произвольно.

Пример:
У нас есть одноконтроллерная система FAS3140, с 4 встроенными в контроллер портами FC 4Gb.
1. Мы хотим подключить к контроллеру дисковую полку.
2. Мы хотим получить на системе 4 порта для подключения к ним серверов.

Неправильное решение:
Купить 2-портовую карту в слот расширения, на два встроенных порта подключить полку, на два - сервера, и еще два сервера на два порта на карте расширения.
Карта расширения в target mode запрещает target mode на встроенных портах.

Правильное решение:
Купить 4-портовую карту, установить ее в target mode, а в два встроенных в контроллер порта включить дисковую полку. Останутся свободными еще два встроенных порта в режиме initiator, для подключения дисковых полок.

Пример:
У нас есть одноконтроллерная система FAS3140, с 4 встроенными в контроллер портами FC 4Gb/s.
1. Мы хотим подключить к контроллеру одну полку типа DS14MK4 (с дисками на 4Gb/s), и старую полку DS14MK2 (с дисками на 2Gb/s).
2. Мы хотим подключить 2 серверных хоста.

Неправильное решение:
Купить 4-портовую карту расширения, поставить ее в initiator mode, и включить в пару портов полку DS14MK4, а в пару - DS14MK2. Во встроенные в контроллер порты включить сервера.
Совмещать разные скорости FC на одной карте нельзя (но можно на встроенных портах)

Правильное решение:
Купить 2-портовую карту расширения, поставить ее в target mode, и включить в нее серверные хосты. Встроенные порты перевести в initiator mode, и включить в 2 из них DS14MK2, а в два - DS14MK4.

Ранее, в посте про надежность RAID-5 я уже писал про такой аспект дисков SATA, как надежность и величину UER (Unrecoverable Error Rate, иногда также называется UBE - Unrecoverable Bit Error).
Величина эта почти на порядок (в 10 раз) хуже, чем для дисков SAS/FC, причем причина тут конструктивная, а не просто в интерфейсе.
Однако, для небольших систем “начинающих”, в первую очередь роль играет цена.

Жесткий диск (и система хранения) характеризуется, в общем случае, двумя параметрами: емкостью (измеряется в Мегабайтах/Гигабайтах (MB/GB)), и быстродействием (измеряется в IOPS - Input-Output Operations per Second - Операций ввода-вывода в секунду ). И если емкости дисков непрерывно растут вот уже несколько лет, то показатели по IOPS замерли уже довольно давно.
Принято считать, что диск SATA дает 80-100 IOPS, диски SAS/FC - 140-160 для 10KRPM, 180-200 - 15KRPM.

Стоимость за мегабайт для дисков SATA весьма низка, на сегодня она составляет 0,17$/MB для диска SATA 1TB, однако около 0.83$/MB для диска SAS 300GB. (я оперирую ценами, взятыми из price.ru: SATA WD RE3 1TB 7200 - 170$, SAS Hitachi 300GB 15K - 250$)

Иная картина будет, если мы посчитаем стоимость IOPS-ов. Диск SATA при этом будет стоить 2,1$ за IOPS, а 15K SAS - 1.38$/IOPS

Допустим, перед нами стоит задача создать сторадж на 3 TB, при этом быстродействие его должно быть не хуже 3000 IOPS.

Рассмотрим два варианта:
Если мы рассматриваем только емкость, то будет все просто:
SATA 1TB нужно три штуки, при цене за диск в 170$ общая сумма хранилища заданного размера, без учета RAID будет 510$
Дисков SAS на 15KRPM емкостью 300GB будет нужно 10 штук, при цене за диск 250$ такая емкость будет стоить 2500$

Казалось бы вывод очевиден, SATA дешевле, причем раз в пять.
Но мы пока не учли второе требование, про 3000 IOPS.

Для быстродействия системы емкостью 3TB в 3000 IOPS, из расчета в 80 IOPS с каждого диска SATA, нам нужно распараллелить ввод-вывод не менее чем на 38 дисков. 38 дисков SATA, это будет стоить уже 6460$.
Однако для дисков SAS те же 3000 IOPS достижимы на всего 17 дисках, что стоит 4250$

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

Этот момент часто не учитывают люди, планирующие использование SATA на задачах primary storage.

Если перед вами стоит задача не просто создать емкость хранения, без учета показателей по быстродействию, что, вообще говоря имеет только одно применение - хранилище архивных и резервных копий, а систему хранения, обеспечивающую приемлемую скорость работы приложения его использующего, то вам следует забыть про гигабайты, и ориентироваться, в первую очередь, на производительность дисков, на IOPS. Необходимый объем вы получите “автоматичски”.
Сегодня, во многих случаях, при планировании системы хранения, производительность есть ее “первичное”, ключевое свойство .
Или, иначе говоря: “GB are free, IOPS cost you money” - “Гигабайты бесплатно, вы платите только за доставку ИОПСы”

Сегодня я бы хотел провести для вас своеобразный "мастер-класс говнилок", или, если угодно, "сеанс черной магии", разумеется "с последующим ее разоблачением". Я воспользуюсь для этого статьей небезызвестного блоггера Чака Холлиса, почти официального "говнильщика" компании EMC. В части "разоблачений" мне поможет Вэл Берковичи, блоггер NetApp, некоторое время назад сделавший показательный разбор одного из постов Чака.

Чак выбрал своей темой сравнительный анализ результатов получения Usable Space из Raw на трех разных платформах хранения - EMC Clariion, HP EVA и NetApp FAS. Ну за EVA, я надеюсь, вступится еще кто-нибудь, я же разберу двух оставшихся, тем более что я по EVA не спец, однако уверен, что и там вполне могут быть схожие "результаты".

Вэл очень показательно сравнивает манеры, при проведении такого сравнения с поведением фокусника. Сначала нам показывают нечто вполне обычное и привычное. Колоду карт. Кролика и шляпу. Женщину в ящике ;) Мы осматриваем их, и вынуждены согласиться, что да, никакого подвоха тут нет (обычно уже на этом этапе что-то не так, и хитрость уже спрятана, чтобы вовремя сработать).

На втором этапе фокусник превращает рассмотренные нами обычные предметы в что-то необычное. Что-то исчезает, что-то видоизменяется, и так далее. Вы потрясены.

Тут все зависит от того, хотите ли вы быть одураченными. Если да, как обстоит дело в большинстве случаев, вам ничего не остается как согласиться с фокусником: "Да все так, кролик исчезает в шляпе, а женщина перепилена", даже несмотря на то, что в глубине души вы и понимаете, что вас где-то провели. Но ведь вы внимательно следили!

В свое время, в каждом выпуске журнала “Юный Техник”, известный фокусник Эмиль Кио давал описания какого-нибудь незамысловатого фокуса (ну у него их много в запасе было), с объяснениями "как".

Попробую и я показать вам в каком месте у Чака начинается "ловкость рук".

Итак, начало, The Pledge, "предъявление предметов".

Чак предлагает нам сравнить величины Usable Space на каком-нибудь простом и знакомом примере. Например инфраструктура хранения для MS Exchange.

Возьмем для примера шляпу диски FC 146GB, определим, что мы хотим получить на выходе пространство, равное емкости 120 дисков (около 17,5TB), и посчитаем, сколько дисков нам придется купить для системы, чтобы эти условия соблюсти.

Мы берем руководства Best Practices по установке для соответствующих систем, и начинаем, оперируя ими, рассчитывать пространство, "делать сайзинг" как это называется у нас.

Повторюсь, я не слишком большой спец в области конфигурирования EMC, поэтому я просто возьму анализ для CX4 самого Чака. Я не стану переписывать тут весь его пост, за подробностями можно пройти непосредственно к нему, покажу лишь сам принцип. Итак, перед нами стоит задача получить на выходе usable-емкость 120 дисков на 146GB. Что добавится к этой величине?

Диски hotspare - EMC рекомендует иметь 1 диск hot spare на каждые 30 дисков данных.

Пространство для snapshots - возьмем эту величину равной 10% от usable

Секторный оверхед - Clariion также как NetApp FAS использует увеличенный до 520 байт сектор, то есть примерно 1.5% к пространству usable.

Но что это? Внимательный взгляд уже видит первую ловкость. Отчего это Чак берет в качестве типа RAID для такой большой системы - RAID-5?

Даже если вас не убедила моя "дюжина ножей"(пост раз и пост два) в спину RAID-5, довольно будет и того, что это не рекомендует даже сам EMC в тех самых Best Practices, на которые сам же Чак Холлис и ссылается:

страница 15, документ #H4060, Oct. 2007:

It is generally accepted that RAID 1/0 is a better choice for random-write environments like Exchange

В том числе это так и для DMX (стр. 7-49):

http://www.emc.com/collateral/hardware/solution-overview/h4067-microsoft-exchange-server-symmetrix.pdf

As a matter of Best Practice, EMC generally recommends RAID1 to be the primary choice in RAID configuration for reasons of reliability and availability and performance for high-end deployments of Microsoft Exchange Server.

Вот он, трюк. Сейчас посмотрим, что получится в результате.

Кроме этого, Чак еще пару раз "забывает" о некоторых моментах, так, например, говоря о рекомендации делать right sizing на 10% для дисков в RAID на NetApp, для того, чтобы, при необходимости, можно было ввести в RAID диск слегка отличающийся по "геометрии", например спустя несколько лет, если поставляемые на замену диски отличаются от оригинальных в количестве секторов, он напрочь "забывает" это учесть в своем расчете для CX4, несмотря на то, что на это прямо указывается в Best Practices EMC.

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

Использовать же эти 5 дисков в составе большого RAID-10 нельзя, так как Vault на них уменьшает их "аппаратную геометрию", и они становятся "несовместимыми" по размерам с остальными дисками системы. То есть минус 5 дисков целиком.

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

Что же у нас получилось?

А вот что:





Разительная разница по сравнению с цифрами, приведенными у Чака, не правда ли?

"Ловкость рук, и никакого мошенства".





 

Теперь займемся нашим NetApp FAS.

Исходные данные те же.

120 дисков по 146GB емкости в Usable, сколько должно быть в Raw?

Исходный ход расчета Чака оставим без изменений, но будем опять внимательно смотреть "за руками".

Вот оно!

One thing is extremely clear — running out of snap reserve looks to be a very bad thing in a NetApp environment — there’s no place to put an incoming write, usually resulting in catastrophic application failure.  By comparison, other approaches (e.g. CX4 and EVA) simply stop trying to capture before-write data if you run out of reserve — the application itself continues to run.

…

It is recommended to have a 100% space reservation value set for volumes hosting LUNs containing Exchange data.

Разумеется в таком анализе не обойдется без традиционной спекуляции на тему 100% LUN space reservation. Как-то даже слишком предсказуемо.

Обязателен, неизбежен и абсолютно необходим ли 100% space reservation, как необходимо отдать 100% от объема data disks при создании RAID-10?

НЕТ.

Вы не можете уменьшить количество дисков, уходящих под "зеркало" в RAID-10, в котором Usable еще до всех "вычетов" всегда будет менее 50% от Raw.

Однако можете уменьшить количество места, отдаваемое под fractional LUN reservation в NetApp FAS, так как его уменьшение не ведет к неработоспособности.

Я уже останавливался ранее на том, что же скрывается за fractional (LUN space) reservation.

Скажу честно, тема непроста, но понять ее можно. Вот, если вкратце, на пальцах:

LUN space reservation это место, выделяемое и резервируемое на томе в том случае, если вы планируете использовать snapshot для LUN,и есть риск, что значительная часть объема этого LUN будет перезаписана. В этом случае резервирование пространства размером с весь LUN гарантирует нам то, что можно будет создать snapshot с этого LUN и место для нормальной работы с этим LUN-ом еще останется.

По умолчанию, руководствуясь правилом "прежде всего - не навреди" Data ONTAP действительно предлагает наиболее "консервативную" установку, в виде 100% reserve, гарантирующую, что даже если админ совсем ничего не понимает, и ставит систему Enter-ом, соглашаясь со всеми дефолтными настройками, то ничего смертельно опасного для его данных при работе не произойдет.

Означает ли это, что никаких других возможностей не предусматривается? Нет, не означает.

Можно ли не использовать 100% LUN space reservation, и чтобы при это все работало? Да, запросто.

Какие еще возможности есть? Можно, например, автоматически увеличивать размер тома, на котором расположен LUN, с тем, чтобы места хватало и на LUN, и на создаваемые Snapshots. А можно настроить автоматическое удаление старых снэпшотов, при создании более новых, если им не хватает места.

Ну и, наконец, если места не хватило, то предусмотрена возможность корректного автоматического размонтирования LUN-а, на котором невозможно продолжать запись.

И все это - без необходимости резервировать 100% от usable space под LUN space reservation.

Давайте посчитаем по нашей методике raw space, взяв желаемый usable добавим к нему все "вычеты", "оверхеды" и "резервации", добавим диски parity RAID из расчета 2 диска на каждые 14 дисков (RAID-DP), и, наконец, hot spare (два на первые 100, и по два на каждые следующие 84), и посмотрим что получилось (все дробные величины округлялись в большую сторону до целочисленных значений, указанные на диаграмме значения показывают доли секторов диаграммы и не всегда равны процентам в таблице).





Для желающих поиграться - прикладываю мою табличку, где я все это рисовал.

EMC_vs._NetApp.xlsx

Итак, резюмируя прочитанное. Для того, чтобы провести правильный сеанс "говнения" конкурента, необходимо следующее:

1. Представить себя как "независимое лицо", незаинтересованное в определенном "предвзятом" результате. Например проведите сравнение параллельно для нескольких вендоров.
2. Продемонстрировать все исходные материалы, упирая на их доступность.
3. Всегда аппелировать к вендорским Best Practices, пусть даже отдельные части их и будут проигнорированы, а сами они могут быть "outdated", устаревшими. Мало кто полезет проверять все подробности в 150-страничном PDF-е, в лучшем случае прочтет указываемое вами предложение в тексте, зачастую без контекстной связи.
4. Всегда сравнивать системы в выгодном для себя контексте. Ваша система имеет низкую производительность? Сравнивайте на задачах архивного хранения и резервного копирования. Система высокопроизводительна, но дорогостояща? Сконфигурируйте минимально возможную, пусть и неприменимую в реальной жизни конфигурацию. Малопроизводительна, но дешева? Активно пользуйтесь сравнением соотношения price/performance. Владея инициативой при написании документа - заставьте противника обороняться на неудобном для него поле.
5. Не забудьте о психологическом давлении и субъективности восприятия. Хорошее название для сравнительного документа "Вся правда о…". Почаще упоминайте "свободность" и "открытость" (“хорошо!”) в пику "проперитарности" и "закрытости" (“плохо!”).
6. Проводя в тексте нужный трюк, постарайтесь отвлечь от него внимание, например ссылками на какие-либо документы, или цитаты авторитетов. Актуальность их обычно не проверяется. Хорошо работают графики таблицы, иллюстрирующие ваши выводы, тем боле, что чаще всего перепроверять данные никто не полезет.
7. Отлично работают: “правильная” группировка результатов, а также маленькие хитрости, типа смешивания единиц измерения, неуказание единиц, нелинейная шкала отображения для графиков, и так далее.

Сокращенный перевод поста Chris Lionetti, Reference Architect – Microsoft Solutions Engineering

Этот пост рассматривает проблему Unrecoverable Error Rate (UER), «Уровня невосстановимых ошибок» на жестких дисках.

Диски типа SATA оптимизируются по соотношению GB/$ и GB/Watt, в то время, как диски с интерфейсом FC и SAS по параметрам IOPS/$ и IOPS/Watt. Это означает, что в плане плотности записи и механики, диски типа SATA решительно отличаются от дисков FC/SAS *1. Диски FC/SAS трехлетней давности имеют Unrecoverable Error Rate равный одному блоку на 10^15 бит данных (UER15). Диски SATA имеют этот параметр равный 1 блоку на 10^14 бит данных (UER14), что означает, что один блок (512Bytes) может быть потерян в среднем каждые 11TB считанных данных. Для UER15 это означает 1 блок каждые 110TB данных, и UER16 значит 1 блок каждые 1100TB пространства.

Давайте используем те же 9-дисковые наборы, что и в первой части поста. Берем 9-дисковый RAID 5 (8+1), 10-дисковый RAID DP/6 (8+2), и 16-дисковый RAID 10 (8+8). Предполагаем, что мы используем ту же инфраструктурную схему, при которой используется суммарно 800 дисков с данными.

Также возьмем за предположение величину отказа в 3%. Это означает 27 ребилдов для RAID 5 (см. предыдущую статью почему так). Допустим, что мы используем диски на 1TB, что означает, что когда в нашей дисковой инфраструктуре случается отказ (по нашим расчетам это может происходить до 27 раз в год) у меня есть шанс 8 из 11 (72% вероятность) что я получу ошибочно прочитанный UER-блок во время ребилда. Так как в случае  возникновения UER она воздействует на весь страйп в наборе RAID 5, она влияет на объем данных, равный Stripe Element size * stripe size. Это означает, что вы можете получить до 64KB x 8 = 512KB поврежденных данных посреди вашего датасета, не узнав об этом. Хорошая новость в том, что, скорее всего, вы используете более надежные диски.

Если вы используете так называемые «enterprise class» диски вместо недорогих дисков «Desktop class SATA», то вы получаете диски с уровнем UER15. Такие более высококачественные диски, с более высоким UER, будут повреждать данные всего в 7.2% случаев во время каждого ребилда. В случае использования дисков FC 15K/10K, эта величина понизится до 0.72% во время каждого ребилда.

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

Данные в таблице берут за основу параметры: 3% AFR, 8 дисков данных, и рассматривают вероятность для каждой операции ребилда.

Диски типа Enterprise SATA обычно приближаются к величине UER15, в то время, как в случае дисков FC и SAS 15K RPM всегда говорят о UER16.

Скрытые проблемы на Enterprise SATA.
Аргумент, который всегда приводится, это что SATA имеют теперь тот же уровень ошибок, что и «enterprise drives». SATA на протяжении последних лет постепенно улучшают свои показатели, с UER14 до UER15, но, одновременно с этим, учетверяют свой объем. Стали ли диски боле надежными? Да, но не в 10 раз, как вы могли бы подумать, глядя на техспеки. За то же самое время диски enterprise FC улучшили показатель надежности с UER15 до UER16, достигнув при этом примерно половины емкости от дисков SATA.

Существует также некая возможность в дисках SATA, которая позволяет индустрии дисков SATA достигать уровня UER15. Эта возможность называется «heroic recovery» *2. Этот вариант восстановления ошибочно считанных данных при чтении означает, что диск прочитывает очень большой фрагмент данных и пытается восстановить неустойчиво прочтенный блок с использованием избыточности, чтобы потом переписать его куда-нибудь в другое место. Результатом замедления работы при «heroic recovery» может быть то, что диск перестает вовремя отвечать на запросы, и, в результате, вываливается из RAID.

Большинство (если не все) контроллеров RAID выключает на своих дисках «heroic recovery». Вопрос, ответ на который невозможно получить ни от одного вендора жестких дисков, это то, измерен ли UER этих диско с выключенной heroic recovery? Если вы утверждаете, что heroic recovery блока может восстановить данные с 9 из 10 неустойчиво читающихся блоков, то выключение этой возможности означает снижение для диска UER15 до UER14. Я включил в график данные как для UER14, так и для UER15, ваши диски будут располагаться где-то между этими двумя. Этот график показывает как оптимистичные, так и пессимистичные оценки вероятностей в RAID 5 и RAID 10 для объемов ваших данных, могущих быть поврежденными на протяжении года.

 
Выводы
У вас есть две возможности избежать неприятностей. Вы можете либо выбрать использовать RAID6, либо использовать диски с UER16. Этот пост написан не с целью продать вам диски SATA или FC, но лишь только помочь вам осознать опасности использования RAID5, а также опасность использования дисков SATA не имея способ смягчить возможные последствия. Вот в чем смысл нашего сегодняшнего заголовка. Все эти три понятия - сказочные.

(прим. romx: долго подмывало вместо Деда Мороза написать Честный Милиционер, или что-то в этом духе. В оригинале был Easter Bunny, «пасхальный кролик»)

Самое главное, что вы должны уяснить, дочитав это пост, это то, что больше нельзя доверять RAID 5. У вас есть сравнительно небольшой риск того, что ваши данные будут полностью потеряны, но существует гораздо более высокий риск того, что поврежденные данные приведут к замедлению работы, если попадутся в момент операции ребилда.

–
*1 Willis Whittington – WINHEC05 presentation on enterprise drives
*2 http://www.wdc.com/en/products/products.asp?driveid=403 Читайте про time limited recovery. Целых 7 секунд!. Эта проблема существует по всей индустрии SATA, а не только у Western Digital.

Мой любимый нетапповский автор, Костадис Руcсос, который в своем блоге на днях закончил длиииинную десятичастную тему, тоже говорил, что в принципе это bad taste in blogging, устраивать такие “сериалы”, так как внимание даже искушенного и лояльного читателя теряется. Надо как-то стараться писать коротко и ясно. Вот всякий раз, как я начинаю в блоге травить анекдоты, сразу налетает толпа, так, на недавний пост с “автопроизводителями”, за три дня пришло почти треть обычной месячной аудитории блога. А то я все умничаю. Во, народу надо доступных зрелищ, это еще древние римляне понимали. ;)

Поэтому пост будет недлинный, нетрудный, и с картинками :)

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

Давайте рассмотрим это на примере небольшой и относительно недорогой, а потому особенно популярной в России системы начального уровня FAS2050.

Это система уровня low-enterprise, вторая с “нижнего конца” (младше ее есть еще FAS2020, предназначенная для совсем небольших инсталляций и систем).

Она представляет собой конструктив  высотой 4U, на 20 дисков 3.5”, вставляемых горизонтально “с лица”, и двумя контроллерами (часто мы называем их на жаргоне “головы” или “filer head”), обеспечивающими отказоустойчивую работу в режиме active-active cluster.

Каждая “голова” несет на себе (слева-направо):

• 2 порта 4GB FC, которые могут использоваться как FC-target (по простому – к ним можно подключить сервера SAN-сети, и они смогут использовать LUN-ы на NetApp), а также к ним можно подключать дополнительные дисковые “полки” расширения. Дисковые “полки” едины для всех моделей NetApp, могут нести в себе по 14 дисков SATA или FC (каждый тип полки под свои диски), и подключаются к контроллерам по интерфейсу FC (даже если диски в них SATA).
• Разъем последовательного порта для непосредственного консольного доступа (аналогичен такому же порту например на оборудовании Cisco, и некоторых других устройств), использует разъем RJ-45, и выглядит как сетевой, но не перепутайте.
• Порт сетевого подключения к BMC – Baseboard Management Control, отдельной управляющей подсистеме, с помощью которой можно организовать отдельную “подсеть” управления, если вы, например по соображениям безопасности, не хотите управлять системой из обычной “общей” LAN. Кроме этого, через BMC можно управлять системой на том уровне, когда обычные сетевые контроллеры еще не работают, например при загрузке системы и Mantenance Mode.
• Два независимых порта Gigabit Ethernet. Каждый из этих портов может работать независимо, например можно создать две подсети доступа, или по одному из интерфейсов подключаться как к NAS, по протоколам NFS или CIFS, а ко второму – по iSCSI. Можно также объединить эти порты либо в отказоустойчивую схему, либо в транк, при котором скорость передачи данных удваивается.
• Выше ряда разъемов интерфейсов располагается заглушка слота PCIe, в которую могут быть установлены платы расширения NetApp, такие как: дополнительные порты FC, Ethernet, аппаратный iSCSI HBA, и даже UW-SCSI, с помощью которой можно подключить к FAS ленточный накопитель, и делать автономный бэкап его содержимого на ленту.

Контроллеры или “головы” полностью автономны, и могут работать независимо, каждая со своим набором дисков. В случае выхода из строя одной из них, или отказа, например, доступа по сети к какому-то из них, система переводит диски такого контроллера, а также все ресурсы (имена файловых шар, IP-адреса для NAS, WWN-ы для SAN) на “выживший” контроллер, и, с точки зрения пользователя, работа в случае такого “cluster takeover” продолжается “прозрачно”, без необходимости ручной перенастройки на серверах и клиентах (хотя, конечно, производительность и падает, ведь теперь один контроллер работает “за двоих”).

Устанавливаемые в базовый конструктив диски могут быть либо SAS, либо SATA. Системы семейства FAS2000 впервые начали использовать диски SAS, так как ранее системы FAS использовали диски FibreChannel (FC). Использование дисков с интерфейсом SAS позволило несколько снизить стоимость системы, однако не в ущерб надежности. Опубликованные данные говорят о том, что применяемые диски SAS и такие же FC отличаются лишь контроллером и типом интерфейсного разъема. Надежность и быстродействие их идентичны.

Такая система продается в двух вариантах “набивки”, на 12 дисков, и на 20 дисков.

Предположим, вы выбрали конфигурацию на 12 дисков. К примеру, вы выбрали диски SAS 450GB 15K, и посчитали, что 12 дисков дадут вам 5.4TB пространства, чего вам замечательно как раз на все и хватит, и при этом не обратили внимание на предупреждения продававшего вам систему специалиста NetApp или его партнера.

“Неприятности” начнутся на этапе первоначальной установки.

Так как наша система кластерная, и имеет два независимых контроллера, нам надо разделить диски между контроллерами. Если мы делим их поровну, то каждому контроллеру достается по 6 дисков.

Теперь на этих 6 дисках мы создаем RAID-ы. Допустим мы выбираем тип RAID по умолчанию, так называемый RAID-DP, нетапповский вариант RAID-6, но без потерь производительности и быстродействия, характерных для “обычного” RAID-6. В случае дисков SATA это, на сегодня, единственно приемлемый тип, но и в случае SAS это вполне разумный выбор.

При создании aggregate и RAID из наших 6 дисков вычтется один (в случае RAID-4) или два (в случае RAID-DP) диска на хранение parity. Кроме этого, каждому контроллеру надо выдать один диск hot spare.

Итого, мы получаем из 12 дисков два RAID по 3 usable диска в каждом. То есть, в случае выбора дисков SAS 450GB: 3×450GB = 1350GB на каждом из контроллеров. Обратите внимание, объединить их, например, чтобы записать на них 2.7TB “одним куском” не получится, только двумя кусками по 1.35TB.

На рисунке коричневым показаны диски parity для контроллеров A и B, зеленым – hot spare, и синим – диски данных. Обведен красным диски контроллера А, синим – контроллера B.

Для новичков в NetApp, а именно к таким обычно и попадают обычно младшие модели NetApp с небольшим базовым количеством дисков, результат неожиданный, и, что уж говорить, если начистоту, не особо приятный.

Тем не менее “Ну ужас, да. Но не “ужас-ужас”, как говорила героиня известного анекдота.

Говоря начистоту, никто из наши конкурентов не рассматривает иные типы RAID кроме RAID-10 в качестве основы для хранения primary data, то есть активных рабочих данных, будь то базы данных SQL, почтовая база Exchange или хранилища виртуальных машин.

Поэтому, гипотетический простой стиральный порошок сторадж на 12 дисков, какой-нибудь другой компании, при выборе RAID-10, даст ровно тот же результат в 50% usable от общего объема. При этом, прошу отметить, RAID-DP объективно надежнее, практически такой же быстрый, и мы получаем с ним еще и два hotspare диска.

Но самое интересное получается дальше.

Если мы захотим теперь расширить емкость нашего FAS2050, добив его дополнительными 8 дисками до 20 штук в базовом конструктиве, то мы сможем все эти диски добавить как диски данных.

В то время как в “обычном сторадже”с RAID-10, в usable будут снова только половина.

Как видите, с увеличением количества дисков в системе, эффективность использования пространства дисков у NetApp возрастает.

Но это не предел.

Максимальный размер одного RAID для дисков SAS и FC в системах хранения NetApp допускается до 28 дисков*. Рекомендуемая величина (делать “очень длинный RAID” по разным причинам не самая лучшая идея) – 16 дисков.   
 

Если мы добавим дисковую “полку” расширения к нашей системе, мы сможем довести соотношение usable к raw до 82%! Из 34 купленных дисков, мы можем отдать под данные целых 28! При этом не поступившись ни надежностью, ни быстродействием. 
Результат более чем впечатляющий. 

Выводы очевидны.

• Чем больше дисков в системе у NetApp, тем выше эффективность их использования.
• ”Побочный” расход дисков на системах NetApp довольно велик для систем с небольшим количеством дисков, но почти не увеличивается при дальнейшем их добавлении.
• Избегайте покупать системы NetApp с дисками “впритык” (особенно небольшие), обязательно при покупке уточните вопрос, сколько в результате получится usable space, чтобы избежать неприятных сюрпризов на этапе пусконаладки.

–
* Один aggregate (и тома на нем) могут располагаться поверх множества независимых RAID-групп (16+16+16…). В пределах заданного при создании aggregate размера RAID, диски добавляются в него, по достижению заданного размера (например 16 дисков) начинается новый. Текущий лимит на размер aggregate/тома для всех систем под ONTAP 7G (кроме 2020) - 16TB

Предыдущие посты серии:

Первый
Второй
Третий
Четвертый

Итак, aggregate созданы, а на них созданы, в свою очередь, тома (volumes).
“Том” (Volume) есть основной элемент структуры хранения NetApp.
Вся информация, и все вышележащие структуры данных, такие как “сетевые шары” и LUN-ы располагаются внутри “тома”.
В частности именно на том действуют снэпшоты.

На каждом томе можно создать 254 снэпшота. С учетом максимального количества томов, возможных на системе, получается суммарно около 51 тысячи. Впрочем это скорее теоретическая величина, поэтому заостряться на ней не будем, что же касается снэпшотов то вам их, я полагаю, хватит в любом случае. Напомню, что решения, называющие себя “снэпшот”, у конкурентов обычно заметно ограничивают их количество в 14-30 на всю систему в целом (см. комментарии). Такое ограничение вызвано не в последнюю очередь тем, что использование snapshots у таких систем резко влияет на производительность, и, обычно, снэпшоты на них массово просто не применяются, так как весьма значительно “сажают” производительность системы в целом.

Раз мы добрались до тома и его снэпшотов, позвольте подробнее остановиться на непростой, и вызывающей множество непонимания теме “резервирования” или snapshot reserve.

Когда-то, давным давно, когда NetApp был только NAS системой, было эмпирическим путем определено количество места, которые отводятся и резервируются под снэпшоты, в 20% от общего объема тома. То есть, для простоты понимания на конкретном примере: из тома в 100MB на блоки, зафиксированные в снэпшоте, мы отводим 20MB (на основные данные остается, соответственно, 80MB).

Для правильного понимания того, как работает резервирование, стоит нарисовать вот такой рисунок:

В ней, для простоты изображения и понимания, данные, записываемые на том, прирастают снизу.

Блоки, попавшие в снэпшоты, прирастают сверху.

Граница “резерва под снэпшоты” это линия, отделяющая верхние 20% емкости, в которых прирастают (условно сверху вниз) данные снэпшотов.
При этом, граница эта “проходима” сверху вниз, но не снизу вверх. То есть, если случилось так, что снэпшотов создалось больше, чем на 20% резерва, например на 25, то будет заняты “сверху” 20, и плюс еще кусочек на 5% “сверху” от активного тома.

Однако, когда мы попытаемся записать активных данных больше 80MB на 100MB-том с резервом в 20%, даже если это резерв и не используется снэпшотами, мы получим сообщение о нехватке места. То же самое произойдет и если двигающиеся “навстречу” данные “активной файловой системы” и снэпшотов встретятся.

Перед этим система будет сыпать алертами о исчерпании места, например в уже рассмотренном случае, когда снэпшоты “вылезли” из пространства резерва, в сообщении будет говориться о “заполненности тома на 105%”. Проценты свыше 100 это как раз то, насколько из резерва вылез хвост объема снэпшотов.

Решить проблему можно удалив часть, возможно уже ненужных снэпшотов, при этом блоки, ими занятые, освобождаются, и поступают “в распоряжение” активной файловой системы.

Можно ли изменять величину снэпрезерва? Разумеется да.
Можно ли поставить ее в 0%? Да.
Отключит ли это возможность создавать снэпшоты на томе? Нет, просто снэпшоты сразу будут занимать место в пространстве “активной файловой системы” тома. Представьте, что граница с рисунка поднята до упора вверх, но она по прежнему проходима для снэпшота, растущего сверху вниз.
Чем это грозит? Да по сути ничем, просто вам надо будет либо не пользоваться снэпшотами (опрометчивый, но имеющий право на существование способ использования стораджа NetApp), либо внимательно контролировать заполнение тома и величину пространства, занятую снэпшотами, чтобы они случайно не исчерпали собой доступное для данных место.
Зачем вообще нужно это резервирование? Ну это просто удобно. Сисадмин системы хранения знает, что у него всегда есть специальный запас места для создания снэпшотов, что туда никто кроме них не залезет и не займет, и снэпшоты, пока это место не переполнится, всегда на томе будет где создать. То есть это просто такое средство немного облегчить жизнь и снизить количество мест, которые надо контролировать.

Традиционно решение ставить snapreserve в 0% применяется при использовании системы NetApp в качестве чистого SAN, когда на volume создается LUN, равный ему по размерам, а создание снэпшотов не используется, и не планируется.
Однако чаще для такой конфигурации, в особенности когда планируется _использовать_ снэпшоты, рекомендуется устанавливать резервирование в 100%. Тогда, даже в самом наихудшем случае, когда все блоки LUN-а изменены, то места на снэпшот хватит.

Я уже писал подробно про этот вопрос в посте про использование “Fractional Reserve”.
Там же я рассказывал про другой способ решения проблемы снэпшота для тома с LUN - автоматическое увеличение тома, опция “autogrow”, в том случае если на aggregate, где он расположен, есть свободное пространство.
Вы можете не резервировать место при создании тома, а просто в свойствах тома сказать, что, когда понадобится, он может расти, занимая под себя свободное место в aggregate.

Итак, мы создали том, и задали ему snapshot reservation ту, какую захотели, например 20, или 15% в случае планов использования данного тома под хранение файлов (NAS), 0 или 100%, или определили fractional reserve, опции autogrow и autodelete, при использовании его для размещения на нем LUN-а.

…и почти добрались до конца. Теперь давайте посмотрим, что же у нас получилось с usable.
Окончание (надеюсь) в следующий понедельник (надеюсь).

Да уже и не must, а почти что almost.

Еще несколько слов аргументации за переход к RAID-6, тем, у кого он не тормозит, не будем показыват пальцем, но: “Есть такие вендоры!” ;).
Да, согласен, RAID-10 тоже вполне может пережить отказ двух дисков, если вам повезет, что это произойдет в разных половинах “зеркала”. Но только в этом случае.

—————
RAID 5 появился в 1987 году, и был вполне адекватен решаемым задачам на протяжении следующих 15 лет непрерывного роста. Обычный размер диска в 1987 был всего 21MB, да, именно МЕГАбайта, и скорость вращения была 3600 RPM. На протяжении следующих 20 лет, диски выросли до 1TB (в 50 тысяч раз больше, но только вдвое-вчетверо в скорости вращения). Этот огромный рост привел к проблеме и продемонстрировал ущербность данного уровня RAID.

Проблема заключается во времени, которое уходит на перестроение большого по объему RAID, которое может исчисляться днями. Это может привести вас к проблеме выхода из строя второго диска на том же RAID, в то время, как процесс ребилда еще не завершился. Величина под названием Annual Failure rate (AFR) для дисков становится лучше год от года, но это не устраняет проблему продолжающегося роста времени ребилда. Другая проблема состоит в том, что в процессе ребилда нагрузка на диски существенно возрастает, что, в свою очередь, увеличивает вероятность отказа, так что процесс ребилда сам по себе может быть для дисков еще опаснее*1 (до 2.5 раз).

Допустим, AFR (Annual Failure Rate, “вероятность отказа”) равен 5%*2, и время ребилда равно 1 дню. Мы используем 9-дисковый RAID-5 (8+1). Шансы получить второй дисковый отказ за это время равен 1/365 x 5% x 8 x 2.5= 0.25%. Допустим, у нас используется 100 таких групп по 9 дисков в RAID 5 в системе (900 дисков). Я могу ожидать, что получу 45 отказавших дисков в течении года. Во время прохождения ребилда я “бросаю кости”. У меня есть 1 шанс из 400 получить за время ребилда отказ второго диска, приводящий к потере данных, и я “бросаю” эти кости 45 раз в год. В течении 5 лет срока службы это означает вероятность 225 из 400 получить катастрофический сбой с потерей данных.

Давайте рассмотрим теперь тот же сценарий, но удвоим размер дисков, и понизим AFR (Annual Failure Rate, “вероятность отказа”) с 5% до 4% (имитировав развитие рынка HDD и выход новых боле емких моделей дисков). Теперь у нас уходит два дня на ребилд, так как удвоился объем, и формула выглядит так: 2/365 x 4% x 8 x 2.5= 0.4%. Те же 100 RAID-групп, те же цифры предположений, но риск двойной ошибки вырос до 1 к 200, хотя я “бросаю кости” только 36 раз в год. На протяжении пятилетнего срока службы это означает шанс 180 из 200 получить катастрофический отказ.

Это выглядит противоречащим здравому смыслу, но тем не менее это так. Да, диски становятся надежнее, но при этом, тем не менее, риск аварии возрастает.

Примечания:
*1: http://www.snia.org/education/tutorials/2007/fall/storage/WillisWhittington_Deltas_by_Design.pdf, см. слайд 50
*2: Официально опубликованный вендорский AFR для дисков всегда ниже 1%Однако множество источников называют размер этой величины вплоть до 12%, Можно считать, что величина “консенсуса” в данном вопросе находится обычно между 3% и 5%.
————-
Найдено и переведено там:
http://blogs.netapp.com/msenviro/2009/08/the-raid-10-upsell-fudbeast.html

Далее переходим к созданию aggregate (вернее создание RAID и aggregate это чаще всего один этап).

Aggregatе это, как я уже рассказывал ранее, некий “слой виртуализации”, некий виртуальный “мета-том”, в который помещаются все диски, и при создании на нем “тома”, тот оказывается распределенным по всем входящим в него RAID, и всем физическим “шпинделям”, что объективно повышает общую производительность.

В ряде особых случаев, некоторые рекомендации Best Practices говорят о необходимости создавать отдельные aggregates для сильно различных типов нагрузки, с тем чтобы одна из нагрузок совершенно не влияла на тома с другим типом нагрузки.
Однако в подавляющем количестве случаев, и в случаях, когда диски ваших систем не исчисляются сотнями, рекомендация заводить все физические диски в один aggregate, а уже потом разбивать емкость на отдельные volumes, дает наилучшие результаты.

Часто приходится сталкиваться с мнением, подкрепленным различными, чаще всего устаревшими рекомендациями, в особенности для баз данных, “делить базу, логи разных типов, и системные файлы, не считая собственно OS в отдельные RAID (да еще и разных типов)”. На сегодняшний день такие рекомендации (по крайней мере в отношении NetApp) стоит считать устаревшими. Они действительно могут дать результат. Но фактический проигрыш от следования им на малом числе дисков, значительно превосходит потенциальный выигрыш от разделения типа нагрузки. Ведь единая RAID-группа (aggregate), состоящая из, например, 10 дисков будет заведомо быстрее по IOPS, даже на смешанной нагрузке, чем пять групп по 2 диска в каждом, даже несмотря на то, что в последнем случае удастся разделить нагрузку по отдельным дискам. Это уж даже не говоря о совершенно непродуктивном расходе места на дисках, в результате построения такой схемы.

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

Рассматривая аггрегейты, давайте остановимся на нетапповской специфике. Знакомые с системами хранения от EMC и Hitachi уже знают некоторую особенность дисковой организации на таких системах. На нескольких дисках такого стораджа размещается некая “служебная область”. Там, например, хранится содержимое внутренней OS системы, туда, например, делается “слив” содержимого кэша в случае выключения, и так далее, подробности обычно не объявляются, и область эта закрыта.
Например у EMC Clariion CX4 с каждого из 5 дисков, отведенных системой под эти нужды (так называемый Vault), отнимается по 62GB (в CX3 - 33GB), то есть “минус 310 MB” на систему в целом.
Такая схема, кроме всего прочего, заставляет при создании RAID, выделять эти 5 дисков (4 в случае Hitachi модели AMS) в отдельный RAID, так как в противном случае они уменьшат размер всех остальных дисков в этом RAID на те же 62GB, ведь объем всех дисков в RAID должен быть абсолютно равный.

Нечто подобное есть и у NetApp. Он хранит настройки системы (для знакомых с UNIX-ами скажу: раздел /etc UNIX-подобной файловой системы ядра) на самих дисках системы хранения. Остальная OS Data ONTAP находится и грузится с Compact Flash-карты, так как она совсем небольшая, несколько десятков мегабайт на все.

По умолчанию этот /etc хранится на своем собственном aggregate (aggr0), состоящем из двух (в случае RAID-4) или трех (RAID-DP) дисков: диск данных, один или два диска parity. На этом aggregate создается том vol0, на котором и лежит около 200 мегабайт содержимого этого самого /etc: настройки, конфигурационные файлы, прошивки firmware для дисков, и так далее.
Такая схема позволяет, в частности, легко переносить данные между системами хранения, а также, в случае необходимости, заменять и апгрейдить контроллер, так как вся конфигурация конкретной системы, по сути, от ее контроллера отделена. В случае замены “головы”, новый контроллер загружает “конфигурациенезависимое” ядро, монтирует к нему /etc, прочитывает оттуда конфигурацию текущей системы - и готово.

Все остальное место на этом “особом” разделе, в принципе, может быть использовано под какие-то нужды. Например, по умолчанию там создается папка home, которую можно использовать для хранения пользовательских home-директорий.

Для системы с небольшим количеством дисков и невысокой предполагаемой загрузкой бывает жалко отдавать отдельный aggregate и целых два-три диска только под служебную директорию размером в несколько мегабайт, особенно если используются большие диски, например при дисках SATA 1TB вы теряете на первом aggregate 1 или 2 TB на диски parity, и еще один диск под служебный vol0, пусть на нем и можно хранить данные. Все равно это минус 2-3 диска целиком, из общего количества.

В этом случае можно порекомендовать создать единый aggregate, в который войдут все диски системы, и уже на нем выделить vol0 под системный раздел.
В этом случае общая производительность вашего aggregate увеличится на величину 2..3 * IOPS одного диска, ведь, как я писал выше, общая нагрузка ввода-вывода в aggregate расделяется поровну по всем входящим в него дискам.

Однако если вы строите систему повышенной готовности, или систему с высокой и специфической нагрузкой, и хотите построить ее “без компромиссов”, в особенности если дисков куплено достаточно, то отделяйте системный раздел в отдельный aggregate, чтобы застраховаться от взаимного влияния ввода-вывода системного раздела, и раздела с данными ваших приложений.

Продолжение как всегда следует в следующий понедельник.