On Tue, May 24, 2011 at 04:38:36PM +0200, Pierre BLONDEAU wrote: > Le 24/05/2011 16:24, Pierre BLONDEAU a écrit : > > I appreciate your recommendations, but in this case I advise you to have > > a redundant iscsi san with a very low recovery time. > > Hi, > > Sorry for my English. I meant: > > but in this case what did you advise me to have a redundant iscsi san > with a very low recovery time.
Problem is, since both iSCSI targets do not know of each other, they cannot coordinate access. DRBD cannot magically make a non-cluster aware service cluster aware, not even an iSCSI target. For example, scsi reservations: they do not know of each other, so they would give out concurrent reservations without even knowing. Same for any other "advanced" scsi command: if the targets do not know of each other, and do not coordinate on the iSCSI target session level, "unexpected" results will be quite common. Then think of replication link loss between your DRBD nodes. You currently don't even have any sort of fencing configured there, so your iSCSI targets would happily keep serving diverging data sets, without even knowing. Depending on which paths the request from the initiator takes, it would see different data. Even in single-primary mode, you should implement fencing. Whenever you use DRBD in dual-primary mode, fencing becomes even more important. Maybe you can adjust your idea of "very low recovery time", (what is very low?), and fix/reconfigure your initiators to cope with whatever time it takes to do a failover? As in iSCSI target and IP on top of single primary DRBD, classical failover solution? How much time do you think your current multipath dual-primary architecture would buy you in "recovery time"? In which scenarios? How does that compare to other failure scenarios, and the impact that would have on recovery time from that scenario, e.g. replication link breakage without fencing and diverging data sets aka data corruption? -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
