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

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


Allocation Models Change Consumption Habits

.

Confidential 18

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

Confidential 19

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

Confidential 20

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 %

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


Why we need Cloud Networks Today

Confidential 25

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.

Confidential 26

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

Confidential 27

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

Confidential 28

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

Confidential 29

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

Confidential 30

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

Confidential 31

32


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


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


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)


172.1.2.254/22

VM .18

VM .19

Component 2

VM .16

VM .17

Component 1


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)


172.1.2.254/22

VM .18

VM .19

Component 2

VM .16

VM .17

Component 1


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



vApps deployed from catalog are NOT customized and are identical copies

VM .16

VM .17



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

Presentation building your cloud with v mware

Documents

Transcript of Presentation building your cloud with v mware