[FreeNAS raid zfs raid-z] что выбрать?

Для начала обнули с помощью dd (dd if=/dev/zero of=/dev/adXX bs=200M) всё пространство на новых дисках, посмотри, как ведёт себя потоковая запись на каждом из них. Диск 500ГБ полностью обнуляется примерно за 2 часа (зависит от скорости I/O интерфейса).

Далее с помощью gpart(8) разметь диски в GPT: на каждом из дисков сделай два раздела: первый раздел (4ГБ) под резервное пространство, второй раздел под данные. Не забудь: так как диски имеют advanced format, то нужно выровнять размещение второго раздела по номеру цилиндра, кратному 4K.

Далее создаёшь пул из одного RAID-Z (RAID-5), который должен состоять по крайней мере из трёх «вторых разделов» дисков и желательно одного Hot Spare из раздела на четвёртом винчестере.

По мере заполнения пула добавляешь (zpool add) в него новые устройства верхнего уровня: это могут быть обычные винчестеры (которые легко потом нарастить до mirror путём zpool attach для выбранного винчестера), зеркальные (mirror) массивы и raid-z массивы из новых винчестеров. В каждом случае желательно использовать не сами винчестеры, а размеченные разделы на них — так есть надежда, что все ёмкости будут соответствовать.

Raid-5 в моём случае не получится. Он получится из дисков по 500Gb. А вот с 2TB как быть которых всего две штуки, не понятно...

А что думаете на счёт:

gmirror: 2x500 2x500 2x2tb geom_lvm сверху, и получаем отказоустойчивый 3TB массив?

geom_lvm не очень, но вроде было что-то нативное во FreeBSD.

http://www.freebsd.org/doc/handbook/vinum-vinum.html

Читаю пока...

На зеркалах слишком много пространства тратиться впустую. Неэффективно.

geom_linux_lvm(4) нужен только для чтения линуксовых логических томов.

>geom_lvm сверху, и получаем отказоустойчивый 3TB массив?

Неа. Во фряхе нет нормальной реализации LVM, то read-only и то при благоприятной фазе луны.

В ZFS менеджер томов очень хреновый - он не умеет освобождать и переносить физические тома, как vgreduce и pvmove в LVM. Т.е. если ты добавил gmirror-пару в пул и на нее записались данные, удалить из пула ты ее уже не сможешь.

Попытка создать аналог LVM во фряхе - gvirstor - fail по тем же причинам.

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

И да, между ZFS и UFS2+gvirstor я бы выбрал второе, ибо быстрее на порядки.

>На зеркалах слишком много пространства тратиться впустую. Неэффективно.

А в raidz впустую тратится много процессорного времени (что вообще характерно для реализации RAID5-6, в т.ч. для gvinum и линуксового mdraid). Не говоря уж о том, что ZFS сама по себе очень неторопливая.

>В ZFS менеджер томов очень хреновый - он не умеет освобождать и переносить физические тома

С физическими томами в ZFS как раз-таки всё хорошо: можно удалять и добавлять из/в устройства верхнего уровня на лету, без перезагрузок.

, как vgreduce и pvmove в LVM. Т.е. если ты добавил gmirror-пару в пул и на нее записались данные, удалить из пула ты ее уже не сможешь.

Не вижу связи между gmirror и ZFS. Это разные подходы: gmirror реализуется модулем GEOM; пулы реализуются исключительно ZFS.

Вот тут: http://www.c0t0d0s0.org/archives/6224-You-dont-need-zfs-resize-...-and-a-work...
показывается, как происходит реструктуризация ZFS пула.

Такс, такс, мужики, а почему все заигнорили:

geom_mirror классический + gvinum?

Я ведь получу 3TB отказо устойчивых...

То есть: создаю три рейда, потом эти три рейда соединяю в один девайс через gvinum

Что не так?

Лучше сделать gstripe из нескольких gmirror. Получится схема RAID-10. Очень надёжная.

