ZFS Primer (на русском)

Файловая система ZFS

ZFS — это современная файловая система, специально разработанная для обеспечения функций, недоступных в традиционных файловых системах UNIX. Она был первоначально разработана в Sun с намерением открыть исходную файловую систему, чтобы ее можно было портировать в другие операционные системы. После приобретения Oracle Sun некоторые из оригинальных инженеров ZFS основали OpenZFS для обеспечения совместной совместной разработки версии с открытым исходным кодом. Чтобы отличать себя от версий Oracle ZFS, OpenZFS использует флаги функций. Флаги функций используются для тегов функций с уникальными именами, чтобы обеспечить переносимость между реализациями OpenZFS, запущенными на разных платформах, если все флаги функций, включенные в пуле ZFS, поддерживаются обеими платформами.

 

FreeNAS® использует OpenZFS, и каждая новая версия FreeNAS® обновляется с последними флагами функций и исправлениями ошибок OpenZFS.

 

Функции предоставляемые ZFS

ZFS — это транзакционная файловая система Copy-On-Write (COW). Для каждого запроса на запись выполняется копирование связанных блоков диска, и все изменения производятся в копии, а не в исходных блоках. Когда запись завершена, все указатели блоков изменены, чтобы указать на новую копию. Это означает, что ZFS всегда записывает на свободное место, большинство записей являются последовательными, а старые версии файлов не отключаются до тех пор, пока полная новая версия не будет успешно записана. ZFS имеет прямой доступ к дискам и объединяет в транзакции несколько запросов на чтение и запись. Большинство файловых систем не могут этого сделать, поскольку они имеют доступ только к дисковым блокам. Транзакция завершается или завершается с ошибкой, то есть никогда не будет дыр для записи, и утилита проверки файловой системы не нужна. Из-за транзакционного дизайна, когда добавляется дополнительная емкость, он становится немедленно доступным для записи. Чтобы перебалансировать данные, можно скопировать их для повторной записи существующих данных на все доступные диски. В качестве 128-битной файловой системы максимальная файловая система или размер файла составляет 16 экзабайт.

ZFS была разработана как само-восстанавливающаяся файловая система. Когда ZFS записывает данные, он создает контрольную сумму для каждого записываемого блока диска. Когда ZFS считывает данные, он проверяет контрольную сумму для каждого считываемого блока диска. Ошибки носителя или bit rot (бит-гниль) могут привести к изменению данных, а контрольная сумма больше не соответствует. Когда ZFS идентифицирует ошибку контрольной суммы блока диска в пуле, который зеркалируется или использует RAIDZ, он заменяет поврежденные данные правильными данными. Поскольку некоторые блоки диска редко читаются, регулярные скрабы должны быть запланированы, чтобы ZFS мог читать все блоки данных для проверки своих контрольных сумм и исправления любых поврежденных блоков. Хотя для обеспечения избыточности и коррекции данных требуется несколько дисков, ZFS по-прежнему будет обеспечивать обнаружение повреждения данных в системе с одним диском. FreeNAS® автоматически планирует ежемесячный скраб для каждого пула ZFS, а результаты скраба отображаются, в выбранном томе, затем нажав кнопку Volume Status(Состояние тома). Проверка результатов скраба может обеспечить раннее выявление потенциальных проблем с диском.

В отличие от традиционных файловых систем UNIX, нет необходимости определять размеры разделов при создании файловых систем. Вместо этого группа дисков, известная как vdev, встроена в пул ZFS. Файловые системы создаются из пула по мере необходимости. Поскольку требуется больше емкости, идентичные vdev могут быть разделены на пул. В FreeNAS® Volume Manager можно использовать для создания или расширения пулов ZFS. После создания пула его можно разделить на datasets динамического размера или zvols фиксированного размера по мере необходимости.

 

Наборы данных — Datasets

