Proxmox проверка состояния дисков

Обновлено: 07.07.2024

Расскажу про свой опыт установки панели в 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 минимален.

два обычных компа - по два SATA диска 4ТБ в каждом. два диска в drbd для KVM виртуалок. два других под системы.
Всего 8 виртуалок (sql сервер,файл сервер, два контроллера домена, теримнальный сервер,шлюз в инет,астериск и по мелочи) - 7 на одной ноде и одна на другой. drbd Primary/Primary. Загрузки нет никакой в виртуалках но диск под ними грузится на 50-75% по команде atop видно. Как понять что грузит этот диск ОСь или какой либо процесс.
Что покрутить или только SSD диск спасет ситуацию?

А iotop тут ничем не поможет?

Видно всю нагрузку создает одна машина - где то 4МБ/с при этом atop показывает 33-45% загрузки диска sdb.
НО! Скорость диска - хорошо было видно при инициировании drbd диска была на уровне 50-55МБ/с. Сейчас загрузка от виртуалок меньше в 10 раз, но atop показывает соизмеримые цифры как во время синхронизации drbd.
Получается что виртуалкам сейчас доступно максимум 12МБ, а где остальные 35МБ?

Процессоры отдыхают загрузка 25-30% и оперативка занята на 30%

А если на самой машине запустить?

iotop запускал в хостовой ОС.

Цифры в студию.
cat /proc/drbd
cat /proc/mdadm
dmesg
syslog
и прочие выхлопы всяких *top.

Я имел в виду в госте запустить. Для офтопа тоже есть подобные утилиты. process explorer от русиновича следит за диском.

немного подсократил вывод

