Apache CloudStack Evolution Proposal Alex Huang Software Architect, Citrix Systems
Design Goals • Make it easier for developers to get started • Allow developers with different skill sets to work on different parts of CloudStack • Give operator the choice to deploy only parts of CloudStack that they want to use • Allow CloudStack components to be written in languages other than Java • Increase deployment’s availability and maintainability
Action Plan • Disaggregate CloudStack services • Clearly differentiate between automation, orchestration, and provisioning • Switch to using well-known frameworks • Allow better composition at the resource layer • Change the deployment model for better resiliency
CloudStack Functional Layers
Pros & Cons Pros Cons • Easy for a small team to • Interdependency in these layers causes reliability problems. develop in – Contracts between layers cannot • be enforced since each layer Easy to deploy cannot be individually tested.
• Developer skill set must range from API design all the way to
system level programming to effectively code in CloudStack
• CloudStack availability and maintainability suffers because layers with different availability and maintainability requirements are deployed in one process.
Action Plan Service Purpose Cloud-Engine - Presents a data center abstraction layer - Orchestration within the data center abstraction layer - Provisioning of the physical resources - Directory for services and service end points Cloud-Access - Account and directory connectors - Authentication - ACL & Governess Cloud-API - End User API & UI Cloud-Management - Management of physical resources - Data Center automation - Admin UI
CloudStack Service Properties • Independent life cycle • Independent scaling • Independent testing • RPC through reliable message queue • Notification through event systems • Individual database (even further in the future)
Cloud-Engine vs Cloud-API Data Center Abstraction API Cloud API • Speaks in virtualization • Speaks in service contracts terms (CPU, RAM, etc) (service offerings, network • Callers can specify offerings, disk offerings) deployment destination • Callers can only specify down to the host deployment destination • Can be used to deploy through resource dedication service VMs (such as SSVM • Can only deploy user VMs and VR) • Contains business logic • Contains orchestration logic
A Possible Future
Automation, Orchestration, & Provisioning
What is the difference? • The key is the data center abstraction layer – Virtual Machine, Template, Nic, IP Address, Volume, Network, Rules, Snapshot • Orchestration orchestrates within this abstraction layer • Provisioning manifests concepts in abstraction layer on physical resources • Automation orchestrates above the data center abstraction layer to bring greater functionality
Examples • Orchestration – VM deploy, Volume creation, Network Creation, Network rules propagation • Provisioning – Starting a VM on a hypervisor – The actual movement of a volume from one storage pool to another • Automation – HA Process – Putting a resource into maintenance mode – Uploading and downloading templates – DR process
Why is this important? • Cloud-Engine is still too big. • Plugin partners need to clearly see the division in functionality between Cloud-Engine and their plugin. • Disaggregating CloudStack Services allow developers to quickly add services utilizing Cloud- Engine • Disaggregating Cloud-Engine allows partners to add more infrastructure to be utilized in the cloud.
Cloud-Engine Components Component Purpose Orchestration - Orchestration of the Data Center Abstraction Layer DeploymentPlanner - Plans the deployment destination for virtual machine and volumes Compute - Provisioning of the hypervisor NetworkGuru - Provides mapping of Network to physical network NetworkElement - Provides various network services PrimaryDataStore - Provisioning of storage ImageStore - Provisioning of templates BackingStore - Provisioning of backup storage SnapshotService - Provides volume snapshots MotionService - Provides data movements between various storage technologies
Cloud-Engine Component Properties • Recommended to have independent life cycles, databases, scaling, and testing. • Utilize CloudStack’s plugins to bridge provisioning needed by Cloud-Engine and functionality provided by the component. • All APIs must be asynchronous. • Operations are idempotent.
Changing CloudStack’s Deployment Model
CloudStack 4.0 Availability Zone 7 Region 2 Mgmt Server Region 1 Cluster MgmtServer Availability Cluster Zone 1 Data Center 2 Data Center 1 Availability Zone 2 Availability Zone 6 Availability Zone 4 Data Center 3 Availability Zone 5 Availability Zone 3 Data Center 5 Data Center 4
Pros & Cons Pros Cons • Simple deployment model • Management plane goes • Easy to track jobs down, the entire cloud is
not operable. •
No fault containment to the availability zone • Unable to do a zone by zone upgrade of CloudStack • Cannot guarantee zero downtime upgrades
New Deployment Model VM Users GSLB Data Center 1 Data Center n Cloud-API Cloud-API Cloud-API Cloud- Cloud- Access Acces Account CloudStack CloudStack Database Account Cloud-Engine Cloud-Engine Database Admin Admin Console Console Database Database
Scalability • Cloud-API nodes can be brought up and added to cluster to handle more requests • Cloud-Engine cluster and Cloud-API cluster are scaled independently – Cloud-Engine cluster to hardware resources – Cloud-API cluster to incoming requests
Availability • Cloud-API Servers can be deployed in geographically remote locations because they don’t share databases • One Cloud-API Server going down only impacts the tasks it is executing • Any number of Cloud-API Servers can be brought up • Cloud-Engine cluster going down means only one zone is down. Not the whole cloud. • Even if the entire Cloud-API cluster is down, admins can still manage VMs by directly connecting to the Cloud-Engine cluster.
Maintainability • Zones can be individually upgraded • Only the zone being upgraded cannot be provisioned • Cloud-API Servers can be brought up with new versions and then the old ones shutdown