ZFS on Linux: вести с полей 2017

  • Tutorial
ZFS является одной из самых нафаршированных файловых систем (ФС), а главное — она заботится о сохранности нашей информации. Да, она не является «серебряной пулей», но в своей области показывает прекрасные результаты.
ZFS

Проект ZFS on Linux изначально был создан для портирования существующего кода из Solaris. После закрытия его исходного кода совместно с сообществом OpenZFS проект продолжил разработку ZFS для Linux. Код может быть собран как в составе ядра, так и в виде модуля.
image
Сейчас пользователь может создать пул с последней совместимой с Solaris версией 28, а также с приоритетной для OpenZFS версией 5000, после которого началось применение feature flags (функциональные флаги). Они позволяют создавать пулы, которые будут поддерживаться в FreeBSD, пост-Sun Solaris ОС, Linux и OSX вне зависимости от различий реализаций.

В 2016 году был преодолён последний рубеж, сдерживавший ZFS на Linux — многие дистрибутивы включили его в штатные репозитории, а проект Proxmox уже включает его в базовую поставку. Ура, товарищи!

Рассмотрим как наиболее важные отличия, так и подводные камни, которые есть в настоящее время в версии ZFS on Linux 0.6.5.10.

Начинать знакомство с ZFS стоит с изучения особенностей CopyOnWrite (CoW) файловых систем — при изменении блока данных старый блок не изменяется, а создается новый. Переводя на русский — происходит копирование при записи. Данный подход накладывает отпечаток на производительности, зато даёт возможность хранить всю историю изменения данных.

image

CoW подход в ZFS даёт огромные возможности: эта ФС не может иметь некорректного состояния, т.к. в случае проблем с последней транзакцией (например при отключении питания) будет использована последняя корректная.

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

Кратко о главных преимуществах ZFS для вашей системы.


Защита данных:

  1. контрольные суммы — гарантия корректности данных;
  2. возможность резервирования как на уровне создания зеркал и аналогов RAID массивов, так и на уровне отдельного диска (параметр copies);
  3. в отличие от многих файловых систем с их fsck на уровне журнала, ZFS проверяет все данные по контрольным суммам и умеет проводить их автоматическое восстановление по команде scrub (если в пуле есть живая копия битых данных);
  4. первая ФС, разработчики которой честно признались во всех возможных рисках при хранении — везде при упоминании ZFS можно встретить требование оперативной памяти с поддержкой ECC (любая ФС имеет риск повреждения при отсутствии ECC памяти, просто все, кроме ZFS, предпочитают не задумываться об этом);
  5. ZFS создавалась с учетом ненадёжности дисков, просто помните это и перестаньте волноваться о вашем WD Green Seagate etc (только, если рядом трудится ещё один выживший диск).

Максимальная гибкость вашего хранилища:

  1. закончилось место? Замените диск на более объёмный, и ваш покорный ZFS сам займёт новоотведённое ему место (по параметру autoexpand);
  2. лучшая реализация снапшотов среди файловых систем для Linux. На это подсаживаешься. Инкрементально по сети, в архив, /dev/null, да хоть раздвойте личность вашего дорогого Linux в реальном времени (clone);
  3. нужно больше золота места? 256 зебибайт хватит всем!

Структура.


В ZFS структура хранилища выглядит следующим образом:

- pool
-- vdev (virtual device) - объединяет носители (в mirror, stripe и др.)
--- block device - диск, массив, файл

В пуле может быть неограниченное количество vdev, что позволяет создать пул из двух и более mirror, RAID-Z или других сочетаний. Также доступны классические RAID10 и т.д.

Типы массивов:


Stripe — обычный RAID0.

Mirror — RAID1 на манер ZFS — реплицируются только занятые блоки, забудьте о синхронизации пустого места.

RAID-Z — создавался как замена RAID5-6, но имеет большие отличия:

— каждый блок данных — аналог отдельного массива (с динамической длинной);
— отсутствует проблема write hole;
— при ребилде создаются только данные (т.е. риск сбоя в этот момент уменьшается). Также в тестовой ветке уже находятся улучшения, которые дополнительно ускорят этот процесс.

Рекомендуется использовать RAID-Z2 (аналог RAID6). При создании RAID-Z стоит обязательно изучить эту статью, основные нюансы:

— IOPS равен самому медленному диску (создавайте RAID-Z с наименьшим количеством дисков);
— эффективность утилизации места увеличивается при бОльшем количестве дисков в массиве (требуется задать корректный recordsize, см. ссылку выше);
— в существующий массив RAID-Z нельзя добавить ещё один диск (пока), но можно заменить диски на более ёмкие. Эта проблема решается созданием нескольких массивов в рамках одного vdev.

dRAID (в разработке) — базируется на наработках RAID-Z, но при сбое позволяет задействовать на чтение-запись все диски массива.

ARC — умное кеширование в ZFS.


CoW ухудшает производительность. Для сглаживания ситуации был создан adaptive replacement cache (ARC). Его основная особенность в проработанных эвристиках для исключения вымывания кеша, в то время как обычный page cache в Linux к этому очень чувствителен.

Бонусом к ARC существует возможность создать быстрый носитель со следующим уровнем кеша — L2ARC. При необходимости он подключается на быстрые SSD и позволяет заметно улучшить IOPS HDD дисков. L2ARC является аналогом bcache со своими особенностями.

L2ARC стоит использовать только после увеличения ОЗУ на максимально возможный объём.

Также существует возможность вынести запись журнала — ZIL, что позволит значительно ускорить операции записи.

Дополнительные возможности.


Компрессия — с появлением LZ4 позволяет увеличить скорость IO за счёт небольшой нагрузки на процессор. Нагрузка настолько мала, что включение данной опции уже является повсеместной рекомендацией. Также есть возможность воспользоваться другими алгоритмами (для бекапов прекрасно подходит gzip).

Дедупликация — особенности: процесс дедупликации производится синхронно при записи, не требует дополнительной нагрузки, основное требование — ~ 320 байт ОЗУ на каждый блок данных (Используйте команду zdb -S название_пула для симуляции на существующем пуле) или ~ 5гб на каждый 1 тб. В ОЗУ хранится т.н. Dedup table (DDT), при недостатке ОЗУ каждая операция записи будет упираться в IO носителя (DDT будет читаться каждый раз с него).
Рекомендуется использовать только на часто повторяющихся данных. В большинстве случаев накладные расходы не оправданы, лучше включить LZ4 компрессию.

Снапшоты — в силу архитектуры ZFS абсолютно не влияют на производительность, в рамках данной статьи на них останавливаться не будем. Отмечу только прекрасную утилиту zfs-auto-snapshot, которая создаёт их автоматически в заданные интервалы времени. На производительности не отражается.

Шифрование (в разработке) — будет встроенным, разрабатывается с учётом всех недостатков реализации от Oracle, а также позволит штатными send/receive и scrub отправлять и проверять данные на целостность без ключа.

Основные рекомендации (TL;DR):


— Заранее продумайте геометрию массива, в настоящий момент ZFS не умеет уменьшаться, а также расширять существующие массивы (можно добавлять новые или менять диски на более объёмные);
— используйте сжатие:

compression=lz4

— храните расширенные атрибуты правильно, по умолчанию хранятся в виде скрытых файлов (только для Linux):

xattr=sa

— отключайте atime:

atime=off

— выставляйте нужный размер блока (recordsize), файлы меньше recordsize будут записываться в уменьшенный блок, файлы больше recordsize будут записывать конец файла в блок с размером recordsize (при recordsize=1M файл размером 1.5мб будет записан как 2 блока по 1мб, в то время как файл 0.5мб будет записан в блок размером 0.5мб). Больше — лучше для компрессии:

recordsize=128K

— ограничьте максимальный размер ARC (для исключения проблем с количеством ОЗУ):

echo "options zfs zfs_arc_max=половина_ОЗУ_в_байтах" >> /etc/modprobe.d/zfs.conf
echo половина_ОЗУ_в_байтах >> /sys/module/zfs/parameters/zfs_arc_max


— дедупликацию используйте только по явной необходимости;
— по возможности используйте ECC память;
— настройте zfs-auto-snapshot.

Важные моменты:


— многие свойства действуют только на новые данные, к примеру при включении сжатия оно не применится к уже существующим данным. В дальнейшем возможно создание программы, применяющей свойства автоматически. Обходится простым копированием.
— консольные команды ZFS не запрашивают подтверждение, при выполнении destroy будьте бдительны!
— ZFS не любит заполнение пула на 100%, как и все другие CoW ФС, после 80% возможно замедление работы без должной настройки.
— требуется правильно выставлять размер блока, иначе производительность приложений может быть неоптимальна (примеры — Mysql, PostrgeSQL, torrents).
делайте бекапы на любой ФС!

В настоящий момент ZFS on Linux уже является стабильным продуктом, но плотная интеграция в существующие дистрибутивы будет проходить ещё некоторое время.

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

Я, gmelikov, состою в проекте ZFS on Linux и готов с радостью ответить на любые вопросы!
Отдельно хочу пригласить к участию, всегда рады issues и PR, а также готовы помочь вам в наших mailing lists.

Полезные ссылки:

