ZFS
Общая информация
В разделе Хранилища - ZFS основного меню содержится информация обо всех хранилищах ZFS, сконфигурированных в системе. ZFS-хранилища являются локальными, но возможности данных хранилищ значительно шире, чем у локальных файловых хранилищ. Создавая хранилище ZFS, необходимо подготовить сервер к созданию на нем пула данных типа zfs.
Создание
Для создания ZFS-хранилища необходимо в разделе Хранилища - ZFS основного меню нажать кнопку Добавить ZFS. В открывшемся окне необходимо выбрать и заполнить следующие поля:
- 
сервер размещения ZFS (выбор из раскрывающегося списка); 
- 
тип пула (выбор из раскрывающегося списка). В типе пула необходимо выбрать режим RAID, который будет применяться к входящим в состав ZFS-хранилища дискам. Доступны следующие режимы: - 
stripe; 
- 
mirror; 
- 
raidz1; 
- 
raidz2. 
 Режимы raidz1 и raidz2 соответствуют RAID5 и RAID6 соответственно; 
- 
- 
локальные устройства (выбор из раскрывающегося списка); 
- 
LUN-устройства (выбор из раскрывающегося списка); 
- 
название и описание пула. 
После заполнения полей необходимо подтвердить операцию, нажав кнопку ОК.
Примечание
В списке доступных блочных устройств показываются только устройства без разметки (разделов). Чтобы очистить требуемое устройство от ранее созданной разметки, следует воспользоваться командой CLI wipefs, после этого устройство появится в списке. В случае устройств LUN, возможно, потребуется отключить и заново присоединить устройство.
Возможна ситуация, когда устройство отсутствует и в списке доступных для создания ZFS пулов, и в списке доступных для очистки. В этом случае вероятнее всего оно сохранилось в кэше ZFS, а сам пул уже не существует или не активен. Чтобы выяснить это, следует воспользоваться командой zdb. Если в полях "path" вывода команды есть нужные нам устройства, а ZFS пул, указанный в поле "name" вывода и к которому относятся данные устройства, отсутствует на узле, то мы можем убрать этот пул из кэша командой zpool destroy <pool_name>. После этого нужные нам устройства можно будет очистить командой CLI wipefs и использовать далее.
Операции
Управление работой ZFS-хранилища происходит в окне состояния, которое открывается при нажатии на название хранилища. Логика управления ZFS соответствует управлению работой RAID-контроллера. В окне состояния ZFS-хранилища доступны следующие операции:
- 
расширение (добавление блочных устройств верхнего уровня). Операция Расширить доступна для ZFS с типом пула stripe. Операция «приклеивает» дополнительные устройства к имеющемуся хранилищу. При нажатии кнопки Расширить в открывшемся окне необходимо выбрать из раскрывающегося списка НЖМД сервера (local_devices) или подключенные к серверу сетевые блочные устройства (lun_devices), после чего подтвердить операцию, нажав кнопку ОК; 
Примечание
Добавлять можно только по одному устройству. Один из списков или оба могут быть пустыми, если нет доступных устройств.
- 
монтирование блочного устройства. Операция Примонтировать доступна для ZFS с типами пула stripe и mirror, в составе которого только один диск. Операция преобразует хранилище в тип mirror. При нажатии кнопки Примонтировать в открывшемся окне необходимо выбрать из раскрывающегося списка тип блочного устройства и присоединяемое устройство (НЖМД или LUN), после чего подтвердить операцию, нажав кнопку ОК; 
- 
добавление устройства горячей замены. Операция Добавить устройство горячей замены позволяет отметить неиспользуемое системой устройство как hot-swap для данного хранилища. При нажатии кнопки Добавить устройство горячей замены в открывшемся окне необходимо выбрать из раскрывающегося списка НЖМД сервера (local_devices) или подключенные к серверу сетевые блочные устройства (lun_devices), после чего подтвердить операцию, нажав кнопку ОК; 
- 
добавление устройства кэширования. Операция Добавить устройства кэширования позволяет добавить кэш для ZFS RAID-массива. При нажатии кнопки Добавить устройство кэширования в открывшемся окне необходимо выбрать из раскрывающегося списка НЖМД сервера (local_devices) или подключенные к серверу сетевые блочные устройства (lun_devices), после чего подтвердить операцию, нажав кнопку ОК; 
- 
сброс ошибок в пуле. При нажатии кнопки Сброс ошибок в открывшемся окне необходимо подтвердить операцию, нажав кнопку Да; 
- 
проверка целостности данных (scrub). При нажатии кнопки Проверка целостности (scrub) в открывшемся окне необходимо подтвердить операцию, нажав на кнопку Да; 
- 
получение расширенных сведений; 
- 
удаление пула. Операция Удалить позволяет расформировать ZFS-хранилище. При нажатии кнопки Удалить в открывшемся окне необходимо подтвердить операцию, нажав кнопку Удалить. 
В окне состояния хранилища содержатся сведения, разделенные на следующие группы:
- 
Информация. 
- 
Пулы данных. 
- 
События. 
- 
Задачи. 
- 
Теги. 
В окне Хранилища – ZFS – <имя ZFS-пула> – Информация отображаются следующие сведения о ZFS-хранилище:
- 
название; 
- 
описание (редактируемый параметр); 
- 
сервер; 
- 
состояние; 
- 
общий размер; 
- 
свободное пространство; 
- 
дата и время создания; 
- 
дата и время изменения; 
- 
локальные устройства (раскрывающийся список). Каждое устройство содержит следующие сведения: - 
размер; 
- 
состояние; 
- 
кэширование; 
- 
устройство горячей замены. 
 Для каждого устройства доступны операции: - 
