HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
BladeSystem - General
cancel
Showing results for 
Search instead for 
Did you mean: 

Recommendations for config of VC-Enet module for redundancy & throughput

 
Paul_637
Regular Advisor

Recommendations for config of VC-Enet module for redundancy & throughput

We have a c-class enclosure with, currently, two BL480c's (front bays 7 & 8) and 6 BL460c's (front bays 1-3 & 9-11).

We also have two VC-Enet (rear bays 1 & 2) and two VC-FC modules (rear Bays 3 & 4).

All blades have default NICs installed (i.e. no additional NICs) and Qlogic 2642 FC HBAs.

The two BL480c's are Vmware ESX servers, and one of the BL460's is a management server for Vmware. The remaining 5 blades have yet to be deployed "live" (i.e. I'm "playing" with test stuff on them for now until their needed).

When I originally configured the VC-Enet modules, I defined two Networks within the VC Management console:

Primary_NET and Secondary_NET

Primary_NET had the following ports configured:

Bay1, ports 1,2,3,4, connection mode "Auto"

Secondary_NET had the following ports configured:

Bay2, ports 1,2,3,4, connection mode "Auto"

Ports 1-4 on the VC-Enet module in bay 1 were cabled to one Allied Telesyn 9424/SP switch, which had the 4 ports configured into an "LACP Trunk Group"

Ports 1-4 on the VC-Enet module in bay 2 were cabled to another Allied Telesyn 9424/SP switch, which had the 4 ports configured into an "LACP Trunk Group"

I created a set of server profiles within the VC Manager and effectively configured the following port settings:

For half-height profiles, Port 1 was configured to Primary_NET and port 2 was configured to Secondary_NET

For full-height profiles, Ports 1 & 3 was configured to Primary_NET and port 2 & 4 was configured to Secondary_NET

However, a limitation I'm hitting now is that the Allied Telesyn switches only support a single VLAN within an LACP trunk Group so I'm looking to an alternative configuration.

Re-reading the Virtual Connect user guide (now with the benefit of more experience!) it seems to suggest a completely different failover type configuration.

Effectively:

o Define a network
o Add one port from each bay (e.g. Bay1:Port1 and Bay2:Port2)
o Configure it as "Failover" type (as opposed to "Auto")
o Configure one as primary, and the other as secondary
o Link to server profiles as required.

I'd never thought of doing it this way and don't know how I missed it in the docs first time around (probably usual thing, when trying to understand stuff, you "miss" things you don't fully understand!) but I'm trying to think how to best apply it to my requirements.

Realistically, how many ports can (or should) you put into such a group? Is it feasible or stupid to put, say, 4 ports (two from each bay) with two primary and two secondary? Would that even make sense?

I'm trying to get to a configuration which gives me the following:

Allows best use of available bandwidth to the blades
Allows me to create multiple (tagged) vlans within each physical switch the VC-Enet modules are connected to (so means not utilising LACP anywhere for the Vmware host blades - i.e. BL480's)

As far as balance goes, I think I'd be happy using, say, 4 ports on each module for Vmware blades and the remaining 4 for the remaining blades. Realistically, the Vmware hosts would probably be happy with two or three external connections but time will tell, it's early days in our deployment yet.

Can anyone make any suggestions (or tell me I'm doing/thinking something stupid? :)

I'd be interested in how others configure their VC-Enet modules...

Regards,

Paul
1 REPLY
HEM_2
Honored Contributor

Re: Recommendations for config of VC-Enet module for redundancy & throughput

That is a pretty tough limitation on the AT switches (maybe a newer code allows vlan tagging on an LACP trunk?)

Your proposed alternative sounds pretty good but let me make one clarification. If you define a network with, say, 4 external connections - 2 from bay 1 and 2 from bay 2 and you are not using LACP, you will end up with 1 active link and 3 standby links. You don't get 2 active links in that scenario so the effective bandwidth for that network is 1 Gb.

Here is another alternative. You would define a series of networks:

Net1: bay1 port1 + bay2 port1
Net2: bay1 port2 + bay2 port2
Net3: bay1 port3 + bay2 port3
...
...

now the effective bandwidth for each network is 1 Gb and you have resiliency to a upstream switch failure or a VC Module failure (assuming you are bonding in ESX)

Now each server profile can be defined to use its own network. For example Server Profile 1 assigned to Net1, Server Profile 2 assigned to Net2, etc.

Really, the best solution would be to use LACP in conjunction with VLAN tagging but if that is not available to you, you need to be creative in crafting a solution.

Hope this helps...