Глава 0. Введение

Заголовок этой книги включает слово "Advanced" (для профессионалов). Мы ожидаем, что вы знаете пару вещей, прежде чем можете начать пользоваться ею. Простейшим ответом будет, что вам следует прочитать две более ранние книги Мастерство FreeBSD (FreeBSD Mastery), озаглавленные Хранение по существу (Storage Essentials) и ZFS. Но вы можете уже знать о чём эти книги, поэтому здесь некоторые подробности о том что вы должны взять с собой для четния.

Вы должны быть знакомы с уровнями управления хранением FreeBSD, GEOM. В платформах не-FreeBSD вы можете применять диски и разделы устройств для ZFS. Всегда применяйте ZFS на диске или разделах устройств, никогда не используйте RAID или программные устройства.

Мы предполагаем, что вы знакомы с пулами и наборами данных ZFS. Вы знаете как добавлять VDEV в пул и понимаете почему вы не можете добавить изолированный диск в свой RAID-Z. Вы можете делать снимки и создавать клоны.

Если вы хотите применять поддержку шифрования ZFS, вы должны понимать GELI кодирование FreeBSD. (Вы можете использовать GBDE, если вы полагаетесь на шифрование для защиты человеческой жизни, однако встроенной поддержки GELI вполне достаточно для большинства из нас. Кроме того, GELI имеет преимущества AES-NI аппаратного ускорения шифрования в современных ЦПУ.)

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

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

В файловых системах с копированием при записи (copy-on-write) удаление файлов потребляет пространство. {Прим. пер.: при изменении новых данных эти данные вначале копируются в новую область.} Привыкшие к обычным файловым системам системные администраторы могли слышать это, когда они начинали работать с ZFS, однако в действительности не усвоили этого, пока они не выйдут за пределы диска и не получат противный удар. Обладая подходом пула к ёмкости, ZFS требует всё больше и больше времени для хранения дополнительных блоков данных. Производительность ухудшается. Хотя разработчики ZFS придерживались уменьшения воздействия фрагментации на производительность, оно становится всё более и более значимым по мере приближения пула к 100% использованию.

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

В мдеале вам следует создать резерв 20% ёмкости вашего пула. Вы всегда можете уменьшить уменьшить резерв, купив время, которое вы отработаете над добавлением большей ёмкости или удаление старых данных. Последняя вещь, которую вы захотите получить это неожиданный выход за пределы пространства. Именно предложение вашей Unix File System (UFS), в которой root может воспользоваться самыми последними процентами дискового пространства, может дать вам мягкую посадку.

В данном пуле 1ТБ мы создадим новый набор данных с 200ГБ refreservation.

# zfs create -o refreservation=200G mypool/reserved
 	   

Каждый раз, когда вы исследуете проблемы пространства в наборе данных ZFS, вспоминайте о команде zfs get space. Вы увидите все связанные с пространством свойства в одном удобном отображении.

# zfs get space zstore/usr
NAME        PROPERTY              VALUE       SOURCE
zstore/usr  name                  zstore/usr  -
zstore/usr  available             5.00T       -
zstore/usr  used                  367M        -
zstore/usr  usedbysnapshots       0           -
zstore/usr  usedbydataset         140K        -
zstore/usr  usedbyrefreservation  0           -
zstore/usr  usedbychildren        367M        -
 	   

Хотя zfs get space и не освободит вам пространство, это простейший способ найти куда оно подевалось.

Как уже обсуждалось на протяжении всей книги ZFS, выбор правильного типа VDEV при создании вашего пула является наиболее важным выполняемым вами решением. Он влияет на производительность вашего пула, а также на расширение возможностей.

