Search results

i would test it bnut do you reall think it would help to even further reduce the time pong has to come? the patch lowers this value based on average instead of peak. so before, if you max ping was 1.5ms you wont time out on a pong at 1.5. with the new patch you may time out sooner. specially...

oxmox-vty-002 corosync[15827]: [TOTEM ] Token has not been received in 84 ms syslog.4.gz:Sep 12 21:50:53 proxmox-vty-002 corosync[15827]: [TOTEM ] Token has not been received in 10117 ms syslog.4.gz:Sep 12 21:50:58 proxmox-vty-002 corosync[15827]: [TOTEM ] Token has not been received in...

do you have by any chance balloing activated and setr different values for min and max?

i dont think so, if anything it would raise more issues. it does nto address the completly lockup of running nodes, it just adresses when we see a timeout. as much i understand this: so currently they measure at start the max ping and set it as a default, which is worst case latency. so it...

yep, down nodes block running nodes, in often a wierd way. how is your network setup?

jup thats how it looks like after reconnect. same here.

swapiness 0 doesnt mean swap will not be used. it coudl be used if the system is out of memory. what you can do to test this theory is install zram and give it a bit swappiness

sorry but this is not correct. it is far enough for corosync alone, just make shure you dont run your migrations over this. corosync itself uses nothing just needs super low latency on a 4 node cluster we have stable 150kbit down and upload on that line. so no you do not need more than those...

question is why do we have those timeouts of the fuse filesystem. promox is supposed to have /etc/pve readonly on nodes that fall out and keep it as is on the other nodes. but for me, the faulty node works fine while all other nodes (that are still joined and working) freezing. it would at...

in short NO Reason: the host cannot know the filesystem and therefore know which part is used. extending is easier as it simply makes the file bigger and set the information about it workarounds: prefered way is using zfs with thin provisioning, prefably on a ssd or nvme. with that you have to...

oh youre right, sorry for that. i dont know why i had the impression it would, i could swear i read about it on debian.org. must have been after dealing so much with those premade images from hetzner and ovh recently. youre right debian10 is no systemd networking by default... well just...

little update on a second ring. i have now eno2 - vlan for ring0 (10gbit interface to OVH vrack) eno1 - bridge via tinc for ring1 while most nodes report no errors, one special problem node does report link downs, sometimes even both at least to some hosts like Sep 12 14:06:49 h3...

oh no debian 10 comes with systemd by default not their fault. the issue with hetzner is the hdd layout and mdraid which isnt officially supported by proxmox either

its /etc/pve/corosync it will rewrite the /etc/corosync and distribute it over the nodes yea restarting the "faulty" node wont help you, you need to restart corosync on the other nodes. its paradox but this is how it works for whatever reason. as i wrote above my hunch is that corosync main...

you said this happens to 2 nodes in a cluster? same time? STOP RIGHT THERE , stop meesing with zfs, its not zfs. just service restart corosync another possible fault would be storage shares, nfs and cfis in particular. if its not corosync deactivate external storages. a faulty storage, or...

then dont use it for now. system.d networking is not supported by promox at the moment. i woudl wait till they implement it officially and then make the leap over. as for the hetzner image, simply configure interfaces the properway, then disable systemd.networking should be enough however...

thanks, will try. little update on this. since i do not trust OVH or their ability to provide virtual networks i setup a second ring on tinc. now its much more stable. had today NO corosync logentry in 2 of the nodes. now wierdly enough, while 2 nodes dont report anything at all for today, 2...

Allnodes same version Attached logs are as described node 1,2,3,4 I shortend some logs and cut of retransmition lists, i left first 3 and last 3 of a junk to have the timestamps in case its interresting same time no errors system logs/dmesg about any network related issue. dont have network...

yes to be expected. the issue seems related to any device i/o, so at the first few megs caches gonna work a bit in your favour. the moment it really needs to access the disk its over. this seems to be very low level kernel related. since most cfis code is also kernel code not that big of a...

just wanted to hint you whats awaits in your forseeable future :)