VMware - Application Portability

© 2011 VMware Inc. All rights reserved

Virtual Application (vApp) Portability

Kamau Wanguhu

Staff Engineer - Integration Engineering

2

vCenter and VCD vApps

vCAC vApps/Blueprints

App Director Blueprints

The Future of vApps

3

vCenter and VCD Applications

vApps

4

vApps in VC: Current State

Distribution: OVF

• Packaging format, not directly runnable

• “Deploy”: Convert to target runtime format, and bind to resources

• Extensible format

• Built-in mechanism for customization on deploy

• OVF Properties

• Attributes to be configured

• Defined by vApp author

• OVF Environment

• Runtime method to assign values to OVF properties

• IP/mask/DNS/Gateway

• Passed to the VM, usually requires glue code

5

OVF Properties

7

Side-step: Guest Customization

Another mechanism to customize VMs

Fixed set of properties

• IP addresses

• Administrator password

• …

Fixed UI

Injects scripts into VM to apply settings

8

Recap

OVF: Distribution format

• Extensible

• Built-in data-driven customization during deploy

• Studio provides scripts to apply common settings

• vApp author must provide code for custom properties

Guest Customization

• Customize a fixed set of properties

• During deploy (VC) or entire life-time (vCD)

9

Multi-VM vApps in VC

Modern Apps consist of multiple VMs

vApp is a container of VMs, managed as one entity

• Import/Export

• Power On/Off

• Includes ordering, so VMs are powered on/off in the defined order

• Shared vApp Environment

• Used to discover other VMs in the vApp

• Built on resource pools

• Can specify resource settings for the whole vApp

• Supports nested vApps

• vApps are limited to the span of a resource pool

10

vApps in vCD

vCD vApps exist only in vCD

• Does not use the vApp construct in VC

• Spans entire VDCs, not limited to a resource pool

• No vApp-wide resource limits

• Limited support for shared vApp Environment

• No nested vApps

11

Dependency Injection: vServices

vService Providers register with vCenter

vApps can depend on vServices

Dependency is bound to provider during deploy

• Can be re-bound later

vService Provider can add information to the vApp’s runtime

environment

Example: Database vService

• When bound, creates database specific to the vApp

• Detailed requirements in vService Dependency section of vApp

• DB connection string (address, credentials) provided in vApp Environment

12

vCAC Applications

Blueprints

14

A specification for provisioning virtual or physical machines, determining

the machines characteristics and the policies applied to it.

Global or local blueprints

Key Attributes

• Machine Resources – CPU, Memory, Storage

• Placement using Reservation Policy

• Quota using ‘max machines per user’, ‘lease’, ‘archive’

• Approval Policies

• Build information using extensible workflows

• Security using permitted operations, access rules

vCAC Concept: Machine Blueprint

A

Requisition

Cost Profile

Provision

Manage

Retire

15

vCAC Screenshot: Machine Blueprint

16

vCAC Screenshot: Blueprint Build Information

17

vCAC Screenshot: Blueprint Security

18

Result of an end-user requesting a machine blueprint from self-service

catalog

Can be virtual machine, cloud machine or physical machine

Day 2 operations permitted to machines based on blueprint security

settings

Machine reclamation based on blueprint lease and archival settings

vCAC Concept: Machine

19

vCAC Screenshot: Machine

20

vCAC Screenshot: Machine Operations

22

Multi-machine Blueprints

Model an application environment comprised of multiple machines

Made up of component machine blueprints with additional

metadata

Machine operations aggregated at multi-machine level

23

MMBP CBP Network Network Tab

24

MMBP CBP Network LB Tab

25

App Director Applications

Blueprints

26

Logical Application Topology

Made up of “Nodes” (ex: Web, AppServer, Database)

• Node has logical template and compute, network information

Nodes contain building blocks called components

• Service components (ex: mysql, apache) or application components (ex: war)

• Components reusable across blueprints

• OOB components, import from marketplace or build new

Inter-node dependencies, Property bindings, Overridability

Same blueprint deployed to multiple environments (dev, test, prod)

Managed by ‘Application Architect’

AppD Concept: Application Blueprint

27

AppD Screenshot: Application Blueprint

Components

31

Future Applications

Options

32

Future of vApps

Need for a unified Application Construct

• Used on all platforms

• Preferably a standard, like IETF

OVF 2.0 adds extra features that could be supported

• Placement groups

• Scale-out settings

• Auxiliary files in OVF Environment (not just a single XML file)

Future of vServices 2.0(??)

• Used by some critical services,

• Service registry should be moved out of vCenter

• Better scale if built into a core services model

• Usable by platforms that do not need vCenter

33

Future of vApps

Open Framework

• Combine OVF properties and the scripts to use them in a single entity

• Scripts are automatically injected into guest OS and executed

• Data-driven UI prompts for user-definable settings

• Examples:

• Set IP address

• Install MSI/RPM

• Configure DB connection

• Completes the OVF customization story

• vApp authoring becomes easier

• vApp = Base OSs + customization ‘bricks’

• Can be applied to running VMs

• Re-customization

• Upgrades

34

Future of vApps

Converge AppD and vCAC Blueprints into one

• So that all AppD and vCAC blueprint scenarios can be met with single set of

concepts

• Machine provisioning, Infra Services, Software, Shared Services, Orchestration

Simplify user experience

• Remove duplicate concepts (Cloud Provider, Deployment Environment)

Take the opportunity to build for the future

• Support for version-control repositories – Blue Prints in textual form

• Comprehensive Extensibility

35

Challenges

Generic model vs. Domain Specific

• Blueprint is a “list of things” vs. “list of tiers made up of machines and software”

Generic composition vs. blueprint specific fulfillment engines

Diverse Use cases

• Pure IaaS, IaaS++, App Environments, Apps, DBaaS, PaaS, XaaS

Diverse Personas

• Infra admins, Middleware, Consumer, Governance Admin, Providers

Legacy functional contracts and technical assets

36

Portable Application Use Cases

• Can be published so that it can be deployed in dev/test, Prod or cloud

• An App vendor can publish a vApp which can easily be deployed.

• Have controls that allows for On, Off, Suspend, Snapshots...

• Ability to reconfigure Application (add/shrink, scale…)

• Monitored for performance, alerts, usage….

• Backed up and restore to a different environment

• Protected from a data center outage (rename/re-IP/…)

• Migrated to a new datacenter (with or without disruption)

• Easily migrated from a Customer site to the “cloud” and back again.

• Can be distributed; part in the “cloud” and part on customer site

• Can be decommissioned

37

Audience Ideas and Feedback