Назначение и принцип работы arc и l2arc в zfs

Монтирование

Файловая система proc поддерживает следующие параметры монтирования:

hidepid = n (начиная с Linux 3.3). Эта опция контролирует, кто может получить доступ к информации в каталогах / proc / . Аргумент n является одним из следующих значений:

- 0 Каждый может получить доступ ко всем каталогам . Это традиционное поведение и значение по умолчанию, если этот параметр монтирования не указан.
- 1 Пользователи могут не иметь доступа к файлам и подкаталогам внутри каких-либо каталогов , но свои собственные (сами каталоги остаются видимыми). Чувствительные файлы, такие как и , теперь защищены от других пользователей. Это делает невозможным изучение того, запускает ли какой-либо пользователь определенную программу (при условии, что программа не раскрывает себя по своему поведению).
- 2 То же, что и 1, но кроме этого каталоги , принадлежащие другим пользователям, становятся невидимыми. Это означает, что записи больше не могут использоваться для обнаружения PID в системе. Это не скрывает того факта, что процесс с определенным значением PID существует (его можно узнать другими способами, например, «»), но он скрывает UID и GID процесса, которые в противном случае могли бы научиться применять stat (2) в каталоге / proc / . Это значительно усложняет задачу злоумышленника по сбору информации о запущенных процессах (например, обнаружение, работает ли какой-либо демон с повышенными привилегиями, выполняет ли какой-либо другой пользователь какую-либо чувствительную программу, запускают ли другие пользователи какую-либо программу вообще и т. д.).
(начиная с Linux 3.3). Задает идентификатор группы, члены которой уполномочены изучать информацию о процессах, иначе запрещенную hidepid (т.е. пользователи в этой группе ведут себя так, как будто был смонтирован с ). Эта группа должна использоваться вместо подходов, таких как помещение нерутованных пользователей в файл sudoers (5).

Стоит ли использовать дедупликацию для хранения конкретного типа информации?

Для того, чтобы определить, подходят ли данные для применения дедупликации и получите ли вы выгоду, используйте отладчик ZFS —

zdb

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

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

Таким образом, процесс дедупликации при попытке обработать неподходящие для дедуплицирования данные просто попусту тратит процессорное время. Дедупликация встроена в ZFS, поэтому потеря процессорного времени будет происходить во время записи на диск.

Например, если коэфициент дедупликации больше 2, вы можете получить экономию дискового пространства. В примере на Листинге 1 коэфициент дедупликации меньше 2, поэтому включение дедупликации не рекомендуется.

Листинг 1: Определение коэфициента дедупликации

# zdb -S tank
Simulated DDT histogram:
bucket allocated referenced
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
 1 2.27M 239G 188G 194G 2.27M 239G 188G 194G
 2 327K 34.3G 27.8G 28.1G 698K 73.3G 59.2G 59.9G
 4 30.1K 2.91G 2.10G 2.11G 152K 14.9G 10.6G 10.6G
 8 7.73K 691M 529M 529M 74.5K 6.25G 4.79G 4.80G
 16 673 43.7M 25.8M 25.9M 13.1K 822M 492M 494M
 32 197 12.3M 7.02M 7.03M 7.66K 480M 269M 270M
 64 47 1.27M 626K 626K 3.86K 103M 51.2M 51.2M
 128 22 908K 250K 251K 3.71K 150M 40.3M 40.3M
 256 7 302K 48K 53.7K 2.27K 88.6M 17.3M 19.5M
 512 4 131K 7.50K 7.75K 2.74K 102M 5.62M 5.79M
 2K 1 2K 2K 2K 3.23K 6.47M 6.47M 6.47M
 8K 1 128K 5K 5K 13.9K 1.74G 69.5M 69.5M
 Total 2.63M 277G 218G 225G 3.22M 337G 263G 270G
dedup = 1.20, compress = 1.28, copies = 1.03,
dedup * compress / copies = 1.50

Чтение из кэша

При чтении, данные, к которым идет наиболее частый доступ, помещаются в ARC, со временем он переполняется и данные из ARC вытесняются в L2ARC.

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

Накопители, выделяемые для L2ARC нет смысла объединять в RAID-массивы или иным образом резервируемые тома, поскольку с точки зрения ZFS отказ устройства L2ARC не является критичным. Вы просто добавляете каждое устройство в L2ARC по-отдельности.

Важно понимать, что ни ARC, ни L2ARC никак не влияют на производительность операций записи, в нагрузках, профиль которых связан с преимущественной записью, использование L2ARC может быть неоправданным

Системные свойства ZFS, доступные только для чтения

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

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

available
creation
mounted
origin
compressratio
referenced
type
used

Для получения подробной информации см. Свойство used.
usedbychildren
usedbydataset
usedbyrefreservation
usedbysnapshots

