On Fri, 2009-06-05 at 19:40 +0200, brem belguebli wrote: > > > 2009/6/5, Jon Schulz <jschulz@xxxxxxxxxxxxxxxxxxxxx>: > 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
