Slide - Amazon Web Services

VMware vCloud Director
and how it works
David Hill, vExpert 2012, VCP, VCAP-DCD
Senior Solutions Architect
Twitter: @davehill99
Business Requirements
VMware vCloud Director Architecture
Virtual Data Centers
Allocation Models
Key Business Requirements for a vCloud
Innovation and new product development
Accelerating release cycles and speed to market
Prolonging legacy applications
Reaching new marketing with existing applications
Operational efficiency
Reduced TCO
Business Agility
 Multi-tenancy support
 Metering capabilities for cost reporting
 Self-Service capabilities
 Leverage shared infrastructure
and resource pooling
 Designed for Scalability
and Elasticity
 Provide differentiated offerings based on cost
VMware vCloud suite components
Capability to Component Mapping
Cloud is built in layers
VMware vCloud Director Architecture
 Horizontal scaling at both application
and physical infrastructure layers
 Add vCloud Director Server(s)
as need increases
 Hardened for availability
on public internet
 User permissions
 Multi-tenancy
 Limit single points of failure
vCloud Director Scaling
VMware vCloud Director Cells
 Scale horizontally
 Add load balancer in front of Cells
 Multi-Cells share vCloud Director
vSphere Resources
 1 VCD Cell : many vCenter Servers
− Multiple vCenter Servers attached to VCD
can be in linked mode (optional)
 Scale vSphere resources as needed
− Consider concurrent provisioning operation
limits in vCenter
− vSphere resource limits apply
Logical Architecture Overview
Provider Virtual Datacenter
A provider virtual datacenter is a grouping of compute
and storage and represents a particular class of service
Use Provider VDCs to offer differentiated services
Virtual Datacenter Considerations
Virtual Datacenter Backing:
 Best practice: use 1:1 mapping of provider VDC to ESXi Cluster
 Avoid sharing datastores between provider vDCs
 Avoid using large clusters from the start (allow headroom for growth)
Create Provider Virtual Datacenters to differentiate between:
Performance level offerings (for instance, different hardware or storage types)
Storage provisioning offerings (for instance, fast vs. full provisioning)
Service level offerings (for instance, VMware HA ‘n+1’ vs ‘n+2’)
Dedicated ‘special purpose’ requirements (for instance, licensing)
If possible limit to a single allocation model (for instance, large deployments)
What are Allocation Models
 Allocation Models define how resources are allocated to an organization
 Allocation is actually the creation of a resource pool subordinate
to the provider vDC object (cluster or resource) in vSphere
 Allocation Models are chosen and set on a per Org vDC basis
 Type and settings dictate how resources are taken out of the Provider vDC
backing the Org vDC
 All reservation settings, such as guarantee percentage, will “commit” them
and take from the available pool
Reservation Pool
Allocation Pool
Choosing an allocation type
 Resources allocated as required
 Transient environment where workloads are repeatedly deployed
and un-deployed
 Good fit for demonstration or training environment
 Resources pre-allocated and a defined portion is guaranteed (v1.5)
 Elastic workloads that have a steady state
 Good fit for workloads that surge during certain periods of time
 Resources pre-allocated and are guaranteed
 Workloads that have a steady state
 Good fit for workloads that demand a predictable level of service
The Big Networking Picture
3 Different Layers of Networking
 External
 Organization VDC
 vApp
Managed at two layers: Consumers & Providers
An External Network is an network that is outside of VMware vCloud
Director, is set up by the Cloud Admin/Provider
An Organization VDC Network is contained within an organization, is can
be set up by the Cloud Admin or Org Admin
vApp Network is a contained within a vApp, is set up by Consumers
External Networks
What can you do with an External Network?
 Create a direct organization network
 Create a routed organization network
Network Pools
Backing for networks in VMware vCloud Director
vSphere port group backed
 Requires standard switch or distributed switch
 Requires distributed switch and VLANs
vCloud Network Isolation-backed
 Requires distributed switch
Virtual eXtensible LAN (VXLAN)
 Requires distributed switch, multicast
 vCloud Director 5.1
 vCloud Networking and Security 5.1
Network Pools – vSphere Portgroup-Backed
 The system administrator must manually create isolated portgroups,
isolated by VLAN ID or other means.
 Can be standard switch portgroups or virtual distributed switch portgroups.
 If using standard portgroups, the portgroups must exist on all ESX servers
in the cluster.
How it works:
 The system administrator manually creates isolated portgroups.
 When creating or modifying the network pool, you are given a list of unused
portgroups and you pick the ones you want.
 The only way to have a network pool using standard switch portgroups,
or portgroups that aren’t automatically created by VCD.
 Requires manual work to create all of the portgroups on the ESXi hosts
and keep them in sync.
Network Pools – VLAN-Backed
 A virtual distributed switch that’s connected to all ESX servers in the cluster.
 A range of unused VLANs.
How it works:
 The system admin creates the network pool and chooses which vdSwitch to attach