Для получения дополнительной информации об учете пространства, включая сведения о свойствах used, referenced и available, см. Учет пространства ZFS.

Свойство `used`

Объем пространства, занимаемого набором данных и всеми дочерними элементами. Это значение сверяется с квотой и резервированием, указанными для набора данных. Используемое пространство не учитывает резервирование для набора данных, но учитывает резервирование для любых дочерних наборов данных. Объем пространства родительского элемента, занимаемого набором данных, а также объем освобожденного пространства в случае рекурсивного уничтожения набора данных – это большее из объема используемого и объема резервируемого пространства.

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

При определении объема используемого, доступного и занятого пространства не учитываются отложенные изменения. Как правило, отложенные изменения существуют в течение нескольких секунд. Запись изменения на диск с помощью команды fsync(3c) или O_SYNC не гарантирует немедленного обновления информации об использовании пространства.

Просмотр информации о свойствах usedbychildren, usedbydataset , usedbyrefreservation и usedbysnapshots возможен с помощью команды zfs list - o space. Данные свойства делят свойство used на пространства, занимаемые дочерними элементами. Дополнительная информация приведена в .

Что следует помнить

Есть несколько аспектов, которые нужно помнить.

Диски L2ARC не зеркалируются. При добавлении дисков кэша нельзя настроить их как зеркальные, но в этом и нет необходимости, поскольку содержимое уже зеркально отражено на жестких дисках. Диски кэша являются просто недорогой альтернативой оперативной памяти для кэширования часто запрашиваемого контента.
В случае, если вы решите использовать накопители SSD вместо HDD для хранения данных, то диски кэша не нужны. Поскольку все накопители уже являются сверхбыстрыми SSD-дисками, использование дисков кэша не даст увеличения производительности.
Если вы планируете подключить большое количество накопителей SSD, рассмотрите использование нескольких контроллеров SAS. Если используется достаточное количество SSD-дисков, есть шанс перегрузить пропускную способность контроллера, что не позволит реализовать весь потенциал системы.

Эффективное кэширование в виртуальных средах

Вероятно, вы задаетесь вопросом, насколько эффективно двухуровневое кэширование для наиболее часто используемых данных в случае использования с виртуальными машинами? Повлияет ли кэш ARC и L2ARC на общую производительность?

Это зависит от того, какой тип данных находится в массиве и как к осуществляется доступ к этим данным, то есть от профиля нагрузки на дисковую систему. Если доступ к данным осуществляется случайным образом, кэширование, вероятно, будет неэффективным. Однако, в случае, когда хранилище используется для файловых систем виртуальных машин (VPS), кэширование будет эффективным, поскольку чаще всего будет обеспечиваться высокая локализованность операций чтения, особенно, когда виртуальные машины порождаются из общего шаблона.

Если вы планируете развернуть большое количество виртуальных машин, первым шагом создайте базовый шаблон, от которого будут порождаться тома виртуальных машин. Когда базовый шаблон готов, каждая дополнительная виртуальная машина должна создаваться на его основе. Технология виртуализации сохраняет изменения, специфичные для каждой виртуальной машины в разностном файле (например, QCOW2 с использованием backing file).

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

Опасно!!!

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 с использованием дисков разного размера, его емкость будет ограничена размером самого маленького диска.

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

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

Поделись записью

Команда zpool

Это основной инструмент управления разделами и функциональными возможностями ZFS, поэтому вам важно его освоить. Общий синтаксис команды достаточно прост, но у нее есть множество подкоманд, которые имеют свой синтаксис и параметры:. $ zpool команда параметры опции устройства

$ zpool команда параметры опции устройства

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

add — добавить раздел к существующему пулу;
attach — добавить раздел или жесткий диск к пулу файловой системы;
clean — очистить все ошибки дисков;
create — создать новый пул из физического раздела, на котором будут размещены виртуальные диски;
destroy — удалить пул разделов zfs;
detach — отключить физический раздел от пула;
events — посмотреть сообщения ядра, отправленные модулем zfs;
export — экспортировать пул для переноса в другую систему;
get — посмотреть параметры пула;
set — установить значение переменной;
history — отобразить историю команд zfs;
import — импортировать пул;
iostat — отобразить статистику ввода/вывода для выбранного пула zfs;
list — вывести список всех пулов;
offline/online — выключить/включить физическое устройство, данные на нем сохраняются, но их нельзя прочитать или изменить;
remove — удалить устройство из пула;
replace — перенести все данные со старого устройства не новое;
scrub — проверка контрольных сумм для всех данных;
status — вывести статус пула.

Это были все основные опции команды, которые мы будем использовать. Теперь рассмотрим примеры настройки zfs и управления разделами.

Информация о видеокарте в /proc

Информация о PCI устройствах содержится в файле /proc/bus/pci/devices, а также в поддиректориях /proc/bus/pci. Как и с другими устройствами, здесь нет информации о производителе — только тип устройства и, видимо, используемое адресное пространство.

