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. Thanks, Stephan