Кэш диски на ZFS

Для начала создадим RAID-Z массив из 3х дисков (в моем случае это
SATA): http://phpsuxx.blogspot.com/2010/09/raid-z-freebsd-81.html

Итак, имеем обычный RAID-Z массив:

zpool status
pool: backup
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
backup ONLINE 0 0 0
raidz1 ONLINE 0 0 0
ad4 ONLINE 0 0 0
ad6 ONLINE 0 0 0
ad10 ONLINE 0 0 0
errors: No known data errors

Теперь подключим к массиву очередное дисковое устройство (в моем
случае это 128GB SSD) как L2ARC кэш:

zpool add backup cache ad14

В документации о роли "cache" сказано следующее (но я не думаю, что
кто-то сочтет это за существенные ограничения):

cache A device used to cache storage pool data. A cache
device cannot be mirrored or part of a raidz or raidz2
configuration.For more information, see the "Cache Devices"
section.

В итоге оно у нас добавится и будет упомянуто в статусе:

zpool status
pool: backup
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
backup ONLINE 0 0 0
raidz1 ONLINE 0 0 0
ad4 ONLINE 0 0 0
ad6 ONLINE 0 0 0
ad10 ONLINE 0 0 0
cache
ad14 ONLINE 0 0 0

errors: No known data errors

FreeBSD 8.1 и ZFS: cannot remove ad14: only inactive hot spares or cache devices can be removed

Имеем вот такой конфиг с 1 slog устройством:

zpool status
pool: backup
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
backup ONLINE 0 0 0
raidz1 ONLINE 0 0 0
ad4 ONLINE 0 0 0
ad6 ONLINE 0 0 0
ad10 ONLINE 0 0 0
logs ONLINE 0 0 0
ad14 ONLINE 0 0 0

errors: No known data errors

И при попытке удалить slog устройство ad14 получаем:

zpool remove backup ad14
cannot remove ad14: only inactive hot spares or cache devices can be removed

