7

I'm setting up some iSCSI storage (Lenovo) along with a physical server running RHEL7. The server has 2 NICs for the main LAN (bonded) and 2 NICs for the iSCSI network. The Lenovo storage has 4 ports connected to 2 physical switches. The iSCSI NICs in the server go to 1 port in each of the switches.

I've installed iscsi-initiator-utils and dm-multipath.

When I run this command I can see the following output

iscsiadm -m discovery -t sendtargets -p 192.168.1.11

192.168.1.13:3260,2 iqn.2002-09.com.lenovo:thinksystem.600a098000f8709a000000005cfff0e0
192.168.1.14:3260,2 iqn.2002-09.com.lenovo:thinksystem.600a098000f8709a000000005cfff0e0
192.168.1.11:3260,1 iqn.2002-09.com.lenovo:thinksystem.600a098000f8709a000000005cfff0e0
192.168.1.12:3260,1 iqn.2002-09.com.lenovo:thinksystem.600a098000f8709a000000005cfff0e0

Which is re-assuring in that the discovery process has found all 4 addresses on the Lenovo storage NICs.

And then I re-scan by SCSI bus with rescan-scsi-bus.sh

I define an alias for the disk wwid called lenovo01 using puppet multipath

Then I run this command and see the following output

multipath -ll

lenovo01 (3600a098000f63bc40000027d5d680d78) dm-14 LENOVO  ,DE_Series       
size=16T features='0' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=1 status=active
| `- 11:0:0:1  sdg  8:96   active ready running
|-+- policy='service-time 0' prio=1 status=enabled
| `- 12:0:0:1  sdc  8:32   active ready running
|-+- policy='service-time 0' prio=1 status=enabled
| `- 13:0:0:1  sdd  8:48   active ready running
`-+- policy='service-time 0' prio=1 status=enabled
  `- 14:0:0:1  sde  8:64   active ready running

This is also good, as it shows my storage volume called "lenovo01", accessible through the 4 Lenovo NICs

I'm using puppet to configure the iSCSI NICs and was wondering if I should create a bond for the connection to the storage? Currently they're 2 separate NICs and the storage only reports seeing a single "host port" for the server (I was maybe expecting to see two host ports?). The storage describes the host port with the iscsi initiator name (as found in /etc/iscsi/initiatorname.iscsi)

Am I right in assuming that if the first storage NIC fails, then multipath is intelligent enough to use the second one automatically. Or do I need to explicitly bond them?

Thanks,

Rob.

6

You can LACP NICs you're planning to use with iSCSI, but only in one case - if both "sides" (target & initiator) support so-called "multiple connections per session". If they don't or this feature isn't configured properly (say # of connections = 1, which is obvious) you'll get uptime, but you won't get any performance increase. Reason is simple: every new TCP session should belong to another physical NIC, so with a few TCP sessions increase will be marginal. Preferred way to handle this is to use iSCSI MPIO rather than MC/S. See (this is SCST page, but it's the same for all the targets & initiators):

http://scst.sourceforge.net/mc_s.html

1

I am assuming by "bond" you mean "portchannel" or "etherchannel". I would not bond them. The multi-path driver and storage should be intelligent enough to handle using the multiple active paths and scheduling which path to send a storage transaction down.

Using a portchannel/bond on your server leaves the server with a single logical NIC meaning typically a single IP and MAC address. The switch and server would be involved in making load balancing decisions on the server to switch link rather than the storage and iSCSI initiator. I'd rather have the storage infrastructure making the load balancing decisions for storage traffic.

Most people as a best practice do a side A and side B setup on their storage/iSCSI initiators using different subnets for each. I've done it both ways and never had an issue.

You are correct that the storage infrastructure is smart enough to detect a storage path being down.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.