|
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
>
|
