Transcript Vmware Network

Module
Networking
Networking
vNetwork Standard Switches
Properties & Configurations
vNetwork Distributed Switches
•
•
•
•
What is a Virtual Switch
What are the connection types on the virtual switches
Limitations of the Virtual Switches
How do we create Virtual Switches
Types of Switches in vSphere
• vSphere supports 2 types of Switches
– vNetwork Standard Switch
• Created, Configured and Managed on ESX Host
• Supports only Outbound Networking Policies
• Networking policies can be applied on Switch Level or Port Group
level
• Supports VLAN’s
– vNetwork Distributed Switch (vDS or DV Switch)
•
•
•
•
Created, Configured and Managed on the vCenter Server
Centralized Point of Management
Supports both Outbound and Inbound Networking policies
Networking Policies can be applied on Switch, Port Group or Port
level
• Supports installation of third party Virtual Switches like Cisco Nexus
1000v
• Supports VLAN’s and Private VLAN’s
Physical Infrastructure
Physical Servers
A
B
C
Now in this second scenario our network has grown
and we have a Layer 3 Switch connected to another
3 systems, these 3 systems can communicate
between them and they can be in difference IP
Classes and yet communicate since the Layer 3
switch can take care of Routing. But these 3 systems
D, E and F cannot communicate with A, B & C
Systems. To connect these 2 switches what we need
is a UPLINK also known as cascading. Remember
an switch port and a uplink port does not have a
MAC or a IP Address associated with it.
NIC
Layer 2 Switch
Layer 3 Switch
NIC
D
E
In This example the Physical servers are connected
to a Layer 2 unmanaged switch, and if these servers
are on the same subnet they can communicate with
each other.
F
This uplink needs to be configured as a TRUNK if
VLAN info needs to be carried between these 2
switches. Systems connected to Layer 2 Switch can
be part of VLAN’s that were created on the Layer 3
Switch and the packets will be transmitted from the
systems to the Layer 2 switch and then to the Layer
3 switch which will do the routing and send the
packet to the destination host.
Virtual Infrastructure
ESX Server
VM A
VM B
VM C
vNIC
vStandard Switch
Physical
NIC
Layer 3 Switch
NIC
D
E
F
Physical Infrastructure
Now using the previous example, I create a
ESX Server and inside the ESX Server I
create 3 VM these Virtual Machines are
connected to a vStandard Switch configured
inside my ESX Box. A vStandard Switch is
based on the model of a unmanaged layer 2
switch.
Further we want our virtual machines to
communicate with other physical servers in
our environment. Just as physical layer 2
switch which has a uplink port without a MAC
or IP Address, Here on the ESX the Physical
NIC of the ESX box acts as a uplink port. ESX
hides the MAC address of this NIC from the
network and this physical MAC address is
never seen by other systems on the network,
making this NIC port purely a uplink port
capable of carrying VLAN tagging if
configured as a TRUNK port on the switch.
Define virtual switch
•
•
•
•
•
•
•
•
Its a software construct allowing connection between VM's or between VM's and
external physical network and between ESX/ESXi Hosts, vCenter Server and vSphere
client.
It combines the bandwidth of multiple network adapters and balances traffic among
them. It can also handle physical network interface card (NIC) failover.
Models a physical Ethernet Layer 2 Switch.
The role of a Physical NIC on a ESX host is that of a Uplink port on a physical switch.
The MAC Address of this NIC is hidden from your infrastructure by your ESX host and
is associated with VMkernel Port.
This MAC address is only assigned to the VMkernel Port for management (ESXi Host
only), vMotion, iSCSI Storage and Fault Tolerance Logging
You can created upto 248 Virtual Switches on a single ESX Host
You can create upto minimum 8 ports and maximum of 4088 ports on a Single Virtual
(Standard Switches and Distributed Switches)
When a new Virtual Switch is created it is created by default with 120 Ports
Next: You can create different connection types on the Virtual Switch……..
Virtual Switch Connection Types
•
Service Console : ESX Only, this port group is used for management of the
ESX Server, for example connecting to ESX Server using vSphere Client.
ESXi does not have a Service Console.
•
VMkernel port (Used for vMotion, Software iSCSI, NFS and Fault
Tolerance) (VMkernel port group is not created by default on ESX Server
during installation. VMkernel port is not used for connection to SAN. On a
ESXi the vmkernel port group is additionally used for management since
ESXi does not have a Service Console)
•
Virtual Machine Port Groups, this port group is used to connect virtual
machines to the vSwitch and then these VM’s can communicate between
themselves on the ESX host or to the outside network.
Why do you need a Connection Type & What are the needs
of these connection types
ESX Server
SAN Storage
VM1
VM Port Group
VM2
SAN Storage
VM1
ESXi Server
VM2
Fibre Channel Switch
SC
FC HBA
VM Port Group
VM Kernel
FC HBA
Physical NIC
Trunk Links
FC Connection
Ethernet
Layer 2 Switch
Windows System
– vSphere Client
Why do you need a Connection Type & What are the needs
of these connection types
In the previous slide there is one ESX Server and one ESXi Server both having a single NIC.
The ESX host is configured with a Single vSwitch with a VM Port Group to connect the Virtual Machines to the
physical network and a Service Console Port Group for management.
The ESX host is configured with a Single vSwitch with a VM Port Group to connect the Virtual Machines to the
physical network and a VMkernel Port Group for management.
The vNetwork Standard Switch is connected to the physical switch and the Uplink is connected and configured at the
Physical Switch end to be a TRUNK link.
Both the ESX and the ESXi are connected and can access the Virtual Machine files kept on the SAN Storage.
However the iSCSI storage is only accessible to the ESXi host
The ESX host is unable to see the iSCSI storage
ESX Host
In the Graphic shown on this page, the ESX host has 3 parts, the service
console, a VMKernel which communicates, manages and monitors the
hardware and the Physical hardware itself.
The Virtualization Layer talks to the hardware and not the service console.
Service Console
Service Console is used for management and has a IP Address to connect
to it and manage the box.
VMkernel communicates with the hardware. In the previous example the
ESX host was trying to communicate with a IP based Storage, which means
VMkernel needs a IP Address to communicate with that IP Storage.
Virtualization Layer (VMkernel)
Hardware
So Adding a VMkernel Port Group on the ESX Server and enabling for iSCSI support will
allow it to access the iSCSI Storage. VMkernel Port is required by the ESX/ESXi host to
communicate with IP based storage like iSCSI, vMotion and Fault Tolerance. So incase if
you think that you don’t need a VMkernel port since you don’t have iSCSI storage, think
whether you are going to use vMotion and Fault Tolerance
ESX Server
SAN Storage
VM1
VM Port Group
SC
VMKernel
PG
VM2
SAN Storage
VM1
ESXi Server
VM2
Fibre Channel Switch
FC HBA
VM Port Group
VM Kernel
FC HBA
Physical NIC
Trunk Links
FC Connection
Ethernet
Layer 2 Switch
Windows System
– vSphere Client
All the 3 connection types, ie Service Console, VMkernel and the Virtual Machine can exist
either on a Single switch or on multiple switches.
One physical NIC on the ESX/ESXi host can connect to only one virtual switch
But multiple physical NIC’s can be connected to the same Virtual Switch, this would ensure
Load Balancing and Redundancy
ESX Server can recognize upto 32 Physical NIC*
[Only e1000 1GB Ethernet ports (Intel PCI-x) and tg3 1GB Ethernet ports (Broadcom)]
(Refer to Maxims Configuration Guide)
All the 32 Physical NIC can be connected to a single Virtual Switch or to multiple switches
You can have maximum 512 Port Groups on a single ESX host (Both for Standard &
Distributed Switches)
For the purpose of the Redundancy, create multiple Service Console & VMkernel Ports with
secondary NIC. So if the primary NIC fails, you can still connect to Service Console (ESX)
and VMkernel (ESXi) for management purposes.
For further redundancy the secondary NIC should be connected to separate switch and not
the switch on which the primary SC & VMkernel are connected and configured. This way if
the primary switch fails, you will still be able to connect to SC & VMK using the second IP
connected to the secondary switch.
Why do you need more than one Virtual Machine Connection type?
When 2 NIC’s are connected to the same Virtual Switch, they are by default teamed
for LOAD Balancing increasing the bandwidth.
In a Real life Scenario where one particular Virtual Machine needs more bandwidth
as compared to another Virtual Machine on the same ESX/ESXi host it would be
more appropriate to create 2 Virtual Machine Port Groups on the same Virtual
Switch and configure Traffic shaping allocating more bandwidth to the one with
more bandwidth needs
ESX Server
SAN Storage
VM1
VMA
Prod
VM2
VMB
Test
SC
FC HBA
Physical NIC
Layer 2 Switch
VLANs
ESX/ESXi supports 802.1Q VLAN tagging.
802.1q is universal standard defined by
IEEE
Virtual switch tagging is one of three
tagging policies supported.
– Packets from a virtual machine are tagged
with 4 Byte as they exit the virtual switch.
– The first 2 bytes carry the information
about what standard of VLAN tagging is
this and the next 2 bytes carry the
information about the VLAN id.
– Packets are untagged as they return to the
virtual machine.
– Performance is not much affected.
– Uplink port should always be configured as
trunk at switch port/ports
– If a port is configured as a trunk to carry
vlan info example vland101 & vlan102,
then it will not carry any other vlan info.
VLANs
•4094 VLAN id can be used in vSwitches
•4095 is valid but in this case the VLAN information is not
stripped at the vSwitch and is passed to the Virtual Machine,
here the Virtual Machine OS should be capable of
understanding and using the VLAN information
Lab
• Create a Virtual Switch
• Create, Configure connection types
• Properties of Connection types
Networking Policies
• vStandard Switches – Only Outbound Policies
• vNetwork Distributed Switches – Both inbound and
outbound policies
3 Policies can be configured
– Security
– Traffic Shaping
– NIC Teaming
Networking Policies
Policies can be configured at:
– At the standard virtual switch level:
• Default policies for all the ports on the standard virtual switch
– At the port or port group level:
• Effective policies: Policies defined at this level override the
default policies set at the standard virtual switch level.
Security Policies
Layer 2 Ethernet security options can be configured at the standard
virtual switch and at the port groups level
Policies are (Option to ACCEPT or REJECT)
Promiscuous Mode – Will listen to broadcasts, required only if
Network Sniffer or Monitoring is used
MAC Address Change – VM will not receive traffic if MAC of the
sender VM has been changed
Forged Transmits - VM will not be allowed to send traffic via the
vSwitch or the Port
Security Policies
The MAC Address Changes and Forged Transmits security options deal
with incoming and outgoing traffic, respectively
Initial MAC:
00:50:56:a4:22:4c
Effective MAC:
ESX Server
VM A
VM B
Win2k
Linux
01:4d:2b:a3:11:1c
Initial MAC:
00:50:56:a4:24:5d
Effective MAC:
01:1C:2d:a4:33:5f
Forget Transmit: Rejects
MAC Address Changes:
Rejects
vStandard Switch
The difference between the MAC Address Changes and Forged Transmits security settings involves the direction of the
traffic. MAC Address Changes is concerned with the integrity of incoming traffic, while Forged Transmits oversees the
integrity of outgoing traffic. If the MAC Address Changes option is set to Reject, traffic will not be passed through the
vSwitch to the virtual machine (incoming) if the initial and the effective MAC addresses do not match. If the Forged
Transmits option is set to Reject, traffic will not be passed from the virtual machine to the vSwitch (outgoing) if the initial and
the effective MAC addresses do not match. The above Graphic highlights the security restrictions implemented when MAC
Address Changes and Forged Transmits are set to Reject.
Networking Policies
Traffic Shaping Policy
By default disabled. Can be configured as
–Average Bandwidth (In kbits/sec)
–Peak Bandwidth (In kbits/sec)
–Burst Size (In kbytes)
By default, all virtual network adapters connected to a vSwitch have access to
the full amount of bandwidth on the physical network adapter with which the
vSwitch is associated. In other words, if a vSwitch is assigned a 1Gbps network
adapter, then each virtual machine configured to use the vSwitch has access to
1Gbps of bandwidth. Naturally, if contention becomes a bottleneck hindering
virtual machine performance, NIC teaming will help. However, as a complement
to NIC teaming, it is also possible to enable and to configure traffic shaping.
Traffic shaping involves the establishment of hard-coded limits for peak
bandwidth, average bandwidth, and burst size to reduce a virtual machine’s
outbound bandwidth capability.
Traffic Shaping Policy
The value entered for the average bandwidth dictates the data transfer per second
across the virtual vSwitch. The peak bandwidth value identifies the maximum amount of
bandwidth a vSwitch can pass without dropping packets. Finally, the burst size defines
the maximum amount of data included in a burst. The burst size is a calculation of
bandwidth multiplied by time. During periods of high utilization, if a burst exceeds the
configured value, packets are dropped in favor of other traffic; however, if the queue for
network traffic processing is not full, the packets are retained for transmission at a later
time.
Traffic Shaping as a Last Resort
Use the traffic shaping feature sparingly. Traffic shaping should be reserved for situations
where virtual machines are competing for bandwidth and the opportunity to add network
adapters is removed by limitations in the expansion slots on the physical chassis. With
the low cost of network adapters, it is more worthwhile to spend time building vSwitch
devices with NIC teams as opposed to cutting the bandwidth available to a set of virtual
machines.
NIC Teaming
Settings Are:
•
•
•
•
•
Load Balancing (outbound only)
Network Failure Detection
Notify Switches
Failback
Failover Order
NIC Teaming
Load Balancing are of 3 types Port ID-Based, Source MAC-Based, Source IPBased
Port ID-Based – Ties each Virtual switch port to specific uplink associated. Does
not give Load Balancing but Redundancy
Source MAC-Based Source IP-Based – Provides Load Balancing as well as Redundancy
Port ID-Based
The vSwitch port-based load-balancing policy that is used by default uses an
algorithm that ties each virtual switch port to a specific uplink associated with
the vSwitch. The algorithm attempts to maintain an equal number of port-touplink assignments across all uplinks to achieve load balancing. This policy
setting ensures that traffic from a specific virtual network adapter connected to
a virtual switch port will consistently use the same physical network adapter. In
the event that one of the uplinks fails, the traffic from the failed uplink will
failover to another physical network adapter.
Load-Balancing Method: Port ID-Based
Source MAC Load Balancing
The second load-balancing policy available for a NIC team is the source MACbased policy, This policy is susceptible to the same pitfalls as the vSwitch portbased policy simply because the static nature of the source MAC address is the
same as the static nature of a vSwitch port assignment. Like the vSwitch portbased policy, the source MAC-based policy is best used when the number of virtual
network adapters exceeds the number of physical network adapters. In addition,
virtual machines are still not capable of using multiple physical adapters unless
configured with multiple virtual network adapters. Multiple virtual network adapters
inside the guest operating system of a virtual machine will provide multiple source
MAC addresses and therefore offer an opportunity to use multiple physical network
adapters.
Load-Balancing Method: Source MAC-Based
VMware vSphere 4.1: Install, Configure, Manage – Revision A
Source IP-Based
The third load-balancing policy available for NIC teams is the IP hash-based policy, also
called the out-IP policy. This policy addresses the limitation of the other two policies that
prevents a virtual machine from accessing two physical network adapters without having
two virtual network adapters. The IP hash-based policy uses the source and destination
IP addresses to determine the physical network adapter for communication. This
algorithm then allows a single virtual machine to communicate over different physical
network adapters when communicating with different destinations.
Balancing for Large Data Transfers
Although the IP hash-based load-balancing policy can more evenly spread the transfer
traffic for a single virtual machine, it does not provide a benefit for large data transfers
occurring between the same source and destination systems. Because the sourcedestination hash will be the same for the duration of the data load, it will flow through
only a single physical network adapter.
Unless the physical hardware supports it, a vSwitch with the NIC teaming load-balancing
policy set to use the IP-based hash must have all physical network adapters connected
to the same physical switch. Some newer switches support link aggregation across
physical switches, but otherwise all the physical network adapters will need to connect to
the same switch. In addition, the switch must be configured for link aggregation.
ESX/ESXi supports standard 802.3ad teaming in static (manual) mode but does not
support the Link Aggregation Control Protocol (LACP) or Port Aggregation Protocol
(PAgP) commonly found on switch devices. Link aggregation will increase throughput by
combining the bandwidth of multiple physical NIC’s for use by a single virtual network
adapter of a virtual machine.
Load-Balancing Method: Source IP-Based
VMware vSphere 4.1: Install, Configure, Manage – Revision A
Detecting and Handling Network Failure
Network failure is detected by the VMkernel, which monitors:
– Link state only
– Link state plus beaconing
Switches can be notified whenever:
– There is a failover event
– A new virtual NIC is connected to the virtual switch
Detecting and Handling Network Failure
Failover detection with NIC teaming can be configured to use either a link status method or a
beacon probing method.
Link state only
The link status failover detection method works just as the name suggests. Failure of an uplink is
identified by the link status provided by the physical network adapter. In this case, failure is
identified for events like removed cables or power failures on a physical switch. The downside to
the link status failover detection setting is its inability to identify misconfigurations or pulled
cables that connect the switch to other networking devices (for example, a cable connecting one
switch to an upstream switch.)
Link state plus beaconing
The beacon probing failover detection setting, which includes link status as well, sends Ethernet
broadcast frames across all physical network adapters in the NIC team. These broadcast frames
allow the vSwitch to detect upstream network connection failures and will force failover when
Spanning Tree Protocol blocks ports, when ports are configured with the wrong VLAN, or when a
switch-to-switch connection has failed. When a beacon is not returned on a physical network
adapter, the vSwitch triggers the failover notice and reroutes the traffic from the failed network
adapter through another available network adapter based on the failover policy.
VMware vSphere 4.1: Install, Configure, Manage – Revision A
Failover implemented by the VMkernel based on configurable parameters:
Failback: Determines how a physical adapter is returned to active duty after
recovering from a failure
Load-balancing option: Use explicit failover order.
Always use the highest order uplink from the list of active adapters that pass
failover detection criteria.
The failover order helps determine how adapters in a NIC team are used
when a failover occurs. Stand by adapters automatically activate when an
active adapter fails.
When a failover event occurs on a vSwitch with a NIC team, the vSwitch is obviously
aware of the event. The physical switch that the vSwitch is connected to, however, will
not know immediately.
A vSwitch includes a Notify Switches configuration setting, which, when set
to Yes, will allow the physical switch to immediately learn of any of the
following changes:
1. A virtual machine is powered on (or any other time a client
registers itself with the vSwitch)
2. A VMotion occurs
3. A MAC address is changed
4. A NIC team failover or failback has occurred