Re: Стратегия поддержания резервных копий. Деградация носителей.
*** Tim Sattarov <stimur@gmail.com> [2017-06-25 07:21]:
>Параллельный вопрос - умеет ли оно кэшировать на более быстрые
>устройства (типа основные данные на HDD, а кэш на SSD) ?
>как те же bcache или dm-cache ?
Да, умеет. Называется это L2ARC (layer 2 adaptive replacement cache).
Абсолютно (ну с точки зрения пользователя) аналогично flashcache в Linux.
У меня один знакомый который это применил -- IOPS-ы зашкалили. В
блогпостах людей тоже видел что помогает отлично. Делается, примерно,
очень просто: zpool add mypool cache sdc (добавить sdc диск как кэш к
mypool). Если добавить несколько, то будут в stripe-е. По сути это
просто вынос части ARC (кэша ZFS) на диск.
Кстати, если памяти для дедупликации не хватает, то именно L2ARC может
вы этом помочь: дедупликационные данные будут хранится на этом носителе.
Хотя, конечно же, и существенно медленнее (RAM vs SSD).
Если в системе есть большая активность на запись с fsync-ом, которая
заставляет сразу же записывать ZIL (участок памяти где агрегируются все
записи) на диск, то существенно можно увеличить производительность
добавив выделенный диск для intent log-а, так называемого. Само собой
это должен быть SSD, если основные диски HDD. Тогда ZIL пишется на этот
SSD и каждые 1-5 секунд checkpoint делается уже с него. Это должно
помогать хорошо или почтовым серверам (Postfix любит fsync) или СУБД.
>сомневаюсь в необходимости, но почему бы и нет...
По факту я нигде не слышал чтобы кто-то сказал что это стоит отключить
или не имеет смысл :-). То есть, хотя бы несколько процентов уменьшения
потребления пространства было бы приятно получить. Безусловно зависит от
типа данных. Если это раздел с кучей .tar.xz-ов, то там конечно не имеет
смысла, но LZ4 устроен так, что он быстро понимает что данные несжимаемы
и поэтому запишет их, как есть, без дополнительного overhead-а.
>А инкремент от `0' или от другого инкремента ?
От другого/предыдущего snapshot-а. Тут вопрос в том как вы это будете
восстанавливать. Если сделать так:
# zfs snap mypool@backup-20170101
# zfs send mypool@backup-20170101 > backup-20170101.zfs
# zfs snap mypool@backup-20170102
# zfs snap -i backup-20170101 mypool@backup-20170102 > backup-20170102.zfs
# zfs snap mypool@backup-20170103
# zfs snap -i backup-20170102 mypool@backup-20170103 > backup-20170103.zfs
то, backup-20170103.zfs это инкремент от инкрмента. Но никто не мешает
при его создании указать -i backup-20170101 чтобы получить инкремент от
самого первого (0). Восстанавливать это нужно в соответствующем порядке:
# zfs recv mypool < backup-20170101.zfs
# zfs recv mypool < backup-20170102.zfs
# zfs recv mypool < backup-20170103.zfs
>> Кроме того, масса мелочей из серии:
>>
>> * включить/отключить atime -- zfs set atime=... mypool/fs, включить
>> отключить sync или перевести в режим бОльшего кэширования -- опять же,
>> один zfs set. Никаких редактирований fstab и перемонтирований.
>
>ну можно и перемонтировать на лету
>mount -oremount,noatime /
>а редактирование fstab даёт уверенность в однозначности конфигурации и
>что никакой умник втихую не поменяет настройки
Я понимаю что можно перемонтировать, понимаю что сделать dd+losetup. В
ZFS даже подключение разделов делается не из серии mount -t zfs
/dev/sda, а просто zpool import mypool -- он просканирует все блочные
устройства в /dev и по метаинформации на них поймёт кто тут mypool,
какие устройства к нему относятся (чтобы массив воссоздать, кэш
устройства добавить, hotspare, итд). Оно менее UNIX-way-но. Но всё-равно
приятно работать не задумываясь об этих мелочах. Меня они конечно не
напрягали никогда, но всё же.
fstab в ZFS вам не придётся редактировать *совсем* вся конфигурация, все
настройки (atime, sync даже) хранятся в самом ZFS в виде zfs set/get
аттрибутов.
Если вам хочется разрешить какому-то пользователю делать snapshot-ы и их
дампить на своей домашней директории, но больше ничего, то в ZFS есть
система прав:
# zfs allow vpupkin snapshot,send mypool/home/vpupkin
Любые изменения в ФС сделанные через zfs set, allow и тому прочее:
журналируются на диске.
>не хочу звучать параноиком, но что-то как-то многовато для ФС, автор не
>Поттеринг случаем ? (здесь картинка тролля)
Я абсолютно прекрасно вас понимаю! ZFS действительно штука которая
совсем не UNIX-way и... я бы впервые тоже покривил лицом услывал про
такой комбайн. Сам я Поттеринга, мягко говоря, не перевариваю и если
есть что-то к чему он притронулся, то 100% использовать не буду. Но ZFS
всё же вынуждена так много всего заменить (mdadm+LVM+ФС) потому-что это
решает вот 100500 проблем которые могут быть решены только если
низлежащие уровни работающие с дисками будут осведомлены о данных
находящихся на самом верху (ФС). По другому просто никак. Ну и всякие
штуки типа NFS, iSCSI, SMB заключаются просто в том что демону mountd,
например, передаётся не только /etc/exports, но и /etc/zfs/exports файл,
в который при zfs set sharenfs="..." просто добавляется строчка "..." с
нужным путём и посылается сигнал mountd демону. Поттеринг бы написал
свой mountd, чтобы по dbus оповещался, а тут просто, грубо говоря,
встроен небольшой набор shell-скриптов для удобства для интеграции с
*уже* имеющимися демонами.
>А как оно с шифрованием ?
Solaris умеет. Я видел выступление на какой-то конференции мужика
который его туда и впиливал и он объяснял устройство. Я, как человек
очень заинтересованный темой криптографии -- одобряю всё что они там
наделали. Грамотно.
https://www.youtube.com/watch?v=frnLiXclAMo
>мне если делать такие тома то часто нужны временные шифрованные диски.
Но вот в OpenZFS, а это всё, что вне Solaris, шифрование не впилили.
Поэтому я его на практике не трогал. В итоге я делаю шифрованное блочное
устройство (LUKS, GELI) и поверх него уже ZFS.
Родная поддержка шифрования в ZFS лучше тем, что можно делать zfs
scrub/resilver/send/recv (проверять целостность, работать с массивами,
бэкапить и восстанавливать) без загрузки ключей шифрования. Если бэкап
отправляется в небезопасное (с точки зрения конфиденциальности место),
то zfs send от зашифрованного ZFS означает отправку зашифрованных данных
и не потребуется какой-нибудь | gpg -e > ....zfs.gpg. Автоматом
шифруются не только данные/метаданные, но и L2ARC кэши и выделенные
диски для ZIL-а. Всё это можно сделать и руками поверх LUKS, но просто
более сложное управление и отслеживание всего этого. Мол явно руками
придётся прописать сначала подключение зашифрованных разделом, а уж
потом zpool import. Судя по слайдам презентации, включение шифрования
выглядит так:
# zpool create -o encryption=<enc> -o keysource=<ks>
# zfs key -l <dataset> # load key into zfs for use
# zfs key -u <dataset> # unload key from the system
# zfs key -c <dataset> # change user's key
собственно аналогично geli init, geli attach, geli detach (ну и
аналогичным командам LUKS). Причём, мне как любителю парольных фраз
очень нравится что они из коробки дают возможность их использовать, с
PBKDF2 (не айс, но хотя бы так) усилением.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Reply to: