© 2009 VMware Inc. All rights reserved
Building Your Cloud with VMware
Deep Dive
Copyright © 2010 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents.
2
Introduction
§ Chris Colotti § Consulting Architect, VMware Global Cloud CoE
§ VCDX #37, vCAP-DCD, VCP
§ Blog: www.ChrisColotti.us
§ Twitter: @CColotti
§ Paul Lembo § Cloud Architect, VMware
§ VCP, ITILv3
§ Blog: www.lemblog.com
§ Twitter: @FPFL
3
Copyright © 2011 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies.
Agenda
§ Why Cloud Computing § How to Work with VMware vCloud • vCloud Eco-System • Allocation Models • Networking • Public/Hybrid
§ VMware vCloud Do’s and Don’ts § Q and A
Confidential 3
4
Why Cloud Computing?
5
Virtualization was about the Data Center
Cloud is about the Users
6
Virtualization and Cloud Computing
Virtualization
Key Characteristics Key Benefits
• Server consolidation and containment • Resource pooling
• Virtualized workloads
• Capital expenditure (CAPEX) savings • Higher utilization
• Flexibility
Cloud Computing
Key Characteristics Key Benefits
• Secured multitenancy • On-demand resources
• Self-service portal and service catalog
• Resource tiering and chargeback
• Economies of scale • Elastic resources and more efficient utilization
• Line of business agility and operational expenditure (OPEX) savings
• Financial cost transparency
7
Why Not Just Virtualization?
§ Challenges in a Virtualized Environment • Multitenancy support – How to securely segment resources by user
organization
• Controlling VM sprawl – Pricing resources to shape user behavior • Self-service provisioning – Avoiding the IT provisioning bottleneck
• How do you accurately “charge” users for their resources to discourage the notion that VMs are “free” resources?
• Can different organizations compete for the same resources?
• Can VMs from different organizations see each other?
Administrator
Users
• Can we have a defined catalog of VMs for user self-provisioning while ensuring some level of control?
8
Why Cloud Computing?
§ Extending vSphere with Cloud Computing Benefits • Multitenancy support – Control access and visibility to resources • Self-service portal for user provisioning through catalogs
• Resource allocation models integrated with chargeback • Economies of scale with elastic resources under your control
Catalog Web Portal
Users
• Self-service portal for users
• Role-based security
• Catalogs of predefined VMs
• VMs assigned with allocation/cost model and quotas
• Resources and access secured along organizational boundaries
• Add capacity seamlessly and reclaim unused resources via leases
• Chargeback reports aligned to resource allocation models to shape user behavior
9
How to Work with VMware vCloud vCloud Eco-System
10
“vCloud” is Comprised of Many Different Products
§ VMware vSphere • vCenter Server • ESX
• Update Manager
§ VMware vCloud Director § VMware vShield • Manger
• Edge
§ Database Servers • Oracle/MS-SQL
§ VMware vCenter Chargeback • “Show-back”
§ VMware vCenter Orchestrator § VMware Service Manager § VMware vCloud Connector • Server
• Nodes
§ VMware vCenter Operations Manager
§ 3rd Party Add-ins
“Core” Components “Additional” Components
11
Eco-System Logical Representation
Service Manager
12
Eco-System Physical Representation
13
Change in the way we Manage things
§ vSphere was traditionally the management layer • Did not matter if vCenter was down for maintenance before
§ With vCloud Director vCenter is more “Application” Layer • Much of the eco-system interfaces with vCenter
§ vSphere administrators may not be vCloud Administrators • vSphere lockdowns (Do’s and Dont’s)
§ Orchestration and customization may be important • Approvals and other workflows
§ High availability of all components involved • vCenter Heartbeat
• Database Log Shipping • FT on vShield Manager
14
Possibly New or Deeper Skillsets
§ vSphere / ESX • Still a foundation and needs care and feeding
§ Deeper Storage Skills • Storage design for vCloud
§ Deeper Networking & Firewall skills • vShield Edge, routing, NAT
§ Scripting (PowerCLI) § Workflows / Automation • vCenter Orchestrator
§ Capacity Planning § Then - ESX, vCenter and some Scripting § Now – Total IAAS Management
15
Eco-System in Practice - One vCloud, Two Buildings
§ Two On-Campus Datacenters § 2 vCloud Director Cells per building (4 Total Cells) • Single NFS mount in Building A • F5 GTM Load Balancer
§ 1 vCenter Server per building (2 Total) • Protected with vCenter Heartbeat • 1 Update Manager server per building
• 1 Cluster per vCenter
§ vShield Manager per building • Protected use VMware Fault Tolerance
§ Database Servers per building § vCenter Orchestrator Server per building § Published Master Catalogs
16
Eco-System in Practice - One vCloud, Two Buildings
17
How to Work with VMware vCloud Allocation Models
18
Copyright © 2011 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies.
Allocation Models Change Consumption Habits
.
Confidential 18
Unblur the virtualization era line between choice and cost.
19
Copyright © 2011 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies.
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 • Not understanding how these are configured can cause some
challenges
Confidential 19
20
Copyright © 2011 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies.
What are the different Allocation Models?
Resource Allocation Models for Organization vDCs • Allocated sub-resources of a provider vDC • Allocation uses a model, each of which can set limits on number of VMs
Allocation Model Definition
Pay As You Go
• No upfront resource allocation in the org vDC • Resources are reserved as users create vApps • Can set a percentage of resources to be reserved • vCPU rating can be adjusted
Allocation Pool (“Virtual container”)
• Allocated pool of resources with a percentage reserved • Cloud admin controls ability to overcommit resources • Users cannot modify VM reservations and limits • Resources can be shared between org VDCs
Reservation Pool (“Physical container”)
• Allocated pool of resources with 100% reserved • Users can adjust VM reservations and limits • No sharing of resources with other org VDCs • Similar to allocation pool, with reservation = 100%
Guarantee
Actual
Actual
Guarantee
Overcommit Range
Fully reserved pool of resources
Pool expands to accommodate resources reserved on demand
vApp
vApp
Partially reserved pool of resources
Confidential 20
21
Copyright © 2011 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies.
Design Considerations – (vCAT 2.0)
• Provider vDC Should Map to Cluster Level • Minimizes Resource Pool Nesting • Prevents “Sibling Rivalry”
• Models affect Resource Pools and VM’s differently • Pay as you Go: Sets limit on all Virtual Machines • Reservation Pool: Sets limit=reservation on Resource Pool • Allocation Pool: Sets Limits and % Reservation on Resource Pool
as well as on all Virtual Machines MEMORY only • Allocation Model = Organization vDC
• When defining an Org vDC you are selecting the allocation model • Pay As You Go Defaults – Change Them!
• .25Ghz • 100% Memory reservation
21 Confidential
22
Allocation Model Impact on vCenter Resource Pools
Attribute Resource Pool Configuration for each Allocation Model
Allocation Model Pay-As-You-Go Allocation Pool Reservation Pool
Org vDC CPU Speed
No configuration change Not Configurable Not Configurable
Org vDC CPU Allocation
Not Configurable Resource Pool CPU Limit = vDC CPU Allocation
Resource Pool CPU Limit & Reservation = vDC CPU Allocation
Org vDC CPU Guarantee %
Resource Pool CPU Reservation = Sum of all VM CPU Reservations
Resource Pool CPU Reservation = vDC CPU Guarantee % x vDC CPU Allocation
Not Configurable
Org vDC Memory Allocation
Not Configurable Resource Pool Memory Limit = vDC Memory Allocation
Resource Pool Memory Limit & Reservation = vDC Memory Allocation
Org vDC Memory Guarantee %
Resource Pool Memory Reservation = Sum of all VM Memory Reservations
Resource Pool Memory Reservation = vDC Memory Guarantee % x vDC Memory Allocation
Not Configurable
Notes Resource Pool CPU & Memory has Expandable Reservations and is Unlimited
No Expandable Reservations for CPU & Memory is not Unlimited.
No Expandable Reservations for CPU & Memory is not Unlimited.
23
Allocation Model Impact on VM Configuration
Attribute Virtual Machine Configuration for each Allocation Model
Allocation Model Pay-As-You-Go Allocation Pool Reservation Pool
Org vDC CPU Speed
Virtual Machine CPU Limit = vDC CPU Speed x No. Virtual Machine vCPUs
Not Configurable Not Configurable
Org vDC CPU Allocation
Not Configurable No Virtual Machine CPU Reservation or Limit
No Virtual Machine CPU Reservation or Limit
Org vDC CPU Guarantee %
Virtual Machine CPU Reservation = vDC CPU Guarantee % x Virtual Machine CPU Limit
No Virtual Machine CPU Reservation
Not Configurable
Org vDC Memory Allocation
Not Configurable Virtual Machine Memory Limit = Virtual Machine Memory Allocation
No Virtual machine Memory Reservation or Limit
Org vDC Memory Guarantee %
Virtual Machine Memory Reservation = vDC Memory Guarantee % x Virtual Machine Memory Allocation Virtual Machine Memory Limit = Virtual Machine Memory Allocation
Virtual Machine Memory Reservation = vDC Memory Guarantee % x Virtual Machine Memory Allocation
Not Configurable
24
How to Work with VMware vCloud Networking Models
25
Copyright © 2011 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies.
Why we need Cloud Networks Today
Confidential 25
1972
1982 1992
2012
430,000 a day
26
Copyright © 2011 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies.
Networking Layers
3 Different Layers of Networking • External • Organization • vApp
Managed at two layers: Consumers & Providers
An External Network is a network that is outside of VMware vCloud Director. • This is set up by the Cloud Admin/Provider
An Organization Network is contained within an organization. • This is also set up by the Provider
vApp Network is a contained within a vApp. • This is set up by Consumers
Note: Both organization networks and vApp networks are entirely within VMware vCloud Director-managed infrastructure.
Confidential 26
27
Copyright © 2011 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies.
Layers: External Networks
a.k.a ‘Provided Network’ • Network that is external to VMware vCloud Director • Created in vSphere/vCenter environment and consumed by VMware vCloud
Director to provide external connectivity to Organizations • Mapped to a portgroup at the VMware vSphere layer
• vSS or vDS
• The portgroup is attached to VMware vCloud Director as an “External Network” Use cases
• Internet access • Network endpoints
• IP based storage • Backup servers
• Backend network infrastructure to the datacenters • Internal IT Infrastructure • Second Datacenter
Set up by Cloud Admins
Confidential 27
28
Copyright © 2011 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies.
Layers: Organization Networks
Contained within an organization Allows vApps within the organization to communicate with each other or outside the organization Can be connected to External Networks as:
• Public (External Org Direct) • Bridged connection to an External Network • Others outside the organization can see
• Private Routed (External Org NAT-Routed) • Connected to an External Network through a vShield Edge • Can be configured for NAT & Firewall
…or left unconnected to external • Private Internal (Internal Org)
• No External connectivity
Backed By Network Pools
Confidential 28
Set up by Cloud Admins
29
Copyright © 2011 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies.
Layers: vApp Networks
Contained within a vApp • Inherently Private Internal
Allows VMs in a vApp to communicate with each other Or ...by connecting them to Org Networks, other vApps Can be connected to Org Networks as
• Public (Direct) • Bridged connection to a organization network
• Private Routed • Connected to a organization network through a vShield Edge • Can be configured for NAT & Firewall
§ Backed by a Network Pool Set up by Consumers
Confidential 29
30
Copyright © 2011 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies.
Network Pools: Overview
A set of pre-configured network resources that can be used for Organization and vApp Networks • Use to facilitate VM to VM communication
Three Types of Network Pools in VMware vCloud Director: • Portgroup-backed
• Reference pre-created portgroups • These have to be created in vSphere manually or through orchestration
• Do not have to be VLAN isolated (but recommended for L2 isolation) • Attach a collection of them to VMware vCloud Director
• VLAN-backed • Exactly like portgroup-backed but VMware vCloud Director will automatically create
the portgroups as needed, and use a range of VLANs to isolate them.
• vCloud Network Isolation-backed (vCD-NI) • VMware proprietary network isolation technology
Confidential 30
31
Copyright © 2011 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies.
Network Pools: Portgroup-backed
Requires • Preconfigured portgroups at the vSphere layer • Assign meaningful names so its obvious what is being mapped • If using vSS portgroups, they must exist on all ESX/ESXi hosts in the cluster
How it works • System administrator manually creates the portgroups • When creating the network pool, you are given a list of unused portgroups that
exist in the cluster Advantages • Works with all types of vSwitches
Disadvantages • Requires manual work or orchestration to create all of the portgroups • Portgroups needs to be keep in sync on a vSS • To ensure isolation portgroups rely on VLANs for L2 isolation
Confidential 31
32
Copyright © 2011 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies.
Network Pools: VLAN-backed
Confidential 32
Requires • A vDS that’s connected to all ESX/ESXi hosts in your cluster • A range of unused VLANs
How it works • vCD admin creates the network pool and chooses an “Organization” vDS to attach it to,
then provides a range of valid VLANs, for example, 10 – 15 • When an isolated network is needed, vCD will automatically create a portgroup on the
vDS and assign it one of the unused VLAN numbers • Many isolated portgroups can coexist on the same vDS because they are isolated by the
VLAN tag
Advantages • Isolated networks • Best network performance
Disadvantages • Requires VLANs to exist in the physical network hardware (physical switches) • VLANs are limited and may not be available at all • Not compatible with Cisco Nexus 1000V
• Use portgroup-backed network pool of portgroups that happen to have VLAN tags
33
Copyright © 2011 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies.
Network Pools: vCloud Network Isolation-backed
Confidential 33
Requires • A vDS that’s connected to all ESX/ESXi hosts in your cluster
How it works: • vCD creates an overlay “transport” network for each isolated network to carry encapsulated
traffic • Each overlay network is assigned a Network ID number • Encapsulation contains source and destination MAC addresses of ESX/ESXi hosts where VM
endpoints reside as well as the Network ID • ESX/ESXi host strips the vCD-NI packet to expose the VM source and destination MAC
addressed packet that is delivered to the destination VM
Advantages: • Does not have to use VLANs (can optionally set a VLAN ID for the transport network; leaving
blank defaults to 0)
Disadvantages: • Small performance overhead due to encapsulation (dvFilter) runs at around 1% CPU utilization • Added MAC header require an increase in MTU same as in MPLS networks • vCD-NI is for layer 2 adjacency and not for routed networks • vCD-NI is only for VMs and cannot be accessed by physical hosts
34
Copyright © 2011 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies.
Putting it Together: vCloud Networking Options – Examples
vApp network
vApp
External Network (set up by system admin)
External Organization Network (set up by system admin)
Organization
Internal Organization network (set up by system admin)
vApp network
(set up by org admin/vApp author, internal to vApp)
External Organization Network
vApp network 1 2 3
4
5 6
7
8
Confidential 34
35
Customer Networking Use Case Requirements
§ Catalog Items need to have static IP’s that cannot be changed • (Static IP Pools will NOT be Used)
§ Multiple levels of Testing are required (Org Isolation) § Developers need their own isolated space
• Ideal for vApp Networking
§ 1:1 NAT’s will be required for external systems to access VM’s • Web Services • HP-UX • Databases • Code Repository
§ Multiple External VLAN’s will be needed per Org § At least 4 Organizations initially will be needed
36
Customer “Master” Org Networking Use Case
36 Confidential
External Org Network Dedicated VLAN (Routable) 10.x.x.x (TBD)
NAT Routed Org Network 172.1.2.0/22
172.1.2.254/22
VM .18
VM .19
Component 2
VM .16
VM .17
Component 1
vApps sharing the same Subnet and Segment for End-to-End
10.x.x.254
Manual 1:1 NAT Example 10.x.x.16 = 172.1.2.16 10.x.x.17 = 172.1.2.17 10.x.x.18 = 172.1.2.18 10.x.x.19 = 172.1.2.19
37
Customer “Functional Testing” Org Networking Use Case
37 Confidential
External Org Network Dedicated VLAN (Routable) 10.y.y.y (TBD)
NAT Routed Org Network 172.1.2.0/22
172.1.2.254/22
VM .18
VM .19
Component 2
VM .16
VM .17
Component 1
vApps sharing the same Subnet and Segment for End-to-End
10.y.y.254
Manual 1:1 NAT Example 10.y.y.16 = 172.1.2.16 10.y.y.17 = 172.1.2.17 10.y.y.18 = 172.1.2.18 10.y.y.19 = 172.1.2.19
38
Customer “End to End Testing” Org Networking Use Case
38 Confidential
External Org Network Dedicated VLAN (Routable) 10.z.z.z (TBD)
NAT Routed Org Network 172.1.2.0/22
172.1.2.254/22
VM .18
VM .19
Component 2
VM .16
VM .17
Component 1
vApps sharing the same Subnet and Segment for End-to-End
10.z.z.254
Manual 1:1 NAT Example 10.z.z.16 = 172.1.2.16 10.z.z.17 = 172.1.2.17 10.z.z.18 = 172.1.2.18 10.z.z.19 = 172.1.2.19
39
Customer Individual Developer Org Networking Use Case
39 Confidential
External Org Network Dedicated VLAN (Routable) 10.a.a.a (TBD)
vApps isolated on Direct connected vApp networks with dynamically created 1:1 NAT
VM .16
VM .17
Component 1 (Developer 1)
vApp Network 172.1.2.0/22
VM .18
VM .19
Component 2 (Developer 1)
vApp Network 172.1.2.0/22
vApps deployed from catalog are NOT customized and are identical copies
VM .16
VM .17
Component 1 (Developer 2)
vApp Network 172.1.2.0/22
40
§ Every Organization will need a dedicated External VLAN § Developer Org will use vApp Networks for Isolation § All other Organizations will use NAT Routed Org Networks § vApp Catalogs would be building block based • Base OS Catalog (Single VM vApps) o Windows and Linux
• “Golden” Image Catalog (Single VM vApps) o Standard Web Server o Standard App Server
o Standard DB Server • Components Catalog (Multi-VM vApps)
Confidential 40
Use Case Design Outcome
41
Public and Hybrid Cloud
42
The future of Cloud is unwritten. You will write it.
We give you choice.
Be their Guide.
43
Experiment with the Providers
§ Search for public providers • vcloud.vmware.com • vCloud Express – Generally Shared
• vCloud Datacenter – Generally Dedicated
§ Move workloads between clouds • VMware vCloud Connector
• Move between vSphere and vCloud
• Build locally then push to cloud
§ Maintain provider based catalogs of your vApps § Single API between public and private • vCloud Providers are using the vCloud API
44
VMware vCloud Do’s and Don’ts
45
Just Some Interesting Stuff
Do…. § Change the PAYG Defaults § Point Provider vDC’s to Cluster
level § Allow access to hosts only in
vCenter • Use vCenter Roles
§ Always install VMware tools, needed for customization
§ Get PSO for vCloud Designs • Terrance Donovan
• Peter Stryzsinski
§ Follow Chris on Twitter and visit my blog
Don’t…. § Disable DRS in vCenter under
vCloud § Manage VM objects in vCenter • i.e. change VM settings (NIC)
§ Don’t make too many clones of clones • Microsoft Activation Limit
§ Remove any vCenter objects • i.e. Hosts, VMs, portgroups
§ Call Paul or Chris if you break
something, call GSS
46
Questions
Top Related