[Linux-cluster] Networking guidelines for RHCS across datacenters

[brem belguebli]

Hello,

Here's a link to illustrate the kind of setup I'm trying to setup with RHCS.

http://brehak.blogspot.com/2009/06/disaster-recovery-setup.html

Regards


2009/6/5, Steven Dake <sdake at redhat.com>:
>
> On Fri, 2009-06-05 at 19:40 +0200, brem belguebli wrote:
> >
> >
> > 2009/6/5, Jon Schulz <jschulz at soapstonenetworks.com>:
> >         Yes I would be interested to see what products you are
> >         currently using to achieve this. In my proposed setup we are
> >         actually completely database transaction driven. The problem
> >         is the people higher up want active database <-> database
> >         replication which will be problematic I know.
> >
> > Still we also use DB (Oracle, Sybase) replication mechanisms
> > to address accidental data corruption, as mirroring being synchonous,
> > if something happens (someone intentionnaly alters the DB or
> > filesystem corruption) it will be on both legs of the mirror.
> >
> >
> >
> >         Outside of the data side of the equation, how tolerant is the
> >         cluster network/heartbeat to latency assuming no packet loss?
> >         Or more to the point, at what point does everyone in their
> >         past experience see the heartbeat network become unreliable,
> >         latency wise. E.g. anything over 30ms?
> >
>
> The default configured timers for failure detection are quite high and
> retransmit many times for failed packets (for lossy networks).   30msec
> latency would pose no major problem, except performance.  If you used
> posix locking and your machine->machine latency was 30msec, each posix
> lock would take 30.03 msec to grant or more, which may not meet your
> performance requirements.
>
> I can't recommend wan connections with totem (the protocol used in rhcs)
> because of the performance characteristics.  If the performance of posix
> locks is not a high requirement, it should be functional.
>
> Regards
> -steve
>
>
> >
>
> --
> Linux-cluster mailing list
> Linux-cluster at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-cluster
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20090608/ea225349/attachment.htm>