• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

ESXi - Using Interfaces

Adam12176

Limp Gawd
Joined
Dec 27, 2007
Messages
205
Hey, couple quick questions for the collective.

I have two R810's that each have four 'forward facing' interfaces, and I'm throwing around some ideas as to how they should be set up.

The four have to accommodate: Management, vMotion, and Active VM traffic.
Overall volume will probably be 50 or less VM's across the two hosts. I'd be really surprised if they hit 100. All the same VLAN even, at least for the immediate future.

I had two ideas about configurations:

1.) Team all 4 interfaces and use IP hash balancing for all roles - would provide a fair amount of redundancy, I keep trying to think of a downside to this but can't - unless it breaks something I'm unaware of with regards to management or vMotion.

2.) Team two interfaces for VM traffic, designate an active and standby interface for management and vMotion, referencing the others active for each role. (A/B and B/A active/standby adapters)
This would eliminate any issue with IP hash with regard to vMotion and management, and still provide redundancy for all roles.

Thoughts/ideas? IP Hash is not something I've played with before, so I'm scouring the forums for any issues or pitfalls that I may not be aware of.
 
What are you using for storage? What type of network switches do you have? What is your license level?
 
Sorry, I did leave all that stuff out.

As far as the mgmt/vmotion/active traffic switch, both hosts are currently going to use the same Dell 5548. Far from ideal, but this is worlds above what is currently used. Baby steps :)

The other end is a quad Intel ET2 NIC in each R810, hooked to two Dell 5524's and an EqualLogic PS6000X.

License level is Essentials Plus.
 
I don't like to share NICs for storage so I'd dedicate two NICs to storage and then do IP hashing on the other two. You won't have much vMotion traffic with only two hosts.
 
Er sorry -

It's 8 total interfaces per host. I left off the storage stuff to make it simple at first :)
 
Two for storage. Two for vMotion and Management. Other 4 for VM traffic.

IP Hashing if your switch supports it. Also configure multi-streaming for vMotion if you want.
 
Really 2 interfaces for storage? I was kind of leaning towards 4 interfaces (2 per switch) based on some of the EQL documentation. I'll have to pull that out again.

No to the 4 (or 6 in your example) interface IP Hash for mgmt/vMotion/Traffic?
 
In a VM environment storage connectivity is rarely about throughput and almost always about IOPS. I bet you don't need more than 2. You could do all 4 NICs in a team with MGMT/vMotion/VM but that depends on your VM workload. Again, most people over estimate that. I rather keep vMotion on its own as it is bursty and heavy...but with only two hosts you can problem just mix it with VM traffic. You won't be doing much vMotion.
 
I guess the root of my question was if it made sense doing that really bought me anything in terms of redundancy or aggregate throughput for all mentioned services, or if it was going to do something really, really bad I wasn't aware of.

Maybe my second scenario would be a better fit? That would guarantee vMotion/mgmt its own interface in normal scenarios but still provide a backup in case of failure.

Thanks for the input too NetJunkie, appreciate it. This is a baby-step learning exercise for me going from a single host to a 'real' environment. Only reason I'm even looking at IP hash so much is because of the VCP class, they liked to emphasize the advantages ad infinitum.
 
With network design there really is no right or wrong answer...well...wrong would be if you aren't redundant or aren't meeting throughput requirements, but outside that you can do a lot of different things. Scott has a good preso here on networking design and vSphere:

http://blog.scottlowe.org/2011/07/21/vsphere-networking-design-presentation/

I'm working on a course that talks about it for TrainSignal right now. But it's up to your requirements. I find most people overestimate what they need. I want to keep storage separate so minimum of two NICs there. Do your VMs need >2 Gb links per host? I can't answer that. But if you take all 4 NICs and hash them for vMotion/Mgmt/VM you might be fine or you might end up on the bad side of hashing and have the heavy VMs and vMotion interfaces all hashed on the same NIC. You don't get to choose that. That's why teaming and hashing is "okay" but 4 NICs in a team do not equal 4Gb throughput.

You could put all 4 NICs in one vSwitch...set one NIC active for the vMotion port-group and the other 3 standby. Then the other 3 active for Mgmt/VM and the 1 on standby. That way vMotion gets dedicated unless there is a failure and VMs get dedicated unless there is a failure. All sorts of combinations to do.
 
Thanks for the link Net, and the primer. I have Scott's book too, although admittedly I haven't had the time for it lately.
 
Back
Top