Комментарии 22
Хорошая статья. Если придираться, то не хватает к тестам про штрафы - как будем меняться производительность при росте реплик. Вероятно стоит ожидать статьи про снепшотирование с последующим бэкапированием разных PVC (вплоть до запуска каких нибудь баз данных). В свое время пробовал openebs и подход из серии - "Есть железная нода с местом. Есть pods которым необходимо иметь PVC. Запускаем и ты на уровне приложения можешь указывать сколько реплик хранилища тебе надо". Уверен что вы также задумывались по такому подходу, например есть случаи где реплика для блочного хранилища не особо нужна и можно запустить, что то типа storage class local-path, но при этом иметь возможность перемещать данные без привязки к конкретной ноде (из серии включил реплику, засинхронил данные, убрал старую реплику).
Давно искал подобное сравнение. Было бы идеально, если в конце была итоговая сравнительная таблица
еще бы longhorn добавить, интересно как оно в сравнении
Спасибо за статью.
Подскажите, а у вас реально есть vitastor в бою?
Уупс… Это в каком, простите, месте, "plain" LVM не умеет делать снапшоты etc.?
- Конечно, если забить всю VG — то таки да. Но так-то — нет.
- Т.н. "thin provisioning" — он немного не про это. Его лучше рассматривать как аналог QCOW, но с минимальным "нижним слоем". (По сравнению с "толстой" ФС под QCOW. Хотя там можно и "гибрид" на LVM собрать. Если очень надо.)
- Снимки в LVM, они не вполне QoW. Там, "на пальцах", что-то типа "журнала наоборот". Когда что-то записывается в "основной" том, в "снимок" записывается то что было до этого. Отсюда и такая просадка при подключении снимков/thin provisioning.
И да. Путать управлятор томами (LVM) с любой RW-ФС — достаточно серьёзное заблуждение. Подумайте, почему в распределённой RW-ФС обязателен надёжный "фенсинг" (подсказка: не превратить данные/метаданные в фарш). А вот LVM (но не thin, по той же причине) вполне может обойтись гораздо более "слабым" shared-механизмом. (Не рушить сбойнувшую ноду любой ценой, а спокойно дождаться ремонта.)
В статье нет ни слова про RW-ФС, все решения тестировались исключительно в блочном режиме.
Классический LVM действительно умеет делать снапшоты, но они достаточно сильно влияют на производительность оригинального тома. По этой причине эта же возможность намеренно выпилена некоторыми вендорами в их софте.
Например Proxmox и LINSTOR не позволяют делать снапшоты на классическом LVM.
По поводу времени тестирования есть замечание.
Есть документ от SNIA, в нем на странице 10 есть график ("Figure 1-1 – NAND-based SSS Performance States (RND 4KiB Writes)") производительность/время для разных SSD, в котором хорошо видно, что устаканившаяся производительность для большой части SSD начинается с 250-300 минут тестов.
Поэтому тест на 1 или 15 минут могут показывать просто сферического коня в вакууме..
тут далеко до пиковых нагрузок именно на ssd, так что не думаю, что будет играть роль.
да и графики по вашей ссылке скорее от десктопных моделей с slc-кэшами, серверные обычно показывают почти постоянную производительность.
А по поводу ссд и тестов в статье — что-то не то.
У них (PM983) по паспорту:
Sequential read Up to 2,000 MB/s
Sequential write Up to 1,200 MB/s
Random read Up to 430K IOPS
Random write Up to 40K IOPS
А в статье, особенно у третьей ноды, на сырых носителях значительное превышение.
Поэтому возникают вопросы и о дальнейшей корректности остальных тестов
А в статье, особенно у третьей ноды, на сырых носителях значительное превышение.
очевидно, что накопители «забыли» заполнить данными перед использованием, в этом случае более-менее приличные накопители выдают на чтении почти скорость pcie (на самом деле читать данные не надо).
уверен, что на третьей ноде оказался накопитель pcie4, когда вы заказываете железо у хостера может иметь место некоторая вариативность.
Поэтому возникают вопросы и о дальнейшей корректности остальных тестов
если бы статья была про тестирование накопителей, я бы согласился с вами.
но речь про тестирование drbd и аналогов, тут некоторое «читерство» с производительностью накопителей не навредит.
накопители «забыли» заполнить данными перед использованием
Как это "забыли"?) fio перед тестами чтения подготавливает временные файлы для тестов. Поэтому ему всегда есть что читать. А уж по скорости записи на сырые диски - в 5-6 раз превышает максимальную их скорость по иопсам. Кто разрешил?!
если бы статья была про тестирование накопителей, я бы согласился с вами. но речь про тестирование drbd и аналогов, тут некоторое «читерство» с производительностью накопителей не навредит.
Проблема в том, что имея недостоверность в одних данных, нельзя утверждать, что другие корректны.
А вдруг во время какого-то теста на диске начался сбор мусора, и на нем просела производительность кратно? Из-за этого и весь тест просел, а мы делаем вывод что drbd/ceph/что-угодно показало плохой результат.
Разумеется тесты проводились неоднократно, во всех случаях результаты были достаточно схожи.
Как это "забыли"?) fio перед тестами чтения подготавливает временные файлы для тестов.
конечно, нет
создадим «дырявый» файл на терабайт и протестируем чтение из него:
root@debian:/# truncate -s 1T /tmp/testfile
root@debian:/# fio --name=test --ioengine=libaio --iodepth=16 --numjobs=28 --cpus_allowed_policy=split --rw=randread --bs=4k --direct=1 --filename=/tmp/testfile --time_based=1 --timeout=20s --randrepeat=0 --group_reporting=1
…
read: IOPS=4517k, BW=17.2GiB/s (18.5GB/s)(345GiB/20001msec)
…fio делает ровно то, что его попросили. и да, это правильно.
А уж по скорости записи на сырые диски — в 5-6 раз превышает максимальную их скорость по иопсам. Кто разрешил?!
а кто запретил? )
вот на чистом pm9a3:
root@debian:/ # fio --name=test --ioengine=libaio --iodepth=16 --numjobs=28 --cpus_allowed_policy=split --rw=randwrite --bs=4k --direct=1 --filename=/dev/nvme1n1 --time_based=1 --timeout=20s --randrepeat=0 --group_reporting=1
…
write: IOPS=970k, BW=3788MiB/s (3972MB/s)(74.0GiB/20001msec); 0 zone resets
…
и если его оставить в таком тесте надолго, то со временем скорость упадёт к тем 200к iops — придётся запуститься сборщику мусора, таблица трансляции станет гораздо больше и т.п.
Спасибо за ссылку на этот документ. Смущает, что этот график уже 10 лет не меняется (https://www.snia.org/sites/default/files/technical-work/pts/release/SNIA-SSS-PTS-2.0.2.pdf ) и в нем нет устройств с TLC как у SSD в этом тесте.
Есть вопросы к методологии тестирования как минимум ZFS. Под bs512 и 4k для ZFS вы имели ввиду recordsize? Это тот, который дефолтно 128k? И который в CEPH 4МБ? При том, что размер блока записи/чтения для максимальной скорости у самих NVMe SSD, может доходить до 512к (см методологию тестирования Intel)? Совершенно понятно, откуда такая разница в результатах между 512 и 4к, файловая система делает в 8 раз больше операций над метаданными. Какой у вас планируется ворклоад, даже для баз данных рекомендуется 8k, разве что виртуалки с WinXP 512 используют? Также не указана версия ZFS, на NVMe показывает в несколько раз более высокие результаты вторая версия (штатно идет с Ubuntu LTS 22.04), у вас видимо дефолтная для 20.04LTS 0.8.3
del
Почему с fsync так сильно чтение проваливается?
Исследование производительности свободных хранилищ LINSTOR, Ceph, Mayastor и Vitastor в Kubernetes