Судя по рассылке ZFS, форуму OpenSolaris и форуму FreeBSD это баг и единственный вариант избавится от slog`а - это удалить массив.

P.S. log устройства во FreeBSD 8.1 использовать КРАЙНЕ не рекомендуется. Кроме невозможности их удаления есть еще одна неприятность - если log-устройство было создано не как mirror, а как одиночное устройство, то в случае его отказа становится недоступным весь пул с данными и как это исправлять у меня информации нету.

Механизмы кэширования ZFS: ARC и L2ARC

Я думаю, многим известно, что ZFS отличается очень большим числом крайне интересных функций. Кэширование не стало исключением - тут у ZFS есть в арсенале целых два механизма: ARC и L2ARC.

Почему они так странно называются, ARC? Эти кэши получили свое название в честь алгоритма кэширования, на котором они основаны, алгоритма ARC, кроме него также широко распространен LRU, но ARC считается более производительным.

ARC - это кэш ZFS, расположенный в оперативной памяти, L2ARC - его продолжение (Layer 2, второй уровень), но на более медленном, чем оперативная память носителе (но при этом обладающим бОльшим объемом) и в то же время, более быстром, чем диски самого массива. Обычно, в роли носителей для L2ARC используются SSD диски, так как их скорости чтения/записи с легкостью превосходят последние модели SAS.

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

Как же это работает на деле?

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

Использование кэша: при попытке прочесть данные с диска, ZFS сначала ищет их в оперативной памяти (ARC), если там необходимые данные отсутствуют, то выполняется попытка найти их в L2ARC кэше и лишь в случае неудачи на этом шаге будет выполнено реальное чтение с физического устройства.

Многие могут заметить - а не проще ли создать огромный ARC кэш, ведь оперативная память крайне дешева? Нет, не проще, крайне проблематично поставить на сервер, скажем, 256 гигабайт памяти под кэш массива тб на 150 :)

Как было сказано выше, в первую очередь эти кэши используется при чтении и как раз при нем дают максимальный эффект, но как быть при записи? Ведь нельзя долго складировать данные в памяти, иначе это чревато их потерей при потере питания (а вот для ZFS это абсолютно безопасно - она не пострадает, просто данные не будут записаны и все, консистеность же файловой системы будет вне угрозы). На этот случай (для ускорения операций записи) в ZFS также имеется технология кэширования (но не данных, а транзакций), которая именуется ZIL. Но об этом я напишу в отдельном посте.

А вот небольшая заметка про реальное увеличение скорости за счет использования L2ARC: http://www.zfsbuild.com/2010/07/30/testing-the-l2arc/ и вот заметка про увеличение скорости работы MySQL: http://blogs.sun.com/cs/entry/improving_mysql_innodb_zfs_read

Источники: http://blogs.sun.com/brendan/entry/test и http://www.zfsbuild.com/2010/04/15/explanation-of-arc-and-l2arc/

Тестирование поведения RAID-Z массива во FreeBSD при полном отказе одного из дисков

Итак, мы имеем собранный RAID-Z массив из 3 дисков: http://phpsuxx.blogspot.com/2010/09/raid-z-freebsd-81.html

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

Частичный отказ диска

Итак, "отключаем" массив от системы:

zpool export backup

При этом он также будет отмонтирован.

Теперь эмулируем физическое повреждение поверхности диска /dev/ad6 (пишем на него гигабайт "белого шума"):

dd if=/dev/urandom of=/dev/ad6 bs=1m count=1000

Снова подключаем массив:

zpool import backup

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

zpool status
pool: backup
state: ONLINE
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool clear' or replace the device with 'zpool replace'.
see: http://www.sun.com/msg/ZFS-8000-9P
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
backup ONLINE 0 0 0
raidz1 ONLINE 0 0 0
ad4 ONLINE 0 0 0
ad6 ONLINE 0 0 10
ad10 ONLINE 0 0 0

errors: No known data errors

То есть, ZFS определила, что мы чего-то нахимичили с данными (так как они не совпадали со своими ключевыми суммами), это на лету исправила и сообщила нам число ошибок из-за ключевых сумм с ad6. Что же, прекрасно, если винт правда начал умирать, Вы узнаете это первым.

Но при этом ZFS нашел не все ошибки (так понимаю, по причине, что мы считали далеко не все данные с диска), поэтому есть возможность попросить ZFS провести полную проверку данных на этом томе и исправить все найденные ошибки:

zpool scrub backup

После чего увидим следующий status:

zpool status
pool: backup
state: ONLINE
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool clear' or replace the device with 'zpool replace'.
see: http://www.sun.com/msg/ZFS-8000-9P
scrub: scrub completed after 0h0m with 0 errors on Sun Sep 5 23:05:03 2010
config:

NAME STATE READ WRITE CKSUM
backup ONLINE 0 0 0
raidz1 ONLINE 0 0 0
ad4 ONLINE 0 0 0
ad6 ONLINE 0 0 21 1.00M repaired
ad10 ONLINE 0 0 0

errors: No known data errors

Теперь же попросим ZFS забыть про наши опыты и сбросить число ошибок:

zpool clear backup ad6

И теперь наш статус девственно чист:

zpool status
pool: backup
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
backup ONLINE 0 0 0
raidz1 ONLINE 0 0 0
ad4 ONLINE 0 0 0
ad6 ONLINE 0 0 0
ad10 ONLINE 0 0 0

errors: No known data errors

Полный отказ диска

Допустим, диск отказывает на пустом месте. Для этого есть прекрасная команда offline:

zpool offline backup ad4

После такой наглости массив переходит в состояние DEGRADED (разрушен, это нештатный режим его работы):

zpool status
pool: backup
state: DEGRADED
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool clear' or replace the device with 'zpool replace'.
see: http://www.sun.com/msg/ZFS-8000-9P
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
backup DEGRADED 0 0 0
raidz1 DEGRADED 0 0 0
ad4 OFFLINE 0 49 0
ad6 ONLINE 0 0 0
ad10 ONLINE 0 0 0

errors: No known data errors

Подключаем диск обратно:

zpool online backup ad4

Смотрим статус массива:

zpool status
pool: backup
state: ONLINE
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool clear' or replace the device with 'zpool replace'.
see: http://www.sun.com/msg/ZFS-8000-9P
scrub: resilver completed after 0h0m with 0 errors on Sun Sep 5 23:00:15 2010
config:

NAME STATE READ WRITE CKSUM
backup ONLINE 0 0 0
raidz1 ONLINE 0 0 0
ad4 ONLINE 0 49 0 21.5K resilvered
ad6 ONLINE 0 0 1 15K resilvered
ad10 ONLINE 0 0 0 14K resilvered

errors: No known data errors

Как я понял, в полях resilvered указано сколько блоков с каждого из рабочих дисков было считано, а напротив "отказавшего диска" указано число блоков которое было восстановлено на основе данных четности (но я могу ошибаться, не верьте мне!). Данные были восстановлены и теперь массив снова в статусе ONLINE. Примерно тоже самое произойдет, когда потребуется заменить один из дисков в связи с отказом.

Физическая замена одного из дисков

Допустим, на одном из дисков по данным S.M.A.R.T. образовалось большое число сбойных секторов и его стоит заменить (для чистоты эксперимента мне пришлось немного погонять техников ДЦ и физически заменить один из дисков.). Нужно ли готовить массив к этому заранее? Совершенно не нужно (официальная документации Sun). Сервер просто выключается, сбойный диск заменяется (то есть, на место подключения старого диска ставится новый) и сервер включается. Статус массива при этом будет следующий:

zpool import
pool: backup
id: 15744554445999282139
state: DEGRADED
status: One or more devices are missing from the system.
action: The pool can be imported despite missing or damaged devices. The
fault tolerance of the pool may be compromised if imported.
see: http://www.sun.com/msg/ZFS-8000-2Q
config:

backup DEGRADED
raidz1 DEGRADED
ad4 ONLINE
ad6 UNAVAIL cannot open
ad10 ONLINE

И при этом массив не был подключен к системе:

zpool list
no pools available

То есть, ZFS заметила, что диск ad6 куда-то пропал и не хочет запускаться. Что же делать?

Делаем "явное" подключение пула:

zpool import backup

После этого статус примет вид:

zpool status backup
pool: backup
state: DEGRADED
status: One or more devices could not be opened. Sufficient replicas exist for
the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
see: http://www.sun.com/msg/ZFS-8000-2Q
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
backup DEGRADED 0 0 0
raidz1 DEGRADED 0 0 0
ad4 ONLINE 0 0 0
1502173858046405299 UNAVAIL 0 227 0 was /dev/ad6
ad10 ONLINE 0 0 0

errors: No known data errors

После этого сообщаем ZFS, что мы заменили этот диск:

zpool replace backup ad6

И, вуаля, массив снова в штатном режиме:

zpool status backup
pool: backup
state: ONLINE
scrub: resilver completed after 0h0m with 0 errors on Mon Sep 6 16:05:36 2010
config:

NAME STATE READ WRITE CKSUM
backup ONLINE 0 0 0
raidz1 ONLINE 0 0 0
ad4 ONLINE 0 0 0 31K resilvered
ad6 ONLINE 0 0 0 2.18M resilvered
ad10 ONLINE 0 0 0 33K resilvered

errors: No known data errors

Поистине фантастическая технология :)

По материалам: http://www.freebsd.org/cgi/man.cgi?zpool и http://people.freebsd.org/~pjd/misc/zfs/zfs_self-healing.swf

Что такое resilvering?

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

http://blogs.sun.com/bonwick/entry/smokin_mirrors

Создание RAID-Z массива на FreeBSD 8.1

Итак, имеем FreeBSD 8.1:

FreeBSD rescue 8.1-STABLE FreeBSD 8.1-STABLE #0: Mon Jul 26 08:20:08 UTC 2010 root@fbsd64.hetzner.de:/usr/obj/usr/src/sys/GENERIC amd64

А также три SATA-2 диска по 1.5 тб (каждый из которых ранее были разбиты для Linux Soft Raid-5):

find /dev | egrep 'ad'
/dev/ad4
/dev/ad4s1
/dev/ad4s2
/dev/ad4s3
/dev/ad6
/dev/ad6s1
/dev/ad6s2
/dev/ad6s3
/dev/ad10
/dev/ad10s1
/dev/ad10s2
/dev/ad10s3

Просмотрим список имеющихся ZFS пулов:

zpool list
no pools available

Создаем ZFS RAID-Z1 пул с именем backup на базе трех винтов:

zpool create backup raidz ad{4,6,10}

Итого, убеждаемся, что он создался:

zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
backup 4.06T 220K 4.06T 0% ONLINE -

В данный момент меня смутило, что при трех дисках по 1.5 тб эффективный объем вышел 4 тб, а не 2.7 (как было бы в случае RAID-5).

Теперь смотрим статус массива:

zpool status
pool: backup
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
backup ONLINE 0 0 0
raidz1 ONLINE 0 0 0
ad4 ONLINE 0 0 0
ad6 ONLINE 0 0 0
ad10 ONLINE 0 0 0

errors: No known data errors

Теперь смотрим в mount и замечаем чудесным образом там появившийся новый раздел:

mount | grep /backup
backup on /backup (zfs, local)

Который как раз на 2.7 тб:

df -h | grep backup
backup 2.7T 24K 2.7T 0% /backup

Вуаля, все, можно на нем размещать свои данные и совершенно не боятся, если один из дисков сбойнет :)

Уничтожить zpool можно также очень просто:

zpool destroy backup

По материалам: http://people.freebsd.org/~pjd/misc/zfs/zfs_self-healing.swf

Что такое RAID-Z?

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

Для начала стоит отметить, что это не какая-то абсолютно новая технология, а, скорее, работа над проблемами, которые имели место в RAID-5. Какие именно недостатки она исправляет? Во-первых, устраняется проблема под название "Write hole", во-вторых, в RAID-5, если была изменена лишь часть страйпа (страйп - это группа блоков, каждый из которых расположен на отдельном жестком диске), то необходимо перечитывать весь страйп для того, чтобы пересчитать его данные четности (а это наносит серьезный урон производительности). То есть, если идет запись всего страйпа целиком, то мы просто асинхронно ее выполняем на всех дисках. Если же переписывается только часть страйпа, то необходимо сначала выполнить синхронное чтение перед тем, как что-либо писать. У железных RAID-5 контроллеров это решается посредством сохранения записываемых данных в кэше на то время пока будет выполнено синхронное чтение.

Как же указанные проблемы решаются в RAID-Z? Во-первых, в ZFS RAID-Z используется динамический размер старйпа (что автоматически устраняет случай "частичной перезаписи страйпа"). Таким образом, устранение частичных записей страйпа вместе с принципом записи copy-on-write (новые данные не записываются поверх старых, а пишутся в новое место, а потом атомарно происходит переустановка указателя на новое расположение данных) полностью решают проблему "Write hole". Также, RAID-Z имеет преимущество в скорости, так как ему не нужно выполнять чтение перед записью (так как отсутствуют частичные записи страйпов).

Уход от фиксированного размера страйпа, очевидно, усложняет устройство RAID-массива, так как теперь невозможно пройти весь массив и, допустим, разбив его на блоки 64 килобайта высчитать их ключевые суммы. В связи с динамическим размером страйпа необходимо где-то хранить метаданные о размере страйпов. Что таит в себе еще одну проблему - теперь файловая система (где хранятся эти метаданные) и RAID массив представляю собой единое целое, что делает невозможным раздельную реализицию файловой системы и RAID контроллера. То есть, требуется взгляд как со стороны механики, так и со стороны логики устройства ФС.

Усложнение структуры файловой системы не может не сказаться на скорости работы. Но будет ли это приводить к замедлению? Совершенно нет, так как при синхронизации будут копироваться только блоки с данными, а пустые блоки не будут. Также стоит обратить внимание, что в ZFS блоки хешируются 256 битными ключевыми суммами, в то время как в обычном RAID используется простейший xor.

ZFS RAID-Z также обеспечивает беспрецедентный уровень защиты данных от повреждения по механическим причинам, так как защищает не только от отказа отдельного жесткого диска, но и позволяет обнаруживать отказы отдельных блоков на диске. Когда Вы считываете с RAID-Z блок он сравнивается с его ключевой суммой. Если данные не соответствуют ключевой сумме, то ZFS считывает данные о четности и пытается реконструировать данные, а также при этом выясняет, какой из дисков послужил источником проблемы и, разумеется, уведомляет об этом администратора. Таким образом, приложение запросившее данные получает корректные данные без каких-либо ошибок.

Очень важнй чертой технологии ZFS RAID-Z является то, что она не предъявляет никаких требований к аппаратной части сервера (не считая повышенных требований к оперативной памяти).

Кроме RAID-Z также существует его модификация RAID-Z2 (близка к RAID-6), которая устойчива к отказу двух жестких дисков. Кроме этого, уже существует (но пока только-только портирована во FreeBSD) версия RAID-Z3, которая выдерживает отказ до трех дисков массива.

По материалам: http://blogs.sun.com/bonwick/entry/raid_z и http://en.wikipedia.org/wiki/Non-standard_RAID_levels#RAID-Z

ZFS Deduplication во FreeBSD 8.1

Пока отсутствует, так как эта фича была реализована лишь в 21 версии ZFS (ссылка), а во FreeBSD 8.1 используется ZFS версии 14 (ссылка).

Update: фича портирована в HEAD версию FreeBSD: http://www.opennet.ru/opennews/art.shtml?num=27828

FreeBSD 8 c корнем на ZFS? Легко!

http://wiki.freebsd.org/ZFSOnRoot

Причем, во Фре 8 можно вообще _ВСЮ_ систему разместить на ZFS (вт.ч. даже и /boot), вот инфа по этому: http://lulf.geeknest.org/blog/freebsd/Setting_up_a_zfs-only_system/

Надо попробовать поставить :)