MPIO vs. Teaming - HP iSCSI SAN

Greetings.  We have our HP P2000 SAN (4 ports x 2 controllers = 8 ports) cross-connected to multiple switches (Cisco 2960g) for redundancy.  The SAN ports are configured with a different internal IP range than our network (172.0.x.x vs 192.168.x.x).  I just set up a new Windows Server 2012, teamed two of the onboard NICS (four total) in a failover configuration (non-aggregated) and used the team as the host for the iSCSI connection.

I've read that MPIO is preferable to Teaming for iSCSI.  However, this is not inside a Hyper-V environment and there's just one "active" NIC, with the other set up as "standby".  Is this setup OK ?  Is there a good reason why I should not continue with this setup and go with MPIO instead ?

Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

You will use the MPIO versus teaming.
MPIO will take advantage of trying to reach the iSCSI storage over two IPs.
Teaming you can setup as a failover as you referenced, or you can bind the NICS to function as one doubling the available bandwidth provided they are connected to the same switch as a LAG (link Aggregation Group).
When you have each going to a separate switch, having each with its own IP will have the through put potential of doubling the bandwidth as well as tolerance for network latency on one ....
andyalderSaggar maker's framemakerCommented:
P2000 doesn't do link aggregation so there's hardly any point using LACP or similar between the host and switch since you're limited to 1Gbps between host and storage. Only way you can setup redundant paths is with MPIO. I suppose if your host has multiple 100Mb ports available then LACP between switch and server would make sense but you'd still use MPIO on top of that.

>The SAN ports are configured with a different internal IP range than our network...

Don't like the sound of that; they should indeed be different than your LAN but also the multiple ports on the controllers should also be on different subnets, if not they may send traffic out the wrong interface assuming your SAN switches are not connected together.
Tommy EriksenSystems Engineer (via Zenit Consult)Commented:
Generally speaking, NIC teaming makes little sense for iSCSI.

When teaming the NICS on your file server, for instance, you can potentially serve more than 1Gbit, if you have several clients accessing it at once - it won't raise the connection speed for a single connection, since it (generally) won't switch that single connection between the physical ports.

MPIO, on the other hand, you can use to create several TCP connections (from port 1 on your server to port 1 on your SAN, port 2 on your server to port 2 on your SAN etc), and your initiator (Windows) can then balance i/o requests across all these connections. This will provide you with both speed (since you can use several ports at once) and fault resiliency (since one connection can fail and it will just go on and use the other ones).

Regarding IP addressing, it's generally a good idea to allocate two subnets:
Controller 1 port 1: Subnet 1
Controller 1 port 2: Subnet 2
Controller 1 port 3: Subnet 1
Controller 1 port 4: Subnet 2
Server NIC 1: Subnet 1
Server NIC 2: Subnet 2

and so on and so forth. This way you can have a totally redundant storage network (on two separate switches).

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Protecting & Securing Your Critical Data

Considering 93 percent of companies file for bankruptcy within 12 months of a disaster that blocked access to their data for 10 days or more, planning for the worst is just smart business. Learn how Acronis Backup integrates security at every stage

lapavoniAuthor Commented:
So MPIO is not a problem with two different servers (iSCSI initiator hosts) connecting to two different vdisk volumes ? The SAN has dual controllers (4 ports each - "A" and "B") and it's set up with a preferred controller for each vdisk.  We have two 2960g switches with the first 10 ports dedicated to the SAN and hosts and tagged as Vlan2.

Sorry for the newbie questions. I'm learning this on the fly.
If you use mpio, the lun should be allocated to a host on both controllers, and segments.
In this case, there should not be a preferred CPU/controller.
lapavoniAuthor Commented:
I guess you haven't worked with HP SANs, Arnold. All controller ports are active for the lun, but one controller is allocated as "active" (your choice). If the SAN controller fails, then failover switches to the other controller. That's how they designed it, as I understand it,
Tommy EriksenSystems Engineer (via Zenit Consult)Commented:
I haven't actually done Windows directly against a HP SAN recently, but on our VMWare hosts (which face a P2000 SAN), we've added sessions towards all controller IPs, and VMWare then determines the active controller via communication with the SAN automatically. If the primary controller for the vdisk dies, it automatically uses the other controller.
I'll presume Windows does the same, but by all means test. :-)

I'll still recommend doing a vlan 2 and 3 (just to name them something) so you can do a separate iSCSI vlan on each switch (on separate subnets). Then you're as redundant as possible.
lapavoniAuthor Commented:
OK, good info so far. I am learning. Just some clarifying information.

1. On each SAN controller, two ports go to one switch and two ports go to another switch.
2. The first 10 ports on the two switches are tagged as vlan2.
3. We do not have the resources or space for separate switches for just iSCSI.  That's why we have this setup. A consultant set it up this way for us. These two switches (2960g) are trunked to the "main" switch, but the first 10 ports only carry traffic from the SAN range - 172.20.0.x
4. To make things a bit complicated, I looked at our current iSCSI host sever (for vdisk1). In the consultant documentation, they were supposed to set up MPIO (Windows Server 2008 R2), but it looks like they may not have done so. I'm not sure. How can I determine if that was done correctly ? There's no "MPIO" tab for the disk in disk manager, *but* there is an online iSCSI disk and an "offline" disk of the same size. Does that indicate successful MPIO ? When I look at the four NICS on the server dedicated to the SAN with 172.20.0.x IPs, only one carries all the traffic. Is this normal ?  Thanks.
andyalderSaggar maker's framemakerCommented:
There's no MPOI tab in disk manager but there is an MIPO control panel applet MPLCPL.EXE. It's not setup for iSCSI to start with so you have to click "add support for iSCSI devices" on the discover multipaths tab to start with.

You still need two subnets/vLANs for iSCSI, with only one it may send traffic out the wrong port and saturate any link between the two switches.
Right, my experience is with EMC sans.

What are you using to establish the iscsi drive links, do you use the OS included iscsi initiator? If so, when establishing the connection, there is a check box whether to use MUlti-pathing

I think in your prior comment you have both network cards for iscsi is on the same network segment.
lapavoniAuthor Commented:
Thanks for the suggestions and relevant information. I have a consultant confirming our switch settings, and will then set up MPIO on existing and additional host.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.