|
Hello,
On Tue, 8 Aug 2000, Ratz wrote:
> >
> > Questions:
> >
> > - what is the main goal? Some things are not "possible" to
> > implement.
>
> what f.e?
If we move all changes this is a big traffic, i.e.
impossible to maintain on busy sites.
>
> > - is breaking the current connections fatal? 1 to 5 seconds
> > without director before switching to backup one?
>
> not really, connections templates on the first director
> not being updated (synced) have the only impact of the
> client having to reconnect and reauthenticate which is
> the current state of todays lvs-setup. And the idea
> was to sync 1/s or n/s to be configurable (speed problems?)
>
> > - are we going to replicate each state change or to grab a
> > connection table snapshot?
>
> How accurate would a snapshot be? I think we just sent
> each second a packet with the state changes. This should
> be safe enough. The problem I see is, how to transfer the
> masq timeout.
The question which raises is which fields from the
connection structure will be replicated. But you already
understood, I'm pesimist. I can only ask some questions to
help the discussion :)
>
> > - is there a requirement for the used transport? Can this
> > transport be universal, i.e. export data to user space daemon
> > and then send the data using any type of transport?
>
> This would have been my first approach, but if I understood
> Wensong correctly, he doesn't want to run a user space
> daemon. My first idea was to use the netlink interface
> to transfer the data to a user space daemon and then
> you could do whatever you want to.
>
> > - Is it required the remote director to be with same CPU type
> > if we send binary data?
>
> Ok, now I start to understand your doubts about the
> functionality of such a feature. I think it hasn't
> to be the same CPU but I can't tell because I'm still
> not very familiar with kernel coding but it's getting
> better :)
I only add some questions to the discussion that must
be answered. May be this can help to clear the idea of the
connection table replication, if this is the goal.
>
> > - What can be the time to replicate 128MB connection table? 1 second,
> > 1 minute? What is the acceptable time?
>
> over parallel: no idea, 1-2 minutes ?
> over ethernet: 20-30 seconds ?
I worry about such parameters. If we have to implement
it correctly, we can't fit in the normal requirements. This can
work only for slow connections to sites that are not busy. It
seems there will be many restrictions in the implementation.
>
> But my approach is to rather sync and fill up
> the other table on changes then to wait and
> push a hugh table.
And to have the ability to send the table when
BACKUP appears after a failure.
Regards
--
Julian Anastasov <ja@xxxxxx>
|
