Download - 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