Most ideal setup for vSphere, FreeNAS & Equallogic's peaceful co-existence

What's your recommended setup?

  • Leave it as is (3 NICs on ESXi side, 2 in Storage VLAN 1, 1 in Storage VLAN 2)

  • Collapse the VLANs/Subnets (2 NICs on ESXi side, both in Storage VLAN 1, no LACP on FreeNAS)

  • Collapse the VLANs/Subnets (2 NICs on ESXi side, both in Storage VLAN 1, with LACP on FreeNAS)

  • Other... please provide response


Results are only viewable after voting.

abrighton

Cadet
Joined
May 18, 2019
Messages
1
Greetings,

A company I do work for has a small (moderate?) size vSphere environment (3 hosts, 4 SANs, 200+ VMs).

The SANs they have in-use are:
  1. Equallogic (PS4210)
  2. 3*FreeNAS (repurposed Dell PE 2950's)
Now they are re-organizing and reworking the network in the environment as part of a move. I'm trying to come up with the best way to structure their storage network. Currently it looks like this:
  • Storage VLAN 1 (250)
  • Storage VLAN 2 (255)
Both the FreeNAS servers and ESXi hosts have 2 separate interfaces dedicated to storage on seperate VLANs and proper MPIO iSCSI is in use for providing the back end storage for the VMs. Awesome.

However, the elephant in the room is the Equallogic - which does not support having two interfaces on separate subnets o_O. Therefore, to get redundant (and load-balanced) connections they have a third adapter on the ESXi hosts configured on Storage VLAN 1 (250), and it appears that MPIO is working for the Equallogic (load is distributed across both NICs on both ends).

Ideally as part of this network re-organization I'd like to simplify this setup (which feels dirty). Initial thoughts were to breakdown the separate VLANs/subnets so that the network is setup to support Equallogic's backwards way of doing things, and have FreeNAS work in a similar way.

This would mean:
  • 1 - Storage VLAN 1 (250)
  • Removing the current 2nd (or 3rd however you look at it) ESXi storage interface, so only 2 exist in the same VLAN/subnet.
  • Setting up a second IP on the FreeNAS in the same subnet
However, after much reading from posts on this forum and elsewhere on the web ... (ignoring the fact that this is highly frowned upon setup) it's likely that FreeNAS wouldn't properly have the traffic load balanced in/out of it's interfaces. So perhaps make use of LACP or some other load balancing algorithm at the FreeNAS end, but many frown upon that even more so?

My question I suppose is what would those of you in this community recommend for a clean setup, that supports MPIO for both the Equallogic and the FreeNAS SANs?

Thanks for any incites you're willing to provide!

Aaron
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,680
This really comes down to how paranoid you are about network problems.

Do you ever need to update your switches? Etc.

Setting up a second IP on the FreeNAS in the sit's likely that FreeNAS wouldn't properly have the traffic load balanced in/out of it's interfaces.

This is kind of like saying "my frickin' car won't drive on two wheels like I see all the time on 70s TV shows."

The standards-based and correct way for multiple interfaces on a single subnet to work is via LACP (This won't work for other reasons though, see below). Storage manufacturers, knowing that storage engineers are usually not also good network engineers, desperately needed a way to create a way for storage networking to work that a non-networking professional could manage.

LACP won't work "as you'd expect" for this because LACP is flow-based. A TCP session between two endpoints is always expected to traverse the same links, based on hash, so if you have only two flows, such as iSCSI sessions from two hypervisors, and you traverse a 2x1G LACP, you have a 50/50 chance that both flows wind up on the same 1G bearer, and then lots of wailing from the non-networking-pro crowd about how LACP doesn't work {right, at all, wotevr}.

So perhaps make use of LACP or some other load balancing algorithm at the FreeNAS end, but many frown upon that even more so?

No, that's fine, but you're going to hit some point at which you have to update a switch, or a switch unexpectedly reboots, and you lose your only actual physical path.

So the thing is, as far as I can tell, your existing setup is potentially optimal. You haven't said anything about switches and how the physical topology is, but I'm *guessing* that someone put some work into this and figured it all out, because this design seems to be correct at the IP networking level. If you are linked into a pair of switches such that a reload or reboot of one does not take out the other path to the storage, this is as good as it gets. Leave it alone. The design's a tradeoff - correct and redundant - but a bit ugly.
 

kdragon75

Wizard
Joined
Aug 7, 2016
Messages
2,457
Also the 2950s could die at any moment. I wouldn't touch one for free at his point. Even the replacement R710 is getting to old to...you may wan to look at more reliable servers for the SAN before you make changes to a working network configuration.
 
Top