Сегодня нашлось время прогнать несколько тестов на среде виртуализации. Среди них - тесты для VDI, основанные на “пользовательских” бенчмарках которые доступны всем подряд. Операционная система Windows 10. Результаты на скриншотах ниже и внесены в таблицу.
Benchmark | Test | Thinkpad T14 | vSphere 7 | НИИ Маштаб VEIL | Росплатформа |
---|---|---|---|---|---|
Версия | Р-Виртуализация 7.0.13-35 | ||||
Дата | 2022-09-26 | ||||
GeekBench | Multi-core | 4944 | 1213 | 1345 | 1406 |
Single-core | 763 | ||||
DiskMark | seq read q=8 (MB/s) | 3120 | 1225 | 820 | 2872 |
seq write q=8 (MB/s) | 1018 | 438 | 357 | 325 | |
rand read q=32 (IOPS) 1) | 44 544 | 50 949 | 9 472 | 91 845 | |
rand write q=32 (IOPS) 2) | 32 000 | 17 113 | 1 024 | 45 224 | |
7zip | rate | 933% | 178% | 187% | 188% |
CineBench | CPU multi core | 1345 | |||
CPU single core | 761 | ||||
MP ratio | 1,77 |
Наблюдается интересная тенденция с тем что по крайней мере если говорить об одной небольшой виртуальной машине - VMware проигрывает в производительности средам виртуализации на базе KVM.
Также я некоторое время назад провел по традиционной методики с красивыми графиками тесты Р-Хранилища, результаты не однозначные и я пока не готов их интерпретировать.
4k | 8k | 16k | 256k | 4k | 8k | 16k | 256k | 4k | 8k | 16k | 256k | 4k | 8k | 16k | 256k | 4k | 8k | 16k | 256k | 4k | 8k | 16k | 256k |
rand read | rand write | rand read/write | seq. read | seq. read/write | seq. write |
Р-Хранилище установлено в виде виртуальной машины. Тестирование произведено с подключением к proxmox по iSCSI;
“Родная” установка Р-хранилище в конвергентном варианте с Р-Виртуализация. Тестирование из виртуальной машины Р-Виртуализация.
Вариант с предварительным заполнением диска случайными данными.
Сравните показатели с VSAN. Оборудование полностью одинаковое. За исключением того, что у Р-Хранилища один SSD в каждом узле расходуется для системы и хранилище метаданных. Я буквально на тех-же серверах установил другую систему виртуализации и протестировал полностью еще раз.
Для Р-платформы возможно данная конфигурация является неоптимальной ввиду огромного объема кэша, который по-видимому система использует “на все деньги”. После снятия нагрузки кэш может сбрасываться на диски порядка часа.
Кэш в Р-хранилище работает только в рамках узла на котором установлен и ускоряет все операции работы с хранилищем. Данный тезис требует проверки, но я считаю что если уровень отказоустойчивости подразумевает защиту от выхода узла целиком - это должно обеспечить также отказоустойчивость кэша, так как данные записаные на один узел будут отправлены на другой и точно так-же попадут там в кэш.