[Pacemaker] Dont start LVM or FS on DRBD Standalone
Lars Ellenberg
lars.ellenberg at linbit.com
Tue May 24 15:02:29 UTC 2011
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.
More information about the Pacemaker
mailing list