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 comments? Regards, Adam -- Adam Goryachev Website Managers www.websitemanagers.com.au