Re: Forwarding method in backup server

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Filesystem Devel]     [Linux NFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]     [X.Org]

  Powered by Linux