Наборы данных (Datasets) могут использоваться для оптимизации хранилища для типа данных, хранящихся в виде разрешений и свойств, таких как квоты, и сжатие может быть установлено на уровне каждого набора данных. ZVOL — это, по сути, необработанное виртуальное блочное устройство, которое может использоваться для приложений, которым нужна семантика raw-устройства, такая как экстенты устройств iSCSI.

ZFS поддерживает сжатие данных в реальном времени. Сжатие происходит, когда блок записывается на диск, но только если письменные данные будут полезны для сжатия. При доступе к сжатому блоку он автоматически распаковывается. Поскольку сжатие происходит на уровне блока, а не на уровне файла, оно прозрачно для любых приложений, получающих сжатые данные. По умолчанию пулы ZFS, созданные с использованием FreeNAS версии 9.2.1 или более поздней версии, будут использовать рекомендуемый алгоритм сжатия LZ4.

ZFS обеспечивает недорогие мгновенные снимки указанного пула, набора данных(datasets) или zvol. Из-за COW снимки изначально не занимают дополнительного места. Размер моментального снимка увеличивается с течением времени, так как изменения файлов в моментальном снимке записываются на диск. Снимки могут использоваться для предоставления копии данных в момент создания моментального снимка. Когда файл удаляется, его блоки диска добавляются в свободный список; однако блоки для этого файла в любых существующих моментальных снимках не добавляются в бесплатный список до тех пор, пока все снимки, ссылающиеся на снимки, не будут удалены. Это делает снимки умным способом хранения истории файлов, полезных для восстановления старой копии файла или удалённого файла. По этой причине многие администраторы часто делают снимки (например, каждые 15 минут), хранят их в течение определенного периода времени (например, в течение месяца) и сохраняют их в другой системе. Такая стратегия позволяет администратору перевести систему обратно в определенное время. Если есть катастрофическая потеря, моментальный снимок за пределами площадки может восстановить систему до последнего интервала моментального снимка (например, в течение 15 минут после потери данных). Снимки сохраняются локально, но также могут быть реплицированы в удаленный пул ZFS. Во время репликации ZFS не выполняет байтовую копию, а вместо этого преобразует моментальный снимок в поток данных. Эта конструкция означает, что пул ZFS на принимающей стороне не обязательно должен быть идентичным и может использовать другой уровень RAIDZ, размер тома или параметры сжатия.

В средах загрузки ZFS предусмотрен способ восстановления после неудачного обновления. В FreeNAS® моментальный снимок набора данных, на котором находится операционная система, автоматически выполняется до обновления или обновления системы. Эта загруженная, загрузочная среда автоматически добавляется в загрузчик GRUB. В случае сбоя обновления или конфигурации просто перезагрузитесь и выберите предыдущую загрузочную среду из меню загрузки. Пользователи также могут создавать свои собственные загрузочные среды в System → Boot по мере необходимости, например, перед внесением изменений конфигурации. Таким образом, система может быть перезагружена в моментальный снимок системы, которая не включала новые изменения конфигурации.

ZFS предоставляет кэш записи в оперативной памяти, а также журнал ZFS Intent Log (ZIL). ZIL — это область хранения, которая временно хранит * синхронные * записи до тех пор, пока они не будут записаны в пул ZFS.

Добавление быстрого (с малой задержкой) SSD с защитой от электропитания в качестве устройства SLOG (отдельный журнал) позволяет значительно повысить производительность.

Это необходимо для NFS через ESXi и настоятельно рекомендуется для серверов баз данных или других приложений, которые зависят от синхронной записи. Более подробная информация о преимуществах и использовании SLOG доступна в этих блогах и на форуме:

• The ZFS ZIL and SLOG Demystified — http://www.freenas.org/blog/zfs-zil-and-slog-demystified/
• Some insights into SLOG/ZIL with ZFS on FreeNAS® — https://forums.freenas.org/index.php?threads/some-insights-into-slog-zil-with-zfs-on-freenas.13633/
• ZFS Intent Log — http://nex7.blogspot.ru/2013/04/zfs-intent-log.html