включение (выключение). При нажатии кнопки Вкл/выкл устройство открывается окно, в котором необходимо подтвердить операцию, нажав кнопку Да; 
- 
замена устройства. При нажатии кнопки Замена устройства открывается окно, в котором необходимо выбрать local_device, после чего подтвердить операцию, нажав кнопку ОК; 
- 
демонтирование устройства. При нажатии кнопки Демонтирование устройства открывается окно, в котором необходимо подтвердить операцию, нажав кнопку Да. Удаление диска из состава ZFS возможно только для хранилища, в составе которого два или более дисков. Если в составе ZFS с типом mirror останется только один диск, то он преобразуется в тип stripe; 
 
- 
- 
устройства LUN (раскрывающийся список); 
- 
дополнительные характеристики (раскрывающийся список): - включение или отключение автозамены; - точка монтирования; - сдвиг (ashift).
Пулы данных
В окне Хранилища – ZFS – <имя ZFS-пула> – Пулы данных отображаются созданные в хранилище пулы данных в табличном виде, включая для каждого из них его название, тип, количество серверов, виртуальных дисков, образов и файлов, использованный объем и статус. При нажатии на название пула открывается окно состояния, в котором доступны следующие операции:
- 
извлечение пула. При нажатии кнопки Извлечь в открывшемся окне необходимо подтвердить операцию, нажав кнопку ОК; 
- 
очистка пула. При нажатии кнопки Очистить в открывшемся окне следует определить необходимость принудительной очистки, после чего подтвердить операцию, нажав кнопку ОК; 
- 
удаление диска (если допускается). При нажатии кнопки Удалить необходимо подтвердить операцию, нажав на кнопку Удалить. 
Информация
В окне Хранилища – ZFS – <имя ZFS-пула> – Пулы данных – <имя пула данных> – Информация содержатся следующие сведения о пуле данных:
ARC-кэш
При создании ZFS-пулов необходимо учитывать адаптивное использование памяти сервера под ARC-кэш.
Пример использования памяти сервера подсистемой ZFS до и после сброса кэша (видно изменение ARC size (current)):

