|
Hello,
On Sat, 12 Aug 2000, Lars Marowsky-Bree wrote:
> On 2000-08-07T21:47:36,
> Julian Anastasov <ja@xxxxxx> said:
>
> > - what is the main goal? Some things are not "possible" to
> > implement.
>
> Having a backup LVS takeover from the main one without losing a single
> active connection.
>
> I would be happy with a two node solution for now, though n > 2 is even nicer
> ;-)
Implementing such thing is not a simple task. It requires
much work. Even LVS is simpler.
> > - are we going to replicate each state change or to grab a
> > connection table snapshot?
>
> Each state change is the only reasonable way.
>
> Upon start of one machine, we obviously need to grab a connection table
> snapshot once and queue the pending updates.
>
> > - 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?
>
> I would prefer this - netlink should make this easily possible.
>
> > - Is it required the remote director to be with same CPU type
> > if we send binary data?
>
> This will not be a problem, we can document it as a prerequisite for this to
> work.
>
> > - What can be the time to replicate 128MB connection table? 1 second,
> > 1 minute? What is the acceptable time?
>
> "As soon as possible".
Other notes:
- For VS/NAT the real servers have to switch to the new router,
with or without their knowledge.
To support or not to support:
- the state of the masq modules/applications must be replicated too
Without such support there is no redundancy of the NAT
box where the LVS and the other MASQ modules play together, for
example a NAT-ed Proxy servers.
- smoothly move all services from one director to the backup one,
i.e. the support is not restricted for failover cases only. For
example, to install a new kernel or to make other changes that
lead to downtimes.
- move only some of the services to another box but continue to
serve the rest of the services.
> Sincerely,
> Lars Marowsky-Brée <lmb@xxxxxxx>
> Development HA
Regards
--
Julian Anastasov <ja@xxxxxx>
|
