?

Log in

No account? Create an account
   Journal    Friends    Archive    Profile    Memories
 

FreeNAS + ZFS: Raid-Z or RaidZ2 - morfizm


Mar. 6th, 2015 03:37 am FreeNAS + ZFS: Raid-Z or RaidZ2

Убедился на опыте, что 4.5T массив в Raid-Z (1.5T полезных данных на каждом диске) имеет вполне реальный риск с отваливанием ещё одного диска в процессе resilvering первого (люди на форумах таки правы, хоть я и не верил). Плюс ZFS в том, что случайный unrecoverable read error на одном из оставшихся дисков в процессе resilver не убивает его наповал: диск вылетел из массива и перестал распознаваться, но после detach volume, перезагрузки и re-import volume, диск подхватился, и заново проведённый resilvering нашёл ошибку в одном файле, благо, это было в одном из архивных snapshot'ов.

Отягощающим обстоятельством является факт глючности моего конфига, в результате чего resilvering одного диска я уже делал раза 4 - при перезагрузке почему-то слетает encryption, а если сделать detach и re-import, то один из дисков не "подхватывается". Volume становится degraded, а диск можно за-wipe'ить и добавить заново, он восстановится через resilvering. Возможно, если бы не делал так часто, то и не попал бы на случай с двойной ошибкой. При этом полный scrub делается раз в две недели, +ежедневный snapshotting на внешний диск, который подключен через USB и раз в месяц происходит rotation с off-site диском.

Отдельно отмечу, что форумы ещё раз правы в отношении рекомендаций против USB. Сервер не перезагружается месяц, всё время включен, никто не трогает провода, тем не менее, раз в пару недель USB на мгновение отключается, и уже раза три это было в момент копирования snapshot'а, что приводило к потерям в нескольких файлах в архиве после скраба архива.

Собираюсь:
- починить отягчающее обстоятельство методом пересоздания pool'а с нуля,
- починить issue с USB тем, что вместо USB буду использовать eSATA.

Что делать с архитектурой массива - неясно. Raid-Z явно не годится. Он максимизирует sequential read/write performance, но по IOPS у него performance не лучше, чем у 1 диска. У меня 2+2+3+3 диски, два диска на 5 в rotation'е для off-site бэкапа. Соответственно, в отношении места больше 5 мне смысла нет (с Raid-Z было 6, т.к. 3 диски пришлось считать как за 2). Есть несколько вариантов, которые я рассматриваю:

1. Raid-Z2. Места будет 4 вместо 6, это туговато, но можно за $100-120 купить ещё один диск на 2-3 и получить свои 6 на 5 дисках. Raid-Z2 даёт полную защиту от сбоев на двух дисках.

2. Сделать 2 vdevs с mirror и поместить их в stripe. Benefits: всё ещё max sequential read/write performance + double read IOPS. В случае ошибок на 2 дисках есть шанс 1/3 потери всего массива. С другой стороны, в случае ошибки на одном диске, resilvering будет происходить зачитыванием с другого диска (парного), а не со всех трёх других, это втрое уменьшает вероятность unrecoverable read error. С местом будет совсем туговато (4) и не понятно, как его занедорого увеличить. Ещё два диска вставлять мне просто некуда.

3. Сделать 2 vdevs с mirror и поместить их в jbod. Benefits: double read IOPS, но sequential read speed может быть в 1.5-2 раза ниже гигабита. Диски будут узким местом. По сравнению с предыдущим вариантом - чуть лучше по безпасности: если умирают 2 диска и с вероятностью 1/3 это происходит на одной паре, то теряешь только эту пару, а не весь массив. Кроме того, массив фундаментально проще, в случае багов можно будет легко восстановить файлы с отдельных дисков без требования целостности оригинального массива. С местом будет нормально (5).

Что вам кажется правильнее?

25 comments - Leave a commentPrevious Entry Share Next Entry

Comments:

From:archaicos
Date:March 6th, 2015 12:08 pm (UTC)
(Link)
Я что-то не понял, USB отключается, и не происходит необходимых проверок на ошибки и восстановления? Кто ж так строит?