Одним из основных моментов, о котором необходимо помнить при использовании ZFS на гипервизоре, является тот факт, что balloon ВМ, использующийся для оптимизации выделения и возвращения неиспользуемой памяти, некорректно работает вместе с динамическим ARC. Поэтому хорошим тоном будет выделение фиксированной памяти для ВМ: balloon=0 и указания максимального размера ARC, таким образом, чтобы суммарная утилизация памяти для машин и кэша была меньше общего количества RAM на 2 Гбайта.
Минимальный размер ARC для более комфортной работы ФС без активного режима записи/перезаписи в файлы ВМ (например, этим грешат базы данных), примерно равен 1 Гбайт на хост + 1 Гбайт на 1 Тбайт, но фактически при кэше меньше 3 Гбайт могут возникнуть проблемы с "отвалом" хранилища, и для работы с активной перезаписью лучше использовать формулу 1 Гбайт + 4-5 Гбайт на 1 Тбайт без дедупликации, 5-6 Гбайт - с дедупликацией. Разово задать максимальный размер кэша до перезагрузки можно командой:
echo $[ N*1048576*1024 ] > /sys/module/zfs/parameters/zfs_arc_max
Параметр zfs_arc_max не может быть ниже текущего минимального размера кэша (zfs_arc_min), который можно посмотреть в выводе команды arc_summary в строке Min size (hard limit). Чтобы указать zfs_arc_max ниже данного значения, следует сперва таким же образом задать параметр zfs_arc_min. Важно помнить, что эти параметры не могут быть менее 64 Мбайт, а также больше объёма ОЗУ на узле. В противном случае эаданные значения параметров будут проигнорированы.
Пример временного изменения максимального размера кэша до перезагрузки (видно изменение Max size (high water)):