dmesg огромный - не добавляется :( может бы ть избранное из него?

Vlad-76 ★★★ ( 13.07.13 18:30:59 )
Последнее исправление: Vlad-76 13.07.13 18:31:29 (всего исправлений: 1)

а для чего внутри виртуалки (гостя) то запускать?

Чтоб узнать, что грузит. Если в госте всё в порядке, значит сам kvm.

по iotop загрузка от всех kvm виртуалок - 3-7МБайт/с, а по аtop загрузка диска - 50%
. т.е. загрузка создаваемая гостевой ОСью уже сидит в этих цифрах

Это tazhate хотел. Я только про pastebin подсказал.

По поводу iotop в гостях - а вдруг там какой процесс реально много обращается. Так его сразу и вычислишь.

виртуалка которая создает нагрузку иногда это файл сервер - суммарно 3-4 МБ/с, это хорошо видно в хостовой части - загрузка по iotop аналогична. Но больше скорости на файл сервере невозможно достичь, это и есть проблема.

Но больше скорости на файл сервере невозможно достичь.

А это как видно?

А какая фс? Посмотри и/о нагрузку.

Как понять что грузит этот диск ОСь или какой либо процесс.

БЛИИН как надоела эта кнопка отмены справа.

короче последовательная чтение/запись одно дело, а рендомное другое. скорость последовательных операций можешь проверить с помощью dd(ну понятное дело на простаивающей системе), если в пределах, привет ssd, хотябы под кэш! sql сервер с прочей лабудой на одном диске очень здоровое решение - запустит бух проводку за квартал и привед аторизация, печать и интернет.

все виртуалки на proxmox переехали с сервера (обычный комп) под Hyper-V в Windows Server 2008, на этом сервере они были тоже виртуалками. Все виртуалки спокойно уживались и файлсервер нормально работал, кстати то что скорость не поднимается выше 3-5 МБ/с и было замечено при переезде - копировании файлов со старого файл сервера. При этом atop на proxmox пишет, что диск сильно занят 50-75%. На старом дисковая подсистема - это два диска в зеркале, программный RAID. Файл сервер только и осталось перенести, но система чувствую не взлетает.

Proxmox - популярная система виртуализации. Для того чтобы максимально эффективно использовать предоставленные операционной системой возможности, давайте разберемся как расширить хранилище данных на жестком диске. Для хранения данных в Proxmox VE можно использовать внешние хранилища, сетевые ресурсы или подключать к системе дополнительные HDD или SSD, а также использовать контроллеры SCSI или RAID.

Обращу ваше внимание на особенность системы: типы хранилищ, кроме Образ диска и Виртуальная машина можно размещать только на подключенных хранилищах с типом Каталог. В этой статье мы рассмотрим как добавить диск Proxmox на примере Debian.

Добавление диска в Proxmox VE

В рассматриваемом случае, подключен и предварительно настроен в BIOS компьютера SATA HDD емкостью 120 Гб. Он полностью очищен и не размечен ни под какую-либо ОС и определился в системе как устройство /dev/sdb. В Proxmox VE подключения к хранилищу логически разделены по вкладкам Датацентр, где можно подключить сетевые хранилища, и каждой машины в отдельности, в нашем случае локальная машина называется PVE. Ниже представлены варианты, предлагаемые к созданию из вкладки Датацентр:

1. Разметка диска

Для операций с диском давайте использовать в режиме XFCE4 от имени суперпользователя root дисковую утилиту GParted:

Выберите меню Устройство, пункт Создать таблицу разделов:

В результате утилита предложит создать несколько видов разделов, в том числе: msdos (MBR), GPT, mac и прочие. Для целей подключения дополнительного хранилища Proxmox VE, рассмотрим создание раздела GPT с различным видом файловых систем. Для этого выберите GPT и нажмите Применить.

2. Поиск раздела в консоли Proxmox VE

Перейдите в раздел PVE, затем в раздел Диски, там должен появиться размеченный под GPT диск /dev/sdb с типом unknown, не используемый (колонка Использование), в колонке GPT должно быть указано Да, а в колонке Использование можно увидеть тип диска, у /dev/sdb его пока нет:

3. Форматирование диска средствами Proxmox VE

В панели управления ProxmoxVE можно отформатировать подготовленный диск под файловую систему LVM или ZFS.

Файловая подсистема LVM позволяет использовать разные области одного жёсткого диска и/или области с разных жёстких дисков как один логический том. Реализована с помощью подсистемы device mapper. Активно используется ProxmoxVE как основная файловая система.
Файловая система ZFS, разработки SUN Microsystems, поддерживает большие объёмы данных, объединяет концепции файловой системы, массивов RAID, менеджера логических дисков, принципы легковесных файловых систем, предоставляет простое управление томами хранения данных.

Так же мы создадим раздел на диске GPT, который отформатируем под EXT4, журналируемой файловой системой, которая используется в операционных системах с ядром Linux.

Для создания LVM раздела перейдите в раздел Диски машины PVE, выберите пункт LVM , Создать: Volume Group, укажите диск /dev/sdb и задайте его имя, например backup.

Тот же способ подходит и для создания раздела LVM-Thin: LVM Thin Provisioned volume, тонкие (разреженные) тома, которые занимают столько места, сколько требуется системе.

Для создания ZFS раздела снова используем не размеченный диск, ранее размеченный диск можно снова вернуть в состояние не размеченного с помощью GParted.

Перейдите в панели управления Proxmox VE в меню Диски машины PVE, затем в разделе ZFS выберите кнопку Создать: ZFS. Снова задайте имя хранилища backup, если необходимо включите сжатие, и нажмите кнопку Создать.

Зеленый значок возле ONLINE говорит о том, что диск доступен для работы. Также из панели управления Proxmox VE можно управлять состоянием хранилища, добавлять диски.

На созданных и подключенных через панель управления Proxmox VE томах LVM можно хранить образы и диски виртуальных машин. Для создания остальных объектов необходимо примонтировать диск к файловой системе хоста PVE. Теперь вы знаете как добавить жесткий диск proxmox.

4. Форматирование диска в Ext4 с помощью терминала

Для разметки диска GPT и форматирования раздела под файловую систему EXT4 воспользуйтесь приложением Терминал. Ниже показано как выглядит структура файловой системы на хосте PVE:

С помощью консольной утилиты fdisk произведите создание системы GPT и создайте новый раздел на диске /dev/sdb:

sudo fdisk /dev/sdb

В результате в системе должен появиться раздел /dev/sdb1 диска /dev/sdb. Создадим файловую систему:

sudo mkfs.ext4 /dev/sdb1

По окончании форматирования, создайте точку монтирования /backup:

Отредактируйте файл /etc/fstab, в котором указываются точки монтирования дисков системы, таким образом, чтобы в конце файла была строка:

sudo vi /etc/fstab

/dev/sdb1 /backup ext4 defaults 0 2

Дайте системе команду монтировать все диски, указанные в файле fstab:

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

Создайте диск LVM, на этот раз из программы Терминал. Для этого необходимо подготовить диск с помощью консольной утилиты fdisk:

sudo fdisk /dev/sdb

sudo pwcreate /dev/sdb1

sudo vgcreate pve-test-bkp /dev/sdb1

sudo lvcreate -L 110G -n backup pve-test-bkp

ls /dev/mapper

Сознательно создавались длинные имена файлов, чтобы показать, как будет именоваться результат выполнения комманд: LVM-раздел pve—test—bkp-backup, расположенный в /dev/mapper теперь можно отформатировать в файловую систему EXT4 и примонтировать в раздел файловой системы /backup точно также, как ранее монтировался /dev/sdb1:

mkfs.ext4 /dev/mapper/ pve—test—bkp-backup

В файле /etc/fstab уберите вместо /dev/sdb1 укажите новый раздел, чтобы выглядело так:

sudo vi /etc/fstab

/dev/mapper/ pve—test—bkp-backup /backup ext4 defaults 0 2

Дайте команду системе перемонтировать диски согласно данным /etc/fstab:

5. Использование диска для хранения архивных копий, образов и шаблонов

После удачного монтирования диска осталось добавить диск proxmox в панели управления. Для этого нажмите кнопку Добавить в разделе Хранилище хоста PVE и укажите тип Каталог. Выберите ID backup, каталог укажите /backup, в содержимом выберите Резервная копия и любые другие пункты с помощью зажатой клавиши на клавиатуре Shift и кликов мышкой.

В меню Пулы Датацентра создайте пул backup и добавьте созданное хранилище backup. Это позволит выбирать пул при создании виртуальных машин, создании бекапов и других файловых операций.

Настройте резервную копию, на примере виртуальной машины CentOS. Для этого перейдите в виртуальную машину, затем в пункт Резервная копия, выберите в правом углу Хранилище backup, нажмите кнопку Создать резервную копию сейчас. После заполнения полей и нажатия кнопки Резеврная копия будет запущен фоновый процесс создания резервной копии.

6. Использование диска для хранения виртуальных машин

При создании хранилища backup были выбраны не только резервные копии, поэтому его можно использовать для создания образов виртуальных машин. Те диски, которые были инициализированы из панели управления Proxmox VE, могут размещать образы виртуальных машин, но не другие объекты.

При создании виртуальной машины можно выбирать любое хранилище, и оно будет поддерживать объекты, которые создаются при создании виртуальной машины. На скриншоте ниже приведены минимальный набор объектов любого хранилища Proxmox VE:

Выводы

Сегодня вы узнали как выполняется подключение дисков Proxmox, путями создания файловой системы на чистом не размеченном диске, с различными методами разметки диска, вариантами подключения хранилища к гипервизору.

Нет похожих записей

Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна.

Проверена скорость работы дисковой системы при хранении образов в общей хранилке с подключением по 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 для случайных операций.

Читайте также: