Presentation building your cloud with v mware

© 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
Confidential3

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
Allocation Models

18
Allocation Models Change Consumption Habits
.
Confidential18
Unblur the virtualization era line between choice and cost.

19
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
Confidential19

20
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
Confidential20

21
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 %
Reservation = Sum of all VM
Memory Reservations
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
Reservation = vDC
Memory Guarantee % x
Allocation
Not Configurable

24
Networking Models

25
Why we need Cloud Networks Today
Confidential25
1972
1982 1992
2012
430,000
a day

26
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.
Confidential26

27
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
Confidential27

28
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
Confidential28
Set up by Cloud Admins

29
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
Confidential29

30
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
Confidential30

31
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
Confidential31

32
Network Pools: VLAN-backed
Confidential32
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
Network Pools: vCloud Network Isolation-backed
Confidential33
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
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 network1 2 3
4
56
7
8
Confidential34

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)
172.1.2.0/22
172.1.2.254/22
VM
.18
VM
.19
Component 2
VM
.16
VM
.17
Component 1
10.y.y.254
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)
172.1.2.0/22
172.1.2.254/22
VM
.18
VM
.19
Component 2
VM
.16
VM
.17
Component 1
10.z.z.254
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)
Confidential40
Use Case Design Outcome

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

Presentation building your cloud with v mware

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (9)

Similar to Presentation building your cloud with v mware

Similar to Presentation building your cloud with v mware (20)

More from solarisyourep

More from solarisyourep (20)

Presentation building your cloud with v mware