Block multipathing in an IP-SAN

Block multipathing in an IP-SAN

[goggin, edward]

I'm wondering about how block device multipathing works in conjunction with
the high availability
features of an IP-SAN.

Does the iSCSI initiator's session layer's retransmission capability and the
IP-takeover capability
of IP-SAN switches eliminate the need for block device multipathing in an
IP-SAN?

Does the iSCSI initiator present redundant paths to the SCSI mid-layer?

Do these answers differ with software verses hardware iSCSI initiators?

Re: Block multipathing in an IP-SAN

[Mike Christie]

goggin, edward wrote:
> I'm wondering about how block device multipathing works in conjunction with
> the high availability
> features of an IP-SAN.
> 
> Does the iSCSI initiator's session layer's retransmission capability and the
> IP-takeover capability
> of IP-SAN switches eliminate the need for block device multipathing in an
> IP-SAN?
> 
> Does the iSCSI initiator present redundant paths to the SCSI mid-layer?
> 
> Do these answers differ with software verses hardware iSCSI initiators?
> 


For linux mainline and what some distros carry, software will be similar 
to HW iscsi becuase the linux-scsi community has not wanted MCS. For 
software iscsi in mainline (open-iscsi/linux-iscsi-5) and RHEL 4 
(linux-iscsi-4), you can use bonding or trunking - whatever you know it 
as, and hide everything from the iSCSI and SCSI levels, or you can use 
dm-multipath. To do the latter for software iscsi, the iscsi driver 
creates a session to each portal, scans it, and dm-multipath/multipath 
assembles dm devices like it would for FC. The softare drivers drivers 
also support login redirect and some vendors use this for failover and 
load balancing. I think qlogic also support this.