In vCloud director if you are deploying the vCD Cells on a different network to your ESXi hosts or indeed your vCenter server there will most likely be a Firewall in-between.
This post will highlight some of the key TCP Firewall port Requirements and a brief description
vCD Cell to ESXi hosts
443 - https to ESXi hosts, required to prepare hosts
902
903
5212 - vCD Agent
vCD Cell to vCenter Server
443
902
903
vCD Cell to Oracle
1512
vCD Cell to SQL
1433
vCD Cell to Message Bus (ActiveMQ) - Bi-directional
61611
61616
vCD Cell to NFS Server - Bi-directional
111
920
vShield Manager to ESXi hosts
443
902
903
vShield Manager to vCenter - Bi-directional
443
These are the bare minimum required to standup vCD with firewalls between vCD, ESXi & vCenter.
There are additional standard ports for infrastructure services like DNS etc, but i wont document these.
Hope this helps.
I'm sure there may be some I have missed, please feel free to comment.
Thursday, 17 November 2011
Tuesday, 1 November 2011
HP FLEX-10 Mapped Mode vs Tunnelling Mode - (d)vSwitch Design
Mapped Mode vs Tunnelling Mode is definitely a strong talking point when deploying FLEX-10 networking architecture in a vSphere environment.
I hope to clear up some common misconceptions around the 2 options which may help you when designing your vSwitch designs with this kind of physical architecture.
What is FLEX-10?
HP FLEX-10 is HP's Blade-system networking solution, they sit within the blade chassis and pass network connectivity to the HP blades through the back-plane.
To support FLEX-10's full functionality you will require 10GbE cards installed in to the blades in the chassis. Obviously the uplinks to the FLEX modules will need to be 10GB to present true 10GbE to the blades physical NIC's.
for more information please see HP's product documentation.
In this scenario we are using a blade which has 1 dual port 10GbE card installed, this is the most common scenario.
There are 2 modes of operation when creating ethernet networks to present to the blades;
Mapped Mode - Each VLAN (Network) is created on a SUS (Shared Uplink Set, representative of a module) and presented to the Blades through the server profile, each NIC can be presented with multiple networks which need to be un-packaged at the vSwitch in to port-groups.
You can utilize what are called FLEX-NIC's, these are presented through a technology called a LOM (LAN on Motherboard) each physical 10GbE port creates 4 FLEX-NIC's 4 on LOMa and 4 on LOMb
Summary:
Tunnelling Mode - You can create vNET's (one on each module) which have direct uplinks from the modules which pass all VLAN's through to the physical NIC's of the blade.
Summary:
So which one of these is provides the most resiliency and flexibility when designing you vSwitch architecture?
The mapped mode will give you the granularity of creating the flex-nics to satisfy design requirements i.e. separate (d)vSwitch's for Management and vMotion and ISCSI etc... but remember that the NIC's are only another abstraction layer and are still going through the same physical NIC port.
Also with the mapped mode you can specify the speed of the networks that are presented to the flex-nics at a sudo hardware level.
With tunnelling mode you get the full 10GB put down the pipe to the physical 10GbE physical ports.
Your limited with your design as you will have to place all networking in one dvSwitch and use NETIOC (Network IO control) to prioritise & limit the network types to satisfy your design.
This along with "Route based on physical NIC Load" (LBT) teaming policy applied to all your dvPort-Groups would give you full use of both sides of the HP Architecture in an Active/Active setup and prioritise traffic during times of contention.
If you would like to have more control of what network runs on which physical nic and hence which physical switch then you could override the failover policy to have active/standby for the particular port-group and separate vMotion, Management and VM traffic to run down different physical 10GB NIC's.
My Opinion
I'm tending to lean towards tunnelling mode + NETIOC + LBT (Route based on physical NIC load) as it simplifies the vSphere design, and after all a good design is a simple design... why would I introduce an extra layer of abstraction and an administrative overhead in to my vSphere design?
This would mean that your ESXi hosts are sat on the same dvSwitch that all your VM traffic is going through, but will still be going through the same physical NIC's (10GB).
This is just my take on this.. i would be keen to get some feedback on to what other people thought about this?
I hope to clear up some common misconceptions around the 2 options which may help you when designing your vSwitch designs with this kind of physical architecture.
What is FLEX-10?
HP FLEX-10 is HP's Blade-system networking solution, they sit within the blade chassis and pass network connectivity to the HP blades through the back-plane.
To support FLEX-10's full functionality you will require 10GbE cards installed in to the blades in the chassis. Obviously the uplinks to the FLEX modules will need to be 10GB to present true 10GbE to the blades physical NIC's.
for more information please see HP's product documentation.
In this scenario we are using a blade which has 1 dual port 10GbE card installed, this is the most common scenario.
There are 2 modes of operation when creating ethernet networks to present to the blades;
Mapped Mode - Each VLAN (Network) is created on a SUS (Shared Uplink Set, representative of a module) and presented to the Blades through the server profile, each NIC can be presented with multiple networks which need to be un-packaged at the vSwitch in to port-groups.
You can utilize what are called FLEX-NIC's, these are presented through a technology called a LOM (LAN on Motherboard) each physical 10GbE port creates 4 FLEX-NIC's 4 on LOMa and 4 on LOMb
Summary:
- You can create up to 4 Active FLEX-NIC Connections per physical 10GB Port
- You have a limit of 162 VLAN's downlink to a FLEX-NIC
- 1000 VLAN's per Shared Uplink Set
- Manage VLAN's at module level
- Manage speed of particular networks i.e. vMotion, Management limit to 1GB
How will your vSwitch Design look?
vSwitch0 (vmnic0,2) - Management, vMotion
dvSwitch0 (vmnic1,3) - ISCSI, NFS
dvSwitch1 (vmnic4,6,7,8) - Virtual Machine Networks Tunnelling Mode - You can create vNET's (one on each module) which have direct uplinks from the modules which pass all VLAN's through to the physical NIC's of the blade.
Summary:
- 4096 VLAN's per module
- No need to manage VLAN's at FLEX-10 Level as all are passed through the trunks
- Limits you to the physical active NIC connections i.e. 2 x 10GbE NIC's each running at 10GB Speed
How will your vSwitch Design look?
dvSwitch0 (vmnic0,1 - 10GB Each NIC) - Management, vMotion, NFS, ISCSI, Virtual Machine Traffic
NETIOC, LBT
The mapped mode will give you the granularity of creating the flex-nics to satisfy design requirements i.e. separate (d)vSwitch's for Management and vMotion and ISCSI etc... but remember that the NIC's are only another abstraction layer and are still going through the same physical NIC port.
Also with the mapped mode you can specify the speed of the networks that are presented to the flex-nics at a sudo hardware level.
With tunnelling mode you get the full 10GB put down the pipe to the physical 10GbE physical ports.
Your limited with your design as you will have to place all networking in one dvSwitch and use NETIOC (Network IO control) to prioritise & limit the network types to satisfy your design.
This along with "Route based on physical NIC Load" (LBT) teaming policy applied to all your dvPort-Groups would give you full use of both sides of the HP Architecture in an Active/Active setup and prioritise traffic during times of contention.
If you would like to have more control of what network runs on which physical nic and hence which physical switch then you could override the failover policy to have active/standby for the particular port-group and separate vMotion, Management and VM traffic to run down different physical 10GB NIC's.
My Opinion
I'm tending to lean towards tunnelling mode + NETIOC + LBT (Route based on physical NIC load) as it simplifies the vSphere design, and after all a good design is a simple design... why would I introduce an extra layer of abstraction and an administrative overhead in to my vSphere design?
This would mean that your ESXi hosts are sat on the same dvSwitch that all your VM traffic is going through, but will still be going through the same physical NIC's (10GB).
This is just my take on this.. i would be keen to get some feedback on to what other people thought about this?
Subscribe to:
Posts (Atom)