Naja, nicht ganz so. :) Der Cache Mode writeback (unsafe) garantiert keine flushes mehr. Das könnte helfen, ist aber auch nur ein Notnagel.
Ansonsten wäre noch Caching in der VM zu betreiben. Aber am Ende muss darauf aufgepasst werden, dass nicht zu viel Caching die Performance wieder drückt...
fio's ioengine rbd spricht direkt mit Ceph, da brauchst kein rbd Image anlegen und mounten. ;)
Ein leeres und unbelastetes Cluster hat natürlich eine höhere Performance im Test, als im Betrieb. Und 400 MB/s sind nicht so schlecht mit HDDs. Was aber weit von einer 'small block' Performance weg...
kvm6a seems to complain about the other MONs as well.
What did the OSD.22 get stuck on? Maybe the MON still had requests for that OSD in the queue that timed out (> 30 sec).
I meant the interfaces, a LAG between the switches OFC wouldn't help.
When two different switches are involved, then you may better use active-backup. Other modes will need further configuration on the switches.
Setz den Cache mal auf writeback, sonst wird kein Schreibcache benutzt. ;)
Kleine Blockgrößen vertragen sich immer schlecht mit HDDs. Da Ceph dazu noch ein verteiltes System ist, wird's nicht besser.
Was für einen Test hast du gemacht?
There may be service disruptions as the network configuration needs to be applied on the switch and host side. But depending on your Ceph setup, it may not impact VM/CT.
There is report on our bugzilla with aborted zstd keeping the lock. But similar as to your test cluster, I couldn't reproduce the issue.
https://bugzilla.proxmox.com/show_bug.cgi?id=2723
You should be able to keep the specific kernel package with apt-mark hold pve-kernel-<version>. Anyway, you can install the older kernel again, they are kept on the repository.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.