|
Wensong,
Thanks for your response below. I have a follow-up question. It
seems that when connection information is transferred via the sync mechanism
that the newly created connections are never bound to a dest (i.e. cp->dest
is always NULL). I believe that this creates many potential problems -- one
of which is that when the backup director takes over it thinks that there
are no connections scheduled to a particular destination when, in fact,
there could be thousands. I would think that this would create serious
scheduling problems.
Was this deliberate? If so, could you explain why this design
decision was made (on the surface it seems like an undesirable thing to me,
but I don't pretend to be aware of all the issues that came up during the
design phase).
Thanks,
Rodger Erickson
> -----Original Message-----
> From: Wensong Zhang [mailto:wensong@xxxxxxxxxxxx]
> Sent: Wednesday, November 28, 2001 10:03 AM
> To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Subject: Re: Sync question
>
>
>
>
> 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
>
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>
|
