We help IT Professionals succeed at work.

iSCSI SAN Network Configuration for Multiple Host Systems


I am trying to abide by best practices with setting up a SAN (Dell MD3200i) that will have 2 host machines connecting to it (Windows Server 2008 R2, Hardware iSCSI HBA's).

Best practices say that you should create multiple paths from the host servers to the SAN (MPIO), and that each connection should be in its own subnet. All the examples I can find seem to be based around 1 host system connecting to a SAN. I understand this configuration pretty well, but I am getting confused when I throw multiple hosts into the mix.

My confusion lies in this wording: "each connection should be in its own subnet". Does that mean each connection, from each host, should be in its own subnet? So if each host has 2 connections to the SAN switch, I should have 4 subnets total? Wouldn't that get out of control if you had a lot of servers with redundant connections to the SAN? Also, my SAN only has 4 network ports, so really its limited to 4 subnets (which works in my scenario I guess, but not if I added more host servers).

So I'm thinking that each host server can share the subnet with the others hosts connecting to the SAN. For example, here is a diagram:

 SAN Config
M0/M1 are failover controller modules, only one is active at a time.

Would this configuration be accurate? Or should HOST02 P0 and SAN P2 be on 192.168.62.x, and HOST02 P1 and SAN P3 be on 192.168.63.x?

This also leads into another question about iSCSI targets...

Assuming the diagram is accurate, should I specify a specific target for each HOST port to connect to? For example, should HOST01 P0 only connect to the IP of M0/M1 P0, and HOST02 P0 only connect to the IP of M0/M1 P2? Or should I add M0/M1 P0/P2 both as available targets?

Clarification would be great!
Watch Question

What it means is that you should have fully redundant paths from one (or more) host servers to the SAN unit.  That way if you loose a path your data will remain secure.  So if you have 1 host or 8 hosts you still need 2 subnets.

On your picture you are using vlans.  This is a waste.  You still have a single switch that presents a single point of failure.  What you really should do is multiple switches and for best redundancy multiple SAN's configured in failover or load-balancing config.
Oh, target....second part.  Each host should know about the redundant path of the target.  Each host should typically be using the same primary IP address.

By the way, if you are on a budget you can consider using your back-end network as the primary path and using the front-end network as the backup path.  If the back-end network goes down everything will slow down as both general network traffice and iSCSI data traffic traverse the same lines.  But data connectivity will be preserved.


Okay that helps.

Multiple SAN's are out of the question, too expensive, but I can manage an additional switch.

So taking my diagram, replacing all the Orange (VLAN60) with 1 switch, and Purple (VLAN61) with a second switch, the configuration should be ok?

Your oranges should all go to one switch and your purples should all go to another.  Orange would be one subnet and purple would be the other.  You say your SAN has 4 ports, but you appear to be drawing 8 (4 per controller).  Is what you drew correct or you do you truly have 4 total (2 per controller)?  Answer that and we'll go from there.
You already have some redundancy built into the SAN itself, so that is good.  Need to balance your specific redundancy needs with cost and business value.

For the switches, keep in mind that you don't have to use managed switches if you don't want to.  Especially for the redundant path.  You could just throw in a high quality "dumb" switch there.

Yes, you got it on the connectivity.  Of course your diagram post-switch moves from physical to virtual, but I know you understand that.


@Zouleous: Sorry I should clarify. Each Controller on the SAN has 4 ports on it, so 8 ports total. I mentioned only 4 ports because one of the controllers is a failover.

@mds-cos: Thanks for all the clarification, I have much better understanding now.
In that case I think your configuration would be correct if you add a switch and put one color per switch.  Configuration can vary from vender to vender so I can't be sure.  On my SAN I only have 2 ports per controller, but both controllers can be active on mine.  Generally some product manuals are ok to just refer to if you have questions, but when it comes to a SAN setup I would read the vender documentation thoroughly.  I know I did with mine.  You'll be glad you spent the time to later when you know you did everything the documentation calls for.  Printer manuals get put on the shelf...SAN manuals get read.  If the documentation is good then this should all be covered with examples to demonstrate.

See with your controllers doing failover like that I'm not sure if you would have 8 indipendent IP addresses configured.  It might only be 4 and during failover the other controller automatically takes over communication on those same 4 IP addresses that the first controller is using.  I'm not sure, but it would be in the documentation.

Oh and bare in mind I'm not a SAN master by any means.  I don't set them up for a living.  I've only configured the one we have.  I think very often the initial configuration is paid for during the purchase and someone comes on site and assists with that setup.  In my case we were unwilling to pay for that setup cost.

Something else to look at -- the multiple ports on the SAN controllers might actually be built-in switch ports.  You may be able to bypass the switches alltogether with just two servers, plugging direct from server to SAN.  Just a thought since most of the SAN's I've worked with do not have that many ethernet ports.


Thanks for all your input. Between your suggestions and downloading the Deployment Guide for the MD3200i, I have a good understanding of how I am going to connect everything up.

Explore More ContentExplore courses, solutions, and other research materials related to this topic.