Dedicated Resources - Private pod, cluster, host Functional Spec

Bug Reference

Branch

master, 4.2.0

Introduction

Dedicating pod, cluster or host to a specific domain/account means that the domain/account will have sole access to the dedicated pod, cluster or hosts such that scalability, security and manageability within a domain/account can be improved. The resources which belong to that tenant, will be placed into that dedicated pod, cluster or host.

Current Scenario

Currently in CloudStack, zones can be reserved for specific domains. Only users in that domain or its subdomain may create guests in that zone.
Dedicated Hosts and HA Hosts: if one of the dedicated hosts fail then the VMs are HAed onto a specific host(s) that is dedicated for purposes of HA.
Domains/Accounts cannot have private pod, private cluster or private host

Purpose

Dedicating a zone might be very expensive offering for several end-users whereas dedicating a pod/cluster/host may be more economical. This feature will allow root admin to dedicate resources to a specific domain/account that needs private infrastructure for additional security or performance guarantees.

This document describes the specifications and design of this feature.

Also see https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+for+VMs+on+hardware+dedicated+to+a+specific+account

References

PM document: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Private+Host%2C+Cluster%2C+Pod

Preliminaries

1. Explicitly Dedicated Resources: Resources dedicated to an account during configuration time

2. Implicitly Dedicated Resources: Resources which are in common pool that any account can pick during runtime.

3. Shared Resources: All the non-dedicated resources.

4. SO dedication flag: a new Parameter in Service Offering. if ON, Use Implicitly Dedicated Resources

5. DVM dedication flag: a new Parameter in deployVirtualMachine API, if ON, VM is deployed on explicitly dedicated resources

Feature Specifications

Requirements

Root Admins must be able to explicitly dedicate a zone, pod or cluster or host to a specific domain or account
When deploying a VM, end user can optionally specify it to be placed on a dedicated resource
Explicit dedication can be for a domain or account and can be a zone/pod/cluster/host; for example, if a cluster is explicitly dedicated to a domain, any account in that domain can share the hosts (as long as they DeployVM with dedication flag on), but sharing is limited to accounts within that domain only. As another example, if a cluster is explicitly dedicated to an account, only that account’s VM can use those hosts in the dedicated cluster (as long as they DeployVM with dedication flag on).
Alternatively, a host or cluster or pod or zone can be "implicitly" dedicated - this flag's description will be clarified below
Implicit dedication can be for a zone/pod/cluster/host, but not associated with any domain or account; however, during VM deployment, once chosen, a host will not be shared across multiple accounts – as an example, here is a reason: for deployment of certain types of applications, such as desktops, due to licensing reasons, no host can be shared between different accounts. However, pre-allocating specific (number of) hosts to each account is not desired as this will create forecasting issues/sub-optimal utilization
A service offering can optionally have an "implicitly" dedicated flag on - this flag's description will be clarified below in the table

Admin must be able to live migrate of such a VM to a resource not owned by the account, but an alert must be generated

Fail the request if DeployVM dedication Flag is specified and SO has implicit dedication ON
When you search implicitly dedicated “area” for a host (second table below), if there is already a host for this account, pick it up (instead of finding a new one every time)
When you delete the last VM from a host in the implicit area, remove the association of the account with the host (i.e. make it implicit-free host as before)

Table 1:Deploying VM with DeployVM dedication flag

	DeployVM dedication Flag specified	DeployVM dedication Flag Not specified
Explicitly Dedicated Resources	Pick from Explicitly dedicated else fail	Pick from shared resources else fail
NO Explicitly Dedicated Resources	Fail the request	Pick from shared resources else fail

Table 2: Deploying VM with SO dedication flag

	SO dedication Flag = ON	SO dedication Flag = OFF
YES - Implicitly Dedicated Resources	Pick from implicit dedicated resources else FAIL	Pick from shared resources else fail
NO - Implicitly Dedicated Resources	Fail the request	Pick from shared resources else fail

Logs

Ensure proper logs are maintained into vmops.log and api.log

Test Guidelines

Dedicated resources can only be used if service offering dedication flag is ON or DeployVM dedication flag is ON but not both.

User Permissions

Only Root Admin can dedicate zone, pod, cluster or host to specific domain or an account.
Only Root admin can implicitly dedicate a zone, pod, cluster or a host.
If a user does not belong to a domain which has dedicated resources, he cannot access the pod, cluster or host dedicated to that domain/account.
Users belonging to domain/account having dedicated resources, can access them but should not be allowed to modify.
At this time, there is no requirement for the domain/sub-domain admins to manage the resource - the root admin will remain the owner of the resources
Only Root Admin can add a service offering with "isdedicated" option enabled.
User/admin can enable the DeplovVM dedication flag.

Use Cases:

Dedicating resources to Domain/Account

Domain level accessibility:

Let D1 domain has SD1, SD2, SD3 sub-domains. A1 is the admin account, U2 is normal user account.

Here z1, z2, ... are zones , p1,p1, ... are pods, c1, c11, c2 ,.... are clusters, H1, H2, ... are Hosts

z1 - (p1-c1,c11,c111),(p2-c2,c22),(p3-c3, c33)
z2 - (p4-c4)

