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 Self-Service capabilities Designed for Scalability and Elasticity Metering capabilities for cost reporting Leverage shared infrastructure and resource pooling Provide differentiated offerings based on cost
VMware vCloud Director Architecture Scalability Horizontal scaling at both application and physical infrastructure layers Add vCloud Director Server(s) as need increases Security Hardened for availability on public internet User permissions Multi-tenancy Availability Limit single points of failure … … Secure Clients Secure Clients
vCloud Director Scaling VMware vCloud Director Cells Scale horizontally Add load balancer in front of Cells Multi-Cells share vCloud Director Database 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
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 Definition 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 Usage 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
Choosing an allocation type Pay-As-You-Go Resources allocated as required Transient environment where workloads are repeatedly deployed and un-deployed Good fit for demonstration or training environment Allocation 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 Reservation Resources pre-allocated and are guaranteed Workloads that have a steady state Good fit for workloads that demand a predictable level of service
Networking 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 VLAN-backed 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 Requires: 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. Advantages: The only way to have a network pool using standard switch portgroups, or portgroups that aren’t automatically created by VCD. Disadvantages: Requires manual work to create all of the portgroups on the ESXi hosts and keep them in sync.
Network Pools – VLAN-Backed Requires: 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. Advantages: Perceived by some as the most secure network pool type. Disadvantages: 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
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 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 Protocol
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 Entire L2 frame encapsulated in UDP 50 bytes of overhead Include 24 bit VXLAN Identifier 16 M logical networks VXLAN can cross Layer 3 Tunnel between ESX hosts VMs do NOT see VXLAN ID IP multicast used for L2 broadcast/multicast, unknown unicast 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 Automation 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: 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. And gives you all networking features: NAT Firewall DHCP IPSec VPN 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.here Web: http://www.backupacademy.comhttp://www.backupacademy.com E-mail: firstname.lastname@example.org@backupacademy.com Twitter: BckpAcademyBckpAcademy Facebook: backup.academybackup.academy