ndaemonv
хотя етстится все в одной сети и на опентековском гипервизоре железо пошустрее даж
ndaemonv
и я подумал может по мимо cache writeback я там чот упустил?
ndaemonv
вримания настройке либвирт, в мануале опенстековском, а пилю я его исключительно по официальной доке, уделено крайне мало
J
хотя етстится все в одной сети и на опентековском гипервизоре железо пошустрее даж
Из твоих объяснений непонятно как тестируешь и что с чем сравниваешь.
Вот смотри:
1. За эталон ты берешь какой-то диск подключенный к проксмоксу по iscsi. Диск то этот откуда? RBD образ? Если да, как именно подключается?
2. Как ты включал rbd кэш на compute серверах?
3. Собственно, как именно ты тестировал? fio? bonniee++? С какими параметрами? Какая ОС в виртуалке? Какая файловая система?
ndaemonv
да это RBD к проксу я его цепанул по iscsi в опенстек через синдер разумеется, Есть цеф в нем пул на ссд, тестирую из впски под виндой NTFS, в нова кэш включил так disk_cachemodes="network=writeback"
ndaemonv
это 2 RBD лежат на одном кластере, на на одном пуле
ndaemonv
в синдер подключился через volume_driver = cinder.volume.drivers.rbd.RBDDriver
ndaemonv
тоже по оф доке
ndaemonv
похоже чертов проксмокс делает за меня что то чегно я прост нарыть не могу
J
Ну для начала посмотри через ps или как угодно еще целиком строку команды qemu-kvm, которой запускаются виртуалки на проксмоксе и в опенстеке.
И давай сравним.
ndaemonv
нет в целом цели сравниваться с проксмоксом, хотел пример привести, хотелось бы понять как настроить опенстек на максимальную производительность. Если учесть что по дефлоту либвирт не конфигурится практически, но имеет кучу параметров, тот же кэш, определения процессора наприметр..
ndaemonv
точнее я не правильно выражаюсь видно не опенстек а вычислители..
J
нет в целом цели сравниваться с проксмоксом, хотел пример привести, хотелось бы понять как настроить опенстек на максимальную производительность. Если учесть что по дефлоту либвирт не конфигурится практически, но имеет кучу параметров, тот же кэш, определения процессора наприметр..
Так ты же ни на какие вопросы не отвечаешь нормально)
Как нам выяснять что ты делаешь не так?
Давай пойдем другим путем.
Покажи, пожалуйста, секцию client из ceph.conf на compute серверах и секцию libvirt из nova.conf.
ndaemonv
из ceph.conf
ndaemonv
[client]
rbd_cache = true
rbd_cache_size = 268435456
rbd_cache_max_dirty = 134217728
rbd_cache_max_dirty_age = 5
ndaemonv
из nova.conf
ndaemonv
[libvirt]
cpu_mode = "host-passthrough"
use_virtio_for_bridges=True
disk_cachemodes="network=writeback"
J
Ну, выглядит нормально.
Теперь давай смотреть действительно ли либвирт запускает процессы qemu-kvm с нужными опциями.
ps -ef | grep qemu-system
В строке опций должно быть cache=writeback
NS 🇷🇺
J
Пока я так и не понял как коллега тестировал производительность.
J
Тут, кроме всего прочего, вопросы еще есть и к сетевой инфраструктуре:
Одинаковые ли сетевые адаптеры на проксмоксе и на compute серверах, настройки mtu какие, опять же)
ndaemonv
ibvirt+ 13962 1 99 15:32 ? 01:19:36 qemu-system-x86_64 -enable-kvm -name instance-00000226 -S -machine pc-i440fx-xenial,accel=kvm,usb=off -cpu host -m 24576 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid eb314349-f12c-4028-9431-485002310369 -smbios type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=14.1.0,serial=6dcd4210-eca9-0807-a146-6f8352cb3665,uuid=eb314349-f12c-4028-9431-485002310369,family=Virtual Machine -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-instance-00000226/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=rbd:ssd/volume-a0074cbd-8844-4043-ab0e-b27185d4edd3:auth_supported=none:mon_host=10.0.0.61\:6789\;10.0.0.62\:6789\;10.0.0.63\:6789,format=raw,if=none,id=drive-virtio-disk0,serial=a0074cbd-8844-4043-ab0e-b27185d4edd3,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:be:6b:c7,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/var/lib/nova/instances/eb314349-f12c-4028-9431-485002310369/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on
root 14252 14186 0 16:48 pts/1 00:00:00 grep --color=auto qemu-system
Eugene
мои глаза =)
ndaemonv
cache=writeback
Eugene
пастебин, коллеги!
ndaemonv
lf e; 'nj nen cnhfiyj cvjnhtnm
ndaemonv
да уж это тут страшно смотреть
ndaemonv
извиняюсь
ndaemonv
так же мотрю
ndaemonv
virsh dumpxml eb314349-f12c-4028-9431-485002310369 | grep cache
ndaemonv
<driver name='qemu' type='raw' cache='writeback'/>
J
Тогда давай анализировать результаты тестов чтоль и думать почему так.
Рассказывай как тестировал.
ndaemonv
тестирую из под винды DiskSPD ntfs
ndaemonv
и кристал диском и еще пачкой утилит
ndaemonv
результаты тестирования диска примерно одинаковы
ndaemonv
Sequential Read (Q= 32,T= 1) : 803.613 MB/s
Sequential Write (Q= 32,T= 1) : 636.378 MB/s
Random Read 4KiB (Q= 8,T= 8) : 77.800 MB/s [ 18994.1 IOPS]
Random Write 4KiB (Q= 8,T= 8) : 40.436 MB/s [ 9872.1 IOPS]
Random Read 4KiB (Q= 32,T= 1) : 78.344 MB/s [ 19127.0 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 39.584 MB/s [ 9664.1 IOPS]
Random Read 4KiB (Q= 1,T= 1) : 6.339 MB/s [ 1547.6 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 22.433 MB/s [ 5476.8 IOPS]
ndaemonv
вот например последнее сень недавно тестил
J
Покажи ты уже, пожалуйста, два набора данных с diskspd с аргументами используемыми для запуска и результатами. Первый набор - там где "хорошо", второй - там где "медленно".
ndaemonv
то что прислал выше это там где полохо щас дам там где хорошо)
ndaemonv
Sequential Read (Q= 32,T= 1) : 4411.940 MB/s
Sequential Write (Q= 32,T= 1) : 4419.121 MB/s
Random Read 4KiB (Q= 8,T= 8) : 392.614 MB/s [ 95853.0 IOPS]
Random Write 4KiB (Q= 8,T= 8) : 309.143 MB/s [ 75474.4 IOPS]
Random Read 4KiB (Q= 32,T= 1) : 303.964 MB/s [ 74210.0 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 227.259 MB/s [ 55483.2 IOPS]
Random Read 4KiB (Q= 1,T= 1) : 38.252 MB/s [ 9338.9 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 20.156 MB/s [ 4920.9 IOPS]
ndaemonv
а вот он хороший
ndaemonv
адский прост какой то
ndaemonv
как он вообще так смог на десктопных ссдхах
ndaemonv
)))
ndaemonv
4000мбс вместо 800 95к иопс против 18к
ndaemonv
я походу всех своими значениями теста напугал)) сам испугался когда увидел ))
ndaemonv
видимо то что на проксе мне нарерял тест это полный бред
ndaemonv
J :-)
Sergei
Ребята, а ктонибудь дружил horizon с gnocchi?
Vladimir Kuznetsov
Какая Связь между gnocchi и horizon?
Vladimir Kuznetsov
Может ceilometer?
Alexander
Может ceilometer?
У Ceilometer нет API, остались только микросервисы публикации и преобразования метрик
Yuf
Alexander
Для Gnocchi подойдёт прометей
Ascandar
для designate rocky для автогенерации записей в днс по другому настраивается нежели в прошлых версиях? у меня даже тулза designate не корректно работает, все через openstack
Ascandar
откуда взять доку, актуальную для рокки для автогенерации записей? на офф доке ничего толкого не нашел
Mike
[client]
rbd_cache = true
rbd_cache_size = 268435456
rbd_cache_max_dirty = 134217728
rbd_cache_max_dirty_age = 5
Можно узнать, зачем вы так делаете?
J
Вы же понимаете, как он работает, да?
Можно же на "ты".
Ну да, понимаю. Да и все кто использует понимают, кроме, конечно, эникейщиков всяких.
Mike
Можно же на "ты".
Ну да, понимаю. Да и все кто использует понимают, кроме, конечно, эникейщиков всяких.
Тогда зачем используете, если понимаете? Еще и в writeback режиме.
J
Тогда зачем используете, если понимаете? Еще и в writeback режиме.
Производительность повышает ощутимо в большинстве случаев, при этом риск потери закэшированного оправдан вполне.
У коллеги проблема не в том что он вообще использует rbd кэш, а в том что разбиратсья не хочет и читает просьбы невнимательно.
Mike
Производительность повышает ощутимо в большинстве случаев, при этом риск потери закэшированного оправдан вполне.
У коллеги проблема не в том что он вообще использует rbd кэш, а в том что разбиратсья не хочет и читает просьбы невнимательно.
это когда приложение думает, что пишет с sync/direct или на raw device и терает потом данные, если compute отъехал?
J
это когда приложение думает, что пишет с sync/direct или на raw device и терает потом данные, если compute отъехал?
Для чего ты сейчас пытаешься доказать что rbd кэш это беда и плохо? Не нравится, не пользуйся. Но в качестве контраргумента могу только привести то что rbd кэш понимает барьеры и flush команды, а значит, когда приложению действительно нужна синхронная запись, данные моментально будут сливаться на OSD, а не висеть в кэше.
Ascandar
вопрос, ресайз по диску в меньную сторону возможен? KVM
George
искаропки. Подумай еще три раза.
J
вопрос, ресайз по диску в меньную сторону возможен? KVM
Без разницы какой гипервизор.
Ты лучше полностью задачу расскажи)
Sergey
от гипервизора зависит
Ascandar
задача представляет такая, имеет стенд, с миним ресурсами для разработки скажем, потом понадобилось для теста или демо увеличить, после чего вернуть в минимальные ресурсы.
Sergey
неважно как ;) единственная проблема подрезать раздел в линуксе
Sergey
в винде то без проблем
George
George
зделай ОТДЕЛЬНЫЙ том под тесты