Ну и это... Если даже хорошее консумерское железо такое говно и софт такое говно, то вот и ответ на вопрос, почему нихера никакие бэкапы не работают толком, и не так уж сильно народ парится по этому поводу. Комбинация говна со средним уровнем кривизны рук и прямоты извилин просто не может работать. Или я ошибаюсь?
From:morfizm
Date:March 6th, 2015 07:31 pm (UTC)
(Link)
USB: раз в два дня происходит вот такое:

mustang.local kernel log messages:
> ugen3.3: at usbus3 (disconnected)
> ugen3.3: at usbus3

-- End of security output --


А несколько раз вот такое:

mustang.local kernel log messages:
> (da3:umass-sim0:0:0:0): WRITE(16). CDB: 8a 00 00 00 00 01 34 42 cc 78 00 00 00 08 00 00
> (da3:umass-sim0:0:0:0): CAM status: CCB request completed with an error
> (da3:umass-sim0:0:0:0): Retrying command
> ugen3.3: at usbus3 (disconnected)
> ugen3.3: at usbus3

-- End of security output --


Софт enterprise grade. Железо server grade почти всё, кроме некоторых дисков (которые я постепенно заменяю на server grade), PCIe USB 3.0 карточки и external USB 3.0 enclosure.

Софт явно говорит "не используй USB" :)
From:archaicos
Date:March 7th, 2015 06:40 am (UTC)
(Link)
Тем более, если софт с железом хором поют «не используй меня, а то козлёночком станешь» :)
From:kot_begemot
Date:March 6th, 2015 01:59 pm (UTC)
(Link)
Крамольную вещь скажу. Выкинуть нах железо, хранить всё в облаке.
From:morfizm
Date:March 6th, 2015 07:31 pm (UTC)
(Link)
Тормозня же будет адская.
From:kot_begemot
Date:March 6th, 2015 10:05 pm (UTC)
(Link)
Это был сарказм. Горький.
From:kot_begemot
Date:March 6th, 2015 10:10 pm (UTC)
(Link)
По существу вопроса - всё равно никуда не деться от ручной классификации данных, с выносом холодных куда-нибудь (да хоть в те же облака). Так что место особо и не нужно, во всяком случае не в таком количестве.
Я бы реально думал в сторону какого-то ILM/HSM/multi-tier решения.
Хотя, сделать такое решение в домашних условиях на коленке - это не FreeNAS сконфигурировать, а где-то на порядок сложнее.
From:morfizm
Date:March 7th, 2015 07:59 am (UTC)
(Link)
В домашних условиях не очень понятно, что делать. С enterprise'ом легче, т.к. большие объёмы это обычно большие объёмы однородных данных. Если что-то "редко важное" стало доступно через другой путь, ну, делаем пару строк code change, корректируем путь, зовём другой API и всё работает. Кто-то хочет реорганизовать всё, чтобы было логичнее - идёт нафиг. Система только растёт, но она не реорганизуется, и всем хорошо. Иногда отдельные комоненты системы заменяют новыми, и тогда есть шанс для частичной реорганизации. Но все эти реорганизационные costs берут на себя большие команды людей.

Дома однородности куда меньше, а ресурс по управлению данными всего один - это ты. И время от времени нужно таки реорганизовывать всё, иначе оно плохо scale'ится (неудобства накапливаются одно на другое и повышают цену доступа).

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

Ещё несколько довольно важных проблем - это группировка данных их важности, по их чувствительности к privacy, и фундаментальный недостаток файловой системы - одна иерархия. Хочется что-то вроде attribute-based store с произвольными выборками и множественными иерархиями, но нет экосистемы, которая бы это давала, не теряя удобств, performance и др. фич.
From:morfizm
Date:November 29th, 2015 01:48 am (UTC)
(Link)
Выложил очередной пост по этой теме: http://morfizm.livejournal.com/983900.html
From:ermouth
Date:March 6th, 2015 09:15 pm (UTC)
(Link)
Дима, NAS, который при таком оверхэде и вкачивании бабла может выдавать такие результаты – это как бы, прости, нелепость какая-то.

Я всё понимаю, ZFS, надёжная защита от сбоя дисков, то-сё... Но если оно не защищено от других уязвимостей, приводящих к повреждению сохранённой инфы – да ну его нафиг, это энтерпрайз решение. Это не NAS.