Синхронные записи относительно редки в SMB, AFP и iSCSI, а добавление SLOG для повышения производительности этих протоколов имеет смысл только в особых случаях. Утилиту zilstat можно запустить из Shell, чтобы определить, получит ли система от SLOG. См. Этот сайт для использования — http://www.richardelling.com/Home/scripts-and-programs-1/zilstat

В настоящее время ZFS использует 16 ГБ пространства для SLOG. Можно установить более крупные SSD-диски, но дополнительное пространство не будет использоваться. Устройства SLOG не могут использоваться совместно с пулами. Для каждого пула требуется отдельное устройство SLOG. Ограничения пропускной способности требуют, чтобы устройство SLOG использовалось только для этой цели. Не пытайтесь добавить другие функции кеширования на одном SSD, иначе производительность пострадает.

В критически важных системах настоятельно рекомендуется зеркальное устройство SLOG. Зеркальные устройства SLOG требуются для пулов ZFS в ZFS версии 19 или ранее. Версию пула ZFS можно проверить из командной оболочки с помощью zpool get version poolname. Значение версии — означает, что пул ZFS — это версия 5000 (также известный как флаги функций) или позже.

ZFS предоставляет кэш чтения в ОЗУ, известный как ARC, который уменьшает латентность чтения. FreeNAS® добавляет статистику ARC в top(1) и включает инструменты arc_summary.py и arcstat.py для контроля эффективности ARC. Если SSD выделен как кэш-устройство, он известен как L2ARC. Здесь хранятся дополнительные данные чтения, что может повысить скорость чтения. L2ARC не уменьшает необходимость в достаточной ОЗУ. Фактически, L2ARC нуждается в ОЗУ для работы. Если для ARC с адекватным размером недостаточно ОЗУ, добавление L2ARC не увеличит производительность. В большинстве случаев производительность фактически уменьшается, что может вызвать системную нестабильность. ОЗУ всегда быстрее, чем диски, поэтому всегда добавляйте как можно больше ОЗУ, прежде чем рассматривать, может ли система извлечь выгоду из устройства L2ARC.

Когда приложения выполняют большое количество случайных чтений на наборе данных, достаточно малом, чтобы вписаться в L2ARC, производительность чтения может быть увеличена путем добавления выделенного кэширующего устройства. Кэш-устройства SSD помогают только в том случае, если активные данные больше, чем оперативная память системы, но достаточно мала, чтобы значительный процент соответствовал SSD. Как правило, L2ARC не следует добавлять в систему с объемом памяти менее 32 ГБ, а размер L2ARC не должен превышать объем оперативной памяти в десять раз. В некоторых случаях может быть более эффективным иметь два отдельных пула: один на SSD для активных данных, а другой — на жестких дисках для редко используемого контента. После добавления устройства L2ARC следите за его эффективностью с помощью таких инструментов, как arcstat. Чтобы увеличить размер существующего L2ARC, пролистните с ним другое устройство кэширования. GUI всегда будет stripe-ить L2ARC, а не mirror-ить его, так как содержимое L2ARC воссоздается при загрузке. Отказ отдельного SSD от пула L2ARC не повлияет на целостность пула, но может повлиять на производительность чтения в зависимости от рабочей нагрузки и соотношения размера набора данных с размером кеша. Обратите внимание, что выделенные устройства L2ARC не могут использоваться совместно с пулами ZFS.

 

Зачем была разработана ZFS?

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

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

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

При определении типа избыточности ZFS для использования следует учитывать, является ли цель максимизировать дисковое пространство или производительность:

• RAIDZ1 максимизирует дисковое пространство и обычно хорошо работает, когда данные записываются и считываются большими кусками (128 КБ или более).
• RAIDZ2 обеспечивает лучшую доступность данных и значительно лучшее среднее время потери данных (MTTDL), чем RAIDZ1.
• Зеркало потребляет больше дискового пространства, но обычно лучше работает при небольших случайных чтениях. Для лучшей производительности зеркало настоятельно рекомендуется для любого RAIDZ, особенно для больших, неуправляемых, случайных считываемых нагрузок.
• Не рекомендуется использовать более 12 дисков на vdev. Рекомендуемое количество дисков на vdev составляет от 3 до 9. С большим количеством дисков используйте несколько vdev.
• В некоторых более старых документах ZFS рекомендуется, чтобы для каждого типа RAIDZ требовалось определенное количество дисков для достижения оптимальной производительности. В системах, использующих сжатие LZ4, которое по умолчанию используется для FreeNAS® 9.2.1 и выше, это уже не так. См. Ширину полосы ZFS RAIDZ или: Как я узнал, чтобы перестать беспокоиться и любить RAIDZ для деталей.

Эти ресурсы также могут помочь определить конфигурацию RAID, наиболее подходящую для ваших потребностей в хранении:

https://forums.freenas.org/index.php?threads/getting-the-most-out-of-zfs-pools.16/

https://constantin.glez.de/2010/06/04/a-closer-look-zfs-vdevs-and-performance/

 

Опасно!!!

RAID и DISK REDUNDANCY НЕ ЯВЛЯЮТСЯ ЗАМЕЩЕНИЕМ ДЛЯ НАДЕЖНОЙ СТРАТЕГИИ РЕЗЕРВИРОВАНИЯ. ПЛОХИЕ ВЕЩИ СЛУЧАЮТСЯ И ХОРОШАЯ СТРАТЕГИЯ РЕЗЕРВИРОВАНИЯ ЕЩЕ НЕОБХОДИМА ДЛЯ ЗАЩИТИТЫ ЦЕННЫХ ДАННЫХ.

См. «Задачи периодического моментального снимка» и «Задачи репликации» для использования реплицированных снимков ZFS в рамках стратегии резервного копирования.

ZFS управляет устройствами. Когда отдельный диск в зеркале или RAIDZ выходит из строя и заменяется пользователем, ZFS добавляет заменяющее устройство в vdev и копирует избыточные данные в процесс, называемый resilvering. Аппаратные RAID-контроллеры обычно не имеют возможности узнать, какие блоки используются, и должны скопировать каждый блок на новое устройство. ZFS только копирует блоки, которые используются, сокращая время, необходимое для восстановления vdev. Resilvering также прерывается. После прерывания, resilvering возобновляется, где это прекращалось, а не начиналось с самого начала.

Хотя ZFS предоставляет много преимуществ, есть некоторые оговорки:

• При пропускной способности 90% ZFS переключается с оптимизации производительности на простор, что имеет значительные последствия для производительности. Для максимальной производительности записи и предотвращения проблем с заменой диска добавьте дополнительную емкость до того, как пул достигнет 80%. Если вы используете iSCSI, рекомендуется не пускать пул на 50%, чтобы предотвратить проблемы фрагментации.
• Рассматривая количество дисков для использования на vdev, рассмотрите размер дисков и количество времени, необходимое для resilvering, что является процессом восстановления vdev. Чем больше размер vdev, тем дольше время resilvering. При замене диска в RAIDZ возможно, что другой диск завершится с ошибкой до завершения процесса resilvering. Если количество отказоустойчивых дисков превышает количество, разрешенное для vdev для типа RAIDZ, данные в пуле будут потеряны. По этой причине RAIDZ1 не рекомендуется для дисков размером более 1 ТБ.
• При создании vdev рекомендуется использовать диски одинакового размера. В то время как ZFS может создавать vdev с использованием дисков разного размера, его емкость будет ограничена размером самого маленького диска.

RAIDZ1 не рекомендуется для дисков размером более 1 ТБ.

Для тех, кто не знаком с ZFS, запись в Википедии в ZFS дает отличную отправную точку, чтобы узнать больше о ее возможностях. Эти ресурсы также полезны для справки:

https://docs.oracle.com/cd/E19253-01/819-5461/index.html