3гб: 3221225472
6гб: 6442450944
10гб: 10737418240
15гб: 16106127360
echo options zfs zfs_arc_max=16106127360>> /etc/modprobe.d/zfs.conf
update-initramfs -u
- 
l2arc - на чтение - он собирает используемые в данный момент обращения и передает их через себя, что ускоряет запросы чтения к файловой системе хранилища. Минимальный размер l2arc примерно рассчитывается по формуле 2000 байт ARC на 1 блок l2arc, размер которого зависит от ashift ZFS-пула. Т.е. чем больше ashift, тем больше должен быть l2arc, но "раздувать" его за пределы 500 байт на 1 блок данных пула смысла нет - нельзя отдавать весь ARC под нужды l2arc, т.к. при максимальной загрузке вместо оперативной памяти вы будете работать с вашим устройством кэширования. 
- 
zil (slog) - кэширование записи. Каждая операция записи на пул будет считаться совершённой при попадании в zil, а на устройства хранения будет попадать уже т.н."дельта" всех операций с минимальным количеством "грязных данных". Минимальный размер zil устройства рассчитывается примерно из скорости работы вашего устройства, где будет размещён лог, и времени задержки записи "грязных данных" * 2. Максимальный размер для конкретной системы нужно определять индивидуально, но на практике размер больше, чем скорость устройства * 10 с, имеет смысл только в узкоспециализированных, направленных на постоянное краткосрочное изменение данных с минимальной задержкой. 
Пример размеров разделов кэширования и логов:
zil:
приблизительная скорость записи на устройство:
[root@04bdd07c-5b93-40b3-9b52-148993161241 ~]#sync; dd if=/dev/urandom of=tempfile bs=1M count=1024; sync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 6.10459 s, 176 MB/s
[root@04bdd07c-5b93-40b3-9b52-148993161241 ~]#sync; dd if=/dev/urandom of=tempfile bs=1M count=1024; sync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 6.31901 s, 170 MB/s
[root@04bdd07c-5b93-40b3-9b52-148993161241 ~]#sync; dd if=/dev/urandom of=tempfile bs=1M count=1024; sync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.0737 s, 152 MB/s
[root@04bdd07c-5b93-40b3-9b52-148993161241 ~]#sync; dd if=/dev/urandom of=tempfile bs=1M count=1024; sync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.9285 s, 181 MB/s  
Примерно 170 Mбайт/с, следовательно, раздел свыше 1700 Мбайт (1.7 Гбайт) будет по сути бесполезным для данной системы. Округляем до 2 Гбайт для ровного счёта и получаем необходимый размер раздела под zil. Если переопределить время сброса данных на диск, то можно раздувать этот раздел больше, но фактического смысла в этом нет.
С l2arc нужно посчитать немного больше:
например, размер zfs_arc_max определён в 10 Гбайт.
Смотрим ashift раздела:
zpool get all "ваш_пул_zfs" | grep ashift`
ashift это размер логического блока ZFS, равный степени двойки. T.е. ashift13=2^13=8192 байт - размер сектора ZFS.
Оставляем ¾ ARC свободной при максимальной загрузке (можно использовать без особых потерь до ⅔ ARC, но для 
невысоконагруженных на чтение систем ¼ более чем достаточно), помня что в ARC 1 блок занимает примерно 400 байт, 
берём 512 для упрощения чисел и рассчитываем размер, при котором l2arc максимально занял бы примерно ¼ основного кэша):
10737418240/4=2684354560/512=5242880 - количество возможных блоков в l2arc.
Далее 5242880*8192=42949672960/1024=41943040/1024=40960/1024=40 Гбайт.
Итого при ashift13 и 10 Гбайт ARC размер l2arc может варьироваться от 40 до 100 Гбайт. 
Больший размер или не даст улучшения скорости работы хранилища, или будет даже уменьшать её.
Импорт ZFS-пулов
- Получение имен и параметров импортируемых ZFS-пулов
zpool import
- Импорт в систему ZFS-пулов
zpool import -C <pool_name> -- импорт из файла кэша, если пул там прописан
zpool import -d /dev/disk/by-id <pool_name> -- при проблемах с файлом кэша или если запись о ZFS-пуле из кэша пропала (например, если ZFS-пул не импортировался ввиду отсутствия дисков на этапе загрузки, а потом с исправными пулами проводились какие-либо манипуляции, не импортированные ZFS-пулы "забываются" кэшем).
Внимание
Важно указать каталог /dev/disk/by-id, так как в противном случае возможен импорт ZFS-пула с "короткими" именами устройств, например, /dev/sdc. Это может привести при последующей перезагрузке к пропаданию устройства из ZFS-пула, так как такие короткие имена назначаются устройствам лишь на основе порядка их определения, что может меняться от загрузки к загрузке, и одно и то же устройство может получать различные короткие имена.
- Проверка появления в системе
zpool list
- Чтобы он сохранился после перезагрузки, нужно пересоздать кэш с указанием этого ZFS-пула.
zpool set cachefile=/etc/zfs/zpool.cache <pool_name>
Загрузка системы с неполным набором устройств (дисков, LUN), входящих в ZFS-пулы
Если ZFS-пул, в котором недостаёт устройств, обладает достаточной избыточностью, чтобы компенсировать их отсутствие (для типа mirror должно остаться хотя бы одно устройство, для типа raidz1 возможно остаться без одного, для raidz2 -- без двух устройств, устройства горячего резерва и кэша чтения на работоспособность не влияют), то такой ZFS-пул импортируется при старте системы обычным образом. В противном случае этот ZFS-пул не импортируется. Если есть техническая возможность вернуть в систему недостающие устройства под теми же именами, то после их возврата  пострадавший ZFS-пул будет импортирован автоматически при перезагрузке узла, либо "на лету" через CLI -- после проверки возможности импорта ZFS-пула командой zpool import или zpool import -d /dev/disk/by-id, см. пункт выше "Импорт в систему ZFS-пулов". Для проверки состояния кэша используют команду CLI zdb. Она отображает запомненные в кэше ZFS-пулы, входящие в них устройства, их типы, а также некоторую дополнительную информацию. 
Внимание
Чтобы ZFS-пул был автоматически импортирован при старте системы, он должен быть прописан в кэше /etc/zfs/zpool.cache. Записи о ZFS-пулах там появляются при их создании, также они модифицируются при манипуляциях с ZFS-пулами. Если какой-то ZFS-пул не импортирован из-за повреждений, т.е. не виден в системе, то в момент модификации кэша (изменений имеющихся или создания новых ZFS-пулов) записи о нём УДАЛЯЮТСЯ из кэша, и при следующей перезагрузке данный ZFS-пул не будет импортирован автоматически. Это следует учитывать, и если есть необходимость и возможность вернуть данный ZFS-пул в работу, и в то же время проводить какие-то действия над имеющимися ZFS-пулами узла, то нужно обеспечить работоспособность повреждённого ZFS-пула и импортировать его вручную до перезагрузки системы, либо импортировать его вручную после перезагрузки. Первый вариант предпочтительней, особенно если ZFS-пул участвует, например, в кластерном хранилище.  
Также может быть полезна информация из меток устройств, входивших в ZFS-пул -- zdb -l <device>. Будет показано, принадлежит ли устройство ZFS-пулу, какому именно, какой GUID у этого устройства и на каком хосте создан данный ZFS-пул.   
Пример:
Информация из кэша о некотором ZFS-пуле:
Команда zdb
# zdb
zfs_115:
    version: 5000
    name: 'zfs_115'
    state: 0
    txg: 4
    pool_guid: 879109887279304795
    errata: 0
    hostid: 4212788997
    hostname: 'f96b4837-a7e3-43a1-ab52-37bdc4677b82'
    com.delphix:has_per_vdev_zaps
    vdev_children: 1
    vdev_tree:
        type: 'root'
        id: 0
        guid: 879109887279304795
        create_txg: 4
        children[0]:
            type: 'disk'
            id: 0
            guid: 15989658986416599112
            path: '/dev/disk/by-id/scsi-SATA_ST1000NX0313_S470HK28-part1'
            devid: 'ata-ST1000NX0313_S470HK28-part1'
            phys_path: 'pci-0000:00:1f.2-ata-1.0'
            whole_disk: 1
            metaslab_array: 256
            metaslab_shift: 33
            ashift: 13
            asize: 1000189984768
            is_log: 0
            create_txg: 4
            com.delphix:vdev_zap_leaf: 129
            com.delphix:vdev_zap_top: 130
    features_for_read:
        com.delphix:hole_birth
        com.delphix:embedded_data
Здесь мы видим, что ZFS-пул имеет имя name: 'zfs_115', GUID pool_guid: 879109887279304795, содержит одно устройство /dev/disk/by-id/scsi-SATA_ST1000NX0313_S470HK28-part1 с GUID в пределах ZFS-пула  guid: 15989658986416599112. Пул принадлежит хосту hostname: 'f96b4837-a7e3-43a1-ab52-37bdc4677b82'.
Просмотрим информацию из метки этого устройства:
zdb -l /dev/disk/by-id/scsi-SATA_ST1000NX0313_S470HK28-part1
------------------------------------
LABEL 0
------------------------------------
    version: 5000
    name: 'zfs_115'
    state: 0
    txg: 2321441
    pool_guid: 879109887279304795
    errata: 0
    hostid: 4212788997
    hostname: 'f96b4837-a7e3-43a1-ab52-37bdc4677b82'
    top_guid: 15989658986416599112
    guid: 15989658986416599112
    vdev_children: 1
    vdev_tree:
        type: 'disk'
        id: 0
        guid: 15989658986416599112
        path: '/dev/disk/by-id/scsi-SATA_ST1000NX0313_S470HK28-part1'
        devid: 'ata-ST1000NX0313_S470HK28-part1'
        phys_path: 'pci-0000:00:1f.2-ata-1.0'
        whole_disk: 1
        metaslab_array: 256
        metaslab_shift: 33
        ashift: 13
        asize: 1000189984768
        is_log: 0
        DTL: 50892
        create_txg: 4
    features_for_read:
        com.delphix:hole_birth
        com.delphix:embedded_data
    labels = 0 1 2 3 
Видим, что устройство принадлежит ZFS-пулу с именем name: 'zfs_115', GUID пула pool_guid: 879109887279304795, а само устройство имеет GUID в ZFS-пуле guid: 15989658986416599112. Имя хоста hostname: 'f96b4837-a7e3-43a1-ab52-37bdc4677b82'.