А оно ещё и обслуживания требует какого-то нехилого судя по твоим словам.

Я бы решил, что эксперимент затянулся, и продал бы это кому-нибудь )

Edited at 2015-03-06 09:16 pm (UTC)
From:morfizm
Date:March 6th, 2015 09:27 pm (UTC)
(Link)
Такие мысли приходят, но у меня ещё есть немного терпения. С моими requirements огребание гемора будет в любом случае.

Что касается как USB, так и Raid-Z vs Raid-Z2, то ответ, понятно, в моей жадности. Я хорошо понимал, что USB диски с FreeNAS'ом никто не использует, а Raid-Z почти никто*. Но я самоуверенно решил, что типа, я такой аккуратный, не буду трогать провода и USB прокатит. Насчёт Raid-Z: для Raid-Z2 такого же объёма нужен на 1 диск больше, т.е. +сто баксов. Пожадничал.

*) Если некоторая конфигурация почти не используется, то, скорее всего, она не будет работать, или будет глючная с очень геморным саппортом. Этот общий принцип я хорошо знаю, мне осталось только научиться его применять везде и всюду :)
From:ermouth
Date:March 6th, 2015 09:39 pm (UTC)
(Link)
Нормальный инженерный авось.

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

У меня когда-то дома было два винсервера и оба контроллеры домена. И снюхивались они по вайфаю – хотя это мягко говоря не рекомендуется.

И я так же решил, что я умный и всё устрою.

Когда я как-то раз протрахался как-то очень долго, пытаясь зайти в ноут, я снёс это всё к чёртовой бабушке.
From:morfizm
Date:March 6th, 2015 09:57 pm (UTC)
(Link)
По количеству геморасаппорта энтерпрайз стопудово хуже, чем "для дома". Проблема в том, что "для дома" не дают нормальных железок и дают сильно меньше фич. Самый минимум это ECC-память (а я точно знаю, что она нужна, я видел своими глазами bit rot в домашних файлах). Х-- вам. Это сразу enterprise level.


Насчёт доменя - я помню очень похожий experience, мне хватило одного домен контроллера без синхронизации :) чтобы понять что всё это к чёртовой матери, куда легче жить, если создавать юзеров с такими же паролями на всех тачках и без домен контроллера вовсе.
From:ermouth
Date:March 6th, 2015 10:05 pm (UTC)
(Link)
Это энтерпрайз левел железяк, но не решения.

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

Ну и тд.

Энтерпрайз-левел решение вполне можно сделать из говна и палок, главное их правильно расставить. Элон Маск тебе в пример – там спейс-левел решения из говна и палок.

Положа руку на сердце, ты же видишь как в самом деле изнутри устроен софт.

Edited at 2015-03-06 10:07 pm (UTC)
From:kot_begemot
Date:March 6th, 2015 10:14 pm (UTC)
(Link)
По секрету. Где-то вот уже лет десять 90% усилий в энтерпрайзе как раз и уходит на то, чтобы это самое говно с палками как-то работало. Остальные 10% прилагаются к замене говна и палок на нормальное железо у особо-важных кастомеров.
From:morfizm
Date:March 7th, 2015 12:26 am (UTC)
(Link)
ECC на материнку хоум-премиум я, скорее всего, не поставлю. Для неё нужен mother board support & CPU support.

"Это энтерпрайз левел железяк, но не решения."

Ты же понимаешь, что так или иначе это экосистема, ты (в общем случае) не можешь взять одного уровня железку и другого уровня решение. Скажем, на серверную железку у workstation-версии винды может не найтись железяк. Или софт который тебе нужен, на неё не встанет, т.к. ему нужен server-specific OS support, какие-нибудь DLL-ки отсутствующие. Вообще ставить Windows на NAS это отвратительно как минимум из-за необходимости перегружаться чтобы ставить апдейты. Любые голые *nix-ы уже автоматом мегагемор по конфигурации. Solutions типа Synology NAS - там ECC-enabled железка стоит вдвое дороже, чем я суммарно потратил на свой setup, и при этом я не защищён от багов, в случае которых мне нужно давать удалённый доступ к своему массиву каким-то странным людям, которым я не доверяю. FreeNAS не такое уж большое зло на этом фоне. Правильное решение, конечно, в принципе, иметь настолько меньше shit'а, чтобы можно было хранить на workstation'ах и использовать только бэкап. Consumer-grade backup soft+железки вполне справляются с парой терабайт.

