Proxmox ssd emulation что это
Приветсвую! Есть 2 практических вопроса мучающих мучающих меня при сборке нового сервера.1. Если гипервизор (в частности proxmox) будет стоять на SSD с f2fs файловой системой (в целях бережного обращения с SSD), то виртуальные машины (KVM) имея например ext4 внутри себя, физически на SSD будут писаться в рамках f2fs? Т.е. получается что на ВМ все равно какая файловая система?
2. F2fs призвана продлить работу SSD путем того что запись производится равномерно. А если стоит контроллер рейд и используется рейд 5 например? На это все ставится f2fs, то она будет иметь какое-то значение, ведь физикой управлять будет рейд контроллер?
Хочу узнать ваши мнения. Может кто напишет что дельное.
> 1. Если гипервизор (в частности proxmox) будет стоять на SSD с f2fs
> файловой системой (в целях бережного обращения с SSD), то виртуальные машины
> (KVM) имея например ext4 внутри себя, физически на SSD будут писаться
> в рамках f2fs? Т.е. получается что на ВМ все равно какая
> файловая система?Да. Нет. Вы забываете про кеширование и IOPS.
> 2. F2fs призвана продлить работу SSD путем того что запись производится равномерно.
> А если стоит контроллер рейд и используется рейд 5 например? На
> это все ставится f2fs, то она будет иметь какое-то значение, ведь
> физикой управлять будет рейд контроллер?Дисками все равно будет рулить RAID. Про степень износа ячеек и равномерность он не в курсе.
Даже TRIM не все RAID контроллеры понимают.
lavr, спасибо за подробный ответ и статьи! Буду изучать.
Понимаю что мало пока понимаю. Но делать вот надо. придется вникать.
> Планируется 2 SSD в рейд-1 и 2 HDD в рейд-1.>> Планируется 2 SSD в рейд-1 и 2 HDD в рейд-1.Сдается мне что велика вероятность смерти двух SSD одновременно. износ ячеек теоретически одинаковый, а писаться будет одновременно в одинаковые ячейки.
Без spare-disk мне кажется сомнительная штука.
> Сдается мне что велика вероятность смерти двух SSD одновременно. износ ячеек теоретически
> одинаковый, а писаться будет одновременно в одинаковые ячейки.
> Без spare-disk мне кажется сомнительная штука.
а все кто использует SLOG на SSD для ZFS "и не знали", используют себе
по 2xSSD с ZIL в mirror, а некоторые в добавок и L2ARC в mirror.
SSD != HDD, вылетают блоки, SSD продолжает работать, разумеется что это
не может радовать, но есть некий timeout.
Собственно, интересней доклад Google об их опыте использования SSD и
неожиданных выводах.
Если кому интересно, мы тут недавно потестили производительность чтение/запись внутри windows машины на ноде с Proxmox 4.3.
Хостовая система была установленна на raid10 реализованный двумя разными способами (zfs и mdadm+lvm)
Тесты проводились на Windows-госте, так-как в первую очередь интересовала производительность именно этой ОС.
Должен признать, это вторая версия статьи, в первой была допущена фатальная ошибка:
zfs тестировался на local storage, а не на zvol, т.к. я до последнего думал, что proxmox не поддерживает zvol.
Огромное спасибо winduzoid за то, что заметил данное недоразумение.
Мысль о написании данной статьи навели коментарии к недавней статье про Установку PROXMOX 4.3 на Soft-RAID 10 GPT от vasyakrg. Не холивара ради, но я решил опубликовать наши недавние результаты.
Водные данные:
CPU: Intel® Core(TM) i7-3820 CPU @ 3.60GHz
RAM: 20GB (1334 MHz)
HDD: 4x500GIB (ST500NM0011, ST500NM0011, ST3500418AS, WDC WD5000AAKX-22ERMA0)
SSD: 250GiB (PLEXTOR PX-256M5Pro)
OS: Proxmox Virtual Environment 4.3-10
Виртуальная машина:
CPU: 8 (1 sockets, 8 cores)
RAM: 6.00 GiB
HDD: 60 GiB (virtio)
OS: Windows Server 2008 R2 Server Standard (full installation) SP1 [6.1 Build 7601] (x64)
Все результаты получены с помощью утилиты CrystalDiskMark 5.2.0 x64.
Каждый тест проводился в 5 итераций по 32GB.
Никаких дополнительных твиков и изменений не указанных в статье не вносилось ни в конфигурацию гипервизора ни в конфигурацию виртуальной машины. То есть использовался просто свежеустановленный Proxmox и восстановленная из бэкапа виртуалка с Windows.
Результаты:
Итак сами результаты:
Позже мы добавили в наш zfs-пул кэширующий SSD.
Ради интереса мы так же запустили тесты на одном SSD:
Графики:
Для наглядности я решил нарисовать несколько графиков
Скорость на последовательное чтение и запись:
Скорость на случайное чтение и запись:
Количество IOPS на случайное чтение и запись:
Выводы:
Не смотря на то, что результаты получились довольно необычные, а местами даже странные, можно заметить что raid10 собранный на zfs, с опцией cache=none для диска показал более хороший результат, нежели raid10 собранный на mdadm + lvm как на чтение, так и на запись.
Однако, с опцией cache=writeback raid10 собранный на mdadm + lvm заметно выходит вперед.
you refer to an old post, newer kernels and newer qemu version are in place now. for zfs, cache=writeback is the recommended setting.
Кроме того IlyaEvseev в своей статье писал, что writeback кэш дает хорошие результаты для виртулок с Windows.
По субъективной оценке, для ВМ с Windows оптимален writeback, для ВМ с Linux и FreeBSD — none.
На этом пожалуй все, если у вас есть какие-либо предложения на тему того, как еще можно увеличить производительность дисковых операций на гостевой машине, с радостью их выслушаю.
Расскажу про свой опыт установки панели в Proxmox в KVM и задействовании режима trim для дисков.
Как говорит документация по Proxmox нужно с дисках включать режим discard, делать тип контроллера -VirtIO SCSI, а диски не VirtIO Block, а SCSI !
Опция discard включается галочкой (в русской версии называется "Отклонить"!).
Также я на всякий случай включил галочку "SSD emulation".
1. Сделал 2 диска: 80 под систему, 300 под папку /home
2. Ставил с CentOS-7-x86_64-Minimal-1908.iso
Выбрал ручное разбиение. LVM, Автоматическое разбиение, потом руками подправлял. Сделал 2 VirtualGroup по каждому диску в группе.
Ставил на ext4.
Переходим к предварительной настройке ОС.
3. Обновил систему
4. Установить qemu-guest-agent
5. Включить trim
5.1 По инструкции
5.2 Добавил опцию discard в каждый диск (включая swap) в /etc/crypttab (он у меня пустой, поскольку шифрование не включал) и /etc/fstab
по принципу:
/dev/sda1 /boot ext4 defaults,discard 1 2
5.3 Установил issue_discards = 1 в /etc/lvm/lvm.conf
5.4 Перестроил initramfs ПЕРЕГРУЗИТЬСЯ.
Настройка trim завершена. Проверял - работает.
Вручную перед бекапом делать обязательно.
и будет вам счастье.
Можно включить почасово
6. Удалил старые ядра
2-е добавилось после начального обновления системы. Т.е. я старое удалил, новое оставил.
Установил в /etc/yum.conf installonly_limit=2 на будущее.
7. Удалить неиспользуемые локали, перестроить архив локалей
При этом консоли ssh закроются.
Подождать немного, что бы архив локалей перестроился и перегрузить.
Таким образом /usr/lib/locale/locale-archive уменьшается с 105мб до 5,5мб.
8. Я еще ставил себе ncdu - полезная утилита для просмотра размеров папок. Ну это кому нужно:
Для исключения ошибок (которые будут на этом этапе), установите gcc и ncursesПри желании вы можете удалить ncdu-1.14.2.tar.gz файл и каталог, в который были извлечены исходные файлы, так как они вам больше не нужны.
9. Установить brainycp
После установки всего-всего панель с системой у меня заняла 5,8Гб.
(правда я немного jail_skeleton подрезал)
Все.
Надеюсь, кому-то поможет.
Я с этим trim'ом день промучался и наэкспериментировался, но именно так все работает.
1) Со временем обнаружилось, что atop, как сервис, пишет много логов.
Отключил:
2) Далее возникла проблема с тем, что trim дисков делается, но на разделе swap все равно есть занятые блоки и он в бекап proxmox'a попадает, как занятое пространство.Для справки: proxmox считает блок на диске гостевой kvm пустым, если там записаны нули. Если не нули - блок занят.
trim на дисках работает, поэтому их не нужно забивать нулями, а со swap такое не проходит.
Поэтому перед бекапом я делал:
Почистил руками все архивные старые логи. Оставил только последние, без дат.
Не забываем проверить и удалить старые ядра. См. предыдущий пост. Если вы установили опцию installonly_limit=2 в /etc/yum.conf, то больше 2-х не будет.
Потом чистка неиспользуемых блоков на swap-разделе.
Соответственно подправьте для своих разделов /dev/dm-1 - у меня swap (узнать это можно через swapon -s)
Забивать нулями для swap нужно, поскольку я думаю, что swapoff только отключает и не очищает.
Раздел swap после забития нулями перестает быть разделом swap поэтому его нужно заново пересоздать mkswap.
После этого бекап в proxmox минимален.
Я хочу построить небольшой домашний сервер виртуализации на базе ProxMox. Требования к подсистеме хранения такие:
дедупликация при небольшом потреблении памяти. не обязательно inline, можно просто по расписанию. ZFS - все круто (“искаропки” есть кеширование, дедупликация и сжатие). Однако, дедупликация требует очень много памяти (>5GB на 1Tb данных). А также на производительность влияет неотключаемый Copy-On-Write. ext3/4 over LVM - быстрая и стабильная. можно сделать кеширование на SSD. Нет дедупликации. Нет сжатия. BTRFS over LVM - можно сделать кеширование на SSD. Есть дедупликация по запросу. Есть сжатие. Можно отключить Copy-On-Write (но тогда отключится сжатие). Virtual Data Optimizer - VDO суперштука. Модуль ядра, который реализует inline-дедупликацию и сжатие для томов LVM. Пока что доступен только в RedHat и непонятно что со стабильностью/производительностью/ресурсами.Выбор пал на связку BTRFS over LVM. Она позволяет дедуплицировать данные по расписанию (с помощью duperemove), кешировать данные на SSD с помощью lvmcache.
Файлы образов дисков должны быть в формате qcow2, что позволит делать снепшоты.
Файловые системы контейнеров LXC можно хранить как в виде образов, так и просто в папках на BTRFS. Последний вариант будет скорее всего быстрее (вследствие отсутствия loop-устройства), позволит дедуплицировать и\или сжимать файлы контейнеров средствами BTRFS.
Забегая вперед, скажу, что SSD кеш делает виртуальные машины ГОРАЗДО отзывчивее. Даже в условиях нехватки оперативной памяти.
ВНИМАНИЕ.
Всем, кто решит использовать BTRFS + lvmcache на хосте ProxMox нужно помнить следующее:
lvmcache НЕ совместим с различными вариантами hibernate. Если вы попытаетесь выполнить pm-hibernate на хосте кешированными томами, то никакого hibernate не произойдет. Система просто перезагрузится, а данные на дисках будут повреждены. Я пробывал. использование BTRFS с флагом nodatacow (то есть отключение Copy-On-Write) наверное, немного поднимет производительность, но взамен сделает и без того не самую надежную файловую систему абсолютно неремонтопригодной. Отключится весь функционал, обеспечивающий надежность хранения (CoW и контрольные суммы). В результате, при повреждения файловой системы даже btrfs check использовать не получится (по причине отсутствия ctree).Создание кешированного тома LVM
Пример конфигурации такой. два диска - /dev/vdb (SSD) и /dev/vdc (HDD). Создаем физичесике тома и группу томов test:
Создаем том с кешем на SSD:
Создаем том с данными:
И теперь собираем конструкцию:
Отсоединить кеш от тома можно командой:
Состояние тома можно поглядеть командой:
Тип кеша можно поменять командами:
Создание хранилища Proxmox
Для начала надо смонтировать том с параметрами noatime,nodiratime
Тестирование FIO
То есть тест блоками по 4k, случайные чтение и запись, глубина очереди 32, размер тестового файла - 1Gb, без кеширования на уровне Windows (direct=1).
Тесты запускались по три раза, чтобы тестовый файл попал в SSD-кеш.
| LVM Cache/PM Cache/Format | Read, MiB/s | Write MiB/s | Read IOPS avg, k | Write IOPS avg, k | CPU Read, % | CPU Write, % |
|---|---|---|---|---|---|---|
| WB/NC/qcow2 | 133 | 100 | 34.0 | 25.6 | 26 | 0 |
| WB/NC/raw | 127 | 104 | 32.5 | 26,6 | 25 | 0 |
| WB/WB/qcow2 | 158 | 107 | 40.5 | 27,4 | 0 | 0 |
| WB/WT/qcow2 | 166 | 5.3 | 42.6 | 1.324 | 0 | 4 |
| WB/WT/raw | 154 | 5.47 | 39.5 | 1.335 | 0 | 3.5 |
| WB/WB/raw | 150 | 118 | 38.3 | 30.1 | 0 | 23 |
| WT/WT/qcow2 | 213 | 0.046 | 54.5 | 0.011 | 21 | 0 |
| WT/WB/qcow2 | 159 | 9.5 | 40.8 | 2.37 | 0 | 0.9 |
| WT/NC/qcow2 | 128 | 0.612 | 32.8 | 0.152 | 12.5 | 0 |
| WT/NC/raw | 121 | 0.832 | 30.9 | 0.208 | 0 | 0 |
| WT/WT/raw | 288 | 0.041 | 73.7 | 0.010 | 56 | 0 |
| WT/WB/raw | 137 | 16.8 | 35.1 | 4.303 | 0 | 3.3 |
| NC/WB/raw | 146 | 4.4 | 37.3 | 1.099 | 0 | 0.4 |
| NC/WT/raw | 148 | 0.0476 | 37.8 | 0.011 | 0 | 0 |
| NC/NC/raw | 1.766 | 0.694 | 0.441 | 0.173 | 0 | 0.33 |
| NC/NC/qcow2 | 1.830 | 0.244 | 0.457 | 0.061 | 0.86 | 0 |
| NC/WT/qcow2 | 1.7 | 0.0465 | 0.449 | 0.011 | 0 | 0 |
| NC/WB/qcow2 | 3.578 | 4.889 | 0.894 | 1.222 | 0 | 0.47 |
Результаты тестирования fio
Предсказуемо, стабильно высокие результаты при минимальной загрузке VCPU показал вариант, когда включено кеширование на LVM и Proxmox в режимах WriteBack. Его недостатком можно считать вероятность потери данных при выходе из строя SSD или отключении питания. Не сильно отстает конфигурация с кешированием только на SSD в режиме WriteBack. От выхода из строя SSD можно защититься, использовав два накопителя в зеркальном массиве. Разница между форматами qcow2 и raw несущественна, при большей функциональности qcow2. В режимах Writeback на уровне proxmox без кеширования на SSD на уровне lvm, скорость записи очень нестабильна. Она может быть как довольно высокой (3000-4000 IOPS), так и довольно низкой (500-1000 IOPS) и меняется произвольным образом. Режимы кеширования ProxMox WriteThrough - существенно ускоряют чтение (в 100 раз), но замедляют запись (в 5-20 раз) по сравнению с режимами без кеширования и writeback.Тестирование с помощью CrystalDiskMark 6.0.2 x64
Тестирование производилось на VM - Windows Server 2008 R2, 4GB mem, 2 cores. Для тестирования виртуальной машине добавлен отдельный пустой диск 32Gb.
В качестве SSD cache выступал том LVM на SATA диске OCZ Vertex V2 EX.
Тест в Crystal Mark запускался по 3 раза, чтобы данные успевали закешироваться. В таблице приведены данные после третьего замера.
Параметры CrystalMark - 5, 1GiB.
Boot Time - время загрузки ОС от включения до появления приглашения Press Ctrl+Alt+Del.
1 - lvm cache - On WriteBack, proxmox cache - no cache, qcow2
2 - lvm cache - On WriteBack, proxmox cache - no cache, raw
3 - lvm cache - On WriteBack, proxmox cache - WriteBack, qcow2 . WARNING - Very High CPU Load while tests. Very Long test.
4 - lvm cache - On WriteBack, proxmox cache - WriteThrough, qcow2 WARNING - Very High CPU Load while tests. Very Long test.
5 - lvm cache - On WriteBack, proxmox cache - WriteThrough, raw WARNING - Very High CPU Load while tests. Very Long test.
6 - lvm cache - On WriteBack, proxmox cache - WriteBack, raw . WARNING - Very High CPU Load while tests. Very Long test.
Проверена скорость работы дисковой системы при хранении образов в общей хранилке с подключением по CIFS. Также она сравнивается с ранее измеренной скоростью работы Ceph.
Содержание
Две конфигурации. Одна для FIO с тестированием NAS/HCI и вторая для SYSBENCH, где и кластер Ceph расширен с 3 до 5.
- 2x Xeon E5-2690 (8C/16T 3ГГц на процессор)
- 194 GB ОЗУ
- 1G Ethernet
- HDD: adaptec 71605Q
- Oracle Linux 8 с ZFS и Samba
- Хранение: на контроллере Adaptec с 1ГБ ОЗУ и 12 HDD 3 ТБ HGST экспортированы как простые тома, на них из ОС создается ZFS RAIDZ3 c ashit=12 (4к). Дополнительно на контроллере включается MaxCache3.0 на двух SSD 480 ГБ Kingstone E50 в RAID1 с writeback на контроллере (т.е. вся запись идет на SSD и лишь затем на HDD, SSD суммарным объемом 480 ГБ используется как кеш на чтение и запись для ZFS и при всем времени теста емкость тестовых данных вмещалась в SSD).
5 серверов с одинаковой конфигурацией, на которых есть как локальный HDD, так и Ceph с двумя пулами, один на HDD и второй на SSD. Для тестов FIO использовались только 3 сервера в кластере с фактором репликации в 3.
- 2x Xeon X5650 (6C/12T 2.5 ГГц на процессор);
- 92 GB ОЗУ;
- 1G Ethernet;
- Proxmox 7.0-11;
- Контроллер HP 410i без кеша на SSD, но с writeback;
- local SSD: 1x480GB 2.5" Sata3 Kingstone 50E в качестве OSD Ceph;
- local HDD: 3x300GB 2.5" 10k SAS в качестве OSD Ceph;
- local HDD: 1x300GB 2.5" 10k SAS в качестве локальной системы хранения.
Oracle Linux 8 QEMU4/KVM 10 ГБ ОЗУ 100 ГБ диск qcow2 с включенным сжатием
Образ виртуальной машины находится на общей хранилке, поключенной по CIFS/Samba.
С помощью fio запускаются тесты на случайные чтение и записи по 4k и последовательные чтение-запись на 1М с большой очередью в 64 операции.
Тесты запускаются на самой хранилке (local native), с хоста на удаленной хранилке (remove native) и из виртуальной машины (remote qcow2). Нас интересует средняя латентность, пропускная способность и IOPS.
Для проведения тестирования надо задать папку, в которой будут тестовые файлы. Примеры ниже.
Кроме пропускной способности (bandwith) и IOPS измеряем латентность.
Также данные нормируем. local native по факту пишет со скоростью локального SSD, поэтому на эту скорость нормируем IOPS и приводим их относительно local native(но это плохо при чтении из ОЗУ). Также раз у нас пропускная способность канала 128 МБ/c, на неё нормируем пропускную способность
Для учета влияния задержек в сети, латентность с хоста на хранилку пингками по 4к составила 0.3 мс.
| system | bandwith avg, (MB/s) | latency avg, (msec) | IOPS avg | iops normalized | bw / (128 MB/s) |
|---|---|---|---|---|---|
| CIFS, local native | 700 | 732 | 694 | 1 | 5,47 |
| CIFS, remote QEMU | 275 | 2740 | 274 | 0,39 | 2,15 |
| CIFS, remote native | 111 | 4144 | 111 | 0,16 | 0,87 |
| Ceph SSD, LXC | 181 | 6624 | 177 | 0,26 | 1,41 |
| Ceph HDD, LXC | 133 | 6947 | 129 | 0,19 | 1,04 |
| Local HDD, LXC | 167 | 2632 | 166 | 0,24 | 1,30 |
| Ceph SSD, QEMU | 125 | 7074 | 118 | 0,17 | 0,98 |
| Ceph HDD, QEMU | 120 | 10690 | 114 | 0,16 | 0,94 |
| Local HDD, QEMU | 300 | 3464 | 296 | 0,43 | 2,34 |
| Ceph SSD LXC/QEMU | 1,50 | QEMU в полтора раза медленнее на SSD |
| Ceph HDD LXC/QEMU | 1,13 | на HDD разница не существенна |
| Ceph LXC SSD/HDD | 1,36 | В Ceph SSD только на треть быстрее HDD |
| QEMU (CIFS remote) / (Ceph SSD) | 2,32 | Ceph SSD оказался медленнее удалённого CIFS в 2 раза |
При последовательной записи QEMU сжала диск и поэтому пропускная способность больше пропускной способности сети (в 128 МБ/c) и видимо по этой же причине ниже латентность.
Т.е. использование сжатия на уровне образа ускоряет последовательную запись сжимаемых данных.
В целом SSD значительного преимущества не даёт, а от нативной производительности хранилки остаётся от 16 до 39%.
| system | bandwith avg, (MB/s) | latency avg, (msec) | IOPS avg | iops normalized | bw / (128 MB/s) |
|---|---|---|---|---|---|
| CIFS, local native | 26 | 10 | 6586 | 1 | 0,20 |
| CIFS, remote QEMU | 9 | 213 | 2410 | 0,37 | 0,07 |
| CIFS, remote native | 0,7 | 332 | 193 | 0,03 | 0,01 |
| Ceph SSD, LXC | 20 | 12 | 5169 | 0,78 | 0,16 |
| Ceph HDD, LXC | 21 | 11 | 5400 | 0,82 | 0,16 |
| Local HDD, LXC | 3,2 | 77 | 829 | 0,13 | 0,03 |
| Ceph SSD, QEMU | 25 | 80 | 6412 | 0,97 | 0,20 |
| Ceph HDD, QEMU | 3,2 | 621 | 829 | 0,13 | 0,03 |
| Local HDD, QEMU | 5 | 378 | 1291 | 0,20 | 0,04 |
| Ceph SSD LXC/QEMU | 0,81 | видимо за счёт сжатия QEMU оказался на 20% быстрее LXC |
| Ceph HDD LXC/QEMU | 6,51 | для HDD LXC существенно быстрее QEMU |
| Ceph LXC SSD/HDD | 0,95 | в Ceph на случайное записи разницы между HDD и SSD существенной нет |
| QEMU (CIFS remote) / (Ceph SSD) | 0,38 | Ceph оказался быстрее CIFS |
Случайная удалённая запись в QEMU раза в три медленнее по IOPS/MB и в 20 по латентности по сравнению с нативной скоростью общей хранилки.
Удивительно, но при случайной записи в Ceph разницы между SSD и HDD не наблюдается. Можно предположить, что это из-за записи через журнал и так как при линейной записи разница SSD/HDD не слишком велика, SSD особого прироста не даёт.
| system | bandwith avg, (MB/s) | latency avg, (msec) | IOPS avg | iops normalized | bw / (128 MB/s) |
|---|---|---|---|---|---|
| CIFS, local native | 9149 | 56 | 9149 | 1 | 72 |
| CIFS, remote QEMU | 11143 | 47 | 11137 | 1,22 | 87 |
| CIFS, remote native | 119 | 4661 | 116 | 0,01 | 0,93 |
| Ceph SSD, LXC | 18551 | 28 | 18648 | 2,04 | 145 |
| Ceph HDD, LXC | 18247 | 28 | 18242 | 1,99 | 145 |
| Local HDD, LXC | 156 | 2512 | 155 | 0,02 | 1,22 |
| Ceph SSD, QEMU | 10439 | 49 | 10435 | 1,14 | 81,55 |
| Ceph HDD, QEMU | 170 | 18480 | 164 | 0,02 | 1,33 |
| Local HDD, QEMU | 118 | 5111 | 115 | 0,01 | 0,92 |
| Ceph SSD LXC/QEMU | 1,79 | Чтение из ОЗУ смысла сравнивать нет |
| Ceph HDD LXC/QEMU | 111,23 | Чтение из памяти сравнивать смысла нет |
| Ceph LXC SSD/HDD | 1,02 | Чтение из памяти сравнивать смысла нет |
| QEMU (CIFS remote) / (Ceph SSD) | 1,07 | Данные нет смысла сравнивать, а отсутствие разницы объясняется, что чтение и в том и в другом случае шло из ОЗУ |
Видно, что и QEMU и нативное чтение на хранилке идут из ОЗУ. ZFS видимо игнорирует direct-чтение. Причем QEMU читает не из ОЗУ сетевой хранилки, а из собственной памяти.
А вот удаленное чтение из хоста оказывается медленным.
| system | bandwith avg, (MB/s) | latency avg, (msec) | IOPS avg | iops normalized | bw / (128 MB/s) |
|---|---|---|---|---|---|
| CIFS, local native | 580 | 0,006 | 149427 | 1 | 4,53 |
| CIFS, remote QEMU | 117 | 11 | 30183 | 0,20 | 0,91 |
| CIFS, remote native | 1,2 | 202 | 318 | 0,0021 | 0,01 |
| Ceph SSD, LXC | 1216 | 205 | 311347 | 2,08 | 9,50 |
| Ceph HDD, LXC | 660 | 0,3 | 168969 | 1,13 | 5,16 |
| Local HDD, LXC | 3 | 85 | 760 | 0,01 | 0,02 |
| Ceph SSD, QEMU | 61 | 33 | 15735 | 0,11 | 0,48 |
| Ceph HDD, QEMU | 2,3 | 587 | 900 | 0,01 | 0,02 |
| Local HDD, QEMU | 1,6 | 1097 | 473 | 0,0032 | 0,01 |
| Ceph SSD LXC/QEMU | 19,79 | Чтение из ОЗУ сравнивать смысла нет |
| Ceph HDD LXC/QEMU | 187,74 | Чтение из ОЗУ сравнивать смысла нет |
| Ceph LXC SSD/HDD | 1,84 | Чтение из ОЗУ сравнивать смысла нет |
| QEMU (CIFS remote) / (Ceph SSD) | 1,92 | Сравнивать смысла нет так как чтение из ОЗУ |
Результаты опять неадекватные.
Тестам на чтение доверять нельзя, так как в действительности оно может идти из ОЗУ.
По записи удивительно то, что на сжимаемых данных QEMU может оказаться быстрее аналогичной записи из хоста. Это можно связать с особенностями архитекторы qcow2.
При последовательной записи Ceph в 2 раза медленнее удалённого хранения CIFS, но только если в QEMU используется сжатие. Локальный жесткий диск даёт производительность сравнимую с Ceph SSD и может превосходить запись по сети на SSD.
При случайной записи по 4k Ceph оказался быстрее удалённого хранилища по CIFS. Можно предположить, что это в результате того, что один из OSD Ceph оказывается локальным диском и оверхед Ceph при записи на локальный диск оказывается меньше оверхеда на запись по сети на CIFS. Но при случайных операциях на Ceph существенной разницы между SSD и HDD нет при использовании LXC, но есть разница в 6 раз при использовании QEMU. Можно предположить, что это из-за большого оверхеда QEMU на случайных записях.
| system | bandwith avg, (MB/s) | latency avg, (msec) | IOPS avg | iops normalized | bw / (128 MB/s) |
|---|---|---|---|---|---|
| CIFS, local native | 355 | 0,05 | 21488 | 1 | 2,77 |
| CIFS, remote QEMU | 326 | 0,05 | 20880 | 0,97 | 2,55 |
| CIFS, remote native | 89 | 0,17 | 5722 | 0,27 | 0,70 |
| Ceph SSD | 28 | 0,55 | 1803 | 0,08 | 0,22 |
| Ceph HDD | 25 | 0,62 | 1596 | 0,07 | 0,20 |
| local HDD | 174 | 0,09 | 11129 | 0,52 | 1,36 |
Видимо SYSBENCH пишет хорошо сжимаемые данные и они настолько хорошо жмутся, что QEMU их пишет почти на скорости локального хранилища и запись упирается в возможности хранилки, при этом формально превышая скорость подключения к хранилке по Ethernet в 120 МБ/c.
Ceph SSD и Ceph HDD оказались малоразличимы между собой, при этом их задержка примерно в три раза больше задержки записи хоста по CIFS и во столько же раз ниже IOPS/bandwith.
Интересно, что локальный диск обогнал сетевые хранилища даже с SSD.
| system | bandwith avg, (MB/s) | latency avg, (msec) | IOPS avg | iops normalized | bw / (128 MB/s) |
|---|---|---|---|---|---|
| CIFS, local native | 3503 | 0 | 224219 | 1 | 27,37 |
| CIFS, remote QEMU | 154 | 0,1 | 9874 | 0,04 | 1,20 |
| CIFS, remote native | 29 | 0,53 | 1886 | 0,01 | 0,23 |
| Ceph SSD | 18 | 0,85 | 1180 | 0,01 | 0,14 |
| Ceph HDD | 16 | 1 | 1003 | 0,0045 | 0,13 |
| local HDD | 151 | 0,1 | 9633 | 0,04 | 1,18 |
Нативная скорость чтения хранилки показала скорость обмена с ОЗУ (3.5 ГБ/c) и 224 тыс. IOPS на чтение.
QEMU опять хорошо сжался и превысил скорость канала и опять опередил в 6 раз несжатую скорость хоста.
Ceph SSD/HDD опять аутсайдеры и опять мало отличаются между собой.
Локальный диск по случайному совпадению оказался близок к работе QEMU.
| system | bandwith avg, (MB/s) | latency avg, (msec) | IOPS avg | iops normalized | bw / (128 MB/s) |
|---|---|---|---|---|---|
| CIFS, local native | 337 | 0,42 | 21589 | 1 | 2,63 |
| CIFS, remote QEMU | 16 | 8,93 | 1018 | 0,05 | 0,13 |
| CIFS, remote native | 95 | 1,49 | 6110 | 0,28 | 0,74 |
| Ceph SSD | 5,52 | 25,7 | 353 | 0,02 | 0,04 |
| Ceph HDD | 5,37 | 26,3 | 344 | 0,02 | 0,04 |
| local HDD | 135 | 1,0 | 8647 | 0,40 | 1,05 |
Локальная запись на хранилке опять уперлась в 21 тыс. IOPS.
QEMU сильно просел и оказался в 6 раз медленнее скорости записи хоста по сети.
Ceph SSD/HDD опять показал самый низкий результат со смешными 350 IOPS и латентностью как у HDD.
Локальный диск опередил сетевую запись.
| system | bandwith avg, (MB/s) | latency avg, (msec) | IOPS avg | iops normalized | bw / (128 MB/s) |
|---|---|---|---|---|---|
| CIFS, local native | 4179 | 0,04 | 267511 | 1 | 32 |
| CIFS, remote QEMU | 118 | 1,32 | 7591 | 0,03 | 0,92 |
| CIFS, remote native | 110 | 1,41 | 7065 | 0,03 | 0,86 |
| Ceph SSD | 170 | 0,9 | 10930 | 0,04 | 1,33 |
| Ceph HDD | 58 | 2,7 | 3714 | 0,01 | 0,45 |
| local HDD | 154 | 1,0 | 9854 | 0,04 | 1,20 |
Чтение на хранилище идет из ОЗУ на скорости 4 ГБ.
QEMU и чтение хоста по сети показывают близкие результаты примерно на скорости интерфейса.
Ceph SSD впервые в тесте значительно отличается от Ceph HDD (в 3 раза), но при этом Ceph SSD лишь немного опережает локальный HDD.
То, что Ceph SSD больше 120 МБ/c можно объяснить тем, что часть данных считалось с локального OSD.
| system | bandwith avg, (MB/s) | latency avg, (msec) | IOPS avg | iops normalized | bw / (128 MB/s) |
|---|---|---|---|---|---|
| CIFS, local native | 76 | 1,87 | 4838 | 1 | 0,59 |
| CIFS, remote QEMU | 56 | 2,54 | 3574 | 0,74 | 0,44 |
| CIFS, remote native | 61 | 2,32 | 3905 | 0,81 | 0,48 |
| Ceph SSD | 52 | 2,7 | 3337 | 0,69 | 0,41 |
| Ceph HDD | 47 | 3,0 | 3002 | 0,62 | 0,37 |
| local HDD | 24 | 5,9 | 1534 | 0,32 | 0,19 |
Максимальная скорость здесь у хранилища при локальном чтении дисков, но только лишь 76 МБ/c при 4838 IOPS. Т.е. уперлись в систему хранения даже не смотря на использование SSD-кеша на запись.
Производительность QEMU и хоста при работе с сетью несколько меньше и сравнимы с Ceph SSD.
Явным аутсайдером является только локальный HDD, но и он смог выдать 1.5 тыс. IOPS, что неплохо для одиночного жесткого диска.
| system | bandwith avg, (MB/s) | latency avg, (msec) | IOPS avg | iops normalized | bw / (128 MB/s) |
|---|---|---|---|---|---|
| CIFS, local native | 1958 | 0,08 | 125358 | 1 | 15 |
| CIFS, remote QEMU | 118 | 1,3 | 7590 | 0,06 | 0,92 |
| CIFS, remote native | 109 | 1,41 | 7000 | 0,06 | 0,85 |
| Ceph SSD | 114 | 1,35 | 8100 | 0,06 | 0,89 |
| Ceph HDD | 15 | 10,3 | 948 | 0,01 | 0,12 |
| local HDD | 6,1 | 23,2 | 391 | 0,0031 | 0,05 |
Для чтения с хранилки опять читаем из ОЗУ.
QEMU, чтение хоста по сети и Ceph SSD опять оказались близки друг к другу и работают примерно на скорости сети.
Чтение с HDD хоть с Ceph HDD, хоть с локального HDD оказалось очень медленным, всего 6015 МБ/c, что типично для HDD при случайных операциях.
Поведение при случайных операциях и последовательных принципиально отличается.
При случайных операциях QEMU, Ceph SSD, обращение с хоста по сети выдают близкие результаты. Локальный HDD оказывается аутсайдером, а Ceph HDD оказывается быстрее локального HDD, видимо за счет распараллеливания запросов.
При последовательном чтении такого единства нет и QEMU может читать из ОЗУ даже при флаге DIRECT, а локальный жесткий диск может превосходить сетевые по скорости и даже подключенные по сети SSD.
Для ряда задач уперлись в скорость сети, также следует обращать внимание на латентность и переход на 10G может не только снять ограничение там где скорости близки к 120 МБ/c, но и снизить латентность и повысить IOPS для случайных операций.
Читайте также: