4. 4
Snapshot Support in vCloud Director 5.1
Allows for the ability to:
• Create
• Revert
• Remove
Works for:
• Virtual Machines
• Powered-on/off/suspended
• vApps
Works with:
• UI and REST API
• Chargeback
Does not support:
• Multi-level snapshots
• Lab Manager-style snapshots
(deployed in fenced mode)
• Network reconfiguration while
snapshots are present
• Revert doesn’t restore vApp
topology and OVF properties,
only the VMs
• Virtual Machines with
independent disks attached
6. 6
Multiple Classes of Storage
Not all storage is the same…
Gold
High Speed/Low
Latency
Silver
Moderate
Speed/Latency
Bronze
Low Speed/ High
Latency
7. 7
Multiple Classes of Storage
Not all storage is the same…
Gold
High Speed/Low
Latency
Silver
Moderate
Speed/Latency
Bronze
Low Speed/ High
Latency
In order to manage this in
the past, Admins had to
create multiple vDCs…
vDC 1
vDC 2
vDC 3
8. 8
Multiple Classes of Storage
Not all storage is the same…
Gold
High Speed/Low
Latency
Silver
Moderate
Speed/Latency
Bronze
Low Speed/ High
Latency
In order to manage this in
the past, Admins had to
create multiple vDCs…
vDC 1
Now Admins can
leverage Storage
Profiles instead…
9. 9
Multiple Classes of Storage
• The Org Admin can now offer
different classes of storage within
a single vDC
• vDCs, vApp Templates, and
Media can define a default
storage profile to be used
• Storage DRS functionality can
now be leveraged within vCD,
allowing for Storage vMotion
between datastores within a
cluster based upon metrics
defined (available space, I/O
latency, ect)
• Will be integrated with
ChargeBack
Gold
High Speed/Low
Latency
Silver
Moderate
Speed/Latency
Bronze
Low Speed/ High
Latency
vDC 1
10. 10
Storage Profiles Feature Overview
Leverages existing constructs in vSphere 5.0
• Requires Enterprise Plus license as the Policy Based Management for storage
in vSphere 5 requires it.
• Datastores expose their capabilities as string labels in 5.0 and 5.1
• Supports datastore clusters - Storage DRS honors the profiles
Storage Profiles are managed through vSphere, not through vCD.
This includes:
• Authoring Storage Profiles
• Adding new Storage Profiles
• Renaming or deleting Storage Profiles
Storage Profiles are a requirements profile, essentially a tier
requirement
Storage Profiles express requirements by depending on
capabilities
11. 11
Storage Profiles Feature Overview
Allows the association of Storage Profiles with Provider vDCs and
Organization vDCs
Can give a subset of storage to a particular Organization vDC
Applies to VMs, vApp Templates, and Media
• VMs placement based on assigned Storage Profile
• Can change Storage Profiles after a VM has already been placed
• Profile-Driven Storage Service remembers association between VM
(home and disks) and Storage Profile (So if it’s relocated to a
different datastore, we can say if it meets the requirements and it is
‘compliant’)
13. 13
Overview of the Three Resource Allocation Models
Summary:
Tenant charged for
resources used
Benefits:
• Over-commitment
controlled by SP
• % of resource
guaranteed can be
unlimited
Use Case:
• Test/Dev
• Unmanaged workloads
in a public cloud –
charge tenants when
resources are used
Summary:
Allows SP to pre-allocate
resources
Benefits:
• Provides predictable
billing
• Does not have
resource QOS
allowing you to
overcommit
Use Case:
• Elastic pool with
minimum resource
guarantees and a cap
• Predictable tenant
billing
Summary:
Has full resource
management controls
(reservations, limits,
shares)
Benefits:
• Cannot over-commit
resources
• Guarantees 100% of
vDC Allocation
Use Case:
• Capacity based
chargeback
• Virtual Private Data
Center
Reservation Pool Allocation Pool Pay As You Go (PAYG)
14. 14
Elastic Virtual Data Center – The Problem
pVDC A pVDC B pVDC C
Tenant
Organization VDC
• Three different clusters, each on separate subnets
15. 15
Elastic Virtual Data Center – Networks
pVDC A pVDC B pVDC C
Tenant
Organization VDC
VXLAN Fabric
• VXLAN allows you to span subnets or L2 domains
16. 16
Elastic Virtual Data Center – pVDC Expansion
Provider Virtual Data Center
Tenant
Organization VDC
VXLAN Fabric
• This allows your Provider vDC to grow to include all three clusters
17. 17
Elastic Virtual Data Center – oVDC Expansion
Provider Virtual Data Center
Tenant
Organization VDC
VXLAN Fabric
• Which allows your Organization Virtual Data Center to expand
18. 18
Elastic Virtual Data Center – Workload Management
Provider Virtual Data Center
Tenant
Organization VDC
VXLAN Fabric
• Can leverage Cross Cluster vMotion to distribute load
19. 19
Elastic Virtual Data Center
Description Benefits
• Container by which a tenant consumes resources (e.g., an
Org VDC) can grow:
• Automatically, without manual intervention on the part of the
cloud provider admin
• On-demand in response to tenant requests (PAYG)
• Within a very large bound that tenants rarely, if ever, reach or
see.
• Provider Admins no longer have to answer “Which cluster
should this VDC go into?”
• Compute capacity for
VDC can come from
multiple clusters under
a single vCenter
• Enables Allocation Pool
& Pay-As-You-Go VDCs
to grow dynamically.
• No support for
Reservation Pool
VDCs
Provider VDC – Bronze A
Physical Hardware
Resource PoolsPort GroupsDatastores
Provider VDC – Bronze B
Physical Hardware
Resource PoolsPort GroupsDatastores
Coke Bronze VDC
Pepsi Bronze VDC Dr Pepper Bronze VDC
20. 20
Added Features to Support Elastic vDCs
1. Elasticity of Allocation Pool Organization vDCs
2. Placement Engine Enhancements
3. Merge Provider vDCs
4. Migrate VMs from a resource pool to other resource pools in a Provider vDC
5. Elasticity of System vDC Resource Pools
25. 25
• Integrated Organization vDC Creation Workflow
• Creates compute, storage, and networking objects in a single workflow
• The Edge Gateway is a first class entity in vCD 1.5
• Exposed at Organization vDC level
• Organization vDC networks replace Organization networks
• Edge Gateways now support:
• Multiple Interfaces on a Edge Gateway
• The ability to sub-allocate IP pools to a Edge Gateway
• Load balancing
• HA
• DNS Relay
• Rate limiting on external interfaces
New Features in Networking
26. 26
Changes at a Glance - vCD 1.5 vs 5.1
Feature vCD 1.5 Organization
Networks
vCD 5.1 Organization
vDC Networks
Gateway visible to user No Org level gateway visible
to user
External network
connectivity for Networks
Single for Org Networks Multiple for Org vDC
networks
Gateway HA No Yes
Multiple edge
configurations
No Yes
Ability to specify external
interface IP
No Yes
IP pool sub allocation User had to assign a set
of external IP addresses
Specify IP ranges on
external interfaces.
DNS Relay No Yes
Ability to configure rate
limits on external
interfaces
No Yes
28. 28
New Features in Gateway Services
Load balancer service on Edge Gateways
Ability to add multiple subnets to VPN tunnels
Ability to add multiple DHCP IP pools
Ability to add explicit SNAT and DNAT rules providing user with full
control over address translation
IP range support in Firewall and NAT services
Service Configuration Changes
• Services are configured on Edge Gateway instead of at the network level
• DHCP can be configured on Isolated Organization vDC networks.
30. 30
Usability Features
New default branding style
• Achieves consistency with our other products
• Cannot revert back to the Charcoal color scheme
• Custom CSS files will require modification
Improved “Add vApp from Catalog” wizard workflow
Easy access to VM Quota and Lease Expirations
New dropdown menu that includes details and search
Redesigned catalog navigation and sub-entity hierarchy
Enhanced help and documentation links
• Every single screen has buttons to access online help
32. 32
Metadata Feature
This feature allows users to assign information to vCD objects
• Can be leveraged by API, Chargeback, ect
• Search functionality is available through the REST API
Metadata consists of Key->Value pairs
Metadata Component Data type Restrictions
Key String • Valid Unicode Strings
• 256 Characters Max
Value
String • Valid Unicode Strings
• No size Restrictions
• >1000 characters - not searchable
Long • As defined by W3 Long Type
DateTime • As defined by W3 DateTimeType
Boolean • As defined by W3 Boolean Type
33. 33
Metadata Access Control
Two types of access control domains:
• ‘General’ – Accessible by Authorized Users
• ‘System’ – Accessible by System Administrators
• Readonly access to Authorized Users
Domain Visibility Accessible by Access type
General Readwrite All users As authorized per vCD entity
System
Readonly System Administrators Full access
Authorized Users Read only access
Private System Admins ONLY Full Access.
35. 35
Miscellaneous Features
Virtual Hardware Version 9
• Supports features presented by HW9 (like 64 CPU support)
• Supports Hardware Virtualization
• VT-x/EPT or AMD-V/RVI
• Memory overhead increased, vMotion limited to like hardware
• Enable/Disable exposed to users who have rights to create a vApp Template
Storage DRS
• Exposes storage Pod as first class storage container (just like a datastores)
making it visible in all workflows where a datastore is visible
• Creation, modification, and deletion of spods not possible in vCD
• Member datastore operations not permissible in VCD
38. 38
Storage Independent of VM Feature
Not specifically a sales feature, more for us to provide support
internally
Added support for Independent Disks
• To support Cloud Foundry as AppCloud could not run on vCD previously without the
API support for this
Provides REST API support for actions on Independent Disks
As these consume disk space, the vCD UI was updated to show
user when they are used:
• Organizations List Page
• A new Independent Disks count column is added.
• Organization Properties Page
• Independent Disks tab is added to show all independent disks belonging to vDC
• Tab is not shown if no independent disk exists in the vDC.
• Virtual Machine Properties Page
• Hardware tab->Hard Disks section, attached independent disks are shown by their
names and all fields for the disk are disabled as they are not editable.
The Snapshot operation with vCloud Director is very simple. It leverages vCenter Server to perform the actual snapshots.
Create Snapshot
Creating a second snapshot overwrites the first
User option to snapshot with/without memory state
User option to quiesce guest before snapshot (requires VMware tools)
Snapshots at vCenter layer will be automatically consolidated
Revert to snapshot
Restores previous VM state (memory, disk, virtual hardware config)
Undeploy operation will preserve snapshots
Cloning and Capture operations will not preserve snapshots
Snapshots can be applied to individual VMs, or to a vApp. When a Snapshot is performed on a vApp, the snapshots are performed in parallel to all the VMs in the vApp in start order groups.
There is no blocking of the Snapshot operations. So if a vApp is told to create a snapshot where a VM in that vApp already has a snapshot, the existing snapshot is overwritten.
No controls/limits on snapshot operations, snapshot storage is the only resource charged for
Some examples:
If you snapshot a vApp, delete the snapshot of a child VM, and revert the vApp, all child VMs will be reverted, except the one where you deleted the snapshot.
If you snapshot a vApp where one of the VMs already has a snapshot, a new snapshot is taken for that VM, and the existing one is overridden.
If you delete the snapshot for a vApp and then snapshot a child VM, then the vApp is again seen as having a snapshot.
ChargeBack
Storage usage for snapshots is accounted for using existing VM modify events.
No new snapshot event type.
NIC settings are read-only for VMs with memory-state snapshots
Thus, networks attached to those NICs cannot be removed
Performance and Cost typically are metrics used to different types of storage.
To provide for multiple tiers of storage, Admins typically created a PvDC for each storage type and used that to manage the storage allocation.
By adding storage profiles, admins can now have multiple tiers of storage within a single pvDC and then divide the storage tiers amongst the various organizations.
Storage profiles is a feature in vsphere and now in vCD allows you to have multiple classes of storage and expose that back to the end user.
Allows the org admin to expose multiple classes of storage in a vDC, gets around limitation in previous release of people having to create multiple vDCs to do the same thing.
Also integrates Storage DRS functionality with vCD. Can cluster different datastores allowing user to do Svmotions between those datastores in the cluster depending on certain events (Like if you run out of space or other metrics you configure (I/O). Storage DRS also allows you to offer additional SLAs on storage.
This is just a review of the current allocation models. Just used to set the stage and ensure everyone is on the same page before beginning.
Allocation Pool Model
With the Allocation Pool Model:
You pay for a pre-allocation of resources.
Organizations are charged for the capacity allocated to their vDCs.
You can expand/contract your resources at any time, but only through Service Provider.
Lowering the guarantee of resources allows for more vApps to fit into the pre-allocation, but this may impact the ability for the vApp to get the resources it asks for.
Service Provider controls resource over-commit by setting a % guaranteed commitment of the Allocation for any vApps deployed (that is, vApp gets an Allocation which is a % guarantee of the reservation). vApps can compete for resources above this guaranteed reservation.
This model:
Does not have Resource Quality Of Service (QOS) in this model, which means that over-commitment is possible.
Has predictable end of month billing.
Reservation Pool Model
The Reservation Pool Model is useful if you know your applications well enough to optimize your own provisioning. This model has Full Resource Management Controls (reservations, limits, shares) available.
As with the Allocation Pool method, Organizations using the Reservation Pool model are charged for vDC capacity.
With this model, Service Provider cannot over-commit resources. This model guarantees 100% commitment of the vDC Allocation.
Note: With this model, the Service Provider has no Percentage of Resource Guaranteed control.
Pay-As-You-Go Method
With this method (also referred to as the Allocation vApp Model) , you are charged for each vApp virtual machine that is running. Like the Allocation Pool Model, the over-commit is controlled by Service Provider and the Percentage of Resource Guaranteed control is available but the Service Provider can set this to unlimited (Expandable Reservation).
This model facilitates an unlimited option similar to Expandable Reservations – it can use Reservations from the pVDC.
Problem Statement:
3 clusters, with 3 different pvdcs on 3 different subnets.
First, you setup a Vxlan fabric. Optional – You can still use it but the clusters have to be in the same subnet
You can then expand your pvdc. You can do this through a ‘merge’ function which is present in this release to create a bigger pvdc on the same vc.
At this point, you can then grow your org vDCs. Grow on demand if it’s paygo as new vm are provisioned, for allocation model you can simply change the settings
In the UI, you can migrate workloads in case you have two clusters, one is heavily loaded, and the other is very light. You can run into this as vDC only has initial placement logic.
Moving a vApp from one cluster, you have to make sure it’s part of the same org, same users. Is vmotion capable, but requires storage to be present. Can use to decommission a cluster, but you can have to move everything and then disable the resource pool and then delete it.
Must be in the same datacenter object.
Elastic vDC feature summary
It doesn’t have to be this painful…
Vmware now supports SSO…
How one uses SSO depends on their role within a cloud environment.
Consumers will tend to use the Web based SSO feature (possibly in conjunction with SSPI), whereas Providers will tend to use SSPI as well as the cross product authentication.
In 1.5, when a routed or isolated network with DHCP was created, in the background a vse device was also created. Now from 5.1 onwards this edge becomes a first class object which is exposed at the org vDC level.
In place of org networks, Org vDC networks have been introduced.
In 1.5, the number of interfaces on the vse used to be 2. Now there are multiple interfaces on the edge gateway.
Also provide support for the ability to sub-allocate pools to the vse.
Generic nat implementation previously wherein the entire control model was limited to the administrators
Used to configure services at the network level. Now, each of the services are configured on the gateway services page.
Feature driven by Cloud Foundry
Before the 5.1 release, AppCloud could not be run on top of vCD simply because it did not have a API to deal with the disks.
The following four APIs are required to support AppCloud:
(String) create_disk(size, vm_locality = nil)
(Object) attach_disk(vm, disk)
(Object) detach_disk(vm, disk)
(Object) delete_disk(disk)
Allows for following integration with other products
Cloud Foundry
Independent disk fills the gap of vCD and Cloud Foundry. It enables AppCloud run on top of the vCD.
ChargeBack
Chargeback uses only REST API for storage usage of independent disk.
Independent disks are accounted for in the organization vDC and provider vDC metrics, whether detached or attached to a VM. The size is not double-counted when attached to a VM.