Я всё жду, когда подешевеют SSD настолько, чтобы можно было поставить обычный mirror на два 5TB диска с SSD, и это бы решило множество проблем в форм-факторе обычного disk enclosure, а не сервера. Кроме, пожалуй, ECC :) Но, может, для file level integrity можно найти или написать софтинку, которая будет регулярно checksum'ить и говорить, если вдруг какое файло оказалось побито и его следует восстановить из бэкапа.

По поводу идеи, что выбор железяки тянет за собой всю экосистему, могу привести мою любимую аналогию с бабами. Вот, допустим, тебе требуется такой функционал:
- классный секс, причём, допустим, чтобы тебя заводило, она должна выглядеть максимально гламурненько, + у неё должно всегда найтись время, когда тебе нужно,
- ум + знания + способности, чтобы можно было вовлекать её в свои дела как партнёра,
- эрудиция и харизма, чтобы было приятно поболтать,
- чтобы борщи варила и убиралась в квартире,
- профессия и работа, чтобы она не была от тебя так зависима, и вы могли разойтись, когда тебе надоест без алиментов и проблем.

Девушки описанной конфигурации, несомненно, существуют, но за каждую фичу (а особенно за их комбинацию) ты будешь по полной программе платить maintenance. Если она гламурная, ей нужен целый арсенал для макияжа, куча времени, и возможность ходить на всякие процедуры. Кроме того, её нужно выгуливать out в разные места, где она будет всё это показывать. Чтобы она была эрудированная и харизматичная, у неё должно быть много друзей + она должна проводить много времени с ними, ходить out, опять же. Работа, ум, профессия, хобби варить борщи, партнёрство? За всё это ты заплатишь равноправным участием в её жизни, и так, что кроме неё вообще ни на что не будет сил и времени.

Короче, бесплатный сыр бывает только в мышеловке :)
From:ermouth
Date:March 7th, 2015 12:31 am (UTC)
(Link)
У тебя "транзакционная" модель – всё сразу в одном месте – или ничего.

Я за распределённые системы – девчонок надо просто несколько, ога
From:metaller
Date:March 7th, 2015 02:50 am (UTC)
(Link)
Отличная мысль !
From:archaicos
Date:March 7th, 2015 07:02 am (UTC)
(Link)
У девочек будет девочковая варсия CAP теоремы:
- будут забывать про цветы и подарки и передумывать по 30 раз на дню
- будут динамить и требовать доказательств любви снова и снова
- будут уходить за покупками все вместе и надолго
:)
From:morfizm
Date:March 7th, 2015 09:08 am (UTC)
(Link)
Я пытаюсь соптимизировать суммарные накладные расходы. Отдельные девочки это отдельный overhead на каждую, который складывается. Ну или это нужно каждую обламывать в тех других вещах, которые она хочет (наращивать жёсткость?). Или искать таких, у которых всё есть, кроме вот ровно того, что ты хочешь от неё взять, а она может дать (прокачивать удачливость?).
From:ermouth
Date:March 7th, 2015 09:50 am (UTC)
(Link)
Ты в самом деле увеличиваешь накладные расходы. Ты можешь иметь гоночную тачку и трак – или гоночный трак.

Попробуй угадать, в каком случае у тебя будут накладные расходы выше ) А overall-применимость, юзабилити – ниже.
From:archaicos
Date:March 10th, 2015 01:27 am (UTC)

Кстате о битроте

(Link)
From:morfizm
Date:March 10th, 2015 01:57 am (UTC)

Re: Кстате о битроте

(Link)
да-да, я видел :) sweet
From:metaller
Date:March 7th, 2015 02:48 am (UTC)
(Link)
Предлагаю RAID 1. Или RAID10 (если дисков больше 2-х).
From:morfizm
Date:March 7th, 2015 09:06 am (UTC)
(Link)
RAID 1 это мой 3-й вариант, а RAID10 это второй.

Склоняюсь всё-таки к Raid-Z2 (это stripe с двумя дисками для избыточности).
У меня 4 диска, я могу легко добавить 5-й, но 6-й уже не влезет.