On Wed, Sep 29, 2010 at 01:01:37AM +0300, Julian Anastasov wrote: Hi Julian, Hi all, > > Hello, > > From the recent discussion about loaded backup server > it looks like we do not properly assign forwarding method > to connections in backup server. If backup is used in master > as real server, eg. DR, then backup should use LOCALNODE > for its IP. May be ip_vs_find_dest should allow real server > with port 0 to be used as default server? And if real server > is found its forwarding method should be used for the > connection? So, backup should have the same IP and Port but > it can choose to use different forwarding method? For example, > master uses DR but backup TUN for the same real server. > > Because now when server is added its method can > be converted to LOCALNODE but when such connections > are created in backup server we should use DR or NAT > or whatever the method is configured there. The same is > when backup is added as DR server in master but the > connections should be LOCALNODE when created in backup. > > If we still allow DR/NAT/TUN connections in backup > to work without real server then all such xmitters should > check RTCF_LOCAL and assume LOCALNODE if needed. This is > needed for the case when we do not know the fwmark used > by connection and we can not find the virtual service. > > Then __ip_vs_update_dest should not replace the > configured forwarding method with IP_VS_CONN_F_LOCALNODE > to allow backup to see this method in fwmark connections. > If needed, we can remember that it is local in some > new dest flag, eg. IP_VS_DEST_F_LOCAL. But better to > show it as it was configured? > > So, how to fix these problems? May be: > > - ip_vs_find_dest to find svc and dest in more complex way > > - if backup has dest it should assign its forwarding method > to the connection (ip_vs_bind_dest) > > - allow some transmitters to deliver traffic locally to support > fwmark setups, eg. when no dest is assigned to connection This seems rather tricky to say the least. I prefer the 2nd version of struct ip_vs_sync_conn option... > There is also an option to create 2nd version > of struct ip_vs_sync_conn. For example, size in > struct ip_vs_sync_mesg can be moved after new field > version which will be in place of size. Old backups will > think the small version number as some short size and will > ignore the message. New backup servers can support both > formats. The new format can add new fields for fwmark, > IPv6 addresses, 1 byte af (AF_INET/AF_INET6), 1 byte len > for easy skipping of messages if af or protocol are not > supported. It funny that you should mention that. I need to extend the synchronisation protocol to allow the synchronisation of persistence engine data. And I came up with more or less the same scheme for extending the protocol without breaking old implementations - set the current size field to 0 (or any other value that doesn't match the packet length), add a new size field and a version field. Lets spend a bit of time thinking out a v2 of the protocol that solves the outstanding problems that we have. * No version field * Only 16 bits of flags * No space for IPv6 addresses * No space fwmarks (* No space for persistence engine data) Individually those problems don't seem to warrant a new protocol. But when combined it seems worthwhile to me. > Simon, may be now ip_vs_nat_xmit should see > RTCF_LOCAL flag and we should check all NAT handlers > to support the LOCALNODE fallback where the port can > be changed too. I'm not quite sure what you are describing there. Is the idea that if the forwarding mechanism is NAT then packets will always go via ip_vs_nat_xmit, even if the IP is local (at config time). And that ip_vs_nat_xmit() will use local xmit if RTCF_LOCAL is set? -- 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
