>>> Noel Kuntze <n...@familie-kuntze.de> schrieb am 12.09.2015 um 20:15 in Nachricht <55f46bc3.7000...@familie-kuntze.de>:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hello Digimer, > >> I am a strong believer in "keep it as simple as possible". In a case >> like this, it's hard to argue that any option is simple, but given that >> RRP is baked into the HA stack, I decided to trust it over QoS. I am >> perfectly open to contrary ideas though. Can you help me understand why >> you think tc's additional complexity is worth it? I'm willing to fully >> believe it is, but I want to understand the pros and cons first. > > If you want or not, the kernel always has a queuing policy on any network > device. > On CentOS 7, it's a pfifo_fast[1][2] queue, which is a classless fifo queue, > but with 3 bands (0,1,2). > Bands with lower numbers have priority over higher numbers. As long as > packets are in band 0, band 1 won't be worked upon and so on. Then that's not FIFO, but priority scheduling. Eveybody knows the starvation problem of priotity scheduling. > The band a packet gets put into depends on the TOS/DSCP mark on the packet > (TOS and DSCP use the same field in an IP packet. > They're just different standards for the values in it). > The TOS/DSCP field of applications that don't set a specific value for that > on the network socket they use (SSH can do that using the IPQoS[3]). > > So obviously, by influencing the TOS/DSCP field value with iptables, we can > influence what packets get send out when. > The goal here is to prioritize Corosync totem traffic (UDP port 5404 and > 5405) with the correct > TOS/DSCP value, so it ends up in band 0 and all the other stuff in band 3. > This leaves you the option to > put dlm traffic into band 2. Imagine some cluster filesystem has it's own timeount / fencing mechanism. Then TOTEM when going wild can cause starvation of other services. It's the wrong design IMHO. I wonder whether this can explain the mysterous cLVM retransmit list growing under some loads. [...] Regards, Ulrich _______________________________________________ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org