[DRBD-user] Dual-primary setup: disconnecting

Adam Goryachev mailinglists at websitemanagers.com.au
Wed Mar 20 09:08:47 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.

On 20/03/13 05:14, Stephan Budach wrote:
> 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.
Why not configure as dual primary, but configure the initiators to only
talk to a single target, and only change to the other target after
failure/timeout. I haven't done this yet, but it is my plan to implement
it soon.

It would be nice to hear whether this "should" work as expected.... Any


Adam Goryachev
Website Managers

More information about the drbd-user mailing list