Проблемы и решения Usable Space. Часть 3.
??так, в предыдущих двух постах этой темы (часть 1, часть 2) я постарался показать, что такое usable space по сравнению с raw space, почему первое всегда меньше чем второе, и почему мы, заплатив за полновесные терабайты получаем на выходе якобы совсем не те терабайты, за которые мы заплатили.
Процесс перехода от raw к usable есть процесс получения из тупых байтов некоего функционала, “обмен байтов на дополнительные возможности и защиту данных”. Обычно чем больше мы теряем в байтах, тем больше получаем в функционале (конечно, если это правильная система хранения ;)
Один из блоггеров NetApp, которого я постоянно читаю, Костадис Руссос, использует в своих постах, в особенности в своих спорах с EMC, термины “Real Fibre Channel” (который так любят Наши Уважаемые Конкуренты) и “Better Than Real FibreChannel” :)
Давайте посмотрим, где же NetApp является “Better Than Real FibreChannel”.
Пост планируется длинный, я разбил его на несколько частей, которые будут идти в несколько приемов, так что готовьте кофе ;)
??так, как уменьшается пространство по пути от “raw data” к “usable data + функционал”?
Первый аспект относится скорее не к нашему случаю, но перечислим и его. Это так называемые “маркетинговые байты”. Большинство из читателей знает, что сто лет как существует проблема перевода из “двоичных” в “десятичные” байты. То есть “килобайт” это не 1000 байт, а 1024 байта.
Бородатый анекдот: “Шофер думает, что в килобайте 1000 байт, а программист - что в километре - 1024 метра”
Так вот, емкость в “двоичных байтах” получается больше, что очень нравится маркетерам компаний по производству жестких дисков: “А в попугаях я гораздо длиннее!” (с) Удав
Строго говоря уже в обед как сто лет принято решение ISO (International Standartization Organisation) для “двоичных байт” использовать специальные приставки, чтобы отличать двоичные и десятичные множители, звучат они непривычно, и немного смешно: не кило- а киби- (би - “бинарные”, двоичные единицы), “мега” - “меби”, и так далее.
Но пока есть что есть, и из диска на один “терабайт” (как называет его производитель), который на деле “тебибайт”, “исчезает” за счет этого почти сто мегабайт.
Аспект номер два - сектор 520 байт на 8 байт больше обычно используемого. Зачем это так сделано я писал тут и тут. Это уменьшает емкость диска примерно на 1/64 долю, повышая надежность хранения и позволяя использовать дедупликацию.
Далее переходим к RAID-ам. Как вы знаете уже, на системах NetApp используется RAID тип 4 (чередование с четностью, с выделенным диском четности), который имеет емкость X*N-X, где X - это емкость одного диска, а N это число дисков в RAID-группе, то есть на обеспечение отказоустойчивости занимается один диск.
Второй применяемый тип RAID, это вариант RAID-6 под названием RAID-DP, в нем на обеспечение отказоустойчивости занимается два диска (X*N-2X). Такой тип RAID рекомендуется использовать по умолчанию.
Максимальный размер RAID для дисков FC и SAS - 28 дисков. Для SATA - 16. Меньший размер RAID в случае SATA диктуется меньшей надежностью дисков, более высокой вероятностью выхода из строя и ошибок, что потребовало ограничить размер RAID. Кроме того, скорость rebuild на длинном RAID для относительно медленных дисков SATA может быть неприемлимо низкой.
При необходимости использовать большее количество дисков необходио создавать две и более группы, на каждую из которых будет потрачено по 2 диска четности (в случае RAID-DP).
Обратите внимание, что максимальный размер RAID для группы типа RAID-4 в два раза меньше, то есть 16 для SAS и FC, и 8 для SATA! Большая разрешенная длина группы RAID-DP также связана с его более высокой надежностью и отказоустойчивостью.
Следующий этап - диски hot spare. Система NetApp назначает все неиспользуемые в действующих RAID-группах диски в Hot Spare. Затем из пула hotspare-дисков вы можете их забрать, создавая RAID-ы, aggregates тома. Более того, эксплуатация системы без Hot Spare дисков вообще - настоятельно не рекомендуется. Это, в принципе, наверное возможно (например какая-нибудь тестовая инсталляция с абсолютно неценными данными, но ограниченная по дисковым ресурсам), но это должно быть осознанное решение, риск которого полностью возлагается на администратора системы. Для отключения весьма надоедливого уведомления о работе без hot spare необходимо установить одну из системных опций в настройках (курите маны, если что - я ни при чем.).
Но это, повторюсь, не рекомендуется, и является нештатным и рискованным режимом.
В нормальном состоянии необходим один hot spare на каждый контроллер кластера, причем для каждого используемого типа дисков.
Например, если у вас “двухголовая”, двухконтроллерная кластерная система, в которой используется два типа дисков, например 300GB и 450GB FC, или 300GB SAS и 750GB SATA, то вам нужно будет иметь spare каждого из типов, то есть отдельно 300 и отдельно 450, или отдельно 300 SAS, и 750 SATA.
С некоторых пор Data ONTAP предлагает иметь два hot spare на контроллер минимум.
Это связано с некими внутренними “маневрами” системы, и в принципе, как и в случае с работой без hot spare вообще, это может быть отключено в системных опциях ONTAP.
Лично вот мне, как частному лицу, кажется, что держать _четыре_ hot spare на систему (по 2 на контроллер) это уже откровенный перебор, даже для достаточно крупной системы, что уж говорить о наиболее популярных у нас “голова плюс одна или две полки”.
* ??зменить установку по умолчанию в 2 spare можно установив опцию raid.min_spare_count в 1, однако добавлять диски в aggreate придется в командной строке, так как для FilerView установку в 2 spare для ONTAP выше 7.3 изменить не удается (она просто не даст вам в GUI использовать дисков больше чем “все диски головы минус два”).
> aggr add [aggrname] -d [diskname]
Тем не менее, всякий раз, когда вы меняете настройки принятые по умолчанию - подумайте дважды. ??ли как было написано в “шапке” конфигурационного файла одной из линуксных программ: “Уберите свои руки от наших установок по умолчанию!”
Продолжение следует.
Привет!
Подскажите плз. ресурс, где можно доходчиво и без глубоких подробностей прочитать о назначении hotspare дисков в СХД?
Не ошибка, что кол-во hotspare зависит от кол-ва контроллеров? Я думал, что hotspare рекомендуется делать в каждом RAID.
Алексей:
Официальный источник - NetApp Resiliency Guide. Я делал его перевод в библиотеку Netwell.
http://netwell.ru/docs/netapp/tr-3437_rus_storage_subsystems_resiliency_guide.pdf
Если же “к черту подробности”, то правила простые:
1. Hotspare назначается на контроллер (два контроллера - значит минимум 2 hotspare в системе суммарно, по одному на контроллер). Эксплуатация систем без hotspares не поддерживается производителем.
2. Количество рекомендованных hotspares выбирается исходя из требований к системе хранения, конкретнее к надежности хранения хранимых на ней данных. Но общее эмпирическое правило: “2 spares на первых 84 диска, на каждый контроллер, и по 1 диску на каждые последующие 84 диска”. Это, конечно, не распространяется на системы типа 2xx0, где общее число дисков обычно значительно менее 84.
В общем, если лень читать весь TR3437, то читайте только главу 5.4
3. Все диски, которые пока не назначены в aggregate или traditional volume, являются для системы hot spares.
> Я думал, что hotspare рекомендуется делать в каждом RAID.
Строго говоря, в WAFL, на дисках NetApp, RAID-а, как такового, нет. Это в значительной мере абстракция, имеющая цель быть понятной “традиционным” стораджистам.
Для WAFL “RAID” - это порядок и последовательность записи блоков данных на имеющиеся в наличии диски.
Я бы добавил, что количество хотсперов может ещё диктоваться “особеннстью” работы CF и использования mailbox дисков.
Кроме того нужны отдельные Hot Spare на каждый тип дисков.
К примеру: у нас 24 SAS и 24 SATA, каждому контроллеру отдаём половину от того и другого типа дисков. Получаем по 12 дисков SAS и 12 SATA на контроллер. Так как каждый контроллер владеет своим набором дисков (общих быть не может, даже Hot Spare): ??з каждой дюжины заберём по два на парити и по два на Hot Spare. ??того потеряли 4-ре SAS и 4-ре SATA диска на HA системе.
bbk:
Ну почему сразу “потеряли”? Я не считаю, что диски, потраченные на обеспечение высокой доступности данных надо называть “потерянные”.
Впрочем, это зависит от хранимых данных ;-D
Спасибо за документ. Теперь более понятно! Указанная статья - как best ptactice для архитекторов, весьма полезна. Мне нужно было нечто вроде этого: http://ru.wikipedia.org/wiki/Hot_Spare :-D
>Строго говоря, в WAFL, на дисках NetApp, RAID-а, как такового, нет. Это в значительной мере абстракция, имеющая цель быть понятной “традиционным” стораджистам.
Не понял. Производитель придумал абстрактное понятие только для того, чтобы пользователям, подсевшим на “устаревающие” решения, было понятно? ??нтересно, а не правильнее ли было заявить - “RAID больше не нужен, а вот почему! …”.
?? все-таки, от традиционного понятия “RAID” здесь много: дисковый массив есть? есть. избыточность ради отказоустойчивости есть? есть. диски parity есть? есть. hot spare - есть? есть. увеличение производительности за счет “размазывания” данных по дискам есть? есть.
вот что говорит вики:
“Дальнейшее развитие идеи RAID:
??дея RAID-массивов — в объединении дисков, каждый из которых рассматривается как набор секторов, и в результате драйвер файловой системы «видит» как бы единый диск и работает с ним, не обращая внимания на его внутреннюю структуру. Однако, можно добиться существенного повышения производительности и надёжности дисковой системы, если драйвер файловой системы будет «знать» о том, что работает не с одним диском, а с набором дисков.
Более того: при разрушении любого из дисков в составе RAID-0 вся информация в массиве окажется потерянной. Но если драйвер файловой системы разместил каждый файл на одном диске, и при этом правильно организована структура директорий, то при разрушении любого из дисков будут потеряны только файлы, находившиеся на этом диске; а файлы, целиком находящиеся на сохранившихся дисках, останутся доступными.”
Я правильно понимаю, что RAID уровнем управляет WAFL? ?? он как раз таки знает о существовании дисков, распределяя блоки (не файлы) по массиву зная на каком диске какой блок?
Алексей:
Ну тут вот какая ситуация. Обычная файловая система, чем бы она ни была, находится на некоем уровне по отношению к дискам. Вот в отношении сетевой структуры это понятнее, потому что там есть формализованная модель ISO OSI, и оперируя ее делением можно показать, что “эта файловая система, она отсюа и досюда”. К сожалени для дисковых структур такого пока нет.
Если вы найдете здесь перевод статьи Костадиса Руссоса, про то, как устроен WAFL, там может быть написано понятнее.
WAFL (как и ZFS) расположена “смещенной вниз” относительно обычной иерархии, привычного ее деления. То есть, если в случае обычной файловой системы, FS “живет” поверх дисков, над которыми находтся какой-то RAID, над которым какой-то volume manager, и вот там, над Volume manager уже файловая система, то в случае WAFL (и ZFS) она же сама по себе является и RAID, и Volume Manager, однако, при этом, она не реализует ряд задач “верхнего уровня”, которые обычно умеет делать “файловая система”, но не делает WAFL, предоставляя только инструментарий, примитивы для написания подобных функций.
Это, в числе прочего, позволило на базе WAFL реализовать и блочную семантику, для использования в SAN, просто потому что и файловая и блочная семантика не была встроена как таковая, а была надстроена по необходимости в Data ONTAP.
То есть WAFL это “файловая система”, смещенная на два уровня иерархии вниз, если Level 1 считать физические диски, Level 2 - RAID, Level 3 - Volume Manager, и так далее. WAFL начинается от уровня 2, и продолжается до уровня, допустим, 5, в то время, как “обычная FS, начинается от уровня 4, и продолжается до уровня 7.
Таким образом в WAFL нет уроаня RAID как такового, отдельного от файловой системы, просто WAFL, живущая поверх физическх дисков непосредственно, формирует RAID-подобную избыточную структуру блоков, просто записывая данные в определенном порядке. У WAFL нет некоего отдельного уровня RAID, который можно по желанию включить или выключить, есть просто вот такая вот структура записи данных, которая реализует принципы RAID путем встроенных возможностей WAFL.
Также работает ZFS, и ее RAID-Z/Z2, возможно, вследствие ее открыторсти, будет проще найти детали реализации, которые, с определенным приближением, можно перенести на WAFL и разобраться “как это работает”.
Понятно. С проекцией на OSI и отдельные уровни - яснее.