haroon abdelrahman created CLOUDSTACK-241:
---------------------------------------------
Summary: AWS Style Regions
Key: CLOUDSTACK-241
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-241
Project: CloudStack
Issue Type: New Feature
Reporter: haroon abdelrahman
Assignee: haroon abdelrahman
Regions
1 Background
Currently, CloudStack only supports Amazon style Availability zones (AZ). This
feature is to allow the CloudStack infrastructure hierarchy to support Amazon
style Regions. Regions provides the following benefits to customers:
• Higher availability of the services: users can deploy services across AZs and
even if one of the AZ goes down the services are still available to the
end-user through VMs deployed in other zones.
•Higher availability of the MS: Since MS only manages a single Region, if that
MS goes down, only that particular Region is impacted. Admin should be able to
access all the other Regions.
•Scalability: The scalability limit of CloudStack dramatically improves, as the
scalability limit of MS is limited to a single Region.
•Object Store: With Regions construct, CloudStack would also allow users to
define Object Store (Secondary Storage) across AZs. This helps users easily
deploy VMs in different AZs using the same template, offerings.
2Requirements
•Admin should be able to install a management server for a Region and then
connect to management servers in other Regions. Each Management Server in each
region should know about all other regions and their management servers.
oConnect To Region
•Admin should be able to create multiple Regions within a CloudStack cloud.
I.e., CloudStack should manage multiple regions within a cloud. The following
operations should be supported:
oCreate Region
oDelete Region
oList Regions
•Admin should be able to create multiple zones with a Region. Management server
cluster manages all the zones within the region. Following Zone operations
should be supported on per regions basis:
oCreate Zone
oDelete Zone
oList Zones
•Management Server cluster for each region should only control the
infrastructure within that region. In other words, if a management server
cluster fails, then only the region managed by that server cluster should be
inaccessible for admin and users. It should not have any impact on the other
Regions in the cloud
•Each Region should have access to an object store. The object store should be
common to all Zones within the Region. I.e., any object stored from a Zone
should be visible across all the other zones within the region
•EIP function should be available across both basic and advance Zones within a
Region
•ELB function should be available across both basic and advance Zones within a
Region
•The administrative hierarchy (Users, Accounts, Domains, Projects) - should be
valid across all the regions. I.e., if admins create domains, accounts and
users etc. in one region it should be reflected in other regions as well.
•Authentication credentials – username, password, keys – should be valid across
all regions
•Switching between Regions should not require the user to sign-on again (SSO
should be supported).
•Resource management should be extended to Region level
oAvailable compute, storage, network (IPs, VLANs etc.) resources that are
currently tracked should be aggregated and displayed at region level
oAppropriate global parameters should be available at Region level while the
remaining would be available at Zone level
•Usage: All the (per account) usage records should be aggregated to Regions
level
•Global Configurations: All of the administrative hierarchy (Domains, Accounts,
Users, Projects) related Global Configurations should have consistent values
across all regions and has to be propagated when a user modifies a
configuration on one of the regions.
•Each region should maintain a list of all other regions and their region
endpoints.
Note:
•Users are required to deploy all the MSs of a particular region in one zone
3UI / UX Requirements
•User/Admin should be able to view all Regions by logging into a MS of any of
the Regions. User then should be able to select a specific Region to view
details of that Region.
oReports on the dashboard should be aggregated to Region level
•On first UI access, user should be able to connect to another Cloudstack
instance or treat this instance as the first region
•Modify the start-up wizard to force users define the Region (Region Name,
Description, etc) before they start creating the Availability Zones
•Users should be able to switch between various regions for UI using SSO.
4Upgrade Scenarios
Following upgrade scenarios should be supported:
•Multiple Zones to Multiple Regions: Current deployments with multiple Zones
should be able to move to a deployment of multiple Regions. Admins should be
able to map one or more zones to a Region
•All AZs in each Region should get access to all secondary storage from each
region
•Multiple Zones to Region: Current deployments with multiple Zones should be
able to move to a deployment of single Region (this is a subset of the above
requirement)
oThis should be default upgrade behavior
5Non-Requirements
•Management Server limited to per Zone is not a requirement for Campo. This
functionality could be added in a subsequent release
•EIP and ELB functions across zones are only supported when both zones are
either basic or advance. It is not required to support EIP or ELB across basic
and advanced zones
•It is not required to display a dashboard/reports that are aggregated across
Regions
6Open Items:
•How will the hierarchy change with the requirement of supporting both a Basic
Zone and an Advanced Zone within a single Cloudstack instance?
•Assuming we don’t need the capability / APIs to disconnect Management server
from one set and connect to another set of management servers
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
