ZFS и скорость доступа к диску в гипервизорах

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



    Всем привет! В сети довольно много материалов, посвященных файловой системе (далее ФС) ZFS, ее развитию в Linux'е и практическому применению. Меня данная ФС очень заинтересовала в контексте совершенствования моего домашнего сервера виртуализации ( а также благодаря посту пользователя kvaps), однако я не смог найти в интернете (может быть плохо искал?) сравнительных тестов производительности виртуализированных машин. Поэтому решил собрать тестовую платформу для проведения своего сравнительного исследования.

    Моя статья не претендует на какие-либо научные открытия, вряд ли поможет профессионалам, которые давно работают с ZFS, и знают все ее возможности, однако поможет новичкам приблизительно оценить «цену» каждого гигабайта поделенного на производительность.

    image

    Суть эксперимента заключалась в следующем: на машину устанавливалась (каждый раз с загрузочного диска) ОС Proxmox VE 5.2. Во время установки выбирался Один из вариантов XFS/ZFS. После этого создавалась виртуальная машина, на которую производилась установка Windows Server 2008 R2, после чего запускалась популярная утилита CrystalDiskMark 5.2.2 и проводились тесты на объемах 1, 4, 32 GiB (в связи с потерей изображений с результатами 32 GiB тестов нельзя воспользоваться при выборе решения, имеющиеся данные приводятся для массовки).

    Тест на ФС XFS использовался для измерения эталонной скорости работы одного ЖД (возможно это и неправильно, но других вариантов ее оценить я не придумал).

    Тесты ZFS RAID 0, RAID 1 проводились на двух случайно выбранных дисках, ZFS RaidZ1 на 3 дисках, ZFS RAID 10, RaidZ2 на 4 дисках. Тесты с ZFS RaidZ3 не проводились по причине отсутствия желания купить еще один крайне экономически нецелесообразный HDD на 500GB.

    Под спойлером кратко приведу описания каждого из видов ZFS RAID с моим примером получаемого объема «коммерческих» гигабайтов:

    ZFS RAID
    2 диска:

    • ZFS RAID 0 — чередование (Striped), объем 2 * DiskSize = 1000ГБ.
    • ZFS RAID 1 — зеркалирование (Mirror), объем 1 * DiskSize = 500ГБ.

    3 диска:

    • ZFS RaidZ1 — он же ZFS RaidZ, аналог RAID5, объем (N — 1) * DiskSize = 1000ГБ.

    4 диска:

    • ZFS RAID 10 — зеркалирование с чередованием (Striped Mirrored), объем 2 * DiskSize = 1000ГБ.
    • ZFS RaidZ2 — аналог RAID6, объем (N — 2) * DiskSize = 1000ГБ.
    • при этом, я такой тест не проводил, но ZFS RaidZ1 при 4 дисках = 1500ГБ.

    Очень понятно расписана суть вот тут (англ). А также сколько дисков допустимо потерять, сохранив информацию.

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

    Технические характеристики платформы, (возможно) влияющие на результаты тестирования:

    • Материнская плата: Intel Desktop Board DS67SQ-B3;
    • Процессор: Intel Pentium G630 2.7GHz;
    • Оперативная память: 2 x 4096Mb Hynix PC3-10700;
    • Жесткие диски: 3 x WD 5000AZRX 500GB SATA 64MB Cache, 1 x WD 5000AZRZ 500GB SATA 64MB Cache, SSD SATA Goldenfir T650-8GB;
    • Блок питания: DeepCool DA500N 500W.

    Виртуальной машине (KVM) для тестов выделялось 4GB оперативной памяти, 1 ядро процессора, жесткий диск VirtIO Block 100GB.



    Для систем, установленных на ZFS выполнялось 2 теста, во втором в качестве кэш-диска подключался SSD.

    Все результаты представлены в виде скриншотов ниже. Если у кого-нибудь возникнет желание оцифровать данные результаты — буду благодарен и включу результаты работы в статью.

    XFS




    ZFS RAID 0


    ZFS RAID 0 + cache




    ZFS RAID 1


    ZFS RAID 1 + cache




    ZFS RAID 10



    ZFS RAID 10 + cache



    ZFS RaidZ1


    ZFS RaidZ1 + cache




    ZFS RaidZ2


    ZFS RaidZ2 + cache



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

    P.S. по непонятным мне причинам часть изображений куда-то пропали, замеры проводились в конце весны, тестовую платформу уже не собрать в том виде, к счастью все они приходятся на тесты с 32 GiB.

    P.P.S. Не пытался рекламировать какие-либо организации и/или программные продукты, не имел цели нарушить лицензионных соглашений, если где-то был неправ, прошу писать в личные сообщения.

    P.P.P.S. Изображение с логотипом ZFS является репродукцией.

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

    Какой тип ZFS выбрал бы ты для виртуальных машин в ProxMox VE?

    Поделиться публикацией

    Похожие публикации

    Комментарии 48

      0
      Не могу разместить ссылку на PDF документ со сводной таблицей, я еще маленький для этого?
        0
        Юзаю ZFS дома в самопальном NAS довольно давно.

        На RAID-Z1 из 4 низкооборотных дисков при даже не сильно активной работе торрент-клиента пользоваться NAS практически нереально — I/O Wait 100% одного ядра, куча IOPS на диски.

        Особых бенчмарков не проводил, но когда аналогичный NAS был на RAID-5/XFS подобных проблем не возникало.
          +1
          Это из за ARC кэша, он очень любит ОЗУ. Тюнить при отсутствии хотя-бы 8ГБ ОЗУ на системе, неблагодарное занятие. Всё-таки ФС расчитана на суровый энтерпрайз. У меня дома ZFS RAID-10 на 6 дисках (3 зеркала), и ОЗУ на компе 64ГБ, вобщем тюнить даже не тянет.
            0
            ОЗУ 8Гб на текущем NAS, кеши не тюнил. Кроме ZFS там память никто не жрет особо.
            Текущий объем ARC 1.8Gb, может стоит разрешить ему кушать побольше чем 25%.

            До этого имел долгий опыт жизни с «NAS» из 10 7.2k SATA дисков в RAID-Z2 при 256Gb RAM (такой вот франкенштейн), по дурости думал что такой объем памяти мне позволит сделать дедупликацию без снижения производительности… угу, щас. Удаление большого файла вызывало дикие локапы всей системы. Когда ее убрал — стало по-божески, но это 256Гб все таки.
              0
              А зачем на файлопомойке урезать ARC? Мне для общего развития… На Linux я его подрезал до 75% исключительно из-за того, что он (linux) иногда начинает драться с ZFS за память. Если их растащить таким способом, всё становится нормально (debian 7, давно дело было). Но до 25% это террор, особенно если учесть, что ARC сильно продвинутее чем кеш ОС.
                0
                А я не ограничивал, все по дефолту.
                Он, насколько я помню, лимитируется в 50% RAM если zfs_arc_max=0.
                Почему он у меня меньше 50% — хз, возможно сдувается под давлением обстоятельств :) На глаз 25% как раз.
                  0
                  Просто ему нечего кешировать, всё нормально =)))
                    0
                    Возможно. Запустил торренты, посмотрим раздует ли и до каких пределов.
                      0
                      так не бывает ) после первый же отгруженного в Torrent фильма ARC должен занять явно больше 2 ГБ… Главный профит ARC — хранение метаданных файловой системы. Ну и чтение, разумеется. Если объём памяти ограничен — атрибут primarycache=metadata для ФС должен помочь. Содержимое самих файлов не будет вымывать из кэша структуру, соотв, ZFS всегда знает, где лежит тот или иной блок и куда положить новый.
                  0
                  Это у вас дома такие франкенштейны обитают?
                    0
                    Да, купил списанный сервер с двумя Xeon E5 и 256Гб т.к. нужно было гонять жоркие до памяти вычисления. Сейчас стоит ненужный уже, буду продавать наверное.
                      0
                      Завидую вам!
                      Я для апа своей старой железки уже пару месяцев не могу найти DDR2 ECC unbuffered памяти, поэтому пользуясь случаем кину здесь свою просьбу у кого есть ненужные 4 x 2 GB модули 667 или 800 MHz, я готов их купить, писать в личку.
                  0
                  Живу на 4 Гигах на машине с второй корой дуба (Core2 Duo) диски на родном контроллере чипсета. Всё в норме, память оно жрёт, но если нужно отпускает. Правда есть некоторый чит, живу я на FreeBSD. ZFS может работать и с 2-я гигами памяти, весь вопрос в том, что при меньшем количестве памяти, будут больше работать диски. 8 Гигов — это для файлопомойки достаточно много, если при этом диски не в raidz и их не много, смысла в этом большого нет ИМХО.
                    0
                    «второй корой дуба» — для чего вы написали именно так?
                      0
                      Чтобы подчеркнуть старость и дряхлость данного процессора. Уже не булыжник, но ещё не алмаз…
                  +1
                  Что-то пошло не так, ZFS использует deadline в качестве планировщика и никогда не кладёт диски в полку на 100%. Может подтормаживать ввод-вывод, но совсем капец наступить не должен. Отзывчивость чтения должна быть на уровне. Можно попробовать recordsize увеличить, если включён large_blocks `zfs get feature@large_blocks $dataset_name` то можно поставить 1 Мбайт. Это уменьшит количество запросов блоков (в среднем один блок в торрентах где-то 1-4 Мбайта) и разгрузит очередь. Но у меня ZFS диски не ложил. XFS легко, EXT4 — это его нормальное состояние, ZFS никогда.
                    0
                    У меня отдельный ZFS датасет под торренты с блоком в 16к по рекомендации лучших собаководов отсюда: www.open-zfs.org/wiki/Performance_tuning#Bit_Torrent

                    И когда работают торренты у меня стандартно 20-30% I/O wait (из 4 ядер), вот скрин из заббикса:
                    image

                    OS Ubuntu 16, ZoL последний, диски HGST какие-то около 5-6к оборотов.
                      0
                      1 блок торрента в среднем 1 мегабайт, для отдачи одного блока в очередь попадает 1024/16 команд на загрузку данных. И получается советская очередь за молоком. Лучше увеличить по среднему размеру блока в торрентах.
                        0
                        Возможно, я не вдумывался, сделал как в доках сказано. Погляжу статистику I/O — какие размеры операций идут. Спасибо.
                          0
                          Помониторил:
                          # zpool iostat 10
                          capacity operations bandwidth
                          pool alloc free read write read write
                          ---------- ----- ----- ----- ----- ----- -----
                          bkp 799G 1.94T 0 0 0 0
                          zfs 5.95T 4.61T 799 0 14.0M 0
                          ---------- ----- ----- ----- ----- ----- -----
                          bkp 799G 1.94T 0 0 0 0
                          zfs 5.95T 4.61T 773 0 15.3M 0
                          ---------- ----- ----- ----- ----- ----- -----
                          bkp 799G 1.94T 0 0 0 0
                          zfs 5.95T 4.61T 813 0 17.1M 0
                          ---------- ----- ----- ----- ----- ----- -----

                          Судя по этим данным средний размер I/O 46400/2385=19.4 килобайта, что примерно соответствует моему размеру блока в 16k.

                          Так что, по крайней мере мой transmission, не читает блоками по 1М.
                            0
                            Он читает блоками, если блок 16, он читает 16. При изменении размера блока, все новые файлы будут писаться на новый размер, тогда может быть выигрыш. Я размер блока посмотрел в статистике своего клиента глазами, может более суровое исследование даст лучший результат. Но кажется что мегабайт будет нормально, тем более, что больше вроде пока нельзя, да и мегабайт можно только с соответствующей опцией.

                            Я смотрел видео, где человек рассказывал о использовании ZFS на серверах раздачи видеоконтента, и он сильно агитировал за больший размер блока.
                              0
                              Проблема в том, что если блок ФС 1М, а блок торрента 16к, то запись блоков по 16к будет вызывать read-modify-write всего 1М блока (для пересчета контрольной суммы, разливания по RAID-Z и т.п.). Поэтому я не уверен что это не ухудшит дела, хотя стоит проверить.

                              zpool все таки показывает что чтение идет блоками в районе 20к, а не 1М. Попробую посмотреть при записи что происходит.
                    +2

                    Очень странно видеть сравнение не со схожей конфигурацией под управлением mdraid, а одним диском под XFS.

                      +1
                      Непонятно также почему выбран Virtio-Block, хотя прокс рекомендует Virtio-Scsi. Ну и цифры эти они о погоде на луне, я раньше тоже так тестил. Имхо если ставим гипервизор, то наверное будет несколько виртуалок, иначе какой смысл в прослойке, если будет несколько виртуалок, то картинка может сильно поменяться, поэтому таких тестов и нету, желательно тестить c помощью fio непосредственно на хосте гипервизора.
                        0
                        Непонятно также почему выбран Virtio-Block, хотя прокс рекомендует Virtio-Scsi

                        Мне в данный момент тоже непонятно почему я такой выбор сделал )
                        то наверное будет несколько виртуалок, иначе какой смысл в прослойке

                        ну зная скорость на одной можно сделать некоторые выводы, мне хотелось понять именно разницу в скорости между этими реализациями
                        желательно тестить c помощью fio непосредственно на хосте

                        ну меня в этих тестах интересовало что именно дойдет до виртуалки.

                        Вот для сравнения, да простят меня все линуксоиды, сравнительный тест в среде MS
                        Гипервизор (не Hyper-V) на Server 2016 (это уже на другой железке тесты)

                        SOFT RAID 5



                        И то что доходит до виртуальной машины на WS 2008 R2
                        VirtualBox


                          0
                          Непонятно также почему выбран Virtio-Block, хотя прокс рекомендует Virtio-Scsi.
                          Именно в вопросе производительности это не сильно важно. Proxmox рекомендует virtio-scsi скорее из-за большего количества функций (полноценное scsi устройство, поддержка blkdiscard, масштабируемость и т.д.) при примерно той же производительности (при некоторых паттернах нагрузки она хуже из-за большего количества прослоек).
                            0
                            ну меня в этих тестах интересовало что именно дойдет до виртуалки.

                            100% практически и дойдет, именно в этом цель virtio драйверов.

                            Вот для сравнения, да простят меня все линуксоиды, сравнительный тест в среде MS
                            Гипервизор (не Hyper-V) на Server 2016 (это уже на другой железке тесты)


                            Вы же понимаете что так не бывает и где-то в тестах косяк? Если на физ. машине действительно запись всего 30 МБ/с, то на виртуалке ну никак 85 не будет. Имхо вы просто не пробили тут кеш 1 гиговым файлом.

                            Также хотелось бы подробностей, вы написали что для кеша использовали SSD, как L2Arc? А то там можно еще SSD подключить как Zil, тогда еще и запись ускорится.

                              0
                              ZFS l2arc cache device
                              А то там можно еще SSD подключить как Zil, тогда еще и запись ускорится.

                              Я так понимаю для этого нужен еще один SSD
                                0
                                профит от SSD ZIL несколько переоценивают. Если не включена принудительная синхронизация тома, и приложение не запрашивает fsync после IO — ZIL не участвует.
                        0
                        В большей степени были бы полезнее iops'ы а не скорость чтения/записи
                          0
                          А IOPS-ы от шпинделей. Выше производительности дисков не прыгнешь.
                            0
                            Не всё так однозначно, если учесть сколько всего ФС пихает в память и ARC/ZIL. Тестировал при помощи утилиты ioping на VM-ках и цифры на ZFS всегда были на порядок выше. Например если на ufs/ext3/ext4 ~2k, то на ZFS ~70-80k. Шпинделя были одни и те же.
                            C методикой тестирования действительно надо бы определиться что бы не сравнивать разрозненные величины. Для меня это так и осталось открытым вопросом.
                            0
                            Если читающим это действительно интересно, напишите какие тесты провести, что замерять. Сейчас на некоторое время есть свободная железка, правда с более слабым конфигом (C2D, 6GB RAM и тот же набор дисков).
                              0
                              zil на SSD и не на SSD, для разных конфигураций (raid-z, raid-z2 итд), L2ARC на SSD, и без него, разные размеры ARC — для всего этого iops, а не мегабайты(мегабиты) в секунду.
                                0
                                У меня нет такого количества SSD, я же написал, что с тем же набором дисков. Все эти тесты проводятся дома, на работе нет свободного железа, да и разрешения руководство на такое никогда не даст )
                            0

                            Из статьи и из моего опыта можно сделать грустный вывод. Сколько дисков zfs не дай, а скорость записи будет просто смешной. Да и xfs в вашей виртуалке в 100мб/сек — тоже отстой. В ntfs win эти диски могут показывать более 180мб/сек, верно?

                              0
                              Сейчас под рукой нет результатов тестов на одиночных дисках, а результаты RAID5 приводил чуть выше,
                                0

                                Совсем не обязателен тестовый стенд, чтоб проверить на запись любой адекватный винт 7200. Только не те зелёные, что сейчас продают как нормальные 7200...

                                  0
                                  У меня как раз все зеленые, 5400. 7200 слишком гроко хрустят для квартиры.
                                0
                                Сколько дисков zfs не дай, а скорость записи будет просто смешной.

                                Вот тут я думаю ваш вывод абсолютно верный! И исходя из целей и задач виртуализированных ОС для кого-то ZFS не будет иметь никакого смысла. В ближайшей перспективе хочу провести сравнение с mdadm.
                                  0
                                  нене, имеет смысл. но только, если это SSD и включена дедупликация. к сожалению и там есть провалы в скорости записи. использую zfs на evo 960. есть ощущение, что там не работает trim.
                                0
                                XFS для Proxmox вроде не самая дефолтная ФС, там же Debian в основе, и дефолтом шла и имет ext3/ext4. Вы их не меряли?

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

                                И ZFS — какие настройки по памяти делали? ОС хоста, гипервизор и сами ОЗУ потребляют, да еще ZFS умеет любит ОЗУ использовать — так вот какими настроками/мануалами пользовались для тюнинга?
                                  0
                                  дефолтом шла и имет ext3/ext4. Вы их не меряли?

                                  У сожалению — нет!
                                  RAID с батарейкой

                                  У меня такое оборудование отсутствует! Это SOHO уровень!
                                  И ZFS — какие настройки по памяти делали?

                                  Все настройки дефолтные при установке ProxMox VE, специально ничего не менял.
                                  0
                                  Ну как так-то?
                                  Почему в случае с включенным кэшем мы получаем производительность сильно ниже, даже на мелких 4 и 1 гб файлах. Сравните ZFS Raid1 и Raid1 + кеш.
                                    0
                                    По теме рекомендую почитать также труды вот этого чела:
                                    jrs-s.net/2013/05/17/kvm-io-benchmarking
                                    jrs-s.net/2018/03/13/zvol-vs-qcow2-with-kvm

                                    Очень познавательно.
                                      0
                                      И вообще его блог рекомендую
                                      +2
                                      Десятикратный прирост производительности на ZFS vs XFS? Можно, я просто не поверю? Это либо прогретые кеши, либо writeback.

                                      Каждый раз, когда мне пытаются продать увеличение производительности диска в 10 раз, я обнаруживаю внутри writeback. Иногда с игнором flush'ей.
                                        0
                                        Во всех тестах процедура была абсолютно идентична: 1. установка прокса; 2-установка ws; 3- тест.
                                        Увеличения в 10 раз вроде и нет, максимум в 5 раз. Мне кажется это возможно при распараллеливании доступа к дискам.

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

                                      Самое читаемое