|
On Tue, 27 Nov 2001, Rodger Erickson wrote:
> I have a few questions about synchronization (ipvs-0.9.7). Let me
> start by saying that even though I've spent a bit of time working with the
> LVS source code, I am fully aware that there are certainly subtleties in the
> workings of LVS and synchronization that are eluding me. Thus, please
> consider my questions/comments an attempt to learn rather than any soft of
> criticism about LVS.
>
> In ip_vs_core.c there is the following fragment of code that regulates the
> frequency of synchronization:
>
> /* increase its packet counter and check if it is needed
> to be synchronized */
> atomic_inc(&cp->in_pkts);
> if (ip_vs_sync_state == IP_VS_STATE_MASTER
> && (cp->protocol != IPPROTO_TCP
> || cp->state == IP_VS_S_ESTABLISHED)
> && (atomic_read(&cp->in_pkts) % 50
> == sysctl_ip_vs_sync_threshold))
> ip_vs_sync_conn(cp);
>
>
> My questions are the following:
>
> 1) Why is "in_pkts % 50 == threshold" used? This would trigger
> synchronization every 50 packets starting with packet number
> sysctl_ip_vs_sync_threshold (assuming threshold is less than 50). Thus it
> would seem to me that this threshold value doesn't buy us anything (other
> than ignoring synchronization for TCP connections that are very short
> lived). Instead, I would have thought that something like: (
> sysctl_ip_vs_sync_threshold && ((atomic_read(&cp->in_pkts) %
> sysctl_ip_vs_sync_threshold) == 0)) would be better suited as a conditional
> to determine when synchronization of the connection should occur. Am I
> missing something?
>
The 50 comes from empirical data, we assume that at the time the next 50
incoming packets arrive, the sychronized connection in the backup director
may expire or close to expire, it is good to synchronize connection to the
backup again.
In the first design, I use sysctl_ip_vs_sync_threshold to control whether
the connection is to be synchronized or not. Because some http requests
are really short, for example it may just contains 7 or 8 incoming
packets, it might be not necessary to synchronize the short connections.
> 2) Why do connections need to be synchronized on an ongoing basis?
> Unless (cp->flags & IP_VS_CONN_F_SEQ_MASK) is true none of the information
> being synchronized would ever change (or am I missing something subtle
> here).
>
Sequence number difference is only used in LVS/NAT, because sequence need
adapt when the size of payload changes. In LVS/DR and LVS/TUN, there is no
sequence number differnce, I would rather not to synchronize this null
info in order to save space.
> 3) Thus, it would seem to be more efficient to just synchronize
> when a connection is created (for UDP) or enters the established state (for
> TCP) or is destroyed. Why was this approach not used?
>
It is good for multicasting.
> 4) As for when (cp->flags & IP_VS_CONN_F_SEQ_MASK) is true, it would
> seem to me that we would need to synchronize the connections each time a
> packet is received in order for this to work. Otherwise, it would appear to
> be pretty random whether or not the backup would have sufficient information
> to handle a failover situation on that particular connection.
>
Sorry, I don't understand the question.
> 5) There doesn't seem to be any synchronization of persistence
> templates. Is this forthcoming in a future release?
>
Good question.
In the first design, it is hard to transfer the controlled/controller
relationship of connections to the backup, so I didn't consider the
persistent templates.
I will think about a solution to solve this.
>
> Also, is there a "roadmap" for synchronization that could help me to
> understand the future development plans in this area?
>
Sorry that we don't have a formal roadmap.
Best regards,
Wensong
|