ZFS on Linux github page
FAQ
ZFS Performance tuning
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 138
  • 0
    Дополнительно стоит добавить, что на подходе версия 0.7, в которую включено огромное количество изменений, проведена работа по синхронизации кодовой базы с OpenZFS, а также внесены значительные изменения во взаимодействие с памятью.
    • 0
      Подскажите пожалуйста, OpenZFS может выступить iscsi initiator? сможет ли с таким томом работать windows? возможна ли загрузка с такого тома. Для меня вообще стало новостью что iscsi может расшарить не блочное устройство.
      • +1

        iSCSI может, но не своими средствами. Сначала нужно сделать zvol — вид датасета, предоставляющий интерфейс блочного устройства.
        Делается легко, например:


        zfs create -V 30G PoolName/volume_name

        Где 30G — объем.
        Затем такое блочное устройство нужно "расшарить" с помощью isci-tartet.


        Снэпшоты и прочие радости ZFS доступны и для zvol.

        • 0
          вау, спасибо!
          интересно, как у этого метода с производительностью.
          загрузка операционной системы с такого тома возможна?
          • 0

            Я только немного экспериментировал с iSCSI, поэтому о производительности такого use-case не могу глубоко рассуждать.
            Но, в общем, производительность сильно зависит от конфигурации vdev.
            Например, принято считать, что для ZRAID* — это производительность самого медленного в массиве HDD.
            Страйп зеркал будет быстрее.
            И еще скорость сильно проседает, если много операций синхронной записи. Тут либо ZIL, либо sync=disabled (если приемлемо) помогут.
            Так же от параметра volsize и паттерна IO приложения зависит…
            В общем, вооружившись fio и его конфигурацией, похожей на паттерн Вашего приложения, можно тюнить...

            • 0

              В RAID-Z IOPS самого медленного диска, последовательная запись в норме.

          • 0

            О, а подскажите, в сценарии, когда ZVOL, SSD и потому ext4 — при использовании ZVOL очень резко снижается количество свободного места (по сравнении с без ZVOL или просто ext4) и это очень чувствительно на ссд, которые и так маленькие. Нельзя ли на это как-то влиять?

            • 0
              Что вы имеете в виду?

              Опишите полностью вашу установку, геометрию пула (mirror, raid-z).
              • 0

                Один ссд. Совсем один. На нем zvol. Размером на весь диск, для теста (потому что нам нужно одновременно сжатие и ext4), на zvol — ext4.

                • 0
                  Если не создаются снапшоты, то место не должно съедаться больше, чем без zfs. Также можете попробовать на ext4 провести trim, после этого zfs отобразит только занятое место, скорее всего это вас смущает (zfs под занятым местом в zvol понимает любой когда-либо аллоцированный блок, не освобождённый).

                  Подскажите, а зачем вам ext4 в такой конфигурации?
                  • 0

                    Мы привязаны к OpenVZ. OpenVZ привязана к ext4. При этом у нас очень хорошо сжимаемые данные и deduplication ratio за 100, поэтому хочется уровнем ниже ext4 иметь сжатие и дедупликацию. Правда на дедупликацию при блок сайз = 4к не всегда есть память (некоторые ссд за терабайт, в некоторых серверах 32гб памяти и нельзя поставить больше)


                    Сравниваю получившийся размер раздела после создания (т.е. диск пустой, раздел делается на весь диск).


                    Судя по логам, которые нашел сходу, у меня получалось так:


                    Тесты на ссд на 480 гигабайт.


                    Если просто ext4, то df -h показывает size = 441G


                    Если


                    zpool create -o ashift=9 vzpool /dev/sdb1 
                    zfs create -o mountpoint=/vz2  vzpool/private

                    то получившийся size похоже то ли 440, то ли ~420.


                    Если


                    zpool create -o ashift=9 vzpool /dev/sdb1
                    zfs create -V 416G -o volblocksize=4k vzpool/vz2
                    mkfs.ext4 ...

                    то size в df -h оказывался 383G


                    В цифрах могут быть ошибки, делал заметки по ходу тестирования, но порядок разницы примерно такой. Если нужно — могу найти сервер с свободным ссд и проверить снова.

                    • +1
                      Скорее всего у вас сочетание ashift=9 и несоответствующего ext4 volblocksize.
                      Выставьте нужный ashift вашему ssd, очень маловероятно, что он 9 (512 байт на блок), к тому же некоторые производители указывают не фактический размер блока.
                      Т.к. Стандартный размер блока ext4 4kb, то создавать zvol лучше с таким же размером блока.
                      zfs create -b 4096 -V size volume
                      


                      В основном это может быть влияние выставленного вами ashift.
                      • 0

                        Посчитал.


                        • если ext4 на 480гб SSD диске, то доступно 440 гигабайт.
                        • если просто ZFS то 430 гигабайт
                        • если ext4 на ZVOL — всего 398 гигабайт

                        Кстати, у ссд дисков (по крайней мере наших) размер сектора таки 512 байт. Все, конечно, наверное, знают, что любая запись там перезаписывает блок на 128к, но все же.


                        Статистика по размерам файлов (какие лучше выбрать параметры для блок сайз и прочего исходя из этого?)


                        • Средний размер маленького файла — чуть меньше 1 килобайта и таких файлов 65%
                        • Средний размер вообще — 9 килобайт
                        • Более 100 килобайт — средний размер ~500 килобайт и таких файлов 4%
                        • Более одного мегабайта — средний размер 11 мегабайт и таких файлов ~0.15%

                        Как все это считалось в красивом оформлении — https://gist.github.com/knutov/453fa860e4f574ac01413273cf79392f


                        И кстати, как я должен был угадать размер ZVOL, если я хотел сделать его на весь диск, и почему потом получилось больше?


                        Прокомментируйте пожалуйста это, возможно я делаю что-то неправильно?

                        • 0
                          Кстати, у ссд дисков (по крайней мере наших) размер сектора таки 512 байт

                          Не спорю, просто рекомендую проверить, в списках рассылки ZFS эта тема уже поднималась, есть некоторые модели дисков, у которых заявленное производителем не сходится с фактическим.

                          если ext4 на 480гб SSD диске, то доступно 440 гигабайт.

                          По приведённой вами ссылке я вижу другую цифру —
                          Если использовать 4 килобайта на иноду (что кажется логичнее), то свободного места на пустом диске будет меньше — 419G
                          То есть для ext4 по умолчанию доступно тоже меньше. Прошу точно описывать исходные данные, иначе диалог неконструктивен.

                          если ext4 на ZVOL — всего 398 гигабайт

                          Момент, который стоит учитывать в расчётах — метаданные. Естественно вы не заполните все 430гб сырого места пула. Чем больше будет volblocksize, тем меньше метаданных будет. Точный расчёт их размера произвести не так просто, т.к. они тоже сжимаются. Ссылка на тему. Т.к. вы используете -V (резервируете место), то ZFS съедает нужное количество места для гарантированной возможности записи зарезервированного места.

                          Плюс, как уже во многих комментариях и статье упоминалось, ZFS не предназначена для заполнения на 100%, что также ведёт к рекоммендациям не выделять всё место под ZVOL, при максимальном заполнении будут накладные расходы.

                          Функционал ZFS требует метаданных большего размера, чем другие ФС, контрольные суммы, снапшоты и другой функционал требует хранения, и чем меньше блок, тем больше метаданных будет.
                          • 0

                            Если я не указываю ashift (ashift=0) то zfs сам выбирает ashift=9.


                            Да, с размером блока недоработка была, поправил https://gist.github.com/knutov/453fa860e4f574ac01413273cf79392f


                            • если ext4 на 480гб SSD диске, то доступно 440 гигабайт (16к на иноду)
                            • если ext4 на 480гб SSD диске, то доступно 419 гигабайт (4к на иноду)
                            • если просто ZFS то 430 гигабайт
                            • если ext4 на ZVOL — 398 гигабайт (blocksize=4k)
                            • если ext4 на ZVOL — 417 гигабайт (blocksize=16k)

                            Но — размер блока ext4 и размер инода — разные вещи.


                            В тесте у ext4 везде размер блока оставлен по умолчанию ( -b 4096 ). В случае с ZVOL при блоксайзе 4к это 398 гигабайт вместо 440.


                            А вот если сделать блоксайз равный размеру инода (16к) — тогда да, получаем 417 гигабайт ext4 на zvol против 440 у ext4 без zfs, что лучше, но все равно — вы выше утверждали


                            место не должно съедаться больше, чем без zfs

                            а судя по тестам — это не так и без ZFS места намного больше.


                            Учитывая, что у меня SSD — вряд ли можно получить какую-то разницу в скорости работы при разных размерах чего угодно, по крайней мере на чтение. По этому, помня, что я хочу дефрагментацию и у 65% файлов размер менее 1 килобайта — разве не логичнее использовать более маленький volblocksize?

                            • 0
                              Но — размер блока ext4 и размер инода — разные вещи.

                              Спасибо, перепутал, но в данном случае не критично. Если вас устроит, что при запросе с диска ZFS будет выбирать блок до 16кб для любого маленького файла (а с учётом сжатия он в любом случае будет меньше), то увеличение blocksize=16k для вас целесообразно.

                              а судя по тестам — это не так и без ZFS места намного больше.

                              Извините, погорячился с утверждением, более корректно — ZFS требует дополнительного места под метаданные, в остальном всё так же.

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

                              Верно, рекомендую провести тестирование производительности и убедиться.

                              По этому, помня, что я хочу дефрагментацию

                              На дефрагментацию вообще не смотрите, до заполнения 80% диска она вас не потревожит, и пусть вас не смущает показатель fragmentation у zpool — он показывает приблизительную фрагментацию метаданных, не более.

                              и у 65% файлов размер менее 1 килобайта

                              Тут критично, каким блоком будет записывать эти файлы ext4, плюс сжатие поможет компенсировать эту проблему.

                              не логичнее использовать более маленький volblocksize

                              С одной стороны — да, но в ZFS чем больше размер блока — тем лучше для производительности и сжатия, и хуже для дедупликации. Что вам приоритетнее, то и стоит выбрать.
                              • 0
                                Тут критично, каким блоком будет записывать эти файлы ext4, плюс сжатие поможет компенсировать эту проблему.

                                Миллионы мелких файлов делятся на два типа — часть из них создается одномоментно — в момент разворачивания дистрибутива Битрикса. Если писать их на диск не сразу, то — наверное запись как-то агрегируется и они будут писаться блоками по 16к? Я ведь правильно думаю, что в одном блоке может быть больше одного файла?


                                Второй тип мелких файлов — кеш битрикса. Он не дедуплицируем, но сжимаем. Но многие файлы вообще по 200 байт. Вот тут мы сможем, видимо, получить большой выигрыш, если откажемся от ext4 — на чистом зфс вроде бы можно для отдельных каталогов дедупликацию отключить и поэкономить память.

                                • 0
                                  то — наверное запись как-то агрегируется и они будут писаться блоками по 16к?

                                  В рамках ZFS — да, но у вас дополнительно есть EXT4. Это, кстати, ухудшит дедупликацию, т.к. она проводится на уровне блоков.

                                  получить большой выигрыш, если откажемся от ext4

                                  Эх, вам бы от ext4 отказаться бы. На чистом ZFS случай битрикса можно очень классно настроить.

                                  А вам точно нужна дедупликация ради ядра битрикса? Оно весит не так много и отлично сжимается. Или в планах ещё что-то?
                                  • 0
                                    Эх, вам бы от ext4 отказаться бы

                                    Да с радостью бы, но у нас еще и OpenVZ, который жестко привязан...


                                    точно нужна дедупликация ради ядра битрикса?

                                    У нас на каждом диске их несколько сотен.


                                    Мы сейчас используем бекапы с LZ4 и дедупликацией (borgbackup) — там просто фантастические цифры по сжатию, очень впечатляет.

      • 0
        Интересно было бы прямое глобальное сравнение скоростей (чтения/записи) для текущих файловых систем и новых… а так же о недостатках каждой.
        • 0
          Согласен, такое сравнение всегда интересно, но очень важно подходить к нему с учётом всех особенностей каждой ФС, на примере ZFS требуется внимательно изучить особенности Copy-on-Write.
          • +1
            Ага, например, ужасную деградацию скорости записи после заполнения >80%. Особо доставляет, когда массив под 100ТБ. Хоп! А 20Тб, извините, будем писать со скоростью черепахи.
            Снапшоты — отлично, да, быстро. Только надо помнить, что если данные меняются быстро, то скорость заполнения раздела при наличии снапшотов шустро увеличивается.
            COW очень не бесплатный, увы.
            • 0
              Согласен, COW никогда не будет бесплатной по сравнению с классическими ФС, у них разные области.

              В вашем примере могла сказаться фрагментация, ZFS по объективным причинам любит большое наличие свободного места.
              • 0
                Нет, фрагментации там практически нет, т.к хранилище использовалось практически только в режиме добавления новых файлов. Возможно, поэтому дикие тормоза случились не совсем на 80%, а чуть позже. Сейчас точно не помню, с тех пор было собрано несколько новых массивов с XFS.

                ZFS по объективным причинам любит большое наличие свободного места.

                Так добавьте это в статью. Узнать об этом, заполнив 100Тб — крайне неприятно, правда?
                • 0
                  Спасибо, добавил.

                  К сожалению, серебряной пули в этом вопросе не существует, и ZFS требует подготовки перед использованием в продакшене (как, собственно, и любая другая ФС).
              • +2
                Ага, например, ужасную деградацию скорости записи после заполнения >80%. Особо доставляет, когда массив под 100ТБ.


                Нужно всего лишь уменьшить значение metaslab_min_alloc_size (http://skeletor.org.ua/?p=3189) и запись будет быстрее. По дефолту оно слишком большое.
                Так же можно отключить/включить prefetch, nocacheflush (смотря что там происходит). Если данные не сильно важны, можно выключить sync, увеличить время сброса кеша да диск (по дефолту раз в 5 секунд).
                В целом, да, zfs немного медленнее, но это не значит, что её нельзя подтюнить для более быстрой работы.

                Насчёт снепшотов (из практики cиспользования zfs). Если diff между снепшототами (или снепшотом и текущим состоянием) достаточно большой (гигабайты, десятки/сотни гигабайт), то разницу начинаешь замечать: нагрузка на диски при таком же количестве iosp'ов значительно выше (логично почему). Так что, снепшоты не полностью бесплатны и это нужно учитывать.
                • +1
                  Нужно всего лишь уменьшить значение metaslab_min_alloc_size (http://skeletor.org.ua/?p=3189) и запись будет быстрее. По дефолту оно слишком большое.

                  Возможно, но возникают вопросы:
                  1) Инженеры Sun не понимали, что делали, что выбрали это значение на несколько порядков больше, чем «надо»?
                  2) Допустим, они ошиблись. Вы более-менее внятно понимаете — на что повлияет изменение этого параметра, где аукнется?
                  3) «будет быстрее» — насколько быстрее? Кто-то проводил тесты?

                  Это я всё к тому, что с ZFS обычно речь идет не о домашней файлопомойке, а о корпоративном хранилище, большом и ценном.
                  Я понимаю, что любая система требует настройки под конкретные задачи, но наобум крутить крутилки стораджа — это опасный путь. Он имеет право на жизнь, «безумству храбрых...» как говорится, но, согласитесь, не стоит рекомендовать его как серебряную пулю.

                  • +1
                    1) Точно так же как и остальные инженеры и разработчики ОС не всегда ставят некоторые параметры оптимальные и SUN здесь не исключение. Можно так же придраться к тому, почему бы по умолчанию не включать LZ4, раз оно сжимает «сжимаемые» данные и не трогает «несжимаемые».
                    2) Данный параметр может «аукнуться», только если у вас опять станет много свободного места (50% и более) и тогда возможно снижение скорости записи по сравнению с дефектными значениями.
                    3) тесты я не проводил, так как они будут очень хосто-зависимы, но из практики скажу следующее: есть у меня несколько одинаковых по железу серверов и так же однотипными данными. Так вот, падение скорости на запись наблюдается только у одного из них, и то, при достижении планки в 95%.

                    А насчёт серебряной пули — она действительно, если таковой не является, то явно стремиться к ней и ближе, чем любая мне известная ФС (суммарное количество преимуществ действительно намного больше, чем у других). Другое дело, что работает она как пуля только в Solaris (ни во FreeBSD, ни в Linux она не является достаточно стабильной).

                    Я думал точно так же как и вы и ко всему скептически относился, пока не поработал с ней плотно несколько лет. И вот тогда понимаешь, что её можно приспособить, практически под любые условия:
                    — нужна стабильность? пожалуйста, есть
                    — нужна супер скорость? да, тоже есть (подтюнил и вперёд)
                    — нужно что-то среднее, да тоже не вопрос.

                    Как уже перечисляли в статье, основные её преимущества это:
                    — неубиваемость. Действительно, её практически невозможно разрушить в виду особенностей строения (при каждой транзакции на диск пишутся 2 метки в начале, 2 в конце, при этом пишутся по диагонали)
                    — простота снепшотов (никакой lvm или btrfs не будет удобным настолько, насколько это делается в zfs)
                    — autoexpand — это действительно вещь и в zfs это очень просто и безболезненно.
                    — множество фич, которые можно тюнить.

                    Так же забыл добавить, что можно налету изменять размер блоков, которыми ФС пишет на диск. К примеру, если у вас на zfs postgresql (а по дефолту она пишет 8кб блоками), то нужно выставить в этой zfs тоже 8кб, тогда скорость записи значительно будет эффективнее, чем дефолтными 128кб. А если этого не знать, то можно сказать, ооо, как медленно пишет (фу, какая плохая ФС), у меня на линуксе писало быстрее.

                    Точно так, если вы не являетесь DBA, то вы не сможете выжать из БД максимум, и будете говорить, почему медленно работает.
                    • НЛО прилетело и опубликовало эту надпись здесь
                      • 0
                        С lvm всё просто — они там не «бесплатные», накладывают большой отпечаток по производительности, сама ФС о снапшотах ничего не знает.
                        С btrfs — можете почитать официальную страницу btrfs gotchas, плюс в нём нет поддержки блочных устройств (в ZFS это ZVOL).
                        • НЛО прилетело и опубликовало эту надпись здесь
                          • 0
                            Сама специфика создания снепшота — общая и одинаковая. Реализация у всех разная. К примеру, можно провести такой тест: сделать снепшот ФС, потом создать и удалить большой файл, и так проделать несколько раз. На сколько будет отличаться снепшот в разных ФС? Вот это и будет коренным отличием (если конечно отличия будут).

                            А что насчёт удобства, то для это наличии многих фич + простота использования.
                        • 0
                          Как минимум то, что в zfs это делается одной командой, а не как в lvm — lvcreate / lvremove. В btrfs видимо это учли, и поэтому там делается одной командой, но с добавлением subvolume.

                          btrfs subvolume [params]

                          в отличии от zfs:

                          zfs [params]

                          Мне удобнее писать меньше текста, выполняя команды. Если кому-то нравится набирать команды из 20-30 символов + иерархические ключи — можете портировать powershell.
                        • 0
                          то нужно выставить в этой zfs тоже 8кб, тогда скорость записи значительно будет эффективнее

                          А если дедупликация — то 320 байт на блок — это на вот этот record size, или там блок — что-то другое?

                          • 0
                            320 байт на recordsize.
                            • 0

                              Вопрос был про является ли рекордсайз блоксайзом, но я увидел


                              # zfs get all | grep -i size
                              vzpool      recordsize            128K                   default
                              vzpool/vz3  volsize               423G                   local
                              vzpool/vz3  volblocksize          16K                    -

                              Т.е. правильно ли я понимаю, что это разные вещи, и если у меня маленький средний размер файла, то мне лучше уменьшать именно recordsize ?


                              А на что тогда влияет volblocksize? Т.е. я понимаю, что это минимальная перезаписываемая порция данных и помню, что COW, но теперь не понимаю как вообще надо выбирать volblocksize и в зависимости от чего.


                              И заодним, если SSD и я очень хочу иметь много заранее очищенных блоков (и часто запускаю fstrim), а из-за COW у меня будет занято сильно больше блоков диска, чем данных — можно ли как-то управлять количеством старых копий, чтобы их было поменьше? И, например, если мне не нужны снапшоты совсем — можно ли их отключить и что-нибудь сэкономить на этом?

                              • 0
                                является ли рекордсайз блоксайзом

                                recordsize используется для dataset, а для ZVOL его аналогом является volblocksize, соответственно на ZVOL recordsize не влияет.

                                как вообще надо выбирать volblocksize и в зависимости от чего

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

                                много заранее очищенных блоков (и часто запускаю fstrim), а из-за COW у меня будет занято сильно больше блоков диска

                                Пока вы не используете снапшоты, то размер ZVOL увеличиваться не будет. Если вы создадите ZVOL в режиме sparse (т.н. thin-provisioning, который в случае с COW практически бесплатен), то trim будет освобождать место и ZVOL будет занимать на пуле только занятое данными место.

                                можно ли их отключить и что-нибудь сэкономить на этом?

                                Особо не сэкономите ничего, просто не пользуйтесь.
                          • 0
                            «Нужно всего лишь уменьшить значение metaslab_min_alloc_size (http://skeletor.org.ua/?p=3189) и запись будет быстрее. По дефолту оно слишком большое. „

                            небольшая проблема в случае zfs on linux:
                            http://list.zfsonlinux.org/pipermail/zfs-announce/2015-September/000001.html

                            [zfs-announce] spl/zfs-0.6.5 released
                            * Removed metaslab_min_alloc_size, it was unused internally due to
                            prior changes.
                • 0

                  А что там с лицензией? Получилось втащить zfs в ядро Linux? А то я давно не слежу за темой.

                  • 0
                    Технически всё уже реализовано, а вопрос лицензии без проблем обходится сборкой модуля DKMS. За несколько лет ни разу проблем с ним не было.

                    К сожалению, интеграция в кодовую базу ядра в ближайшее время точно не произойдёт.
                  • 0
                    2.возможность резервирования как на уровне создания зеркал и аналогов RAID массивов

                    А аналог RAID-6 в ней есть (т.е. сохранность целостности при выходе из строя 2 физических дисков)?
                    • 0
                      Конечно, RAID-Z1, 2 и 3 допускают отказ 1, 2 и 3 дисков соответственно.
                    • 0
                      в существующий массив RAID-Z нельзя добавить ещё один диск (пока)

                      уже запланировано? для домашнего использования очень не хватает
                      • +1
                        К сожалению, пока планов на эту задачу нет.

                        Но вопрос удобства всё же поднимается — в OpenZFS уже появилась возможность исключать диски.
                      • 0
                        >лучше включить LZ4 шифрование.
                        ухты… новый алгоритм шифрования… ;)))
                        компрессия это а не шифрование
                        • 0
                          Упс, спасибо! Видимо наболевшее ожидание встроенного шифрования сказалось.
                          • –3

                            А про шифрование можно найти здесь!!

                          • 0

                            А рассматривается ли возможность ручного прогона дедубликации в отведённый даунтайм без необходимости включать его напостоянно? Есть один юзкейс (CI/DI сервера) когда происходит сильное дублирование данных и можно было бы по выходным прогонять дедубликатор (когда всё стоит и можно испоьзовать хоть всю память для этого). Но постоянно гонять никак т.к. память для работы нужна.

                            • 0
                              У нас был плохой опыт использования дедупликации на ZFS в SDS NexentaStor — хранилище было заполнено от силы на 50%, но в какой-то момент времени производительность катастрофически упала, до десятков кБайт/сек.
                              Миграция в течение нескольких часов одной виртуалки, потом еще нескольких, ребут жесткий хранилища со включенными виртуалками под ESXi — ожила хранилка, отключение дедупликации, миграция части виртуалок на другой СХД, потом обратно — старые остались дедуплицированными, а новые уже нет.
                              Общее решение — пересоздание массива с нуля только.
                              • +1
                                Возможно в оперативку не влезли служебные данные нужные для дедупликации. Тогда системе пришлось сбросить это на диск, а к этой таблице нужно обращаться при каждой операции чтения и записи. Там расход примерно 8гб ОЗУ на 1 тб данных
                                • 0
                                  Причины как бы понятны, но крайне неприятны.
                                  • 0
                                    Всё верно, правда DDT требуется только для записи, что в случае Daimos и произошло.
                                  • +1

                                    Ну вот в том-то и вопрос, что активация на постоянной основе спотыкается об требование памяти. Но одноразовые прогоны дедубликации по уже записанным данным может решить большинство ситуаций. Но этого как раз и не предусмотрено. Увы...

                                  • 0
                                    Кейс понимаю, но сейчас таких планов нет.

                                    Сейчас требуется около 5гб ОЗУ на 1 тб данных, они требуются только в момент записи.
                                  • +1
                                    Тема весьма интересна.
                                    Хотелось бы сравнить скорость работы текущей реализации ZFS в Linux (Debian 9.0) и Solaris (OpenIndiana Hipster).
                                    • 0
                                      Подскажите возможно ли после уничтожения датасета заставить ZFS вернуться к старому состоянию базы данных, где этот датасет будет еще живой чтобы спасти данные? Вроде бы есть «мифический» способ сделать это использую флаг -T и указав id транзакции до дестроя при импорте, но как бы я не старался, у меня не вышло.
                                      Команда выглядит примерно так:
                                      zpool import -N -o readonly=on -f -R /pool -F -T <transaction_id>
                                      • +1
                                        A deferred free means that a block has been freed but cannot be used by the pool until TXG_DEFER_SIZE transactions groups later. For example, a block that is freed in txg 50 will not be available for reallocation until txg 52 (50 + TXG_DEFER_SIZE). This provides a safety net for uberblock rollback. A pool could be safely rolled back TXG_DEFERS_SIZE transactions groups and ensure that no block has been reallocated.


                                        TXG_DEFER_SIZE = 2. Поэтому со 100% вероятностью можно восстановить только то, что было 2 транзакции назад. А если пул заполнен, то шансов ещё меньше.
                                        • 0
                                          Это понятно. К примеру мы случайно сделали destroy, затем сразу zpool export и пытаемся подключить пул со старой TXG. Проблема именно подключить… Драйвер ZFS не дает использовать старую TXG запись насколько я понял. Если есть специалисты, которые смогли найти решение данной проблемы, заклинаю, напишите как это сделать!
                                          • +1
                                            Технически, существует возможность откатиться на более ранние транзакции, которые могут быть уже повреждены — вам поможет вот этот патч. К сожалению, это не гарантированный вариант. Удачи вам!

                                            Рекомендую все действия производить над копией массива.
                                      • 0

                                        Какие сейчас минимальные адекватные требования к оперативной памяти? Мне снапшоты zfs нравятся больше чем btrfs, но память на домашней машинке ограничена (8гб, 5 постоянно занято kvm-ками). Стоит пробовать?

                                        • +1

                                          У меня в таких условиях полёт нормальный. Только надо учитывать, что ARC кеш выглядит так, как будто какое-то приложение сожрало всю память. Хотя реально эта память свободно перераспределяется под нужды приложений по требованию. Короче в моём случае работает, хоть и выглядит странно.


                                          Использую для тестирования приложений на больших БД, которые надо долго готовить для каждого прогона. А так пересоздал снапшот и готово. Очень доволен.

                                          • 0
                                            Согласен с vektory79, жить можно, однако учитывайте, что ОЗУ нужно для кеширования, вы можете сказать ZFS кешировать хоть не более мегабайта (параметр zfs_arc_max), но при этом производительность на чтение будет ожидаемо ниже.
                                            • 0

                                              Ну я ничего не указывал специально. Кеш в некоторые моменты отъедает половину оперативки. Но если я в этот момент запускаю локально приложение с прода, которое заведомо съедает всю память, то ничего летального не происходит. Кеш отдаёт память этому приложению. Ну обмен с диском начинает ожидаемо тупить. Но он и так тупил в этом случае. Ещё до установки zfs. Сейчас мне даже кажется, что после остановки приложения система быстрее вылазит из тупежей. Но конкретных замеров не делал.


                                              Или я где-то не прав?

                                              • 0
                                                Всё верно, я хотел просто указать на конкретный параметр.
                                          • 0
                                            Не увидел в статье, а Linux умеет загружаться с ZFS, как та же самая FreeBSD?
                                            • 0
                                              Да, прекрасно загружается, на 2 машинах у меня нет никаких проблем. Из минусов — установка не двумя кликами.
                                              • 0
                                                Да умеет. GRUB2 поддерживает /boot без отдельного раздела, прямо на ФС.

                                                # zpool get bootfs
                                                NAME PROPERTY VALUE SOURCE
                                                zboot bootfs zboot/ROOT local

                                                # zfs list
                                                NAME USED AVAIL REFER MOUNTPOINT
                                                zboot 621G 2,03T 136K legacy
                                                zboot/ROOT 621G 2,03T 8,98G legacy

                                                # mount | grep boot
                                                zboot/ROOT on / type zfs (rw,relatime,xattr,posixacl)

                                                Кто-то спрашивал про прозводительность (всё от IOPS дисков зависит, конфигурации RAID и кол-ва шпинделей). Вот на домашней системе

                                                Сначала смешное:

                                                # dd if=/dev/zero of=./zerodump.useless bs=128k count=102400
                                                102400+0 records in
                                                102400+0 records out
                                                13421772800 bytes (13 GB, 12 GiB) copied, 1.9465 s, 6.9 GB/s

                                                Т.е. это на самом деле данных было записано в X раз меньше — сжатие на лету.

                                                # zfs get all zboot/ROOT | grep compress
                                                zboot/ROOT compressratio 1.27x — zboot/ROOT compression lz4 inherited from zboot
                                                zboot/ROOT refcompressratio 1.55x — -------

                                                # time cp -r American\ Gods Dark\ Matter SG-1 tmp/

                                                real 0m34.449s
                                                user 0m0.016s
                                                sys 0m1.524s

                                                # du -hs tmp
                                                5,3G tmp

                                                5,3G/34.449s = .1538GB/s на копирование файлов с компрессией на одной и той-же FS.

                                                T.e. это и чтение и запись одновременно. Примечание, — компрессия для файлов-фильмов, — бесполезная трата ресурсов ЦПУ, но на производительность I/O в данном случае мало влияет.

                                                Скорость чтения и валидации данных на диске (zpool scrub zboot/ROOT):

                                                ссылка на скрин nmon: http://imgur.com/oNXmm3H

                                                image

                                                Диски SATA III Seagate Barracuda 1TB в конфигурации RAID-10

                                                config:

                                                NAME STATE READ WRITE CKSUM
                                                zboot ONLINE 0 0 0
                                                mirror-0 ONLINE 0 0 0
                                                sda2 ONLINE 0 0 0
                                                sdb2 ONLINE 0 0 0
                                                mirror-1 ONLINE 0 0 0
                                                sdc1 ONLINE 0 0 0
                                                sdd1 ONLINE 0 0 0
                                                mirror-2 ONLINE 0 0 0
                                                sde1 ONLINE 0 0 0
                                                sdf1 ONLINE 0 0 0

                                                Как-то так.
                                                • 0
                                                  Примечание, — компрессия для файлов-фильмов, — бесполезная трата ресурсов ЦПУ, но на производительность I/O в данном случае мало влияет.

                                                  В случае несжимаемых данный ZFS не проводит сжатие, можете об этом не волноваться.
                                            • 0
                                              сильно не хватает аналога reorgvg
                                              • –1
                                                давно интересовал вопрос: возможна ли установка linux на raw zfs?
                                                на freebsd работает добавлением загрузчика:
                                                dd if=/boot/zfsboot of=/dev/ada0 count=1 && dd if=/boot/zfsboot of=/dev/ada0  skip=1 seek=1024
                                                
                                                • 0
                                                  Да, прекрасно работает, выше уже ответили.
                                                  • 0
                                                    Boot vdev может быть RAID-Z'ом?
                                              • +4

                                                Использую zfs как NAS хранилку, впринципе очень доволен. LZ4 сжатие вообще огонь, на датасторах виртуалки жмутся в среднем в 2.4 раза. Прогретый ARC от 94 — 98% чтения отдает с RAM, остальное забирает L2ARC и совсем немного приходится на hdd. Не используем дедубликацию, т.к. она имеет смысл быть при блоках 4к, а для этого требуется очень много памяти.


                                                Пробывал варианты с


                                                • centos7 + openzfs
                                                • illumous — дистрибутив omnios
                                                • solaris 11.2/11.3

                                                В итоге остановился на конаничном — Solaris.


                                                типовая конфигурация у нас это:


                                                • Cisco UCS 240m4 ( cpu: 2 x E5-2699A v4, ram: 768gb, 2 x dual intel x520 10gbe, 2 x lsi sas 9200-8e )
                                                • 216BE2C-R741JBOD / SC847E2C-R1K28JBOD
                                                • SLOG: PX04SHB020 — очень рекомендую
                                                • L2ARC: HUSMM1640ASS204

                                                Тестировал fio как локально, так и экспортируюмую шару по NFSv4, так и iSCSI волум.


                                                Linux

                                                Плюсы:


                                                • Нет проблем с железом / дровами
                                                • Легко найти человека который знаком с linux
                                                • Имеется поддержка nfsv 4.1

                                                на этом пожалуй плюсы закончены


                                                Минусы:


                                                • производительность zfs меньше на процентов 15 по сравнению с тем же OmniOS, на локальных тестах + тестах по iscsi (использовал targetd lio) и на процентов 20% по сравнению с тестами по nfs.
                                                • autoreplace для пула, т.к. каждый диск у нас видится по четырем путям, нам необходимо сконфигурировать multipathd таким образом, чтобы в названии он отоброжал физическое расположение диска — в идиале полка/слот. чтобы после замены диска он автоматически выполнял реплейс.
                                                • т.к. я тестировал на centos7 при проблемах с производительностью мы имеет только счетчики из proc и стандартные утилиты типа iostat (в systemtap я не селен), что как мне кажется делает анализ производительности более сложным чем в случае с solaris base дистрибутивами.
                                                • Кластер на базе Pacemaker + Corosync. Умные проверки придется пилить руками.

                                                OmniOS

                                                плюсы:


                                                • Хорошая производительность как при локальных теста, так и при использовании nfs
                                                • Имеется платный кластер — RSF-1 заточенный под кустарные схд
                                                • Dtrace который облегчает поиск проблемных мест + множество готовых скриптов под него.
                                                • Comstar уже интегрирован с zfs (ISCSI)
                                                • Нет проблем с мультипазингом, MPxIO работает на ура.
                                                • Отличное сообщество.
                                                • FMD (fault managment daemon) — этот парень всегда пришлет письмо,
                                                  если у вас, что то сломалось (если конечно сервер и fmd еще живы). Расширяется за счет плагинов.

                                                Минусы:


                                                • Не на всем железе взлетит + проблема с драйверами, для современных 40гбе карточек.
                                                • до недавнего времени была проблема с UEFI
                                                • Админов знакомых с solaris в разы меньше.

                                                Solaris 11.3

                                                все плюсы из OmniOS, а так-же:


                                                • Производительность раза в полтара выше чем у OmniOS и тем более Linux,
                                                  как я понимаю это связанно с фитчей efficiency block allocation
                                                  котарая появилас в 36-ой версии, пула если не изменяет память.
                                                • L2ARC остается горячим при переключении кластер (активной ноды) или перезагрузки
                                                • в FMD
                                                  появились плагины io retired && zfs retired, которые отслеживают
                                                  события с I/O на диске и в случае например "дребезка" диска, помечают его
                                                  как failed и убирает из системы до выяснения обстоятельств
                                                • Sun Cluster — это парень имеет багатую историю и тесно интегрирован с
                                                  Solaris. Отлично работает, прост в использовании, вообщем нареканий нет.

                                                Минусы:


                                                • Сообщество на металинки достаточно "тухлое"
                                                • Не на всем железе взлетит + проблема с драйверами, хотя дела обстоят не так
                                                  остро как с OmniOS, а если брать сервера от Oracle так проблем вообще нет.
                                                • Нет фитчи с асинхронным удалением датасетов, например датасеты размером в
                                                  50тб удаляются сутки или двое, но зато это операция не просаживает CPU как в случае с OpenZFS.
                                                • Админов знакомых с solaris в разы меньше.
                                                • Comstar не кластирезуется из коробки, нужно допиливать.

                                                Десклеймер: По поводу производительности, настройки openzfs на linux и
                                                illumous я старался сделать как можно более одинаковыми. У Oracle ZFS естественно они отличались. Ну и естественно это мой личный опыт, ваше мнение/опыт могут отличаться.


                                                По поводу использования zfs в качестве бэка для систем виртуализации, аля Linux KVM + ZFS — посмотрите проект SmartOS, он достаточно интересный и активно развивается компанией Joyent.

                                                • –1
                                                  Как давно тестировали? В будущем релизе ZoL 0.7 включено множество оптимизаций производительности, которые, кстати, сразу портируются в OpenZFS (то есть проблемы уже не в реализации на Linux, основную проблему взаимодействия с ОЗУ уже решили в 0.7).

                                                  Эх, вот бы усилия Oracle да объединить с OpenZFS…
                                                  • +1

                                                    В начале 2016 года. Я вкратце описал почему выбор пал на Солярис, также я убежден в том, что на "родной" системе zfs работает стабильнее + fmd очень удобен в части проблем с дребезгом дисков, а также автоматического создания инцидентов о возникших проблемах. Обязательно затестирую релиз 0.7 на нотнике ))

                                                    • 0
                                                      Спасибо, была интересна актуальность.

                                                      Если я правильно понял, в ZoL есть аналог fmd — ZED.

                                                      на «родной» системе zfs работает стабильнее

                                                      Не спорю, интерес именно в накладных расходах разных реализаций.
                                                    • 0

                                                      btw, а что с "efficiency block allocation" в ZoL?


                                                      Я что-то не смог сходу разобраться в версиях и как версия 5000 относится к линейке версий в солярисе.

                                                      • 0
                                                        btw, а что с «efficiency block allocation» в ZoL?

                                                        Уточните, какая возможность конкретно интересует (желательно ссылкой), в этом направлении многое было сделано и в Oracle, и в OpenZFS.

                                                        Я что-то не смог сходу разобраться в версиях и как версия 5000 относится к линейке версий в солярисе.

                                                        OpenZFS версия 5000 базируется на версии 28 последнего релиза с открытым исходным кодом, далее новый функционал подключается через feature flags, об этом написано в статье.
                                                        Есть пересекающийся новый функционал, но его реализации несовместимы.
                                                        • 0

                                                          (я погуглил, но слово log не заметил, и потому родился вопрос)


                                                          Судя по гуглу — есть zpool version 36


                                                          36  Efficient log block allocation

                                                          У openzfs максимальная версия — 28, но, например, версия 37 — lz4 и lz4 у openzfs на сколько я вижу есть.


                                                          Поэтому непонятно что из того, что после 28ой версии, реально есть в 5000

                                                          • 0
                                                            Вот список features у OpenZFS, они немного отличаются у конкретных реализаций.

                                                            Вы можете сопоставить пересечения, но технически даже реализации LZ4 у них не совместимы.
                                                    • 0
                                                      Нет фитчи с асинхронным удалением датасетов, например датасеты размером в
                                                      50тб удаляются сутки или двое, но зато это операция не просаживает CPU как в случае с OpenZFS.

                                                      Да, это действительно так. Если нужно удалить весь пул, то пользуюсь таким хаком: делаю zpool export, zpool create -f и всё. Новый пул создан меньше чем за минуту.
                                                    • +1

                                                      Рекомендую к просмотру, хоть материал и старенький, но концепция изложена полностью:
                                                      ZFS: The Last Word in File Systems — Part 1
                                                      ZFS: The Last Word in File Systems — Part 2

                                                      • 0
                                                        Для больших инсталляций хочу сравнение производительности с ceph'ом. Да, я знаю, что они не полностью пересекаются, но в условиях «локальное всё» их вполне можно пытаться сравнивать.
                                                        • 0

                                                          Я думаю сложно будет подобрать сопостовимые конфигурации, сравнивать по price/performance?

                                                          • 0
                                                            Почему? Берём то железо, какое есть. В тесте один — zfs, в тесте два — ceph. У ceph'а можно с лёгкостью сконфигрировать вариант без избыточности, то есть использовать его просто как «shared volume». И тогда уже можно тестировать производительность cephfs/rbd VS zfs.

                                                            А если же мы говорим про варианты с избыточностью, то тут вообще всё просто — в crush map задаём «использовать osd одного хоста» и смотрим на результат.

                                                            Ключевое что в ceph было бы интересно в сравнении с zfs — абсолютная толерантость к ресайзу в любую сторону. Хоть вверх, хоть вниз. Плюс возможность работать с ним как blob-хранилищем напрямую, что может быть иногда интереснее, чем fs/блочное устройство.

                                                            Но фичи ладно. Интересно было бы raw-производительность сравнить.
                                                            • 0
                                                              Для больших инсталляций хочу сравнение производительности с ceph'ом

                                                              Ну если на текущем железе, то это не большая инсталяция ))


                                                              Без избыточности тестировать как мне кажется смысла тоже нет, т.к. тогда и
                                                              zfs можно собрать как raid0.


                                                              Если интересно, то в середине июля должнен получить очередное оборудование под NAS
                                                              ( 2 сервера + 4-ре полки на 24-ре диска) можно попробывать на них.


                                                              По Объему схожая конфигурация это:


                                                              zfs pool (Solaris):
                                                                40 x mirror - hdd 10krpm
                                                                8 x slog    - ssd
                                                                4 x l2arc   - ssd

                                                              ceph (Linux 4.X)
                                                                replicated pool == 2 copies
                                                                  node1:
                                                                    20 x osd  - hdd
                                                                    4 x ssd == 20 journal partitions
                                                                  node2:
                                                                    20 x osd  - hdd
                                                                    4 x sdd == 20 journal partitions

                                                              Берем примерно 10% от общего полезного объема


                                                              fio --time_based --name=benchmark --size=3000g --runtime=1200 --filename=/dev/sdb --ioengine=libaio --randrepeat=0 --iodepth=128 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 --numjobs=1 --rw=write --blocksize=4k --group_reporting
                                                              fio --time_based --name=benchmark --size=3000g --runtime=1200 --filename=/dev/sdb --ioengine=libaio --randrepeat=0 --iodepth=128 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 --numjobs=1 --rw=randwrite --blocksize=4k --group_reporting
                                                              fio --time_based --name=benchmark --size=3000g --runtime=1200 --filename=/dev/sdb --ioengine=libaio --randrepeat=0 --iodepth=128 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 --numjobs=1 --rw=read --blocksize=4k --group_reporting
                                                              fio --time_based --name=benchmark --size=3000g --runtime=1200 --filename=/dev/sdb --ioengine=libaio --randrepeat=0 --iodepth=128 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 --numjobs=1 --rw=randread --blocksize=4k --group_reporting
                                                              fio --time_based --name=benchmark --size=3000g --runtime=1200 --filename=/dev/sdb --ioengine=libaio --randrepeat=0 --iodepth=128 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 --numjobs=1 --rw=readwrite --blocksize=4k --group_reporting

                                                              так?


                                                              Ключевое что в ceph было бы интересно в сравнении с zfs — абсолютная толерантость к ресайзу в любую сторону

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


                                                              PS: за терминологию касательно цефа заранее извиняюсь + если тестировать будем, возможно будет полезно узнать какой то бест практис по тонкой настроки ceph.

                                                              • 0
                                                                Почти. Я бы использовал librados напрямую: --ioengine=rbd, плюс, если мы говорим про трушный бенчмарк, то --fsync=1. Я наблюдал как добавление fsync'а многие хранилки убивало к чертям в район сотен иопсов (с десятков тысяч).

                                                                Плюс на ceph'е лучше всё-таки blustore использовать, они его объявили production-ready этой весной.
                                                        • +4
                                                          Большое спасибо за статью!

                                                          Вставлю свои 5 копеек: Использую ZFS в связке с OwnCloud-сервером (как средство сихронизации пользовательских данных с Windows-машин на сервер через OwnCloud-клиент) + Samba + снапшоты.
                                                          Для себя, как администратора, сделал доступ к папке с данными через скрытый ресурс.
                                                          И через настройки Samba объяснил, как интерпретировать снапшоты ZFS:
                                                          [USERDATA$]
                                                          comment =
                                                          path = /owncloud/
                                                          public = yes
                                                          writable = no
                                                          guest ok = yes
                                                          guest only = yes
                                                          read only = yes
                                                          hosts allow = 192.168.0.2
                                                          create mask = 0777
                                                          directory mask = 0777
                                                          vfs objects = shadow_copy2
                                                          shadow: format = auto-%Y-%m-%d_%H.%M
                                                          shadow: sort = desc
                                                          shadow: snapdir = .zfs/snapshot
                                                          shadow: localtime = yes


                                                          Что мне это дало — на любом каталоге я могу вызвать в Explorer контекстное меню и выбрать пункт: Предыдущие версии. Вижу все предыдущие версии (zfs-auto-snap то работает), могу тут же их открыть и найти нужный файл нужной версии.
                                                          В добавок к этому в самом OwnCloud есть версионность и корзина.

                                                          В общем вариант, неубиваемый вирусами шифровальщиками — как бы на машине они не поработали (клиенткой) — на сервере все равно исходный вариант останется. Либо в OwnCloud, либо в ZFS.
                                                          • +1
                                                            Пилите полноценную статью, будет очень интересно.
                                                            • 0
                                                              О да!!! очень интересно!!! Я тоже хочу поднять OwnCloud. Сделайте статью с нуля по использованию ZFS+OwnCloud+Samba+снапшоты.Буду ждать!!!
                                                            • +1
                                                              А ту замечательную «особенность», когда при заполнении диска на 100% становится невозможно удалять файлы, в новой версии пофиксили? ;) Это такой знатный троллинг.
                                                              А вообще это единственная ФС, которая позволила мне стабильно зашарить раздел между Linux и OSX.
                                                              • 0
                                                                Вроде и тогда были методы почистить диск, сейчас уже не воспроизводится. Вообще CoW имеет свои особенности, это да =)
                                                                • 0
                                                                  Обновил zfs до 0.6.5.9-5 на debian jessie

                                                                  tank/rc-544 50G 50G 0 100% /var/www/rc-544/data

                                                                  При 100% забитом разделе при попытке удалить файл получаю ошибку:
                                                                  rm: cannot remove ‘backupland.com.log’: Disk quota exceeded

                                                                  Проблема обходится
                                                                  cat /dev/null > backupland.com.log
                                                                  после чего появляется чутка места и после можно уже удалить файл

                                                                  Но мне кажется это какой-то мегакостыль, есть нормальное решение проблемы?
                                                                  • 0
                                                                    Давайте вспомним, что это CoW, да, ей даже при удалении надо сначала записать.

                                                                    Плюс добавлю, что не рекомендуется заполнять пул больше, чем на 80%, дальше начнутся проблемы с фрагментированием. Последнее, что стоит делать с CoW — заполнять её на 100%, уже на 90% мониторинг обязан орать.
                                                                    • 0
                                                                      На основном пуле место свободно с большим запасом:
                                                                      NAME USED AVAIL REFER MOUNTPOINT
                                                                      tank 17.6T 7.81T 1.48T /home

                                                                      создаю я подпул так:
                                                                      /sbin/zfs create tank/rc-544 -o mountpoint=/var/www/rc-544/data -o quota=51200M

                                                                      50 гиг это же не размер раздела, а квота по сути.

                                                                      Или нужно делать quota+20%, а ограничивать через refquota?
                                                                      • 0
                                                                        Нашёл тикет, касающийся данного вопроса. Проблема квалифицирована не как баг, соответственно у неё нулевой приоритет.

                                                                        К сожалению, ZFSonLinux развивается в основном за счёт энтузиастов с упором на продакшн, удобства для десктопов только начинают получать какое-то внимание. Всегда рады пулл реквестам!
                                                                        • 0
                                                                          Мы не для десктопов zfs используем, а для бэкапов серверов.
                                                                          Сделал такой тест:

                                                                          /sbin/zfs create tank/rc-544 -o mountpoint=/var/www/rc-544/data -o quota=61440M
                                                                          /sbin/zfs set refquota=51200M tank/rc-544

                                                                          То есть размеру раздела добавляем 20% места, а квоту для пользователей делаем 50gb
                                                                          Чтобы при бэкапе если раздел заполнится на 100% по факту будет ещё 20% места в запасе.

                                                                          Ну и при попытке удалить опять получаем ошибку
                                                                          rm: cannot remove ‘backupland.com.log’: Disk quota exceeded

                                                                          • 0
                                                                            Не касаемо обсуждаемой проблемы, вы не совсем верно поняли значение quota и refquota, они в данном случае ничем не помогут, а ваши команды выполняют дословно:
                                                                            /sbin/zfs create tank/rc-544 -o mountpoint=/var/www/rc-544/data -o quota=61440M

                                                                            tank/rc-544 — quota — лимит на размер датасета, включая его дочерние датасеты
                                                                            /sbin/zfs set refquota=51200M tank/rc-544

                                                                            tank/rc-544 — refquota- лимит на размер датасета, исключая дочерние датасеты.

                                                                            То есть никакого запаса нет, вы съели всё разрешённое место (упёршись в наименьшую квоту).

                                                                            Рекомендую следить за местом и увеличивать его заранее, а не руками по факту. К сожалению, в ближайшее время это поведение точно не будет изменено.
                                                                      • 0
                                                                        Последнее, что стоит делать с CoW — заполнять её на 100%, уже на 90% мониторинг обязан орать.

                                                                        Иногда события развиваются очень стремительно. Например чекаут корневой дериктории svn, с разворотом 1500 тегов, сделаных CI.

                                                                        • 0
                                                                          дальше начнутся проблемы с фрагментированием

                                                                          Т.е. на ссд это не критично и повлиет мало?

                                                                          • 0
                                                                            Падение производительности будет меньше, но этого всё равно не стоит допускать.
                                                                    • 0
                                                                      хм а как такую ситуацию разрулили? кроме backup-format-restore?
                                                                      • 0
                                                                        Разруливалось через усечение файла.
                                                                        dd if=/dev/null of=bigfile.mkv
                                                                        rm bigfile.mkv
                                                                    • 0

                                                                      Домашний NAS стал на шаг ближе, немогу не нарадоваться!

                                                                      • 0
                                                                        gmelikov, насколько я понимаю, четверть из ARC отводится под метаданные для L2ARC. Я хотел бы использовать как можно больше l2arc, и как можно меньше отводить под ARC.

                                                                        Насколько оправдано на сервере виртуализации, использовать 2gb ARC (с настройками по-умолчанию) + 80GB l2arc? Каким образом в подобной ситуации (с минимальным размером ARC) достигнуть максимума использования l2arc?

                                                                        Спасибо!

                                                                        • 0
                                                                          Вот пример расчёта количества ОЗУ, требуемого для L2ARC.

                                                                          Я бы советовал потратить деньги на ОЗУ, L2ARC на малых конфигурациях не особо вам поможет. Также стоит учесть, что пока L2ARC не сохраняет состояние между перезагрузками, и каждый раз требует «прогрева».
                                                                          • 0
                                                                            пока L2ARC не сохраняет состояние между перезагрузками, и каждый раз требует «прогрева».
                                                                            Вы уверены? Насколько я понял что это уже исправлено. Мои беглые тесты, показали, что l2arc — используется после перезагрузки. Вроде на баг треккере уже закрыты тикеты которые вопрошали об этом.
                                                                            • 0
                                                                              Был бы рад ошибиться, но эта возможность ещё не опубликована. В ZFSonLinux появится только после публикации патча Nexenta.
                                                                              • 0
                                                                                Кажется, да, Вы не ошибаетесь. :( В общем, zfs on linux по-прежнему расстраивает (патч был представлен ещё в 2015 году).

                                                                                По калькулятору совсем не понял схему рассчётов, что-то зависит от размера блока записи, от типа записи. Но, я если честно (в силу отсутствия опыта и понимания всей картины в целом), не могу правильно аплицировать это на виртуализаию (в моём случае proxmox). Как будет вести запись вирт. машина — не знаю. Да и машины — разные.

                                                                                Пока хочу попробовать под ARC отвести 2-3 гб., после чего смотреть процент попадания в l2arc. К сожалению, сервера не имеют физической возможности расширения ОЗУ.

                                                                                Как Вы считаете, подобный подход имеет право на жизнь?
                                                                                • 0
                                                                                  патч был представлен ещё в 2015 году

                                                                                  Стоит уточнить, что стабильный патч Nexenta ещё не выпущен.

                                                                                  Расчёт простой — на каждый блок в L2ARC нужно ~200байт ОЗУ, для виртуализации скорее всего вы будете использовать zvol с volblocksize=8kb, соответственно на 100гб L2ARC потребуется около 2.5гб ОЗУ, на практике будет меньше.

                                                                                  Если у вас уже есть ssd, то проведите бенчмарк, иначе для начала просто настройте ограничение на ARC и попробуйте. Главное правильно настроить proxmox, volblocksize должен соответствовать блоку гостевой системы.

                                                                                  Производительность будет зависеть от особенностей ваших данных, если горячие данные поместятся в ваши 3гб ОЗУ, то это лучше, чем L2ARC.
                                                                                  • 0
                                                                                    Огромная благодарность за развернутый ответ. Осталось развеять только один вопрос. Что конкретно означает фраза:

                                                                                    на 100гб L2ARC потребуется около 2.5гб ОЗУ

                                                                                    Эта область ОЗУ сама будет забираться из ARC? Или максимально отводимая область под l2arc, будет регулироваться параметром: vfs.zfs.arc_meta_limit?

                                                                                    • 0
                                                                                      https://github.com/zfsonlinux/zfs/issues/1420#issuecomment-16831663

                                                                                      Да.

                                                                                      Вот интересная информация по этой теме.

                                                                                      Добавлю, что в релизе 0.7 требования к ОЗУ сильно оптимизированы, и в вашем случае может помочь (но он ещё в стадии тестирования, без бекапов ставить не рекомендую).
                                                                                      • 0
                                                                                        Добрый день, огромная благодарность за уделенное внимание! Крайне приятно общаться с разработчиком напрямую.

                                                                                        Если я верно понял, то у товарища из треда не удалялся mirror устройство, после чего, он получил объяснение, что это может происходить из-за не достатка памяти в ARC и слишком большого l2arc.

                                                                                        В следствии чего, он получил рекомендацию или увеличить ОЗУ для arc, или уменьшить разделы l2arc.

                                                                                        Если я Вас понял верно, то для 4GB RAM отведенного под ARC, мне следует ограничить l2arc размером в 60GB, тогда, в среднем, у меня будет уходить для l2arc не более 2gb RAM + 1 GB будет оставаться для собственно ARC и 1 GB под vfs.zfs.arc_meta_limit. При этом, vfs.zfs.arc_meta_limit мне не следует трогать.

                                                                                        Все ли верно понимаю?

                                                                                        Релиз 0.7, пока мне рановато применять, так-как планирую zfs в продуктивную установку.
                                                                                        • 0
                                                                                          не удалялся mirror устройство

                                                                                          Я дал ссылку на комментарий основного контрибьютора Brian Behlendorf, в котором он разъяснял требования к ОЗУ, касающиеся первого поста в тикете (проблема с производительностью при увеличении L2ARC). Проблема с mirror не касается обсуждаемого нами.

                                                                                          Все ли верно понимаю?

                                                                                          Всё верно, l2arc можете увеличивать по надобности без даунтайма, если ssd позволяет. arc_meta_limit стоит трогать только если выделенный объём l2arc не заполнится.

                                                                                          • 0
                                                                                            Благодарю! Последнее что мне не до конца ясно, это от чего я должен отталкиваться при расчетах размера l2arc устройства. От размера ARC, или от размера arc_meta_limit?

                                                                                            Если от arc_meta_limit, выходит:

                                                                                            ARC = 4GB
                                                                                            arc_meta_limit (25% от 4GB) = 1GB
                                                                                            volblocksize = 8kb


                                                                                            По формуле выходит 40GB — максимальный размер l2arc, если отталкиваюсь от arc_meta_limit.

                                                                                            Как понять сколько у меня реально испольузется l2arc? Всё же, arc_meta_used, насколько я понял, косвенный параметр.

                                                                                            За сим откланяюсь, больше не буду приставать с вопросами. Ответы на эти вопросы ищу с 2013 года, но так внятности не получил. По этому очень рад возможности спросить у компетентного разработчика!

                                                                                            Вообще, это тянет на отдельную статью на Хабре.
                                                                                            Ведь есть ещё вопрос по размеру zlog, там я понял чуть проще, размер должен быть таков, чтобы максимум за 5-10 секунд туда успела влезть вся запись с режимом sync.

                                                                                            Спасибо!

                                                                                            • 0
                                                                                              Да, arc_meta_limit ограничивает максимальное количество метаданных в кеше, а записи о l2arc являются метаданными.

                                                                                              Статистика по заполнению l2arc есть, к примеру в Linux можно посмотреть
                                                                                              cat /proc/spl/kstat/zfs/arcstats
                                                                                              


                                                                                              Рекомендую без донастроек проверить заполняемость, и только после этого по надобности тюнить arc_meta_limit, т.к. 200 байт ОЗУ на 1 блок l2arc — максимальный расчёт, а не фактический.
                                                                        • 0
                                                                          А что касаемо установки from scratch для новых систем? С какими дистрибами оно уже в поставке?
                                                                          • 0
                                                                            https://github.com/zfsonlinux/zfs/wiki/Debian-Jessie-Root-on-ZFS
                                                                            • 0
                                                                              Если вы имеете в виду установку root раздела системы на ZFS, то пока она включена только в инсталлятор Proxmox. При этом сам пакет с ZFS уже есть во многих репозиториях (Debian, Ubuntu, Arch, Gentoo, Fedora, Centos), ручками ставится без проблем.
                                                                            • 0
                                                                              В ZFS новичок, рискнул попробовать на паре серверов, когда оно стало наконец «искаропки» в Proxmox.

                                                                              На ZFS-зеркало из пары шпиндельных HDD 500GB максимально дефолтно накатил под i5/16GB для экспериментов.
                                                                              А в Hetzner сложнее — нет у них автоматизированной процедуры и возможности поставить Proxmox корнем на ZFS без заказа консолей и прочих извратов. В итоге хост поставил на BTRFS-зеркало небольшое, а 200GB под виртуалки разбил вручную, сверяясь с дефолтными параметрами экспериментальной машинки. Вроде конфиги не отличаются. Но Хетцнер — это пара Xeon-ов и Интеловские SSD.

                                                                              И вот вопрос. Почему оно выдаёт такие низкие значения IO?
                                                                              i5/16GB/2xHDD:
                                                                              CPU BOGOMIPS:      23947.04
                                                                              REGEX/SECOND:      1604707
                                                                              HD SIZE:           300.58 GB (rpool/ROOT/pve-1)
                                                                              FSYNCS/SECOND:     83.9

                                                                              2xXeon/32GB/2xSSD
                                                                              CPU BOGOMIPS:      54394.40
                                                                              REGEX/SECOND:      2948181
                                                                              HD SIZE:           68.60 GB (rpool/data)
                                                                              FSYNCS/SECOND:     36.28

                                                                              Это включенная компрессия LZ4 так влияет или CoW или что-то ещё? Без ZFS вроде (на старом Promox) сотни FSYNCS выдавало… но в целом серверу скорости хватает, а плюшки (снапшоты для бэкапов, сжатие) наверное перевешивают.

                                                                              Может, не стоит заморачиваться? Или всё же что-то неверно настроено, и даже не руками, а дефолты Proxmox?
                                                                              • 0
                                                                                Вот тред на форуме Proxmox, в котором есть отзывы о том, что эти измерения не сходятся с фактической производительностью.

                                                                                Если вам не критично потерять информацию за последние 5-10 секунд, то вы можете выставить настройку пула sync=disabled, в таком случае ZFS не будет сбрасывать информацию на диск по команде программ, а делать это с определённой периодичностью. Но это повышает производительность за счёт риска потерять записанную информацию за последние 30 секунд (при этом сама ФС на диске битой не будет, можете не переживать).
                                                                                • 0
                                                                                  в подавляющем большинстве случаев такая потеря — битые файлы, база данных и т.п.
                                                                                  • 0

                                                                                    Ну при сбое питания вы в любом случае теряете последние данные, файлы, как и БД, и так и так не допишутся. Только ZFS пишет транзакционно, то есть риск повреждения уже минимален, если блок не дозаписался (причина поломки БД), то при загрузке будет использован предыдущий корректный.


                                                                                    Да, риск проблем с ПО при сбое питания есть всегда, в этом не спорю, но ФС в этом случае не повредится.

                                                                              • 0
                                                                                Eсть отличная статья — перенос корневой ФС на ZFS с шифрованием и созданием RAIDZ.
                                                                                Разбираемся в ZFS
                                                                                • 0
                                                                                  Пролистал, в этой статье есть злые советы, которые хотят съесть ваши данные:
                                                                                  — RAID-Z1 не рекомендуется к использованию, лучше использовать RAID-Z2, который выдержит отказ 2 дисков;
                                                                                  — параметр copies=3 никак не спасает от выхода из строя 2х дисков из 3х в RAID-Z1.
                                                                                • 0

                                                                                  И еще вопрос про iSCSI (btw, спасибо вам огромное, что отвечаете здесь на вопросы)


                                                                                  Сценарий — очень много мелких файлов, которые постоянно используются + много больших архивов, которые один раз пишутся (скорость, с которой они пишутся, не имеет значения) и часто больше даже не читаются. Хочется скорость (SSD) и сэкономить денег. Таких серверов много.


                                                                                  Будет ли хорошим такое решение:


                                                                                  Сделать один отдельный NAS с обычными 3.5 дисками (+ arc побольше и l2arc какой-то), подцеплять его по iSCSI на рабочий сервер по гигабитной(!) сети (помним — хочется сэкономить, а скорость работы с большими файлами не важна), а на рабочих серверах поставить SSD под l2arc, размером как все мелкие файлы для этого сервера + какой-то запас?


                                                                                  Правильно ли я думаю, что в этом случае все данные будут в локальном l2arc и скорость работы с ними будет такая же, как если бы они были на локальном диске?


                                                                                  Будет ли оставаться l2arc кеш между рестартами сервера? ZOL последней версии. Если не будет, то будет ли в следующей 0.7 ?

                                                                                  • 0
                                                                                    (+ arc побольше и l2arc какой-то),

                                                                                    l2arc с записью не поможет, он только на чтение, для ускорения записи можете посмотреть ZIL, или просто отключить sync=disabled, но только в случае хорошего резервирования по питанию (риск потери данных за последние 30 секунд). Т.к. сеть у вас гигабитная, то проще всего просто поставить побольше оперативки на NAS и всё, скорее всего вы упрётесь в гигабит даже на 1 диске (если включите sync=disabled).
                                                                                    а на рабочих серверах поставить SSD под l2arc

                                                                                    Я пользуюсь в основном локально ZFS, но, насколько я знаю, такая схема невозможна (ZFS у вас на стороне NAS).
                                                                                    Если вы в основном пишете, то кеш со стороны клиента особо смысла не имеет.

                                                                                    Будет ли оставаться l2arc кеш между рестартами сервера? ZOL последней версии. Если не будет, то будет ли в следующей 0.7 ?

                                                                                    Пока он не постоянный, патч уже есть, но когда он будет включён в stable ветку — точно сказать невозможно. Думаю, что через год.

                                                                                    спасибо вам огромное, что отвечаете здесь на вопросы

                                                                                    Всегда рад помочь!

                                                                                    • 0
                                                                                      очень много мелких файлов, которые постоянно используются

                                                                                      Ой, извините, пропустил. В таком случае будет работать стандартный кеш Linux на стороне клиента, тут стоит изучить скорее ISCSI.
                                                                                      На NAS можно использовать L2ARC и ZIL, но лучше начать с увеличения RAM до максимально возможного и использования ARC. Советы по поводу sync выше менее актуальны.
                                                                                      • 0
                                                                                        насколько я знаю, такая схема невозможна (ZFS у вас на стороне NAS).

                                                                                        Идея была — на NAS сделать ZVOL, его отдать по iSCSI, на клиенте это будет блочное устройство, на которое можно сделать ZFS со стороны клиента, и тогда, вроде бы, к ZFS должно быть можно сделать l2arc и ZIL. Или я неправильно думаю?

                                                                                        • 0
                                                                                          Такая реализация возможна, но, по моему, в ней получается много уровней абстракции.
                                                                                          ZVOL -> ISCSI -> EXT4 по моему будет более производительной, но при канале в 1гбит\сек ваш вариант может дать выигрыш.

                                                                                          Хотя меня и не покидает чувство, что это не правильно.
                                                                                          • 0
                                                                                            ZVOL -> ISCSI -> EXT4

                                                                                            Тогда придется делать еще bcache/flashcache. Но это, возможно, и лучше — кеш будет оставаться между ребутами. Вот только их новые версии с OpenVZ не совместимы :(

                                                                                    • 0

                                                                                      Прежде всего большое спасибо за статью. Очень интересно и вдохновляюще. Решил после неё поэкспериментировать над нашим CI. Суть в том, что там крутится много разных задач, которые пересобирают в разных вариантах одни и те же исходники. В результате получается огромное дублирование данных. В ближаёшее время надо будет увеличить количество задач и количество обрабатываемых исходников. Как следствие нужно или значительно расширять дисковое пространство или как-то дедублицировать данные на диске.


                                                                                      Дай, думаю, попробую дедубликацию ZFS:


                                                                                      Взял виртуалку на нашем proxmox. Отрезал для тестов 100G том, создал пул:


                                                                                      zpool create -f -O compression=lz4 -O dedup=on -O recordsize=4096 -O atime=off -O sync=disabled -O relatime=on -m /storage jenkins /dev/vde

                                                                                      Оперативки выдал 24G.


                                                                                      Сначала вроде всё полетело нормально, но потом начал замечать, что периодически ZFS уходит в жирный IO wait, останавливая все процессы.


                                                                                      По расчётам процессы не должны выедать больше 6-8G памяти.


                                                                                      То-ли под ARC памяти не хватает, то-ли чего… Пока опыт небольшой — не могу понять как это корректно диагностировать и куда смотреть.


                                                                                      Буду рад любой помощи.

                                                                                      • 0
                                                                                        Перед использованием дедупликации стоит понять, сколько же ОЗУ она потребует и насколько она применима к вашим данным, в этом комментарии про это писал, рекомендую ознакомиться. Также zdb вам в помощь, смотрите ключ -D и -S.

                                                                                        Если ОЗУ хватает, то стоит смотреть, в какой момент именно возникает проблема, что съелось и др., в части arc может помочь
                                                                                        cat /proc/spl/kstat/zfs/arcstats
                                                                                        


                                                                                        Кстати, вам точно нужен relatime?

                                                                                        Чуть не забыл, срочно включите xattr=sa, на большом количестве мелких файлов иначе будет сильное просаживание производительности, об этом упоминал в статье.
                                                                                        • 0

                                                                                          Огромное спасибо за ответ. Статью читал сразу после публикации, так что некоторые детали успел запамятовать, а сейчас читал по диагонали и просмотрел про xattr. Каюсь. Остальное тоже попробую. Ну и по поводу relatime — нет, не уверен :-). Тоже можно поиграться.

                                                                                          • 0

                                                                                            Спасибо за советы. Немного подрихтовал стало значительно лучше. По сути пересоздал том:


                                                                                            zpool create -f -O compression=lz4 -O dedup=on -O recordsize=128K -O atime=off -O sync=disabled -O relatime=off -O xattr=sa -m /storage jenkins /dev/vde

                                                                                            И перезалил туда данные.


                                                                                            По дороге наткнулся ещё на одну граблю: на CentOS сильно мешает работе SELinux. Пытаюсь выполнить следующий скрипт:


                                                                                            hg clone -U http://host/hg/core
                                                                                            cd core
                                                                                            hg hg update --clean --rev 2c16204ae20ee88aa9d4641c23907b400b82fca9

                                                                                            Т.е., по сути склонировать меркуриаловский репозиторий без развёртывания локальной копии файлов, перейти в каталог и встать на конкретную ревизию (собственно развернуть файлы этой ревизии). Так вот: первые две команды всегда проходят нормально, а вот последняя с некоторым небольшим шансом падает. То говорит, что подкаталой какой-либо не найден, то прав нехватает, то ещё что… При том, что половину репозитория успешно разворачивает, а потом падает.


                                                                                            Отключение SELinux решило проблему.

                                                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.