Исследование Pâris, Amer, Long и Schwarz (http://arxiv.org/ftp/arxiv/papers/1501/1501.00513.pdf) определило, что построение дискового массива, который может обслуживаться четыре года без вмешательства человека, требует тройного избыточного кодирования RAID. Двойное кодирование, даже с неограниченным числом запасных частей, не может поддерживать 99.999% (пять девяток) надёжности на протяжении четырёхлетнего периода.

Объединяйте это соображение с имеющимся у вас оборудованием и своими ожидаемыми потребностями хранения в будущем.

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

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

# zpool status
pool: data
state: DEGRADED
status: One or more devices is currently being resilvered. The
        pool will continue to function, possibly in a degraded
        state.
action: Wait for the resilver to complete.
 scan:  resilver in progress since Sat Apr 11 17:49:38 2015
        62.0M scanned out of 1.55T at 5.16M/s, 87h40m to go
        9.81M resilvered, 0.00% done

config:
NAME                   STATE     READ WRITE CKSUM
data                   DEGRADED     0     0     0
 mirror-0              DEGRADED     0     0     0
  spare-0              UNAVAIL      0     0     0
   5694975301095445325 FAULTED      0     0     0  was /dev/da1
  da7                  ONLINE       0     0   856  (resilvering)
  da14                 ONLINE       0     0     0
 mirror-1              ONLINE       0     0     0
  da1                  ONLINE       0     0     0
  da13                 ONLINE       0     0     0
 	   

Первоначально это пул состоял из двух зеркал: mirror-0 из da1 и da15, а также mirror-1 из da2 и da14. Диск da1 оказал.

FreeBSD динамично назначает узлы дисковых устройств при загрузке. Потеряв da1, FreeBSD перенумеровала оставшиеся дисковые устройства сдвинув номер на один вниз. Диск da15 стал da14, da14 стал da13 и, что хуже всего, da2 стал da1.

Поэтому mirror-1 содержит da1 - который был совсем не тем же диском da1, который отказал. mirror-0 применил свой запасной диск (da7) в месте, в котором использовался диск с именем da1. Поскольку неудачливый приятель Джуда поместил диск назад на место отказавшего da1, то da7 стал da1.

ZFS не использует имена дисков FreeBSD для поиска участников VDEV, вместо этого полагаясь свои собственные метки дисков с глобально уникальным идентификатором (GUID, Globally Unique IDentifier). ZFS может определить свой диск вне зависимости от того, где операционная система разместила свой узел устройства. А операционная система даже и не беспокоится- она нашла диск для вас и смонтировала вашу файловую систему; чего ещё вы хотите?

Однако, это может легко ввести оператора человека в заблуждение. Внезапно da1 является не отказавшим устройством, а прекрасно работающим устройством, да ещё совсем и в другом VDEV! После того, как оператор заменит устройство и перезагрузит машину, заменённый диск, почти несомненно, станет снова da1. Все узлы устройств сдвинутся назад в свои первоначальные значения. По окончанию всего этого системный администратор не имеет идей какой диск кем является. Единственная имеющаяся у него мысль, что он должен сильно напиться.

FreeBSD предоставляет различные способы пометки диска или раздела. Некоторые являются автоматическими, а некоторые управляются пользователем. Каждый из них имеет преимущества и недостатки. Одно устройство может иметь множество меток.

Когда осуществляется доступ по одной метке, другая метка указывающая на то же самое устройство засыхают и становятся недоступными. Это предотвращает доступ к одному устройству по множеству имён.

Все автоматически создаваемые метки активируются по умолчанию. Если вы хотите применять устанавливаемые вручную метки, то лучше запретить эти методы установки вручную. {Прим. пер.: так в тексте. Вопрос авторам задан.}

Если диск разбивается на разделы при помощи GUID Partition Table (GPT), каждый раздел может содержать текстоовую метку по своему выбору. Это является предпочтительным методом пометки дисков для обоих авторов.

Используйте gpart(8) для создания и пометки нового раздела.

# gpart add -t freebsd-zfs -l zfs-mirror-1 da2
 	   

Вот мы изменяем свою метку для существующего 2го раздела.

# gpart modify -i 2 -l f01-serialnum da2
 	   

Устанавливаемые вручную метки позволяют вам идентифицировать диски по таким характеристикам, как физическое местоположение и серийный номер.

Если вы используете метки GPT, мы рекомендуем запретить GPTID и дисковые ID метки.

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

ada0p1: /dev/gptid/b305e4ff-b889-11e5-bace-002590db872e
ada1p1: /dev/gptid/b329ff70-b889-11e5-bace-002590db872e
ada1p2: /dev/gptid/b33db4ac-b889-11e5-bace-002590db872e
 	   

Если только последние несколько символов самого первого сегмента в действительности отличны, достаточно легко запутаться.

Если ZFS просматривает часть пула с метками GUID до того, как он увидит что тот же пул применяет другие метки, он применяет метки GPTID. Это скроет аккуратно создаваемые вами вручную метки. Запретите метки GPTID при загрузке добавив следующую строку в /boot/loader.conf.

kern.geom.label.gptid.enable=0
 	   

По умолчанию FreeBSD делает метки GPT ID доступными.

В то время как метки GPT и GPTID идентифицируют раздел, метки Disk Ident (или diskid) идентифицируют диск целиком. Имя устройства основывается на серийном номере диска, который вполне подходит для этого. К сожалению, любые специализированные символы в этом серийном номере - в особенности, пробелы - кодируются. Это создаёт весьма уродливые имена устройств. Кроме того, так как метка идентифицирует весь диск, а не раздел, добавляется в конец часть раздела имени устройства (p3) и может быть трудно ухватить имя этого устройства.

/dev/diskid/DISK-07013121E6B2FA14
/dev/diskid/DISK-%20%20%20%20%20WD-WCC131365642
/dev/diskid/DISK-%20%20%20%20%20%20%20%20%20%20%20%20Z300HTCE
 	   

Такие автоматически создаваемые метки могут быть запрещены для блокирования их применения ZFS вместо ваших меток GPT. Добавьте в /boot/loader.conf следующее:

ern.geom.label.disk_ident.enable=0
 	   

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

По умолчание метки diskid в FreeBSD разрешены.

В добавление ко всем прочим типам меток вы можете также создавать метку GEOM, сохраняемую в самом последнем секторе диска или раздела. Эти метки определяются в специфичном для GEOM формате и называются glabel. Преимущество таких устанавливаемых пользователем меток состоит в том, что нет необходимости применять формат GPT, поэтому они могут работать и в дисках формата MBR, и в голых дисках без каких бы то ни было разделов. Glabel используют самый последний сектор поставщика.

Создадим и просмотрим glabel при помощи glabel(8).

# glabel label -v mylabel /dev/ada0p2
Metadata value stored on /dev/ada0p2.
Done.
# glabel status
         Name  Status  Components
 gpt/gptboot0     N/A  ada0p1
label/mylabel     N/A  ada0p2
 gpt/zfs0         N/A  ada0p3
 	   

Это теперь устройство /dev/label/mylabel

Все метки должны быть уникальными. Хотя вы и можете применять одну и ту же метку для множества дисков, отображаться будет только одна.

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

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

Мы будем поощрять вас использовать вывод подобных сценариев DTrace как для решения ваших проблем ZFS, так и точку входа для выбора предмета изучения внутреннего устройства ядра. Вы не обязательно должны быть программистом, однако профессиональный системный администратор должен развивать понимание того, как работает система.

Работающие вслепую сценарии в точности соответствуют "мистическому ведению дел", против которого с напором выступает Лукас. Тем не менее, здесь мы опишем как именно выполнять сценарий DTrace вслепую.

DTrace применяет модули ядра для исследования программного обеспечения, которые наблюдают за поведением программных средств: dtrace.ko и dtraceall.ko. Вы можете загружать их автоматически при загрузке в loader.conf. Если эти модули ядра не найдены, программа dtrace(1) автоматически загрузит их когда вы её выполните первый раз.

Вы должны выполнять dtrace с правами root.

Скопируйте свой сценарий в какой-нибудь файл. Затем выполните dtrace -s с этим сценарием в качестве аргумента.

Чтобы прервать сценарий, нажмите CTRL-C.

Вы можете загрузить все приведённые в этой книге сценарии DTrace из репозитория GitHub Лукаса, ссылка на который имеется на zfsbook.com

Системный администратор с пониманием того как работает его ядро сможет решать проблемы более быстро и правильно. В качестве обзора внутреннего устройства ZFS прихватите последнюю редакцию Проектирования и реализации операционной системы FreeBSD (The Design and Implementation of the FreeBSD Operating System, Addison-Wesley Professional,2014, кое- кто из авторов TD&IotFOS использует наши книги по ZFS для изучения написанного ими кода, так что всё уравнивается.) Аналогично, DTrace является мощным инструментом, стоящим его обучения и понимания. Мы рекомендуем книгу Gregg и Mauro, DTrace: Dynamic Tracing in Oracle Solaris, Mac OS X, and FreeBSD Prentice Hall, 2011.

Глава 0 является данным Введением.

Глава 1, Окружения загрузки проведёт вас сквозь применение снимков ZFS для создания сред загрузки в стиле Sloaris. Окружения загрузки делают для вас возможными без головной боли обратимые изменения, такие как обновления. Вы даже можете одновременно иметь множество установленных версий FreeBSD. Когда у вас есть одновременно установленное множество версий FreeBSD, вы будете удивляться тому, как вы могли до этого жить без них.

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

Глава 3, Совместное использование наборов данных описывает функциональность совместного сетевого применения файлов. ZFS FreeBSD интегрирована с Network File System, а также крайне полезна для устройств iSCSI.

Глава 4, Репликация обучает тому, как реплицировать наборы данных ZFS на другие машины. Репликации могут позволить вам подхватывать массивные объёмы данных и перемещать их поперёк страны или вокруг планеты, сохраняя при этом их актуальность, даже без уведомления пользователей.

Глава 5, Тома ZFS обсуждает некоторые тонкие детали создания и применения блочных устройств поверх пула ZFS.

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

Глава 7, Кэширование охватывает все возможные механизмы кэширования. Вы изучите кэш адаптивной замены и все его варианты, кэширование чтения и записи, а также кэширование дискового пула.

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

Глава 9, Тонкая настройка обсуждает как регулировать лучшим образом работу ZFS в вашей среде, имея надежду в отсутствии необходимости приобретения дополнительного и более дорогостоящего оборудования.

Глава 10, Попурри ZFS включает группу коротких советов по применению ZFS.

Для тех, кто читает введение в книги: наши поздравления. Мы надеемся, вы что- то узнали, или, по крайней мере, были предупреждены о некоторых важных подробностях. Давайте перейдём к средам загрузки!