Больше информации вы сможете найти в папке /proc/driver, пример вывода данных о драйвере NVidia:

cat /proc/driver/nvidia/gpus/0000\:01\:00.0/information

Пример вывода:

Model: 		 GeForce GTX 1050 Ti
IRQ:   		 157
GPU UUID: 	 GPU-e7cc6b38-164e-babb-d5e7-14b23d2e5e05
Video BIOS: 	 86.07.50.00.54
Bus Type: 	 PCIe
DMA Size: 	 47 bits
DMA Mask: 	 0x7fffffffffff
Bus Location: 	 0000:01:00.0
Device Minor: 	 0
Blacklisted:	 No

Здесь информация о модели, версии БИОСа, типе шине, находиться ли устройство в чёрном списке (для отключения) и некоторые другие данные.

Функции предоставляемые 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 фиксированного размера по мере необходимости.

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

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

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/

L2ARC

Чтобы поддерживать ARC большим, требуется установить на сервер как можно больше оперативной памяти. В какой-то момент добавление большего объема памяти становится неразумно дорого или невозможно. Тогда можно начать использовать L2ARC. L2ARC — это кэш адаптивной замены второго уровня. Данный кэш располагается на высокопроизводительных дисковых устройствах, чаще всего на SATA или NVMe накопителях типа SSD. Когда диски кэша присутствуют в пуле дисков ZFS, они кэшируют часто используемые данные, которые не помещаются в ARC.

SSD-диски медленнее системной памяти, но все же намного быстрее, чем жесткие диски большого объема, которые используются для фактического хранения данных

Что еще более важно, SSD-диски намного дешевле, чем системная память. Большинство людей сравнивают стоимость SSD-дисков с ценой на жесткие диски, поэтому SSD-диски кажутся дорогими

Но по сравнению с системной памятью накопители SSD MLC на самом деле значительно дешевле.

Пользовательские свойства ZFS

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

Имена пользовательских свойств должны соответствовать следующим характеристикам:

содержать символ двоеточия («: «), отличающий их от системных свойств;
содержать буквы в нижнем регистре, числа и следующие знаки пунктуации: ‘:’, ‘+’,’.’, ‘_’.
максимальная длина имени пользовательского свойства составляет 256 символов.

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

module:property

При программном использовании пользовательских свойств для компонента модуль имен свойств следует указать имя домена DNS, элементы которого представлены в обратном порядке. Это позволит снизить вероятность использования двух независимо созданных пакетов с одним именем свойства в различных целях. Имена свойств, начинающиеся с com.sun., зарезервированы для использования Sun Microsystems.

Значения пользовательских свойств имеют следующие характеристики:

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

Пример:

# zfs set dept:users=finance userpool/user1
# zfs set dept:users=general userpool/user2
# zfs set dept:users=itops userpool/user3

Все команды, выполняемые по отношению к свойствам, например zfs list, zfs get, zfs set и т. д., могут использоваться для управления как системными, так и пользовательскими свойствами.

Пример:

zfs get -r dept:users userpool
NAME            PROPERTY    VALUE           SOURCE
userpool        dept:users  all             local
userpool/user1  dept:users  finance         local
userpool/user2  dept:users  general         local
userpool/user3  dept:users  itops           local

Для сброса пользовательского свойства используется команда zfs inherit. Пример:

# zfs inherit -r dept:users userpool

Если свойство не определено ни в одном родительском наборе данных, оно удаляется полностью.

Развертывание

В настоящее время ARC используется в контроллерах хранения IBM DS6000 / DS8000 .

Масштабируемая файловая система ZFS Sun Microsystems использует вариант ARC в качестве альтернативы традиционному кэшу страниц файловой системы Solaris в виртуальной памяти. Он был изменен, чтобы разрешить заблокированные страницы, которые в настоящее время используются и не могут быть освобождены.

PostgreSQL на короткое время использовал ARC в своем диспетчере буферов (версия 8.0.0), но быстро заменил его другим алгоритмом, сославшись на опасения по поводу патента IBM на ARC.

VMware vSAN (ранее называвшаяся Virtual SAN) — это гиперконвергентное программно-определяемое хранилище (SDS), разработанное VMware. Он использует вариант ARC в своем алгоритме кэширования.

OpenZFS поддерживает использование ARC и L2ARC в многоуровневом кэше в качестве кэшей чтения. В OpenZFS чтение с диска часто попадает в дисковый кеш первого уровня в ОЗУ с использованием ARC. Если SSD настроен для хранения дискового кеша второго уровня, он называется L2ARC. L2ARC использует тот же алгоритм ARC, но вместо хранения кэшированных данных в ОЗУ L2ARC сохраняет кэшированные данные на быстром SSD.