На FreeBSD 8.1-STABLE RAID-Z (ZFSv15) из трёх винчестеров практически не нагружает систему: на копировании с отдельного диска на пул RAID-Z тратится порядка 10% CPU Phenom II X4 810 (2,6ГГц); при наличии всего 2ГБ ОЗУ в системе память занята на 30% (это вместе Xfce и Firefox).

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

в raidz впустую тратится много процессорного времени

Нет.

ZFS сама по себе очень неторопливая.

Только на многопоточных задачах ввода-вывода.

Raid-5 в моём случае не получится. Он получится из дисков по 500Gb. А вот с 2TB как быть которых всего две штуки, не понятно...

Я думаю, получится. Просто нужно подсчитать пространство.

Четыре винчестера (большие разделы с них) можно объединить gstripe(8) в страйп-массив размером ~2ТБ. Затем из этого страйп-массива и оставшихся винчестеров по 2ТБ можно средствами ZFS создать отказоустойчивый пул RAID-Z размером ~4ТБ.

> В ZFS менеджер томов очень хреновый - он не умеет освобождать и переносить физические тома, как vgreduce и pvmove в LVM.

Матчасть надо учить.. Освобождать действительно нельзя, но сделать 'zpool replace' для диска ничего не мешает

Блин, как-это очень сложно всё выглядит... Ну чёт ну очень сложно...

Что сложно?

Боюсь, что сложно потом будет сопровождать этот гемморой. :(

Делаем RAID-Z из страйпа маленьких винтов и двух отдельных больших винтов.

Размечаем маленькие винты:

% gpart create -s GPT adXX
% gpart add -b 4096 -s 470G -t freebsd-ufs -l stripe_dataN adXX

Создаём из них страйп:

% kldload geom_stripe 
% echo 'geom_stripe_load="YES"' >> /boot/loader.conf
% gstripe label -v -s 131072 big_data1 gpt/stripe_data1 gpt/stripe_data2 gpt/stripe_data3 gpt/stripe_data4

— должно получиться блочное устройство /dev/stripe/big_data1 размером около 2ТБ.

Размечаем большие винты (по 2ТБ):

% gpart create -s GPT adYY
% gpart add -b 4096 -s 2047G -t freebsd-ufs -l big_data2 adYY

Делаем RAID-Z:

% zpool create MyPool raidz stripe/big_data1 gpt/big_data2 gpt/big_data3

СУПЕР!

Теперь надо подумать и поэкспериментировать что будет если будет отказ диска, ибо данные там будут весьма критичные, и что делать если полетит винт с FreeBSD.

По-этому всё же RAID 10 средствами: geom_mirror geom_stripe вроде кажется более изящным решением с одной стороны. А с другой стороны производительность Ваших решений мне кажется более высокой, или я не прав?

На raidz поверх страйпов производительность должна быть не фонтан (raidz такой riadz), а вот надежность впечатляющая - вылет одного из мелких винтов отправляет raidz в degrated, тормоза и нагрузка на оставшиеся (большие) винты возрастает на порядок - возрастает соответственно и вероятность вылета одного из них. Не говоря уже о том, что в некоторых случаях алгоритмы защиты данных в raid5/6 элементарно не смогут восстановить degrated-массив (такое бывает, очень редко, но бывает).

gvinum over gmirror, на мой взгляд, лучшее, что здесь можно сделать. Только будь морально готов к тому, что удалить зеркальную пару ты уже не сможешь, только заменять винты по отдельности (как и в ZFS).

>Матчасть надо учить..

Судя по дальнейшей реплике, вы с ней уже знакомы =)

Освобождать действительно нельзя, но сделать 'zpool replace' для диска ничего не мешает

И что это решает? Тут, как и у линаксовой xfs, получается билет в один конец - все выше и выше и выше.

>Нет.

