Re: Снова о ZFS
*** Sergey Matveev [2018-01-16 00:15]: >https://blogs.oracle.com/darren/zfs-encryption-what-is-on-disk >Не знаю поменялось ли это в ZFS-е, но там говорят что L2ARC недоступен >для использования зашифрованным dataset-ам. Статья устарела. В https://youtu.be/frnLiXclAMo где точно актуальный разработчик они L2ARC уже шифруют. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
18.01.2018 22:02, Sergey Matveev пишет: > *** artiom [2018-01-18 21:53]: >> А что там за проблема с тем, что зеркало будет обеспечивать GEOM, была? > > Ну как минимум зачем это делать когда ZFS это тоже может? Во-первых, > меньше на одну прослойку из gmirror (или что там). Во-вторых, ZFS сам > это всё будет подхватывать. В-третьих, resilvering зеркала в ZFS, если > оно не сильно забито, существенно быстрее происходит чем обычного > RAID-а. Обычный RAID понятия не имеет какие данные актуальны на каком > диске -- он по сути делает последовательное полное чтение с одного диска > и запись на другой. А ZFS, увидев что диск был частью зеркала, найдёт > его последние актуальные данные и ссинхронизирует только diff. Если диск > не был в зеркале, то зальёт на него только полезную нагрузку > (терабайтный pool заполнен на 50 гигабайт? только эти 50 GB и будут > записаны на зеркало). В-четвёртых, если данные испортились на каком-либо > из дисков (ну ошибки, сыпется что-то), то из-за контрольных сумм точно > известно где данные корректные и он их восстановит на втором > (self-healing типа). > Стойте, вопрос-то в другом был. С пулом всё и так ясно (кроме шифрования). Вопрос был про служебные и системные носители. Короче, позже проработаю схему и опишу. Как-то непросто получается.
Re: Снова о ZFS
*** artiom [2018-01-18 21:53]: >А что там за проблема с тем, что зеркало будет обеспечивать GEOM, была? Ну как минимум зачем это делать когда ZFS это тоже может? Во-первых, меньше на одну прослойку из gmirror (или что там). Во-вторых, ZFS сам это всё будет подхватывать. В-третьих, resilvering зеркала в ZFS, если оно не сильно забито, существенно быстрее происходит чем обычного RAID-а. Обычный RAID понятия не имеет какие данные актуальны на каком диске -- он по сути делает последовательное полное чтение с одного диска и запись на другой. А ZFS, увидев что диск был частью зеркала, найдёт его последние актуальные данные и ссинхронизирует только diff. Если диск не был в зеркале, то зальёт на него только полезную нагрузку (терабайтный pool заполнен на 50 гигабайт? только эти 50 GB и будут записаны на зеркало). В-четвёртых, если данные испортились на каком-либо из дисков (ну ошибки, сыпется что-то), то из-за контрольных сумм точно известно где данные корректные и он их восстановит на втором (self-healing типа). -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
Хотя, вроде не так всё плохо. Взял две SSD на 256 ГБ (меньше не было): - Samsung 850 PRO (http://www.samsung.com/semiconductor/minisite/ssd/product/consumer/850pro/) - Micron MTFDDAK256TBN-1AR1ZABYY (https://market.yandex.ru/product--micron-mtfddak256tbn-1ar1zabyy/1721921626) Micron - TLC 3D, Samsung Pro - некий 3D V-NAND (хотя, есть подозрение, что это тоже самое). Ну и под L2ARC остаётся Samsung Evo. Сильно плохо? 16.01.2018 14:43, Dmitry Kulagin пишет: > >>> Это, кстати, очень странное замечание, я думал, что мы уже давно живем >>> во времена SATA-3 и всеобщей поддержки "WRITE BARRIERS" (ну за >>> исключением счетного числа сломанных дисков), так что энергонезависимый >>> кеш на запись для программного рейда давно не нужен... >>> >> Так здесь не про рэйд, как таковой, а про SSD пользовательского сегмента. >> > Так и я говорю про диски вообще, сейчас в любом накопителе хоть ССД > хоть НЖМД есть кешь память и она, что характерно, работает в режиме кеш на > запись по умолчанию, в режим только кеш на чтение она может переводиться > только > в аппаратных рейд контроллерах, потому как остальным ОС это не надо, > они пользуются командами сброса кеша в энергонезависимую память > для коммита транзакций. Кстати, поэтому не стоит покупать TLC SSD > диски для ZIL, на них этот коммит относительно долгий, а запись ZIL - > это непрерывный коммит, и кеш в такой ситуации не в состоянии > что-либо ускорить. А потери данных при перебое питания, которые > обсуждаются по ссылке будут всегда, вопрос только в том, что при > неадекватной > поддержке "WRITE BARRIERS" в firmware накопителей, Вам после каждого > перебоя > питания придется делать проверку файловой системы. > И фича сброса кеш памяти она, насколько я помню, не фича пользовательского > и корпоративного, или ССД и НЖМД сегмента, - это часть спецификации SATA-2 > (ну и SATA-3 и SAS, который вроде это изначально поддерживал еще со > времен SCSI) > и ее должны поддерживать все продающиеся сейчас накопители. > Насчет NVMe SSD не уверен, но думаю там должен быть аналог... >
Re: Снова о ZFS
> >>> Это, кстати, очень странное замечание, я думал, что мы уже давно живем >>> во времена SATA-3 и всеобщей поддержки "WRITE BARRIERS" (ну за >>> исключением счетного числа сломанных дисков), так что энергонезависимый >>> кеш на запись для программного рейда давно не нужен... >>> >> Так здесь не про рэйд, как таковой, а про SSD пользовательского сегмента. >> > Так и я говорю про диски вообще, сейчас в любом накопителе хоть ССД > хоть НЖМД есть кешь память и она, что характерно, работает в режиме кеш на > запись по умолчанию, в режим только кеш на чтение она может переводиться > только > в аппаратных рейд контроллерах, потому как остальным ОС это не надо, > они пользуются командами сброса кеша в энергонезависимую память > для коммита транзакций. Кстати, поэтому не стоит покупать TLC SSD > диски для ZIL, на них этот коммит относительно долгий, а запись ZIL - > это непрерывный коммит, и кеш в такой ситуации не в состоянии > что-либо ускорить. Блин, я похоже, херню сделал: спрашивал сегодня SLC/TLC вместо MLC (почему-то из этого коммента всё наоборот запомнилось).
Re: Снова о ZFS
16.01.2018 11:25, Sergey Matveev пишет: > *** artiom [2018-01-16 08:37]: >> - Либо я использую ZFS шифрование и теряю L2ARC (т.е. часть >> производительности). >> - Либо я использую Gely, усложняю систему и теряю часть возможностей и >> производительности ZFS. > > Ну насчёт заметной потери (чтобы об этом можно было думать) > производительности не уверен, ну а так да -- всё верно. > >> - Докупаю 2x100 Гб (достаточно 50 Гб или не стоит жадничать?) в зеркало. >> - На них делаю два раздела поверх gely: OS и ZIL. >> - SSD на 250 Гб отвожу под L2ARC (корзина на 2.5" забита, там три диска >> всего). >> - На SAS делаю Gely слой (предполагается, что все диско-специфичные >> ioctl будут проброшены вниз, но так ли это?). >> - Организую из 4-х SAS ZRAID1 (достаточно ли 1, а не 2?). > > Раз ZIL в зеркале, то вопрос надёжности снят. > > По поводу ioctl ничего не могу сказать, не задавался этим вопросом. > > RAIDZ какого уровня это tradeoff между кол-ом дисков сколько могут > вылететь, IOPS-ами, потерянным местом -- можно и 1, можно и 2. В > домашних условиях сервер же будет под "присмотром" -- поэтому вылет > диска будет обнаружен во вменяемое время и заменён для resilver-а. > > Не забыть что и ZIL и L2ARC разделы тоже надо поверх GELI сделать. Я > кстати L2ARC делаю поверх раздела зашифрованного одноразовым ключом > (geli onetime gpt/SSDCACHE ; zpool add storage cache gpt/SSDCACHE.eli): > после перезагрузки он конечно всё "потеряет", но зато ключи нигде не > надо хранить и загружать. > А что там за проблема с тем, что зеркало будет обеспечивать GEOM, была?
Re: Снова о ZFS
*** artiom [2018-01-07 21:18]: >- Какой ZRAID лучше использовать: ZRAID2 или достаточно ZRAID? >- Имеет ли смысл использовать stripped mirror или это неоправданно >(максимум может быть 8 дисков в корзине, но пока будет 4)? В книге https://www.michaelwlucas.com/os/fmzfs есть хорошие таблицы по которым можно грубо прикинуть что даёт какой RAID/mirror/stripe и при каком количестве дисков. Демонстрируются характеристики одного диска, а потом из подобных собирают pool-ы: +---+ |Disks|Config| ReadIOPS | WriteIOPS | ReadMB/s | WriteMB/s | Usable Space | Fault Tolerance | |-+--+--+---+--+---+--+-| |1|Stripe| 250 | 250 | 100 | 100 | 1 TB (100%) | none| +---+ +---+ |Disks|Config |ReadIOPS|WriteIOPS|ReadMB/s|WriteMB/s|Usable Space|Fault Tolerance | |-+-++-++-++| |2|2 x Stripe |500 |500 |200 |200 |2 TB (100%) |none| |-+-++-++-++| |2|1 x 2 disk Mirror|500 |250 |200 |100 |1 TB (50%) |1 | +---+ +---+ |Disks|Config|ReadIOPS|WriteIOPS|ReadMB/s|WriteMB/s|Usable Space|Fault Tolerance| |-+--++-++-++---| |3|1 x 3 disk Mirror |750 |250 |300 |100 |1 TB (33%) |2 | |-+--++-++-++---| |3|1 x 3 disk RAID-Z1|250 |250 |200 |200 |2 TB (66%) |1 | +---+ +---+ |Disks|Config|ReadIOPS|WriteIOPS|ReadMB/s|WriteMB/s|Usable Space|Fault Tolerance| |-+--++-++-++---| |4|2 x 2 disk Mirror |1000|500 |400 |200 |2 TB (50%) |2 (1/VDEV) | |-+--++-++-++---| |4|1 x 4 disk RAID-Z1|250 |250 |300 |300 |3 TB (75%) |1 | |-+--++-++-++---| |4|1 x 4 disk RAID-Z2|250 |250 |200 |200 |2 TB (50%) |2 | |-+--++-++-++---| |5|1 x 5 disk RAID-Z1|250 |250 |400 |400 |4 TB (80%) |1 | |-+--++-++-++---| |5|1 x 5 disk RAID-Z2|250 |250 |300 |300 |3 TB (60%) |2 | |-+--++-++-++---| |5|1 x 5 disk RAID-Z3|250 |250 |200 |200 |2 TB (40%) |3 | +---+ ++ |Disks|Config |ReadIOPS|WriteIOPS|ReadMB/s|WriteMB/s|Usable Space|Fault Tolerance| |-+---++-++-++---| |6|3 x 2 disk Mirror |1500|750 |600 |300 |3 TB (50%) |3 (1/VDEV) | |-+---++-++-++---| |6|2 x 3 disk Mirror |1500|500 |600 |200 |2 TB (33%) |4 (2/VDEV) | |-+---++-++-++---| |6|1 x 6 disk RAID-Z1 |250 |250 |500 |500 |5 TB (83%) |1 | |-+---++-++-++---| |6|1 x 6 disk RAID-Z2 |250 |250 |400 |400 |4 TB (66%) |2 | |-+---++-++-++---| |6|1 x 6 disk RAID-Z3 |250 |250 |300 |300 |3 TB (50%) |3 | |-+---++-++-++---| |12 |6 x 2 disk Mirror |3000|1500 |1200|600 |6 TB
Re: Снова о ZFS
16.01.2018 14:43, Dmitry Kulagin пишет: > >>> Это, кстати, очень странное замечание, я думал, что мы уже давно живем >>> во времена SATA-3 и всеобщей поддержки "WRITE BARRIERS" (ну за >>> исключением счетного числа сломанных дисков), так что энергонезависимый >>> кеш на запись для программного рейда давно не нужен... >>> >> Так здесь не про рэйд, как таковой, а про SSD пользовательского сегмента. >> > Так и я говорю про диски вообще, сейчас в любом накопителе хоть ССД > хоть НЖМД есть кешь память и она, что характерно, работает в режиме кеш на > запись по умолчанию, в режим только кеш на чтение она может переводиться > только > в аппаратных рейд контроллерах, потому как остальным ОС это не надо, > они пользуются командами сброса кеша в энергонезависимую память > для коммита транзакций. Кстати, поэтому не стоит покупать TLC SSD > диски для ZIL, на них этот коммит относительно долгий, а запись ZIL - > это непрерывный коммит, и кеш в такой ситуации не в состоянии > что-либо ускорить. А потери данных при перебое питания, которые > обсуждаются по ссылке будут всегда, вопрос только в том, что при > неадекватной > поддержке "WRITE BARRIERS" в firmware накопителей, Вам после каждого > перебоя > питания придется делать проверку файловой системы. > И фича сброса кеш памяти она, насколько я помню, не фича пользовательского > и корпоративного, или ССД и НЖМД сегмента, - это часть спецификации SATA-2 > (ну и SATA-3 и SAS, который вроде это изначально поддерживал еще со > времен SCSI) > и ее должны поддерживать все продающиеся сейчас накопители. > Насчет NVMe SSD не уверен, но думаю там должен быть аналог... > SSD у меня не SAS, а SATA (SAS только диски). Но, в общем, понятно. Не должно быть проблем.
Re: Снова о ZFS
Это, кстати, очень странное замечание, я думал, что мы уже давно живем во времена SATA-3 и всеобщей поддержки "WRITE BARRIERS" (ну за исключением счетного числа сломанных дисков), так что энергонезависимый кеш на запись для программного рейда давно не нужен... Так здесь не про рэйд, как таковой, а про SSD пользовательского сегмента. Так и я говорю про диски вообще, сейчас в любом накопителе хоть ССД хоть НЖМД есть кешь память и она, что характерно, работает в режиме кеш на запись по умолчанию, в режим только кеш на чтение она может переводиться только в аппаратных рейд контроллерах, потому как остальным ОС это не надо, они пользуются командами сброса кеша в энергонезависимую память для коммита транзакций. Кстати, поэтому не стоит покупать TLC SSD диски для ZIL, на них этот коммит относительно долгий, а запись ZIL - это непрерывный коммит, и кеш в такой ситуации не в состоянии что-либо ускорить. А потери данных при перебое питания, которые обсуждаются по ссылке будут всегда, вопрос только в том, что при неадекватной поддержке "WRITE BARRIERS" в firmware накопителей, Вам после каждого перебоя питания придется делать проверку файловой системы. И фича сброса кеш памяти она, насколько я помню, не фича пользовательского и корпоративного, или ССД и НЖМД сегмента, - это часть спецификации SATA-2 (ну и SATA-3 и SAS, который вроде это изначально поддерживал еще со времен SCSI) и ее должны поддерживать все продающиеся сейчас накопители. Насчет NVMe SSD не уверен, но думаю там должен быть аналог...
Re: Снова о ZFS
*** artiom [2018-01-16 08:37]: >- Либо я использую ZFS шифрование и теряю L2ARC (т.е. часть >производительности). >- Либо я использую Gely, усложняю систему и теряю часть возможностей и >производительности ZFS. Ну насчёт заметной потери (чтобы об этом можно было думать) производительности не уверен, ну а так да -- всё верно. >- Докупаю 2x100 Гб (достаточно 50 Гб или не стоит жадничать?) в зеркало. >- На них делаю два раздела поверх gely: OS и ZIL. >- SSD на 250 Гб отвожу под L2ARC (корзина на 2.5" забита, там три диска >всего). >- На SAS делаю Gely слой (предполагается, что все диско-специфичные >ioctl будут проброшены вниз, но так ли это?). >- Организую из 4-х SAS ZRAID1 (достаточно ли 1, а не 2?). Раз ZIL в зеркале, то вопрос надёжности снят. По поводу ioctl ничего не могу сказать, не задавался этим вопросом. RAIDZ какого уровня это tradeoff между кол-ом дисков сколько могут вылететь, IOPS-ами, потерянным местом -- можно и 1, можно и 2. В домашних условиях сервер же будет под "присмотром" -- поэтому вылет диска будет обнаружен во вменяемое время и заменён для resilver-а. Не забыть что и ZIL и L2ARC разделы тоже надо поверх GELI сделать. Я кстати L2ARC делаю поверх раздела зашифрованного одноразовым ключом (geli onetime gpt/SSDCACHE ; zpool add storage cache gpt/SSDCACHE.eli): после перезагрузки он конечно всё "потеряет", но зато ключи нигде не надо хранить и загружать. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
16.01.2018 00:15, Sergey Matveev пишет: > Есть вот статья про ZFS шифрование: > https://blogs.oracle.com/darren/zfs-encryption-what-is-on-disk > Не знаю поменялось ли это в ZFS-е, но там говорят что L2ARC недоступен > для использования зашифрованным dataset-ам. ZIL точно шифруется. В общем > лично для себя я отмечаю что GELI/LUKS спокойнее как-то использовать, > без вот этих вот особенностей что L2ARC будет недоступен. > Не очень-то хорошая картина получается: - Либо я использую ZFS шифрование и теряю L2ARC (т.е. часть производительности). - Либо я использую Gely, усложняю систему и теряю часть возможностей и производительности ZFS. Следующий вариант компоновки тогда: - Докупаю 2x100 Гб (достаточно 50 Гб или не стоит жадничать?) в зеркало. - На них делаю два раздела поверх gely: OS и ZIL. - SSD на 250 Гб отвожу под L2ARC (корзина на 2.5" забита, там три диска всего). - На SAS делаю Gely слой (предполагается, что все диско-специфичные ioctl будут проброшены вниз, но так ли это?). - Организую из 4-х SAS ZRAID1 (достаточно ли 1, а не 2?).
Re: Снова о ZFS
16.01.2018 00:22, Sergey Matveev пишет: > *** artiom [2018-01-16 00:06]: >> Я смотрю с другой стороны: есть пространство на SSD. Оно либо будет не >> использовано, либо использовано под ZIL/L2ARC. Почему бы и нет? > > Согласен. Но лучше под кэш :-), лично по мне. Хуже не будет, а профит > очень даже можно получить. А выделенное место под ZIL на системе где > возможно вообще fsync-ов софт делать не будет -- полностью бесполезно. > > Ещё кстати L2ARC может использоваться для хранения таблиц дедупликации. > Она требует приличных объёмов памяти (зависит количества от того как всё > устроено, как данные лежат, но говорят про 5 гигабайт RAM/L2ARC нужно на > терабайт данных). Сам, правда, не пробовал никогда. > Дедап выключен.
Re: Снова о ZFS
*** artiom [2018-01-16 00:06]: >Я смотрю с другой стороны: есть пространство на SSD. Оно либо будет не >использовано, либо использовано под ZIL/L2ARC. Почему бы и нет? Согласен. Но лучше под кэш :-), лично по мне. Хуже не будет, а профит очень даже можно получить. А выделенное место под ZIL на системе где возможно вообще fsync-ов софт делать не будет -- полностью бесполезно. Ещё кстати L2ARC может использоваться для хранения таблиц дедупликации. Она требует приличных объёмов памяти (зависит количества от того как всё устроено, как данные лежат, но говорят про 5 гигабайт RAM/L2ARC нужно на терабайт данных). Сам, правда, не пробовал никогда. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
Есть вот статья про ZFS шифрование: https://blogs.oracle.com/darren/zfs-encryption-what-is-on-disk Не знаю поменялось ли это в ZFS-е, но там говорят что L2ARC недоступен для использования зашифрованным dataset-ам. ZIL точно шифруется. В общем лично для себя я отмечаю что GELI/LUKS спокойнее как-то использовать, без вот этих вот особенностей что L2ARC будет недоступен. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
> *** artiom [2018-01-15 23:25]: >> SSD на 250 Гб, чем ещё забить? Возможно, конечно, L2ARC организовать. Надо? > > Лично я бы точно не ZIL-ом бы его забивал и вряд ли бы вообще (если нет > нагруженного PostgreSQL или Postfix какого-нибудь) под него выделял > что-то. ZIL может быть абсолютно бесполезен и, как мне кажется, для > большинства он таков. А вот L2ARC почему бы и нет. > Я смотрю с другой стороны: есть пространство на SSD. Оно либо будет не использовано, либо использовано под ZIL/L2ARC. Почему бы и нет?
Re: Снова о ZFS
*** artiom [2018-01-15 23:25]: >SSD на 250 Гб, чем ещё забить? Возможно, конечно, L2ARC организовать. Надо? Лично я бы точно не ZIL-ом бы его забивал и вряд ли бы вообще (если нет нагруженного PostgreSQL или Postfix какого-нибудь) под него выделял что-то. ZIL может быть абсолютно бесполезен и, как мне кажется, для большинства он таков. А вот L2ARC почему бы и нет. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
15.01.2018 20:12, Dmitry Kulagin пишет: > Вообще-то размер ZIL рекомендуют порядка нескольких ГБ, зачем там 150 ГБ > - не очень понятно... > SSD на 250 Гб, чем ещё забить? Возможно, конечно, L2ARC организовать. Надо? > 13.01.2018 21:56, artiom пишет: >> >> 10.01.2018 18:25, Sergey Matveev пишет: >>> *** artiom [2018-01-10 18:18]: Если же установлена опция sync=disabled, произойдёт ошибка записи? >>> Если опция установлена, то не, ошибок не будет, но и fsync-а по факту не >>> будет происходить. >>> >> Т.е., приложение всё-равно запишет, не поняв что была ошибка и данных на >> диске нет? >> В чём тогда разница? >> >> Ещё вопрос: есть SSD размером 250 ГБ на который будет установлена >> система (или два SSD), и на которые будет вынесен ZIL. >> Хочу сделать два одинаковых GPT раздела на каждой из SSD. >> На раздел под систему отвести 100 ГБ, под ZIL 150 ГБ. >> Оба раздела будут шифроваться стандартным ZFS шифрованием. >> С первого раздела (миррора) должна грузиться ОС. >> >> Эта конфигурация жизнеспособна? >> >
Re: Снова о ZFS
> > Это, кстати, очень странное замечание, я думал, что мы уже давно живем > во времена SATA-3 и всеобщей поддержки "WRITE BARRIERS" (ну за > исключением счетного числа сломанных дисков), так что энергонезависимый > кеш на запись для программного рейда давно не нужен... > Так здесь не про рэйд, как таковой, а про SSD пользовательского сегмента.
Re: Снова о ZFS
Вообще-то размер ZIL рекомендуют порядка нескольких ГБ, зачем там 150 ГБ - не очень понятно... 13.01.2018 21:56, artiom пишет: 10.01.2018 18:25, Sergey Matveev пишет: *** artiom [2018-01-10 18:18]: Если же установлена опция sync=disabled, произойдёт ошибка записи? Если опция установлена, то не, ошибок не будет, но и fsync-а по факту не будет происходить. Т.е., приложение всё-равно запишет, не поняв что была ошибка и данных на диске нет? В чём тогда разница? Ещё вопрос: есть SSD размером 250 ГБ на который будет установлена система (или два SSD), и на которые будет вынесен ZIL. Хочу сделать два одинаковых GPT раздела на каждой из SSD. На раздел под систему отвести 100 ГБ, под ZIL 150 ГБ. Оба раздела будут шифроваться стандартным ZFS шифрованием. С первого раздела (миррора) должна грузиться ОС. Эта конфигурация жизнеспособна?
Re: Снова о ZFS
15.01.2018 00:25, artiom пишет: Вот это наталкивает на мысли (пусть оно и для ZIL): "After a crash, ZFS will attempt to replay the ZIL contents. SSDs themselves have a volatile write cache, so they may lose data during a bad shutdown. To ensure the ZFS write cache replay has all of your inflight writes, the SSD devices used for dedicated ZIL devices should have power protection. HGST makes a number of devices that are specifically targeted as dedicated ZFS ZIL devices." Отсюда: http://www.freenas.org/blog/a-complete-guide-to-freenas-hardware-design-part-iii-pools-performance-and-cache/ Это, кстати, очень странное замечание, я думал, что мы уже давно живем во времена SATA-3 и всеобщей поддержки "WRITE BARRIERS" (ну за исключением счетного числа сломанных дисков), так что энергонезависимый кеш на запись для программного рейда давно не нужен...
Re: Снова о ZFS
*** artiom [2018-01-15 00:29]: >Вот это наталкивает на мысли (пусть оно и для ZIL): >"After a crash, ZFS will attempt to replay the ZIL contents. SSDs >themselves have a volatile write cache, so they may lose data during a >bad shutdown. To ensure the ZFS write cache replay has all of your >inflight writes, the SSD devices used for dedicated ZIL devices should >have power protection. HGST makes a number of devices that are >specifically targeted as dedicated ZFS ZIL devices." А, ну то бишь это как и HDD специально сделанные для NAS решений: как бы без write cache-а. Разумно. Действительно полезно. На HDD часто просто можно отключать этот write cache и нивелировать проблемы внезапного выключения. >Оттуда же (насчёт производительности): >"A key thing to know here is a ZFS vdev gives the IOPs performance of >one device in the vdev. That means that if you create a RAIDZ2 of ten >drives, it will have the capacity of 8 drives but it will have the IOPs >performance of a single drive." Для random IOPS всё верно. Sequential read будет всё же быстрее. >>> Вопрос по загрузке возникает. В Linux эта проблема решается через >>> вынесение ядра и initrd с cryptsetup на отдельный раздел. Здесь тоже самое? >Каким образом (FreeBSD давно был)? Нужен отдельный незашифрованный раздел? Да, просто отдельный раздел где будет загрузчик с ядром и модулями которые они подгружают. В самом man-е GELI есть примеры касающиеся boot: https://www.unix.com/man-page/FreeBSD/8/geli/ (/boot/loader.conf) -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
14.01.2018 22:55, Sergey Matveev пишет: > *** artiom [2018-01-14 17:14]: >> Т.е., в случае sync=disabled, ZIL запишется сразу (на SSD), но на диск >> данные не будут сброшены? > > sync=disabled даже на ZIL не запишет, насколько знаю. С sync=standard > (по-умолчанию) всё как вы сказали: на ZIL точно запишет, на диск позже. > Кстати, был вопрос "чем отличается брэндовый L2ARC от обычной SSD?". Вот это наталкивает на мысли (пусть оно и для ZIL): "After a crash, ZFS will attempt to replay the ZIL contents. SSDs themselves have a volatile write cache, so they may lose data during a bad shutdown. To ensure the ZFS write cache replay has all of your inflight writes, the SSD devices used for dedicated ZIL devices should have power protection. HGST makes a number of devices that are specifically targeted as dedicated ZFS ZIL devices." Отсюда: http://www.freenas.org/blog/a-complete-guide-to-freenas-hardware-design-part-iii-pools-performance-and-cache/ Оттуда же (насчёт производительности): "A key thing to know here is a ZFS vdev gives the IOPs performance of one device in the vdev. That means that if you create a RAIDZ2 of ten drives, it will have the capacity of 8 drives but it will have the IOPs performance of a single drive." >> Вопрос по загрузке возникает. В Linux эта проблема решается через >> вынесение ядра и initrd с cryptsetup на отдельный раздел. Здесь тоже самое? > > Про GNU/Linux, к сожалению, ничего не смогу сказать. В FreeBSD такое > точно без проблем работает -- у меня схожая схема используется. > Каким образом (FreeBSD давно был)? Нужен отдельный незашифрованный раздел?
Re: Снова о ZFS
*** artiom [2018-01-14 17:14]: >А что можете сказать про другие системы (NAS специфичные)? >В частности, интересует NAS4Free. Я наслышан только о FreeNAS и то что он активно используется знакомыми. Он just-works, подвохов не было. Сам руками ничего не трогал. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** artiom [2018-01-14 17:14]: >Т.е., в случае sync=disabled, ZIL запишется сразу (на SSD), но на диск >данные не будут сброшены? sync=disabled даже на ZIL не запишет, насколько знаю. С sync=standard (по-умолчанию) всё как вы сказали: на ZIL точно запишет, на диск позже. >Вопрос по загрузке возникает. В Linux эта проблема решается через >вынесение ядра и initrd с cryptsetup на отдельный раздел. Здесь тоже самое? Про GNU/Linux, к сожалению, ничего не смогу сказать. В FreeBSD такое точно без проблем работает -- у меня схожая схема используется. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
10.01.2018 18:29, Sergey Matveev пишет: > *** artiom [2018-01-10 18:18]: >> И всё бы хорошо, но про OMV вы молчите. >> Что скажите насчёт ZFS+Linux? >> Доводы за и против? > > Лично я с GNU/Linux уже давно не работаю (и не хочу) и поэтому ничего не > могу сказать, так как опыта нет. Качество падает и подходы к качеству в > GNU/Linux мире меня ОЧЕНЬ удручают и поэтому я в него больше "не лазаю" :-) > Но это чисто личное мнение/опыт. Про OMV я вообще только от вас впервые и > услышал. > А что можете сказать про другие системы (NAS специфичные)? В частности, интересует NAS4Free.
Re: Снова о ZFS
>> Т.е., приложение всё-равно запишет, не поняв что была ошибка и данных на >> диске нет? >> В чём тогда разница? > > Я не понимаю про какую разницу вы спрашиваете. > > * zfs set sync=disabled -- означает что "не делать настоящую > гарантированную запись на диск во время вызова fsync", а поместить всё > в буфер и уж когда запишется, тогда и запишется. Программа после fsync > думает что на диске всё есть, но при какой-то поломке/проблеме, то, > что не записалось из буфера, будет потеряно > * вынесенный ZIL но без зеркалирования -- fsync гарантирует что до ZIL > запись дошла, на него записалась, но при поломке, то, что из ZIL не > успело перенестись на диск, будет потеряно. Аналогично sync=disabled, > с той лишь разницей что данные оказались на ZIL накопителе, а не в > памяти > Т.е., в случае sync=disabled, ZIL запишется сразу (на SSD), но на диск данные не будут сброшены? > Так как ZIL это SSD наверняка всегда, то SSD имеет очень не нулевой шанс > внезапно отказать (а не плавно деградировать как это делают HDD) и, > соответственно, шанс потерять какие-то данные после fsync. Поэтому ZIL > так сильно рекомендуется зеркалировать. > Ok, понял, докуплю вторую SSD. >> Ещё вопрос: есть SSD размером 250 ГБ на который будет установлена >> система (или два SSD), и на которые будет вынесен ZIL. >> Хочу сделать два одинаковых GPT раздела на каждой из SSD. >> На раздел под систему отвести 100 ГБ, под ZIL 150 ГБ. >> Оба раздела будут шифроваться стандартным ZFS шифрованием. >> С первого раздела (миррора) должна грузиться ОС. >> >> Эта конфигурация жизнеспособна? > > Да, проблем или каких-то особенностей тут не вижу. > Вопрос по загрузке возникает. В Linux эта проблема решается через вынесение ядра и initrd с cryptsetup на отдельный раздел. Здесь тоже самое?
Re: Снова о ZFS
*** artiom [2018-01-13 21:58]: >Т.е., приложение всё-равно запишет, не поняв что была ошибка и данных на >диске нет? >В чём тогда разница? Я не понимаю про какую разницу вы спрашиваете. * zfs set sync=disabled -- означает что "не делать настоящую гарантированную запись на диск во время вызова fsync", а поместить всё в буфер и уж когда запишется, тогда и запишется. Программа после fsync думает что на диске всё есть, но при какой-то поломке/проблеме, то, что не записалось из буфера, будет потеряно * вынесенный ZIL но без зеркалирования -- fsync гарантирует что до ZIL запись дошла, на него записалась, но при поломке, то, что из ZIL не успело перенестись на диск, будет потеряно. Аналогично sync=disabled, с той лишь разницей что данные оказались на ZIL накопителе, а не в памяти Так как ZIL это SSD наверняка всегда, то SSD имеет очень не нулевой шанс внезапно отказать (а не плавно деградировать как это делают HDD) и, соответственно, шанс потерять какие-то данные после fsync. Поэтому ZIL так сильно рекомендуется зеркалировать. >Ещё вопрос: есть SSD размером 250 ГБ на который будет установлена >система (или два SSD), и на которые будет вынесен ZIL. >Хочу сделать два одинаковых GPT раздела на каждой из SSD. >На раздел под систему отвести 100 ГБ, под ZIL 150 ГБ. >Оба раздела будут шифроваться стандартным ZFS шифрованием. >С первого раздела (миррора) должна грузиться ОС. > >Эта конфигурация жизнеспособна? Да, проблем или каких-то особенностей тут не вижу. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
10.01.2018 18:25, Sergey Matveev пишет: > *** artiom [2018-01-10 18:18]: >> Если же установлена опция sync=disabled, произойдёт ошибка записи? > > Если опция установлена, то не, ошибок не будет, но и fsync-а по факту не > будет происходить. > Т.е., приложение всё-равно запишет, не поняв что была ошибка и данных на диске нет? В чём тогда разница? Ещё вопрос: есть SSD размером 250 ГБ на который будет установлена система (или два SSD), и на которые будет вынесен ZIL. Хочу сделать два одинаковых GPT раздела на каждой из SSD. На раздел под систему отвести 100 ГБ, под ZIL 150 ГБ. Оба раздела будут шифроваться стандартным ZFS шифрованием. С первого раздела (миррора) должна грузиться ОС. Эта конфигурация жизнеспособна?
Re: Снова о ZFS
*** artiom [2018-01-10 18:18]: >Если же установлена опция sync=disabled, произойдёт ошибка записи? Если опция установлена, то не, ошибок не будет, но и fsync-а по факту не будет происходить. >0.4 % - не ахти, как много. Но такой "опции" (хранить IV) никто не предлагает для полнодискового шифрования :-). Оно должно быть максимально прозрачным и не отличимым от обычной работы. А так как IV нельзя будет хранить где-то "рядом" с сектором (всё же должно быть кратно размеру сектора), то IV будет где-то в отдельной части диска -- а это значит что регулярно нужно диском ещё и считать/писать эти IV надо будет. То есть, кроме потери места, ещё и random seek добавляется. >> Но на практике в LUKS конечно не нулевой вектор используется, а ESSIV >> (encrypted salt-sector initialization vector), что уже не предсказуемо >> для злоумышленника. >> >Но один на все блоки? Для каждого блока непредсказуемый для злоумышленника. Например вы можете просто зашифровать номер сектора на ключе неизвестному злоумышленнику -- вот и будет is good enough IV. >> Как вариант. У меня один гигабайтный диск так и сделан: ZFS поверх GELI >> поверх ZVOL-а на другом ZFS :-). Просто overhead большой, что, конечно, >> неприятно. >> >А зачем так? Основной диск с системой у меня на голом ZFS. Где-то нужно иметь зашифрованный диск (почту например хранить). Выделять отдельную партицию -- геморрой (с одним ZFS разделом удобно перенести все данные просто zfs send/recv, а когда уже несколько партиций, то начинаются пляски), когда речь о всего-то гигабайте. Поэтому проще уж, забив на overhead, сделать поверх ZVOL-а было. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** artiom [2018-01-10 18:18]: >И всё бы хорошо, но про OMV вы молчите. >Что скажите насчёт ZFS+Linux? >Доводы за и против? Лично я с GNU/Linux уже давно не работаю (и не хочу) и поэтому ничего не могу сказать, так как опыта нет. Качество падает и подходы к качеству в GNU/Linux мире меня ОЧЕНЬ удручают и поэтому я в него больше "не лазаю" :-) Но это чисто личное мнение/опыт. Про OMV я вообще только от вас впервые и услышал. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
И всё бы хорошо, но про OMV вы молчите. Что скажите насчёт ZFS+Linux? Доводы за и против? stub для рассылки: > Родное ZFS шифрование делает не просто какой-нибудь CBC/XTS, а > аутентифицированное шифрование CCM/GCM -- поэтому там аутентификация > данных явно проводится и он явно скажет что именно аутентичность > нарушена, а не просто целостность. Ведь если злоумышленник имеет доступ > к ZFS (но в которой родное шифрование), то он может в принципе изменить > данные и пересчитать все хэши, чтобы, с точки зрения scrub всё выглядело > так, что целостность не нарушена. Но изменить аутентифицированный > шифротекст он, само собой, не сможет. Это ведь кстати ещё один плюс в > сторону родного шифрования: с GELI/LUKS у вас может сыпаться жёсткий > диск и действительно нарушаться целостность, а может быть и > злоумышленник данные подменивает -- с ними вы этого не узнаете. А > включать аутентификацию GELI/LUKS -- дорого, так как для каждого > 512/4096 сектора придётся отбирать несколько десятков байт. >
Re: Снова о ZFS
10.01.2018 15:48, Sergey Matveev пишет: > *** Артём Н. [2018-01-10 15:31]: >> Ну и ok: тогда, если даже она потеряется, ничего особо не случится (да, в >> итоге я всё-же куплю 2-й SSD)? > > Если потеряется ZIL (эта short-term область), то это равносильно тому > что записи не было произведено, хотя программа получила успешное > завершение fsync и убеждена что данные сохранены. > Если же установлена опция sync=disabled, произойдёт ошибка записи? >> Почему? Возможно хранить список векторов в метаданных, шифрованных на >> фиксированном ключе. >> Собственно, там же, где хранится реальный ключ шифрования диска. > > Для каждого блока диска где-то хранить вектор? Если взять 2 TiB диск с > 4KiB секторами, то вектора будут занимать (если считать что у нас > 128-битный шифр и IV занимает один блок) > 16 * (2 * 1024 * 1024 * 1024 * 1024 / 4096) / 1024 / 1024 / 1024 = 8 (GiB). > Что много. Просто так ключи занимают считанные десятки байт. > 0.4 % - не ахти, как много. > Но на практике в LUKS конечно не нулевой вектор используется, а ESSIV > (encrypted salt-sector initialization vector), что уже не предсказуемо > для злоумышленника. > Но один на все блоки? >> Вопрос-то в другом: кроме просадки по скорости, атаку на целенаправленное >> изменение данных, >> без знания ключа для AES (он же использует AES по умолчанию) сложно >> реализовать? > > На практике вообще не сложно: > https://packetstormsecurity.com/files/124571/Practical-Malleability-Attack-Against-CBC-Encrypted-LUKS-Partition.html > Это для CBC режима конечно же. С XTS сделать *осознанное* изменение > plaintext-а уже не получится. > Статейка любопытная, почитаю. >> Да, ещё конечно имеется вариант сделать geli/luks поверх ZFS, но он мне >> кажется весьма сомнительным. > > Как вариант. У меня один гигабайтный диск так и сделан: ZFS поверх GELI > поверх ZVOL-а на другом ZFS :-). Просто overhead большой, что, конечно, > неприятно. > А зачем так?
Re: Снова о ZFS
*** Артём Н. [2018-01-10 15:31]: >Ну и ok: тогда, если даже она потеряется, ничего особо не случится (да, в >итоге я всё-же куплю 2-й SSD)? Если потеряется ZIL (эта short-term область), то это равносильно тому что записи не было произведено, хотя программа получила успешное завершение fsync и убеждена что данные сохранены. >Почему? Возможно хранить список векторов в метаданных, шифрованных на >фиксированном ключе. >Собственно, там же, где хранится реальный ключ шифрования диска. Для каждого блока диска где-то хранить вектор? Если взять 2 TiB диск с 4KiB секторами, то вектора будут занимать (если считать что у нас 128-битный шифр и IV занимает один блок) 16 * (2 * 1024 * 1024 * 1024 * 1024 / 4096) / 1024 / 1024 / 1024 = 8 (GiB). Что много. Просто так ключи занимают считанные десятки байт. Но на практике в LUKS конечно не нулевой вектор используется, а ESSIV (encrypted salt-sector initialization vector), что уже не предсказуемо для злоумышленника. >Вопрос-то в другом: кроме просадки по скорости, атаку на целенаправленное >изменение данных, >без знания ключа для AES (он же использует AES по умолчанию) сложно >реализовать? На практике вообще не сложно: https://packetstormsecurity.com/files/124571/Practical-Malleability-Attack-Against-CBC-Encrypted-LUKS-Partition.html Это для CBC режима конечно же. С XTS сделать *осознанное* изменение plaintext-а уже не получится. >Да, ещё конечно имеется вариант сделать geli/luks поверх ZFS, но он мне >кажется весьма сомнительным. Как вариант. У меня один гигабайтный диск так и сделан: ZFS поверх GELI поверх ZVOL-а на другом ZFS :-). Просто overhead большой, что, конечно, неприятно. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
On 09.01.2018 20:25, Sergey Matveev wrote: *** Артём Н. [2018-01-09 20:23]: Только дорого, и начинка у меня получше будет (я так понимаю, там ASRock со впаянным Avoton). Если так, то тогда про мать молчу. Только корпус хороший точно получается. Корпус, да. Проблема матери ASRock в том, что она не miniITX, а miniITX extended (китайцы запилили свой форм-фактор). Для того, чтобы она влезла в корпус SilverStone DS380B, пришлось убрать в нём кусок металла. Жалею, что не взял корпус от FreeNAS (мать для Xeon, собственно, менять не на что, разве, что на Asus, но там контроллер SAS только один встроен). Но теперь, увы.
Re: Снова о ZFS
Потеря ZIL грозит потере части транзакций последних, верно. Но просто получается что с точки зрения ОС выполнен fsync, а на самом деле, при потере log устройства мы всё-равно теряет данные как-будто fsync-а не было. Если бы не было log-устройства, то fsync на обычные диски в RAIDZ надёжен -- при вылете одного из дисков всё-равно данные есть. Поэтому если вам так не нужна надёжность fsync-ов и не хочется чтобы проседала скорость от них, то можно просто zfs set sync=disabled выставить -- и скорость не просядет и надёжность не зависит от вылета несдублированного log устройства. Но это моё личное мнение :-). Насколько знаю, log-device нужен тем у кого нагруженные почтовые сервера, СУБД всякие. А так ведь не сказать что много софта нуждается в fsync-е. Как-то это противоречит тому, что потеря ZIL грозит потерей данных.
Re: Снова о ZFS
Ну предполагается, что журнал пишется синхронно с записью данных. В ZFS все записи (данных, изменённых метаданных) какое-то время агрегируются в памяти, а потом сбрасываются одним большим куском на диски. fsync для ZIL означает что эти данные не ждут когда они накопятся, а сразу же записываются на диск, но только в особую для ZIL область и только потом они уже распределяются по дискам нормально, штатно. http://www.freenas.org/blog/zfs-zil-and-slog-demystified/ Тут вот они и говорят, что сначала данные запишутся в short-term ZIL область, а только потом, второй раз ещё запишутся учитывая все эти RAIDZ конфигурации и прочее. То есть писаться они будут по два раза. Отдельное log устройство как-раз просто и выносит эту short-term область на отдельный диск. Ну и ok: тогда, если даже она потеряется, ничего особо не случится (да, в итоге я всё-же куплю 2-й SSD)? Эм... Сейчас у меня только одна SSD и та - системная. А ведь потеря части ZIL мне грозит лишь частичной потерей последних транзакций? Потеря ZIL грозит потере части транзакций последних, верно. Но просто получается что с точки зрения ОС выполнен fsync, а на самом деле, при потере log устройства мы всё-равно теряет данные как-будто fsync-а не было. Если бы не было log-устройства, то fsync на обычные диски в RAIDZ надёжен -- при вылете одного из дисков всё-равно данные есть. Поэтому если вам так не нужна надёжность fsync-ов и не хочется чтобы проседала скорость от них, то можно просто zfs set sync=disabled выставить -- и скорость не просядет и надёжность не зависит от вылета несдублированного log устройства. Но это моё личное мнение :-). Насколько знаю, log-device нужен тем у кого нагруженные почтовые сервера, СУБД всякие. А так ведь не сказать что много софта нуждается в fsync-е. Для тех кто готов "сливать" только факт изменения всего блока, но не конкретной позиции в нём, есть режим EME -- который делает двойное шифрование (туда-обратно), что в два раза дороже для CPU, но да -- надёжнее. Каким образом он сливал? Вряд ли хранил в незашифрованном журнале. Я так думаю, что дисковое шифрование нужно для предотвращения оффлайновых атак, разве нет? Смотрите, у вас есть 512-байт блок жёсткого диска. Он шифруется в CBC режиме: то есть это 32 128-битных блока симметричного шифра. Вы перезаписываете данные в этом секторе диска, но начиная например с 300-го байта. Само собой весь блок физически на диск записывается с нуля, но перед этим он перешифровывается. Ключ у вас точно такой же как и был прежде, изменяемого вектора инициализации нет (его просто негде хранить на диске) Почему? Возможно хранить список векторов в метаданных, шифрованных на фиксированном ключе. Собственно, там же, где хранится реальный ключ шифрования диска. и первые 16 128-битных блоков такие же как и были прежде -- поэтому их перешифрование произведёт абсолютно точно такой же шифротекст как и был прежде. Но с 17-го блока (288-го байта внутри сектора) блок шифротекста уже поменяется. Если злоумышленник видел каким был блок до этой перезаписи и после, то он и видит что в этом секторе вы начали что-то менять в пределах с 288-304 байт этого сектора. Данные само собой не слились, но данные об этих данных (метаинформация) выдаёт где именно эти данные менялись. Так же как сделав LUKS/GELI на чистом диске, вы всё-равно видите что диск забит на 100% сплошными нулями и значит, хоть он и зашифрован, но ещё не использовался и данных на нём не было. Всё, понял: атака возможна, при наличии постоянного физического доступа к шифрованному диску. Я когда-то очень давно (больше 10 лет назад) писал вот такую статью: http://www.stargrave.org/Disk-encryption.html Прочитаю, спасибо. само собой не я придумывал все эти атаки, а просто собирал из разных источников эти знания в одной статье. Атак много разных. И до изобретения XTS режима (и tweakable block cipher) вы или мирились с двойным проседанием по скорости (по CPU) или шли на жертвы по разным атакам. Вот у меня дома жёсткие диски, но дома кроме меня, грубо говоря, никогда никого не бывает и я не представляю что в моё отсутствие кто-то приходил, вынимал диски, что-то с ними делал, вставлял обратно, итд. Я готов мириться с такими видами атак и поэтому вряд ли бы жёг на них свой CPU (хотя понимаю что сейчас производительность CPU такая, что все эти лишние перешифрования на скоростях НЖМД -- копейки). Зависит от загрузки. Или вот GELI/LUKS по-умолчанию не предоставляют никакой аутентификации данных, так как это начнёт занимать дополнительное место, но тоже не самый безопасный вариант. В смысле? GELI по-умолчанию делает просто XTS шифрование и не более. Вы можете спокойно изменить зашифрованные данные на диске и никто вам не скажет что их аутентичность/целостность нарушена. Полнодисковое шифрование требует чтобы никакого дополнительного места под это шифрование не занималось (ну не считая заголовков LUKS/GELI само собой). LUKS, насколько помню, тоже просто делает XTS/CBC/whatever шифрование -- аутентификации нет. В GELI это можно
Re: Снова о ZFS
*** Артём Н. [2018-01-09 20:23]: >Только дорого, и начинка у меня получше будет (я так понимаю, там ASRock со >впаянным Avoton). Если так, то тогда про мать молчу. Только корпус хороший точно получается. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
On 09.01.2018 16:56, Sergey Matveev wrote: *** Артём Н. [2018-01-09 16:50]: https://www.amazon.com/FreeNAS-Mini-Cache-L2ARC-Upgrade/dp/B00LVA9E5A Они продают NAS в сборе, и честно говоря, я бы его может и взял, если бы уже не собирал свой. У меня кстати именно буквально в таком же корпусе целых два своих сервера. И начинка наверное (материнская плата этой платформы) такая же как у них. Отличная платформа! Если бы мне снова пришлось бы себе NAS собирать, то я бы снова выбрал бы такое тоже. Только дорого, и начинка у меня получше будет (я так понимаю, там ASRock со впаянным Avoton).
Re: Снова о ZFS
*** Артём Н. [2018-01-09 16:50]: >> > https://www.amazon.com/FreeNAS-Mini-Cache-L2ARC-Upgrade/dp/B00LVA9E5A >Они продают NAS в сборе, и честно говоря, я бы его может и взял, если бы уже >не собирал свой. У меня кстати именно буквально в таком же корпусе целых два своих сервера. И начинка наверное (материнская плата этой платформы) такая же как у них. Отличная платформа! Если бы мне снова пришлось бы себе NAS собирать, то я бы снова выбрал бы такое тоже. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** Артём Н. [2018-01-09 16:45]: >> А, пардон: я всё это время почему-то подумал что у вас 4*4 дисков, то >> бишь 16. А это 4 четырёхтерабайтных. Да, тогда о RAIDZ3 или stripe из >> RAIDZ-ов можно не думать конечно же. Я бы наверное тоже как и вы бы >> сделал: просто RAIDZ4 из них и не парился. >> >Именно. Четыре четырёхтерабайтника. Это же не стойка, а всего-лишь корпус с >корзиной горячей замены. >В смысле? RAIDZ из 4-х дисков? Да, опечатался. RAIDZ из четырёх дисков. >> > Они же не хотят сказать, что при использовании RAIDZ на четырёх дисках, >> > производительность упадёт в четыре раза, по отношению к одному диску? >> >> Честно говоря, с ходу я пока тоже не могу понять этой их фразы. Вот >> минут 10 пытаюсь понять, но не доходит :-) >> >Однако, производительность не падает в два раза, при увеличении числа дисков >вдвое? Я думаю подразумевалось следующее: при записи на RAIDZ ZFS дожидается пока *все* диски сделают свою запись и только после этого он может делать что-то дальше. Диски, как правило, более менее одинаковые, но всё-равно разнятся по скоростям, более того: записываться то данные могут в совершенно разные области дисков -- а там время поиска/скорости могут отличаться существенно. Поэтому всегда ZFS ожидает конец IO операции самого медленного. Чем меньше дисков -- тем меньше разброс по скоростям и время ожидания. Но в целом сказано верно что в *среднем* оно как один диск, как самый медленный диск. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
On 08.01.2018 11:38, Sergey Matveev wrote: *** artiom [2018-01-08 04:18]: Как известно, FreeNAS продаёт свои уже собранные аппаратные конфигурации. И я заметил у них вот такой интересный девайс: https://www.amazon.com/FreeNAS-Mini-Cache-L2ARC-Upgrade/dp/B00LVA9E5A Есть ли отличия от обычной SSD и, если да, то какие? Лично я про FreeNAS мало чего знаю, но удивлён что у них вот такие брэндовые штуки оказывается есть. Мне кажется что это простая SSD-шка. Даже не знаю что там может быть оптимального/специфичного для L2ARC. Они продают NAS в сборе, и честно говоря, я бы его может и взял, если бы уже не собирал свой.
Re: Снова о ZFS
Вроде немного, но я так полагаю, что оптимальное решение - просто сделать пул RAIDZ из 4-х дисков (и по скорости будет нормально, и избыточность не 33%, а 25%) и не париться. А, пардон: я всё это время почему-то подумал что у вас 4*4 дисков, то бишь 16. А это 4 четырёхтерабайтных. Да, тогда о RAIDZ3 или stripe из RAIDZ-ов можно не думать конечно же. Я бы наверное тоже как и вы бы сделал: просто RAIDZ4 из них и не парился. Именно. Четыре четырёхтерабайтника. Это же не стойка, а всего-лишь корпус с корзиной горячей замены. В смысле? RAIDZ из 4-х дисков? Не вполне понятно другое: 'To double your read IOPS, you would need to halve the number of "data" disks in the RAID-Z group (e.g. with RAIDZ-2, go from 12 to 7 disks).' Они же не хотят сказать, что при использовании RAIDZ на четырёх дисках, производительность упадёт в четыре раза, по отношению к одному диску? Честно говоря, с ходу я пока тоже не могу понять этой их фразы. Вот минут 10 пытаюсь понять, но не доходит :-) Однако, производительность не падает в два раза, при увеличении числа дисков вдвое? Ok, вас понял. Сжатие оставляю. Кроме того, серьёзных вычислительных задач, которые загрузят Xeon, там по-идее не будет: оно не должно мешать. У меня дома есть очень слабенький Celeron в котором я всюду и везде упираюсь в скорость SHA2/AES/Skein (вообще во всех задачах, не только ZFS) и прочей криптографии, но никогда не упирался в compression=lz4 (включай, не включай -- всё-равно упрусь в хэши). Ok, с этим всё ясно.
Re: Снова о ZFS
*** artiom [2018-01-08 04:28]: >Да, вспомнил тему: солярис использует снэпшоты для отката обновлений. >FreeNAS, как я заметил, тоже. Я и руками это делаю перед обновлением системы -- это очень удобно. >Ну предполагается, что журнал пишется синхронно с записью данных. В ZFS все записи (данных, изменённых метаданных) какое-то время агрегируются в памяти, а потом сбрасываются одним большим куском на диски. fsync для ZIL означает что эти данные не ждут когда они накопятся, а сразу же записываются на диск, но только в особую для ZIL область и только потом они уже распределяются по дискам нормально, штатно. http://www.freenas.org/blog/zfs-zil-and-slog-demystified/ Тут вот они и говорят, что сначала данные запишутся в short-term ZIL область, а только потом, второй раз ещё запишутся учитывая все эти RAIDZ конфигурации и прочее. То есть писаться они будут по два раза. Отдельное log устройство как-раз просто и выносит эту short-term область на отдельный диск. >Эм... Сейчас у меня только одна SSD и та - системная. >А ведь потеря части ZIL мне грозит лишь частичной потерей последних >транзакций? Потеря ZIL грозит потере части транзакций последних, верно. Но просто получается что с точки зрения ОС выполнен fsync, а на самом деле, при потере log устройства мы всё-равно теряет данные как-будто fsync-а не было. Если бы не было log-устройства, то fsync на обычные диски в RAIDZ надёжен -- при вылете одного из дисков всё-равно данные есть. Поэтому если вам так не нужна надёжность fsync-ов и не хочется чтобы проседала скорость от них, то можно просто zfs set sync=disabled выставить -- и скорость не просядет и надёжность не зависит от вылета несдублированного log устройства. Но это моё личное мнение :-). Насколько знаю, log-device нужен тем у кого нагруженные почтовые сервера, СУБД всякие. А так ведь не сказать что много софта нуждается в fsync-е. >> Для тех кто готов "сливать" только факт изменения всего блока, но не >> конкретной позиции в нём, есть режим EME -- который делает двойное >> шифрование (туда-обратно), что в два раза дороже для CPU, но да -- >> надёжнее. >Каким образом он сливал? Вряд ли хранил в незашифрованном журнале. >Я так думаю, что дисковое шифрование нужно для предотвращения >оффлайновых атак, разве нет? Смотрите, у вас есть 512-байт блок жёсткого диска. Он шифруется в CBC режиме: то есть это 32 128-битных блока симметричного шифра. Вы перезаписываете данные в этом секторе диска, но начиная например с 300-го байта. Само собой весь блок физически на диск записывается с нуля, но перед этим он перешифровывается. Ключ у вас точно такой же как и был прежде, изменяемого вектора инициализации нет (его просто негде хранить на диске), и первые 16 128-битных блоков такие же как и были прежде -- поэтому их перешифрование произведёт абсолютно точно такой же шифротекст как и был прежде. Но с 17-го блока (288-го байта внутри сектора) блок шифротекста уже поменяется. Если злоумышленник видел каким был блок до этой перезаписи и после, то он и видит что в этом секторе вы начали что-то менять в пределах с 288-304 байт этого сектора. Данные само собой не слились, но данные об этих данных (метаинформация) выдаёт где именно эти данные менялись. Так же как сделав LUKS/GELI на чистом диске, вы всё-равно видите что диск забит на 100% сплошными нулями и значит, хоть он и зашифрован, но ещё не использовался и данных на нём не было. Я когда-то очень давно (больше 10 лет назад) писал вот такую статью: http://www.stargrave.org/Disk-encryption.html само собой не я придумывал все эти атаки, а просто собирал из разных источников эти знания в одной статье. Атак много разных. И до изобретения XTS режима (и tweakable block cipher) вы или мирились с двойным проседанием по скорости (по CPU) или шли на жертвы по разным атакам. Вот у меня дома жёсткие диски, но дома кроме меня, грубо говоря, никогда никого не бывает и я не представляю что в моё отсутствие кто-то приходил, вынимал диски, что-то с ними делал, вставлял обратно, итд. Я готов мириться с такими видами атак и поэтому вряд ли бы жёг на них свой CPU (хотя понимаю что сейчас производительность CPU такая, что все эти лишние перешифрования на скоростях НЖМД -- копейки). >> Или вот GELI/LUKS по-умолчанию не предоставляют никакой >> аутентификации данных, так как это начнёт занимать дополнительное место, >> но тоже не самый безопасный вариант. >В смысле? GELI по-умолчанию делает просто XTS шифрование и не более. Вы можете спокойно изменить зашифрованные данные на диске и никто вам не скажет что их аутентичность/целостность нарушена. Полнодисковое шифрование требует чтобы никакого дополнительного места под это шифрование не занималось (ну не считая заголовков LUKS/GELI само собой). LUKS, насколько помню, тоже просто делает XTS/CBC/whatever шифрование -- аутентификации нет. В GELI это можно включить, но (кроме потери скорости из-за HMAC операции (судя по man, там только HMAC)) вы, при использовании, потеряете ощутимо места. -a aalgo Enable data integrity verification
Re: Снова о ZFS
*** artiom [2018-01-08 04:18]: >Как известно, FreeNAS продаёт свои уже собранные аппаратные конфигурации. >И я заметил у них вот такой интересный девайс: >https://www.amazon.com/FreeNAS-Mini-Cache-L2ARC-Upgrade/dp/B00LVA9E5A > >Есть ли отличия от обычной SSD и, если да, то какие? Лично я про FreeNAS мало чего знаю, но удивлён что у них вот такие брэндовые штуки оказывается есть. Мне кажется что это простая SSD-шка. Даже не знаю что там может быть оптимального/специфичного для L2ARC. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** artiom [2018-01-08 04:12]: >Хотя, я пересмотрел: я же не могу сделать RAIDZ2 менее, чем с 6-ю >дисками, а у меня их только 4. Ну вообще можно с 4-мя, так же, как и RAID6. Если что, то с ZFS можно играться с обычными файлами, чтобы на деле проверить. # truncate -s +2G disk1 # truncate -s +2G disk2 # truncate -s +2G disk3 # truncate -s +2G disk4 # zpool create testingpool raidz2 \ /home/stargrave/data/disk1 \ /home/stargrave/data/disk2 \ /home/stargrave/data/disk3 \ /home/stargrave/data/disk4 # zpool status testingpool pool: testingpool state: ONLINE scan: none requested config: NAMESTATE READ WRITE CKSUM testingpool ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 /home/stargrave/data/disk1 ONLINE 0 0 0 /home/stargrave/data/disk2 ONLINE 0 0 0 /home/stargrave/data/disk3 ONLINE 0 0 0 /home/stargrave/data/disk4 ONLINE 0 0 0 >Вроде немного, но я так полагаю, что оптимальное решение - просто >сделать пул RAIDZ из 4-х дисков (и по скорости будет нормально, и >избыточность не 33%, а 25%) и не париться. А, пардон: я всё это время почему-то подумал что у вас 4*4 дисков, то бишь 16. А это 4 четырёхтерабайтных. Да, тогда о RAIDZ3 или stripe из RAIDZ-ов можно не думать конечно же. Я бы наверное тоже как и вы бы сделал: просто RAIDZ4 из них и не парился. >Не вполне понятно другое: 'To double your read IOPS, you would need to >halve the number of "data" disks in the RAID-Z group (e.g. with RAIDZ-2, >go from 12 to 7 disks).' > >Они же не хотят сказать, что при использовании RAIDZ на четырёх дисках, >производительность упадёт в четыре раза, по отношению к одному диску? Честно говоря, с ходу я пока тоже не могу понять этой их фразы. Вот минут 10 пытаюсь понять, но не доходит :-) >Ok, вас понял. Сжатие оставляю. Кроме того, серьёзных вычислительных >задач, которые загрузят Xeon, там по-идее не будет: оно не должно мешать. У меня дома есть очень слабенький Celeron в котором я всюду и везде упираюсь в скорость SHA2/AES/Skein (вообще во всех задачах, не только ZFS) и прочей криптографии, но никогда не упирался в compression=lz4 (включай, не включай -- всё-равно упрусь в хэши). -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
> *** artiom [2018-01-07 21:09]: >> А вообще есть ли смысл в ZFS на системном SSD? > > Ну а почему нет? Вообще почему ZFS может не иметь смысла :-)? Избыточность и сложность, там где она не нужна. > Как минимум, бэкапы удобнее делать (snap/send/recv) и проверка целостности. > Ok, согласен. Да, вспомнил тему: солярис использует снэпшоты для отката обновлений. FreeNAS, как я заметил, тоже. >> Где-то я читал, что выигрыш от переноса журнала на SSD порядка 0.3. > > Всё зависит от режимов работы (fsync). > Ну предполагается, что журнал пишется синхронно с записью данных. >> Как сбалансировать надёжность хранения журнала и скорость работы с ним? > > По идее, если понадобился ZIL/log, то просто делают зеркало из него. То > есть, в идеале, это например просто две SSD в зеркале, отданные от log. > Эм... Сейчас у меня только одна SSD и та - системная. А ведь потеря части ZIL мне грозит лишь частичной потерей последних транзакций? >> Да ну. При хотсвопе это возможно сделать автоматически. >> [...] >> Чем такая схема хуже? > > Всё что вы написали верно. Но всё это подразумевает, что у вас *есть* > ключ шифрования. Вы не можете отдать ваши диски кому-нибудь чтобы он > например сделал resilver или scrub или send/recv ваших дисков. Вы не > можете подключить чужие зашифрованные диски чтобы просто проверить > scrub-ом их целостность. Мало ли чего бывает. ZFS некоторые задачи по > обслуживанию может провести без ключа. > Достаточно любопытные кейсы, я о таком даже не подозревал. > Лично я нисколько не призываю к использованию ZFS шифрования из-за этих > фич. Они не всем нужны. Так как ваш сервер домашний, то ключи наверняка > всегда, как бы, под рукой и поэтому все эти фишки бесполезны. Я просто > отметил в чём могут быть плюсы встроенного шифрования. > Ok, вас понял. Спасибо. >> Но, фактически, такое шифрование открывает информацию, значит не >> является надёжным. > > Это всё tradeoff как и в случае с "классическим" полнодисковым > шифрованием. Например часто используется (ну когда-то, как минимум) CBC > режим "сливал" данные о конкретном месте с которого началось изменение > данных в пределах блока жёсткого диска. Да -- это слив данных, но надо > прикидывать и оценивать чему он может грозить. Большинству пользователей > он ничему не грозит и поэтому он по-умолчанию повсеместно использовался. > Для тех кто готов "сливать" только факт изменения всего блока, но не > конкретной позиции в нём, есть режим EME -- который делает двойное > шифрование (туда-обратно), что в два раза дороже для CPU, но да -- > надёжнее. Каким образом он сливал? Вряд ли хранил в незашифрованном журнале. Я так думаю, что дисковое шифрование нужно для предотвращения оффлайновых атак, разве нет? > Или вот GELI/LUKS по-умолчанию не предоставляют никакой > аутентификации данных, так как это начнёт занимать дополнительное место, > но тоже не самый безопасный вариант. В смысле? > Если вы сделаете GELI/LUKS диск > поверх чистого, забитого нулями, то, пока полностью весь диск не будет > записан (хотя бы dd if=/dev/zero of=disk-encrypted), то информация о > реально используемом месте будет тоже "видна". Везде tradeoff. > Это да. Но во-первых, они предлагают сделать перезапись свободного места перед созданием раздела. Во-вторых, это даст только сведения о записанном объёме: это почти ничего. > Это я всё к тому что не стал бы называть ZFS шифрование не надёжным. > По-сравнению с LUKS/GELI -- оно больше выдаёт метаинформации, согласен > (но, взамен давая "плюшки"). > Да, в этом был вопрос: насколько незашифрованная метаинформация облегчает: - Оффлайновую дешифровку. - Возможность оффлайнового изменения файлов (в т.ч. системных).
Re: Снова о ZFS
Как известно, FreeNAS продаёт свои уже собранные аппаратные конфигурации. И я заметил у них вот такой интересный девайс: https://www.amazon.com/FreeNAS-Mini-Cache-L2ARC-Upgrade/dp/B00LVA9E5A Есть ли отличия от обычной SSD и, если да, то какие? Это stub для защиты от криворукого админа рассылок, который так и не осилил их настройку: > Я помню, что было много тем про неё. Но сейчас, когда последние железные > компоненты наконец-то доезжают до меня, я начал разбираться подробнее, и > появились новые вопросы. > > Кратко: требуется построить квартирный NAS, ближе к hi-end (Xeon, ECC > RAM 16 Gb, 4x4TB HDD SAS Hitachi/HGST, мать Mini-ITX extended ASRock > серверный). > > > Вопросы: > > - Насколько стабилен ZFS в OMV или всё-таки имеет смысл использовать > FreeNAS, а от идеи с OMV отказаться? > - ZFS более оптимально работает с голым диском (делает ioctl, определяет > диск ли это, если результат вызова положительный, выставляет оптимальные > для себя параметры работы). Будет ли работать ZFS также оптимально через > различные слои, в частности LUKS или gely? > - Если нет, то насколько стабильно, надёжно, изучено шифрование ZFS (по > сравнению с вышеназванными)? Выполняется ли полнодисковое шифрование или > это шифрование пофайловое (+метаданные)? Есть ли защита от cold boot > attack (как в Linux ZFS, так и в BSD ZFS)? > > Пока всё. Жду ответов от имеющихся здесь экспертов. По ходу обсуждения > будут новые вопросы. >
Re: Снова о ZFS
07.01.2018 21:58, Sergey Matveev пишет: > *** artiom [2018-01-07 21:18]: >> - Какой ZRAID лучше использовать: ZRAID2 или достаточно ZRAID? > > Зависит от количества и размера дисков в массиве, режимов > работы/нагрузки на них, в случае с ZFS ещё и recordsize. Почему появился > RAIDZ2 (или RAID6)? Потому-что размеры дисков растут быстрее чем их > скорость работы. Если в массиве RAID5/RAIDZ вылетает диск, но всё > начинает rebuild-ится, находится под бешенной нагрузкой. С маленькими > размерами диска rebuild занимает вменяемое время. С большими дисками > может занимать дни/неделю. Так как диски в основном ставят более-менее > из одной партии, то вероятность что ещё кто-то кокнется из этих же > дисков -- высока. А когда они ещё и под бешеной нагрузкой -- ещё выше. По-идее, у меня диски должны быть по две группы из разных партий (по 2 от разных поставщиков и в разное время заказаны). Понятно, что от указанной проблемы это не сильно спасёт, лишь уменьшит вероятность. Хотя, я пересмотрел: я же не могу сделать RAIDZ2 менее, чем с 6-ю дисками, а у меня их только 4. > Отсюда и появились RAID6/RAIDZ2 где два диска могут вылететь и ничего > плохого не случится. RAIDZ3 -- аналогичное продолжение, где уже три > диска. В ZFS с RAIDZ ещё добавляются вопросы по эффективности > использования места. В некоторых конфигурациях можно с ним потерять > половину места. Советую вот эту статью посмотреть: > https://www.delphix.com/blog/delphix-engineering/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz > И не забывать что можно/стоит использовать не один RAIDZ массив, а > stripe из нескольких. > 3-й - не мой вариант. Слишком велика избыточность, при малой вероятности события, от которого он защищает (плюс, возможно использование дополнительных резервных копий). Страйп - тоже сомнительный вариант, хотя я и думаю про него: дисков-то у меня от 4-х до 8-ми. Статью почитал. Вроде немного, но я так полагаю, что оптимальное решение - просто сделать пул RAIDZ из 4-х дисков (и по скорости будет нормально, и избыточность не 33%, а 25%) и не париться. Не вполне понятно другое: 'To double your read IOPS, you would need to halve the number of "data" disks in the RAID-Z group (e.g. with RAIDZ-2, go from 12 to 7 disks).' Они же не хотят сказать, что при использовании RAIDZ на четырёх дисках, производительность упадёт в четыре раза, по отношению к одному диску? >> - Имеет ли смысл включать сжатие (в приведённой выше конфигурации)? > > Практически всегда не имеет смысла не включать его (compression=lz4). > Если заранее известно что там будет только плохосжимаемые данные, то да, > можно отключить. LZ4 безумно быстрая штука, которая хорошо понимает что > ей суют несжимаемые данные и она оставит их "как есть" -- не будет > overhead-а как от сжатия. Сжатие тут как-правило только ускорит всё: так > как данных между дисков и системой надо просасывать меньше. Ну и просто > приятно видеть как du для MongoDB может показать 20 GB, хотя реально в > ней данных на 60 -- JSON/BSON хорошо сжимаются и получается отличная > экономия RAM, как кэша ФС, ведь в ней сжатые ZFS объекты хранятся. > Ok, вас понял. Сжатие оставляю. Кроме того, серьёзных вычислительных задач, которые загрузят Xeon, там по-идее не будет: оно не должно мешать. P.S.: Нашёл калькуляторы. http://wintelguy.com/zfs-calc.pl https://jsfiddle.net/Biduleohm/paq5u7z5/1/embedded/result/
Re: Снова о ZFS
*** artiom [2018-01-07 21:18]: >- Какой ZRAID лучше использовать: ZRAID2 или достаточно ZRAID? Зависит от количества и размера дисков в массиве, режимов работы/нагрузки на них, в случае с ZFS ещё и recordsize. Почему появился RAIDZ2 (или RAID6)? Потому-что размеры дисков растут быстрее чем их скорость работы. Если в массиве RAID5/RAIDZ вылетает диск, но всё начинает rebuild-ится, находится под бешенной нагрузкой. С маленькими размерами диска rebuild занимает вменяемое время. С большими дисками может занимать дни/неделю. Так как диски в основном ставят более-менее из одной партии, то вероятность что ещё кто-то кокнется из этих же дисков -- высока. А когда они ещё и под бешеной нагрузкой -- ещё выше. Отсюда и появились RAID6/RAIDZ2 где два диска могут вылететь и ничего плохого не случится. RAIDZ3 -- аналогичное продолжение, где уже три диска. В ZFS с RAIDZ ещё добавляются вопросы по эффективности использования места. В некоторых конфигурациях можно с ним потерять половину места. Советую вот эту статью посмотреть: https://www.delphix.com/blog/delphix-engineering/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz И не забывать что можно/стоит использовать не один RAIDZ массив, а stripe из нескольких. >- Имеет ли смысл использовать stripped mirror или это неоправданно >(максимум может быть 8 дисков в корзине, но пока будет 4)? Может быть оправдано. Всё индивидуально :-). >- Имеет ли смысл включать сжатие (в приведённой выше конфигурации)? Практически всегда не имеет смысла не включать его (compression=lz4). Если заранее известно что там будет только плохосжимаемые данные, то да, можно отключить. LZ4 безумно быстрая штука, которая хорошо понимает что ей суют несжимаемые данные и она оставит их "как есть" -- не будет overhead-а как от сжатия. Сжатие тут как-правило только ускорит всё: так как данных между дисков и системой надо просасывать меньше. Ну и просто приятно видеть как du для MongoDB может показать 20 GB, хотя реально в ней данных на 60 -- JSON/BSON хорошо сжимаются и получается отличная экономия RAM, как кэша ФС, ведь в ней сжатые ZFS объекты хранятся. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** artiom [2018-01-07 21:09]: >А вообще есть ли смысл в ZFS на системном SSD? Ну а почему нет? Вообще почему ZFS может не иметь смысла :-)? Как минимум, бэкапы удобнее делать (snap/send/recv) и проверка целостности. >Где-то я читал, что выигрыш от переноса журнала на SSD порядка 0.3. Всё зависит от режимов работы (fsync). >Как сбалансировать надёжность хранения журнала и скорость работы с ним? По идее, если понадобился ZIL/log, то просто делают зеркало из него. То есть, в идеале, это например просто две SSD в зеркале, отданные от log. >Да ну. При хотсвопе это возможно сделать автоматически. >[...] >Чем такая схема хуже? Всё что вы написали верно. Но всё это подразумевает, что у вас *есть* ключ шифрования. Вы не можете отдать ваши диски кому-нибудь чтобы он например сделал resilver или scrub или send/recv ваших дисков. Вы не можете подключить чужие зашифрованные диски чтобы просто проверить scrub-ом их целостность. Мало ли чего бывает. ZFS некоторые задачи по обслуживанию может провести без ключа. Лично я нисколько не призываю к использованию ZFS шифрования из-за этих фич. Они не всем нужны. Так как ваш сервер домашний, то ключи наверняка всегда, как бы, под рукой и поэтому все эти фишки бесполезны. Я просто отметил в чём могут быть плюсы встроенного шифрования. >Но, фактически, такое шифрование открывает информацию, значит не >является надёжным. Это всё tradeoff как и в случае с "классическим" полнодисковым шифрованием. Например часто используется (ну когда-то, как минимум) CBC режим "сливал" данные о конкретном месте с которого началось изменение данных в пределах блока жёсткого диска. Да -- это слив данных, но надо прикидывать и оценивать чему он может грозить. Большинству пользователей он ничему не грозит и поэтому он по-умолчанию повсеместно использовался. Для тех кто готов "сливать" только факт изменения всего блока, но не конкретной позиции в нём, есть режим EME -- который делает двойное шифрование (туда-обратно), что в два раза дороже для CPU, но да -- надёжнее. Или вот GELI/LUKS по-умолчанию не предоставляют никакой аутентификации данных, так как это начнёт занимать дополнительное место, но тоже не самый безопасный вариант. Если вы сделаете GELI/LUKS диск поверх чистого, забитого нулями, то, пока полностью весь диск не будет записан (хотя бы dd if=/dev/zero of=disk-encrypted), то информация о реально используемом месте будет тоже "видна". Везде tradeoff. Это я всё к тому что не стал бы называть ZFS шифрование не надёжным. По-сравнению с LUKS/GELI -- оно больше выдаёт метаинформации, согласен (но, взамен давая "плюшки"). -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
Да, и мне говорили, что в OMV (в Linux реализации вообще) есть проблемы с кэшэм. Не стоит использовать OMV? Вопрос не политический, а чисто практический: изначально я был нацелен на OMV, потому что мне проще иметь везде одну ОС и я относительно знаю Debian, но по поступившим данным, выяснилось, что это будет не самое надёжное решение, потому сейчас я склоняюсь к FreeNAS.
Re: Снова о ZFS
Ещё вопросы: - Какой ZRAID лучше использовать: ZRAID2 или достаточно ZRAID? - Имеет ли смысл использовать stripped mirror или это неоправданно (максимум может быть 8 дисков в корзине, но пока будет 4)? - Имеет ли смысл включать сжатие (в приведённой выше конфигурации)?
Re: Снова о ZFS
>> Имеет ли смысл? Я планировал установку на SSD. Т.к., SSD достаточно большой, >> там же хочу держать кэш/журналы ZFS, значит требуется два раздела минимум. > > Тогда смысла "чистого" ZFS не имеет конечно же. А вообще есть ли смысл в ZFS на системном SSD? > Держать кэш на > ненадёжном хранилище можно без проблем, а вот если под журналом вы > подразумеваете ZIL (который "log" в терминах zpool), то его очень > желательно зеркалировать. Ну и иметь в виду, что ZIL/log имеет смысл > только и только для fsync операций: если их мало/нет, то он не даст > ничего. > С кэшэм понятно. А вот насчёт ZIL... Где-то я читал, что выигрыш от переноса журнала на SSD порядка 0.3. Как сбалансировать надёжность хранения журнала и скорость работы с ним? >> В смысле "без предоставления ключа"? Имеется ввиду, что он хранится >> глобально? > > В том смысле, что не делая аналога luksOpen/geli attach, вы всё-равно > сможете делать scrub/resilver/send/recv. Да ну. При хотсвопе это возможно сделать автоматически. Например, для шифрования ключей я использую ключевой файл, который хранится на зашифрованном диске (типичная схема для LUKS с несколькими дисками). Также, есть первичный ключ. Диск в корзину вставляется, udev (условно) запускает хэндлер, который запускает file на устройство, чтобы определить есть ли там шифрование. Затем, если есть, пытается расшифровать. Если нет, автоматически затирает то, что на диске, создавая шифрованный раздел и подключает его в zpool. Если это шифрованный диск, но с другим ключом, может быть выдано предупреждение, используя REST API web интерфейса. Это вкратце. Чем такая схема хуже? > В отличии от полнодискового > шифрования, вы будете знать сколько там реально занято места и размеры > объектов. > Но, фактически, такое шифрование открывает информацию, значит не является надёжным. Потому, остаётся вопрос насчёт geli. На хабре разбирался код ZFS, и там явно видно, что она пытается сделать ioctl, чтобы определить диск/не диск.
Re: Снова о ZFS
*** Артём Н. [2018-01-07 20:12]: >Вопрос был в том, как она работает не с "голым диском"? А, пардон, всё перепутал. О проблемах с не голым диском не слышал. >Имеет ли смысл? Я планировал установку на SSD. Т.к., SSD достаточно большой, >там же хочу держать кэш/журналы ZFS, значит требуется два раздела минимум. Тогда смысла "чистого" ZFS не имеет конечно же. Держать кэш на ненадёжном хранилище можно без проблем, а вот если под журналом вы подразумеваете ZIL (который "log" в терминах zpool), то его очень желательно зеркалировать. Ну и иметь в виду, что ZIL/log имеет смысл только и только для fsync операций: если их мало/нет, то он не даст ничего. >Ладно trim, пробрасывается ли другие специфичные ioctl к диску или это будет >ioctl к geli? Тут ничего не могу сказать. >В смысле "без предоставления ключа"? Имеется ввиду, что он хранится глобально? В том смысле, что не делая аналога luksOpen/geli attach, вы всё-равно сможете делать scrub/resilver/send/recv. В отличии от полнодискового шифрования, вы будете знать сколько там реально занято места и размеры объектов. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
On 07.01.2018 19:22, Sergey Matveev wrote: *** artiom [2018-01-07 18:51]: - ZFS более оптимально работает с голым диском (делает ioctl, определяет диск ли это, если результат вызова положительный, выставляет оптимальные для себя параметры работы). Будет ли работать ZFS также оптимально через различные слои, в частности LUKS или gely? С голым диском работает без проблем. Но возможно надо будет указывать ashift параметр: http://www.open-zfs.org/wiki/Performance_tuning#Alignment_Shift_.28ashift.29 для дисков с 4KB размером блока. Это очевидно. Вопрос был в том, как она работает не с "голым диском"? Где то я видел что иногда ZFS не справляется с автоматическим нахождением всех членов пула если диски переименовываются (был sda, стал sdb, итд). И давали совет всегда делать ZFS поверх хотя бы GPT раздела с label-ом. Этот label очевидно при смене контроллера/диска/backplane не будет меняться, в отличии от имени диска. Кроме того, GPT ещё и от необходимости ashift избавит. Не будет менять контроллер (это смена платы, потому что он встроен), ни имя диска (диски в корзине). ZFS раздел в начале имеет немного зарезервированного места в которое например можно засунуть загрузчик ОС. FreeBSD например может быть полностью установлена на диск без каких-либо MBR/GPT на чисто ZFS диск. https://www.unix.com/man-page/freebsd/8/zfsboot/ Имеет ли смысл? Я планировал установку на SSD. Т.к., SSD достаточно большой, там же хочу держать кэш/журналы ZFS, значит требуется два раздела минимум. Насчёт ZFS поверх LUKS слышал что люди делают и проблем не было. Сам я использую ZFS поверх GELI -- тоже проблем нет. Более того, GELI даже TRIM-ы "пробрасывает" наверх по-умолчанию, так что SSD-GELI-ZFS всё-равно будет с TRIM-ом. Ладно trim, пробрасывается ли другие специфичные ioctl к диску или это будет ioctl к geli? - Если нет, то насколько стабильно, надёжно, изучено шифрование ZFS (по сравнению с вышеназванными)? Выполняется ли полнодисковое шифрование или это шифрование пофайловое (+метаданные)? Есть ли защита от cold boot attack (как в Linux ZFS, так и в BSD ZFS)? Родное шифрование сделано вроде бы грамотно, но оно не полнодисковое. Только часть метаинформации и данные шифруются и аутентифицируются. Плюсы родного шифрования: scrub, resilver, send/recv будут работать без предоставления ключа, тогда как с LUKS/GELI, не "открыв" ключом диск, нельзя будет сделать ничего. В смысле "без предоставления ключа"? Имеется ввиду, что он хранится глобально? Я пока не задумывался, как будет делать хот-своп для шифрованного диска, но возможно это будет сделать через udev (или аналогичную систему во FreeBSD). Т.е., если система работает, ничто не мешает мне проверить наличие шифрования с данным ключом у воткнутого диска. Если диск не шифрован, я просто создам шифрованный раздел, используя известный "ключ". Насчёт cold boot защиты не в курсе касательно ZFS. В Linux есть патч, переводящий ключи LUKS в регистры.
Re: Снова о ZFS
*** artiom [2018-01-07 18:51]: >- ZFS более оптимально работает с голым диском (делает ioctl, определяет >диск ли это, если результат вызова положительный, выставляет оптимальные >для себя параметры работы). Будет ли работать ZFS также оптимально через >различные слои, в частности LUKS или gely? С голым диском работает без проблем. Но возможно надо будет указывать ashift параметр: http://www.open-zfs.org/wiki/Performance_tuning#Alignment_Shift_.28ashift.29 для дисков с 4KB размером блока. Где то я видел что иногда ZFS не справляется с автоматическим нахождением всех членов пула если диски переименовываются (был sda, стал sdb, итд). И давали совет всегда делать ZFS поверх хотя бы GPT раздела с label-ом. Этот label очевидно при смене контроллера/диска/backplane не будет меняться, в отличии от имени диска. Кроме того, GPT ещё и от необходимости ashift избавит. ZFS раздел в начале имеет немного зарезервированного места в которое например можно засунуть загрузчик ОС. FreeBSD например может быть полностью установлена на диск без каких-либо MBR/GPT на чисто ZFS диск. https://www.unix.com/man-page/freebsd/8/zfsboot/ Насчёт ZFS поверх LUKS слышал что люди делают и проблем не было. Сам я использую ZFS поверх GELI -- тоже проблем нет. Более того, GELI даже TRIM-ы "пробрасывает" наверх по-умолчанию, так что SSD-GELI-ZFS всё-равно будет с TRIM-ом. >- Если нет, то насколько стабильно, надёжно, изучено шифрование ZFS (по >сравнению с вышеназванными)? Выполняется ли полнодисковое шифрование или >это шифрование пофайловое (+метаданные)? Есть ли защита от cold boot >attack (как в Linux ZFS, так и в BSD ZFS)? Родное шифрование сделано вроде бы грамотно, но оно не полнодисковое. Только часть метаинформации и данные шифруются и аутентифицируются. Плюсы родного шифрования: scrub, resilver, send/recv будут работать без предоставления ключа, тогда как с LUKS/GELI, не "открыв" ключом диск, нельзя будет сделать ничего. Насчёт cold boot защиты не в курсе касательно ZFS. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Снова о ZFS
Я помню, что было много тем про неё. Но сейчас, когда последние железные компоненты наконец-то доезжают до меня, я начал разбираться подробнее, и появились новые вопросы. Кратко: требуется построить квартирный NAS, ближе к hi-end (Xeon, ECC RAM 16 Gb, 4x4TB HDD SAS Hitachi/HGST, мать Mini-ITX extended ASRock серверный). Вопросы: - Насколько стабилен ZFS в OMV или всё-таки имеет смысл использовать FreeNAS, а от идеи с OMV отказаться? - ZFS более оптимально работает с голым диском (делает ioctl, определяет диск ли это, если результат вызова положительный, выставляет оптимальные для себя параметры работы). Будет ли работать ZFS также оптимально через различные слои, в частности LUKS или gely? - Если нет, то насколько стабильно, надёжно, изучено шифрование ZFS (по сравнению с вышеназванными)? Выполняется ли полнодисковое шифрование или это шифрование пофайловое (+метаданные)? Есть ли защита от cold boot attack (как в Linux ZFS, так и в BSD ZFS)? Пока всё. Жду ответов от имеющихся здесь экспертов. По ходу обсуждения будут новые вопросы.
