Hello, On Fri, 24 May 2013, Alexander Frolkin wrote: > Hi, > > > > 1. Sloppy TCP handling. When enabled (net.ipv4.vs.sloppy_tcp=1, > > > default 0), it allows IPVS to create a TCP connection state on any TCP > > > packet, not just a SYN. This allows connections to fail over to a > > > different director (our plan is to run multiple directors active-active) > > > without being reset. > > For most of the connectoins the backup server > > should get a sync messages in time, so it should be able > > to find existing connection in correct state, usually > > established. By using persistence the chances to > > hit the right real server in backup are increased. > > We have a number of directors in active-active mode, we don't have any > kind of state sync. My understanding is that the state sync daemon only > supports an active-backup configuration. In our configuration it would > have to be sending out updates and receiving updates from other servers > at the same time. Even if this works, we don't want a connection on one > server creating state on all the servers in the cluster, because that > would be a waste of memory most of the time. Also, state sync > introduces a race condition which doesn't exist without state sync. ok, I have to think more days about the effects from sloppy_tcp. May be this logic is useful also for SCTP. > > The SH authors decided to change the mapping in SH > > table with destinations only when dest is added/removed > > but not when weight is set to 0. It is better not to > > complicate the SH scheduler, especially when more schedulers > > can be created. > > Fair enough. So if I create a new scheduler instead of hacking SH, > would that be more likely to be accepted? OTOH, the difference is very small: the port. The problem is that we add only global controls, it would be good if we can configure such parameters per virtual service: - use port in source hash - use source netmask for source address - similar to the netmask used by persistence Not sure what solution is better. May be we can add some IP_VS_SVC_F_SCHED1..N definitions to parametrize the schedulers. As for the netmask, one variant is to reuse the persistent mask/plen. For example: IP_VS_SVC_F_OPEN (or other name): sloppy_tcp/sloppy_sctp The problem here is that we call ip_vs_service_find() after checking th->syn. So, may be it is better to have global sysctl flag here, as in your patch. IP_VS_SVC_F_SCHED1: scheduler flag 1 (SH: fallback to other dest if weight=0), i.e. the sh_rebalance flag IP_VS_SVC_F_SCHED2: scheduler flag 1 (SH: add port in hash) IP_VS_SVC_F_SCHED3: scheduler flag 2 (SH: consider mask/plen) Note that latest SH version supports weights and RCU, you have to consider it for next patch versions. sh_rebalance can become sh_fallback if not done with IP_VS_SVC_F_SCHED1. May be SHP is not needed if SH is parametrized. Comments? Also, you have to check the coding style rules: Documentation/CodingStyle - there are lines above 80 chars - '||' must not be first in line # scripts/checkpatch.pl /tmp/ocado-ipvs.patch gives more warnings. Regards -- Julian Anastasov <ja@xxxxxx> -- To unsubscribe from this list: send the line "unsubscribe lvs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