Root Admin should be able to dedicate a pod, cluster or host to any domain or sub-domain.
Once a Zone is dedicated to a domain, its pods and clusters will be dedicated to that domain eg: pod: p1 is dedicated to domain D1, clusters:c1, c11, c111 will be automatically dedicated to D1 by default.
Users in Sub-Domains SD1, SD2, SD3 should be able to deploy vm in parent domain's clusters c1, c11, c111 or pod p1.
After dedicating pod p1 to domain D1, if further cluster c11 (in pod p1) is dedicated to SD3, then D1 or SD1 or SD2 should not be able to access c11. (Can SD3 use SD2, SD1 or D1's resources, verify)
If another pod p2 is dedicated to SD1, then SD11, SD12 or D2 should not be able to access pod p2.
Before dedicating a pod to a domain , check whether its zone is dedicated or not.
Child Domain can access pod/cluster/host dedicated to parent domain, vice-versa is not (TBD).

Account level accessibility:

Once a pod/cluster/host is dedicated to an account, only users in that account can access it.
No other user from different accounts in the same domain or different domain can access the resources.

Deletion of Account/domain

Deleting an account will delete all the VMs, snapshots, templates, etc. of that account, and also removes the dedication of host, cluster or pod to that account.
Deleting a domain, will remove the dedication from the hosts, clusters or pods (if dedicated).

VM Deployment

If dedicated resources get exhausted for a domain/account, VM deployment will not fail unless shared resources has no free empty host, provided Implicit dedication flag: ON and service offering flag: ON.
VMs that belong to two different offerings can be on the same host as long as they belong to the same account/domain and have isdedicated flag ON. For e.g. If an instance is deployed by account user and :
a. If that account has dedicated resources, service offering flag "isdedicated" checked, then VM will be deployed on the dedicated host having VMs of same account or on the host which is empty.
b. If that account has NO dedicated resources, service offering flag "isdedicated" checked then VM will be deployed on the host which is empty and that host will become dedicated to this account.
The dedicated VM of other accounts (e.g. A2 or A3 ) of same domain or other domain, cannot use above host, but can use an empty host or host having vms of same account(A2 or A3).
If the service offering flag if OFF, the VM will be deployed as CloudStack is doing now but should not use the host marked "dedicated for domain/account x".
If no such host exists, VM operation should fail.
If the dedication is removed and host has NO dedicated VMs, then host will be available for all the accounts.
The following Figure graphically illustrates the VM deployment in hosts. Host 1 is explicitly dedicated to domain D1

Host Tags with isDedicated flag and dedicated resources

If Host Tag is provided and isDedicated flag is true and NO dedicated Resources (Host)
1. if Host has dedicated vms, place the vm in the that host
2. if Host has no dedicated vms, fail the request.
If host tag is provided and isDedicated flag is false and NO dedicated Resources
1. if Host has dedicated vms, fail the request
2. if Host has no dedicated vms, place the vm in that host as cloudstack is doing now
If host tag is provided and isDedicated flag is true and have explicitly Dedicated Resources (dedicated Host)
1. Search for tagged as well as dedicated host, if found place the vm, if not found, fail the request.

Migration of VMs

If VM to be migrated is non-dedicated
1. if destination host has dedicated vms, fail the request
2. if the destination host is explicitly dedicated, fail the request.
3. if destination host has no dedicated vms or is not explicitly dedicated, migrate it to the destination host.
If VM to be migrated is dedicated
1. if destination host has dedicated vms, migrate it to that host.
2. if destination host is explicitly dedicated to the account owning VM, migrate it to the host
3. if destination host is empty, migrate it to the host. Now host is implicitly dedicated to the account.
4. if destination host has non-dedicated vms or is not explictly dedicated, fail the request

Architecture and Design description

This feature will come as a separate plugin which will use the PluggableService to add the DedicatedResources feature APIs into CloudStack, the DedicatedResourceManager will be responsible for thread scheduling and the DedicatedResourcePlanner which will implement a deployment planner interface.

Dedication will be achieved as:

Admin adds Pod/cluster/host
Admin dedicates the pod/cluster/host to a domain/account using new dedication APIs
Admin enables the pod/cluster/host

Dedication will be used when:

If a request is placed to deploy a VM with Service Offering flag "isdedicated" ON.
1. Check if the account/domain has dedicated resources:
  1. If Yes, Place the VM in dedicated resources.
  2. If No, Place the VM in new free empty host, make that host dedicated to that account.

Note: If Service Offering Flag is OFF, non-dedicated (shared) resources will be used.

API Changes:

Following new APIs will be added:

Dedicating Resources to an account/domain
- dedicatePod
- dedicateCluster
- dedicateHost

These are new APIs to dedicate a pod/cluster/host for an account/domain.

Parameters include:
a) PodId/ClusterId/HostId
b) DomainId
c) AccountId

Updating dedication of resources
- updateDedicatedPod
- updateDedicatedCluster
- updateDedicatedHost

These are new APIs to update the dedicated pod/cluster/host for an account/domain.

Parameters include:
a) PodId/ClusterId/HostId
b) isPublic (if true, dedication is removed)

Listing Dedicated resources per account/domain
- listDedicatedPods
- listDedicatedClusters
- listDedicatedHosts

These are new APIs to list dedicated pods/clusters/hosts for an account/domain.