[DRBD-user] Dual-primary setup: disconnecting

Stephan Budach stephan.budach at jvm.de
Tue Mar 19 19:14:57 CET 2013

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

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.


More information about the drbd-user mailing list