it to, and provides a range of valid VLANs, for example, 100 – 200.
 When VCD needs to create a network, it will create a portgroup on the vdSwitch
and assign it one of the unused VLAN IDs.
 Many networks can co-exist on the same vdSwitch because they are isolated
by the VLAN tag.
 Perceived by some as the most secure network pool type.
 Requires VLANs to exist in the physical network (physical switches and routers).
 VLANs are a limited resource and may not be available at all.
Network Pools – VLAN-Backed
How to use a VLAN-Backed Network Pool:
 Two routed org networks created using the VLAN-backed network pool.
 Two vApps, each using one of the routed org nets.
 In vCenter Server, two portgroups have been created from the network pool
on the vdSwitch
Network Pools – VCDNI backed
Network link layer or segment
 Isolated virtual network exposed as port group (same VM connectivity)
Provides network traffic isolation
 Network traffic isolated from other port groups including other isolated
virtual networks
 Network traffic visible only to VMs connected to the virtual networks
Spans hosts
 The same isolated network can be reached by different hosts
Network Pools – VCDNI Protocol
Overlay using MAC-in-MAC Ethernet frame encapsulation
 Private network traffic isolated by frame encapsulation that purely terminates
on ESX hosts
 Physical infrastructure switches do not see or have to deal with this
 Encapsulation adds 24 bytes to the Ethernet frame
− Protocol fragments frames if physical network’s MTU is not large enough
− Recommend increasing MTU size on physical network (if 1500, change to 1600)
 Encapsulated traffic is not encrypted
Network Pools – VCDNI Best Practices
Security and Isolation
 Do NOT connect machines to the underlying transport network directly
‒ VCD NI traffic is un-encrypted and visible to any machine directly connected
to the underlying transport layer
‒ Required to avoid sniffing and spoofing of VCD NI traffic by unmanaged machines
(not managed by VMware vCloud Director)
 Use non-routed LANs/VLANs as transport layer
Network Pools – VCDNI-Backed
 Two vApps, each using a routed vApp network
 In vCenter Server, two portgroups have been created from
the network pool on the vdSwitch, all using VLAN 3930
Network Pools – VXLAN
Ethernet in IP
overlay network
Tunnel between ESX hosts
 Entire L2 frame encapsulated
in UDP
 50 bytes of overhead
IP multicast used
for L2 broadcast/multicast,
unknown unicast
Include 24 bit
VXLAN Identifier
 16 M logical networks
VXLAN can cross
Layer 3
 VMs do NOT see VXLAN ID
Technology submitted
to IETF for standardization
 With Cisco, Citrix, Red Hat,
Broadcom, Arista, and Others
Network Pools – VXLAN Benefits
Alternative to VLAN for network isolation
 VLAN IDs not required, but one must be created for operations
 VLAN physical switch provisioning unnecessary
 Works on existing underlying physical network topology
Scalable for cloud requirements
 Ability to create 16 million isolated virtual networks
 Allows providers to support more than the 4,000 VLAN space provides
 Uses multicast to contain broadcast/multicast, unknown unicast
 Ability to automate the provisioning of the software-based isolated
virtual networks
Organization Networks
Three Types Of Organization Networks:
 Direct :
 Routed:
 Isolated (internal):
Direct Organization Networks
The VM is logically connected to the organization net, but the VM NIC
is really connected to the external net since the organization net is only
a logical entity.
Routed Organization Networks
Routed Organization Network:
It consists of:
And gives you all
networking features:
 An isolated portgroup
(which the VMs are attached to).
 A vShield Edge (the virtual router).
 The vShield Edge has one NIC connected
to the isolated portgroup, and one NIC
connected to an external network.
Static Routing
Isolated (Internal) Organization Networks
Isolated (Internal) Organization Network:
An isolated organization network consists of:
− An isolated portgroup (which the VMs are attached to).
− A vShield Edge (the virtual router) if DHCP is enabled.
− The vShield Edge has one NIC connected to the isolated portgroup.
The only networking feature available to an isolated network
is DHCP.
VMs connected to an isolated network can’t communicate
with any other network or the external network.
IPv6 considerations
 vCloud Director GUI does not support IPv6
 vCloud Director management workloads support IPv6
‒ vCenter Server
‒ ESXi Server (vSS and vDS)
‒ Virtual Machines
 Using IPv6 in conjunction with vCloud Director
‒ Cannot use vShield Edge (no support for IPv6)
‒ Can deploy VMs with IPv6 on vApp and Organization networks (direct only)
‒ Use dual stack IPv4 and IPv6 (devices supporting pure IPv6 are limited)
*Needs to be done using guest OS or deploy a DHCPv6 VM
‒ Consider use of IPv6 to IPv4 tunnel
Enjoy and share this material
 Feel free to promote this material
 Recommend your peers to pass certification
 Blog, Tweet and share this material and your experience
on Facebook
 You’re an Expert? We will be happy to have you as Backup
Academy contributor. Apply here.
E-mail: [email protected]
Twitter: BckpAcademy

similar documents