|
Hi Julian,
>
> Questions:
>
> - what is the main goal? Some things are not "possible" to
> implement.
what f.e?
> - 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.
> - 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 :)
> - 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 ?
But my approach is to rather sync and fill up
the other table on changes then to wait and
push a hugh table.
> Regards
>
> --
> Julian Anastasov <ja@xxxxxx>
>
regards,
Roberto Nibali, ratz
|
