Am 19.03.13 17:32, schrieb Lars Ellenberg:
On Tue, Mar 19, 2013 at 05:11:05PM +0100, Stephan Budach wrote:
Am 18.03.13 20:05, schrieb Stephan Budach:
Am 18.03.13 10:07, schrieb Lars Ellenberg:
On Sun, Mar 17, 2013 at 08:19:26AM +0100, Stephan Budach wrote:
Hi all,
I am running DRBD 8.4.3 in a dual-pri setup. DRBD interlink is
through a 10 GbE Intel Cx520 link, which is piggy-backed between the
two Supermicro boxes. I have configured two SCST iscsi targets from
two DRBD volumes, which configured as multipathed targets on three
Don't.
Simply: Don't.
Multipath expects to talk via more than one path to *the same target*.
What your setup does it have multipath talk (via one path each) to
*two different targets*, that don't know of each other,
and happen to be able to present the same data most of the time.
As iSCSI is not just about READs and WRITEs, but, especially in a
clustered setup, about reservations and other management commands,
this CAN NOT WORK, and that is NOT drbd's fault.
So just don't.
Thank you.
Lars
Hi Lars,
okay, point taken, but what about the issue with drbd
disconnecting when both primary get under high load? Even without
iSCSI access this shouldn't happen, should it?
Thanks,
Stephan
Btw, LIO does support SCSI3 persistent reservations, so one could
swap scst with LIO and build multipathed iSCSI targets with it,
unless I am mistaken and have misread anything.
You are absolutely mistaken.
First, SCST does support SCSI-3 persistent reservations as well.
But the point is not about wether or not the target supports some SCSI
command subset. But wether or not it is cluster aware.
The initiators are assuming to talk to *ONE* and the same target,
whereas in this setup, it would talk to *TWO* independent targets
(which happen to be able to present the same data most of the time).
So, staying in the "reservation" example,
one initiator would succeed in checking out reservations on the
pink target, while an other initiator succeeds in checking out the same
reservation on the purple target.
As the targets are not cluster aware, all management commands
(even "just" LUN resets) can (and thus will!) cause serious harm.
Ok, so would it then even make sense to deploy, a dual-primary DRBD
where the SCST target fails over along with a virtual IP for the target
then? This would cause a little timeout to the initiators, but they
should then be able to log into their targets again.
I guess this may be good enough and even, altough this setup lacks the
inherent load balancing, but if the target servers are connected through
10GbE, I guess I could live with that.
Thanks,
Stephan
_______________________________________________
drbd-user mailing list
[email protected]
http://lists.linbit.com/mailman/listinfo/drbd-user
