Cloudstack Japan - cloudstack, the best kept secret in the cloud
CloudStack Collaboration Conference 12; Refactoring cloud stack
-
Upload
buildacloud -
Category
Technology
-
view
1.350 -
download
2
description
Transcript of CloudStack Collaboration Conference 12; Refactoring cloud stack
![Page 1: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/1.jpg)
Apache CloudStackEvolution Proposal
Alex Huang
Software Architect, Citrix Systems
![Page 2: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/2.jpg)
A little bit about me
• Cloud.Com Founding Engineer• Software architect for CloudPlatform• Responsible for overall architecture,
performance, and scalability• Committer and PPMC member• BS from UC Berkeley and MS from Stanford
![Page 3: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/3.jpg)
Design Goals
• Make it easier for developers to get started• Allow developers with different skill sets to work on different
parts of CloudStack• Give service provider 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• Contain fault within a zone• Allow for zero downtime upgrades• Testability of different components
![Page 4: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/4.jpg)
Action Plan
• Disaggregate CloudStack services• Disaggregate CloudStack Orchestration (Cloud-
Engine)• Switch to using well-known frameworks• Allow better composition at the resource layer• Change the deployment model for better
resiliency
![Page 5: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/5.jpg)
Disaggregating CloudStack
![Page 6: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/6.jpg)
CloudStack Functional Layers
Presentation
Hardware Resource Management
Virtual Resource Management
End User Services
Data Center Abstraction Layer
OAMP API End User API AWS API S3 API
Accounts/ACL Policies Offerings Templates Console ProxyDomains &
Projects
HA UsageStatistics
Collection Alerts VM Sync
Orchestration Deployment Planning
Templates SDN Snapshots
StoragePools
HypervisorClusters
L2/L3Networks
NetworkServices
ObjectStorage
Configuration / Mappings
![Page 7: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/7.jpg)
Pros & Cons
Pros• Easy for a small team to
develop in• Easy to deploy
Cons• Interdependency in these layers
causes reliability problems.– Contracts between layers cannot be
enforced since each layer 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.
![Page 8: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/8.jpg)
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
![Page 9: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/9.jpg)
CloudStack Service Properties
• Independent life cycle• Independent scaling• Independent testing• REST-ful properties• Notification through event systems• Individual database (even further in the
future)
![Page 10: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/10.jpg)
Cloud-Engine vs Cloud-API
Data Center Abstraction API• Speaks in virtualization
terms (CPU, RAM, etc)• Callers can specify
deployment scope down to the host
• Can be used to deploy service VMs (such as SSVM and VR)
• Contains orchestration logic
Cloud API• Speaks in service contracts
(service offerings, network offerings, disk offerings)
• Callers can only specify deployment destination through resource dedication
• Can only deploy user VMs• Contains business logic
![Page 11: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/11.jpg)
A Possible Future
Cloud-Engine
UsageService
End User VM Mgmt
Service
Stats Collection
Service
Resource Mgmt
Service
HA/DRService
ACL/Account Service
AWS APIService
Console Proxy
Service
Notification System
Data Export/Import
Service
PolicyMonitoring
Service
End User Facing Services
Cust
omer
Car
e Se
rvic
es
System Adm
inistrator Services
![Page 12: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/12.jpg)
Disaggregating CloudStack Orchestration or Cloud-Engine
![Page 13: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/13.jpg)
Why is this important?
• 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.
![Page 14: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/14.jpg)
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
![Page 15: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/15.jpg)
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.
![Page 16: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/16.jpg)
Cloud-Engine Components
Network Subsystem
BackupServices
StorageSubsystem
ComputeSubsystem
Network Service
Providers
TemplateMgmt
Deployment Planning
Data Center Abstraction
API
SnapshotServices
Event Bus Database
Physical Network Elements
Hypervisors Object Store
Storage (iSCSI, FC, NFS, Local,
etc)
SDN
Notification System
External Event
System
![Page 17: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/17.jpg)
Changing CloudStack’s Deployment Model
![Page 18: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/18.jpg)
CloudStack 4.0
Region 1 MgmtServer
ClusterAvailability Zone 1
Region 2 Mgmt Server Cluster
Availability Zone 4
Availability Zone 5 Availability
Zone 3
Availability Zone 2
Data Center 1
Data Center 2
Data Center 5
Data Center 3
Data Center 4
Availability Zone 6
Availability Zone 7
![Page 19: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/19.jpg)
Pros & Cons
Pros• Simple deployment model• Easy to track jobs
Cons• Management plane goes
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
![Page 20: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/20.jpg)
Data Center nData Center 1
New Deployment Model
Cloud-Engine
Cloud-API
Cloud-Access
Cloud-Engine
Cloud-API Cloud-API
Database Database
Cloud-Access
AccountDatabase
AccountDatabase
GSLB
VM Users
Admin Console Admin
Console
DB Sync
Service ProviderDatabase
![Page 21: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/21.jpg)
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 scaled to hardware resources– Cloud-API cluster scaled to incoming requests
![Page 22: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/22.jpg)
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.
![Page 23: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/23.jpg)
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
![Page 24: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/24.jpg)
Use Cases
![Page 25: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/25.jpg)
Data Center 2
Cloud-Engine(Cloud)
Data Center nData Center 1
One Infrastructure Multiple Workloads
Cloud-EngineTraditional
Cloud-API(Traditional)
Cloud-Engine(Cloud +
Traditional)
Cloud-API(Cloud)
Cloud-API(Traditional)
GSLB
Traditional VM Users
Cloud VM Users
![Page 26: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/26.jpg)
Data Center 2
Cloud-Engine(Dedicated to Customer A)
Data Center nData Center 1
Dedicated Entry Points
Cloud-Engine
Cloud-API
Cloud-Engine
Cloud-APICloud-API
(Dedicated )
GSLB
General VM Users
Customer A
![Page 27: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/27.jpg)
Data Center 1
Cloud-Engine
Data Center nCustomer Data Center
Hybrid Clouds
Cloud-Engine
Cloud-API
Cloud-Engine
Cloud-APICloud-API
(Dedicated )
GSLB
General VM Users Customer
A
Cloud-API
![Page 28: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/28.jpg)
Milestones
• 12/31– New cloud-engine server and deploy VM
• Alex Huang & Prachi
– New Storage rearchitecture• Edison
– New IPC mechanism• Kelven
• 1/31– Completely switched out cloud-api and cloud-management
• Alex Huang, Rohit
– Network refactoring• Chiradeep
– API Refactoring• Fang, Likitha, Min, Rohit
• 4.2– ACL
• Prachi
![Page 29: CloudStack Collaboration Conference 12; Refactoring cloud stack](https://reader036.fdocuments.us/reader036/viewer/2022070301/546257ebb1af9f936c8b4f4d/html5/thumbnails/29.jpg)
The future needs you!
Project web site: http://incubator.apache.org/projects/cloudstack.html
Mailing lists: [email protected] [email protected]
IRC: #CloudStack on irc.freenode.net