>The problem with fully automated systems for remote replication is >that they are fully automated. This opens you up to a set of failure modes >that you may want to avoid, such as replication of data that you don't >want to replicate. This is why most replication is used to support disaster >recovery cases and the procedures wrapped around disaster recovery >also consider the case where the primary data has been damaged -- and >you really don't want that damage to spread.
I seem to be misrepresenting how automatic DRBD is because it offers a rich set of policies and strategies to deal with faults. For one thing, it (along with heartbeat) will bend over backwards to avoid disasters such as split-brain. It's more likely that one would get split-brain by manually executing the wrong command than by DRBD's (or heartbeat's) doing. >I disagree, there are many ways to remotely replicate Solaris systems. >TrueCopy and SRDF are perhaps the most popular, but almost all I was referring to cost free options. -- Maurice Volaski, [EMAIL PROTECTED] Computing Support, Rose F. Kennedy Center Albert Einstein College of Medicine of Yeshiva University _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