Если копировать один файл на более-менее топовом десктопе, может, и ничего. Только к ситуации с нагруженным сервером это никак не относится.

Только на многопоточных задачах ввода-вывода.

Да на всех задачах. Просто на нагруженных серверах с многопоточным io это уже катастрофа. Этакий линаксовый 12309 длиной в жизнь =(

Теперь надо подумать и поэкспериментировать что будет если будет отказ диска, ибо данные там будут весьма критичные, и что делать если полетит винт с FreeBSD.

Для FreeBSD можно выкроить пространство на тех же дисках и, опять же, из небольших разделов (по 4ГБ каждый) сделать какой-нибудь RAID-10 (stripe из двух mirror). Просто нужно рассчитать размеры разделов.

отправляет raidz в degrated, тормоза и нагрузка на оставшиеся (большие) винты возрастает на порядок - возрастает соответственно и вероятность вылета одного из них.

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

Не говоря уже о том, что в некоторых случаях алгоритмы защиты данных в raid5/6 элементарно не смогут восстановить degrated-массив (такое бывает, очень редко, но бывает).

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

Сегодня замерил время операции копирования: 60ГБ каталог с файлами весьма различных размеров скопировался с одиночного диска с ZFS на вновь созданный RAID-Z пул из трёх 2,5" дисков (5400 rpm, 8Mb, ~71Mbps RAW) ровно 30 минут.

> Судя по дальнейшей реплике, вы с ней уже знакомы =)

есть немножко

И что это решает?

Как минимум, устраняет неверную часть утверждения.

Тут, как и у линаксовой xfs, получается билет в один конец - все выше и выше и выше.

Мне вот интересно - все так носятся с уменьшением размера пула, но вот если задаться вопросом «когда в последний раз приходилось уменьшать размер файловой системы или группы томов LVM» - каково будет распределение ответов?

>>ZFS сама по себе очень неторопливая.

Только на многопоточных задачах ввода-вывода.

Это на основе чего сделан такой вывод?

>>Это на основе чего сделан такой вывод?

на основе фрибсд? =)

Это на основе чего сделан такой вывод?

На основе многочисленных тестов производительности ZFS на FreeBSD с сайта http://www.phoronix.com.

> >Это на основе чего сделан такой вывод?

На основе многочисленных тестов производительности ZFS на FreeBSD с сайта www.phoronix.com.

А голову включать не пробовал?

А голову включать не пробовал?

Чисто по-десктопным ощущениям, UFS2 рвёт ZFS по скорости как Тузек грелку, но не больше, чем на 10%.

>>А голову включать не пробовал?

Чисто по-десктопным ощущениям, UFS2 рвёт ZFS по скорости как Тузек грелку, но не больше, чем на 10%.

Насколько я понял - не пробовал.. Ну да ладно.

А ощущения - они такое дело, крайне субъективное..

>>как Тузек грелку

но не больше, чем на 10%

толи тузег маловат, толи грелка не по-зубам, но 10% на глаз заметить это сильно ;)

настройки тоже какие то делал или как есть сравнивал?

Зачем на глаз?

Бенчмарки, конечно не устраивал, но то, что требовалось для меня, я определил.

Делал ZFS-пул mirror и делал UFS2 на GMirror на тех же винчестерах-разделах и сравнивал скорость копирования файлов. Скорость копирования на UFS2/GMirror оказалась чуточку выше, чем на ZFS mirror. А по потреблению RAM при буферизации данных UFS2 очень неприхотлива, в отличие от ZFS.

>Зачем на глаз?

Чисто по-десктопным ощущениям

наверное навеяло

Делал ZFS-пул mirror и делал UFS2 на GMirror на тех же винчестерах-разделах и сравнивал скорость копирования файлов.

ну это уже что-то )
но никаких параметров не крутил нигде?

зы не всегда все дело в производительности, тем-более пару процентов разницы. удобство управления и целостность порой ценнее )