|
Wensong,
Thanks for the reply. I certainly appreciate your taking the time
to explain the design decisions.
One final (hopefully :-) thing I noticed while working with the sync
code is that there's no byte order translation being done on information
being passed. For things like addrs and ports that are always stored in
network byte order this isn't a problem. However, there are other items
like cp->protocol, cp->flags, and cp->state that are __u16 and stored in
host-byte order. IMO these should be translated into network-byte order for
transmission and then translated back to host-byte order by the receiver.
I realize that it is unlikely that different processor architectures
would be used for the primary and the backup directors. However, it is
possible for this to be the case. IMO these changes should be made to
prevent problems from occurring under a configuration that is perfectly
legal and reasonable.
Thanks,
Rodger
> -----Original Message-----
> From: Wensong Zhang [mailto:wensong@xxxxxxxxxxxx]
> Sent: Saturday, December 01, 2001 5:03 AM
> To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Subject: RE: Sync question
>
>
>
>
> Hello Rodger,
>
> On Thu, 29 Nov 2001, Rodger Erickson wrote:
>
> > 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.
> >
>
> Yes, the synchronized connections at the backup director are
> never bound
> to a destination server, because I don't want to add extra overhead to
> transfer the destination server information, and in the some failover
> implmentations the backup director will not create ipvs
> routing table and
> will create ipvs routing table only when it takes over. So,
> if we would
> pass the destination server, but the destination server would
> not exist,
> this would be a fatal problem.
>
> The synchronized connections contains information about the
> destination
> address, so when the backup director takes over, the established
> connections can continue to access the service. That's what
> we design it
> for.
>
> As for the scheduling problem you mentioned, it should not be a big
> problem. Supposing that the load is almost balanced among the servers
> before the master director fails, after the backup director
> takes over,
> the scheduling algorithm can balance load among the servers.
> Supposing the
> load is not well balanced among the servers before the master director
> fails, after the backup director takes over, it doesn't know this, but
> will consider every server equal into scheduling, it may
> probably cause
> slight load imbalance. After the synchronized connections expires (the
> connections for most Internet service is short), it will be in load
> balance mode soon.
>
> BTW, the workload of each request varies too, it may cause
> load imbalance
> among the server. So, it is good to some kinds of
> dynamic-feedback weight
> adaptation, i.e. if a server is overloaded, we decrease its weight, so
> that less new requests will be sent to the server; if a server is less
> loaded, we increase its weight.
>
> Regards,
>
> Wensong
>
>
> > 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
> >
>
>
> _______________________________________________
> 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
>
|
