Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 28.11.2011 21:26, Lars Ellenberg wrote: > On Fri, Nov 25, 2011 at 09:11:39PM +0100, Andreas Hofmeister wrote: >> On 25.11.2011 17:08, John Lauro wrote: >> >> @list: did anybody try such a thing ? > > "dual-primary" iscsi targets for multipath: does not work. > > iSCSI is a stateful protocol, there is more to it that than just reads and writes. > To run multipath (or multi-connections per session) > against *DISTINCT* targets [*] on separate nodes > > ** you'd need to have cluster aware iSCSI targets ** > > which coordinate with each other in some fashion. Mhh, I just wondering what exactly could explode. Surely one would (have to) synchronize the more static configuration aspects - ACLs, authentication etc, in some way. Things like iSCSI reservation or limits on concurrent access to a single target is likely something that would require support from the target infrastructure. And indeed, it seems that none of the iSCSI targets on Linux would support that. But for pure read/write aspects, multipathing requires support from the initiator anyways, no ? TCP f.e. cannot guarantee the ordering of packets in different TCP streams in the first place, so the order of simultaneous writes to different portals is pretty much undefined (or a write on one path and a flush on the other) ? > > To my knowledge, this does not exist (not for linux, anyways). > > [*] which happen to live on top of data that, due to replication, > happens to be the same, most of the time, unless the replication link > was lost for whatever reason; in which case you absolutely want to make > sure that at least one box reboots hard before it even thinks about > completing or even submitting an other IO request... ... which is was just another reason why to have proper I/O-Fencingor STONITH in place, no ? Ciao Andi