incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "haroon abdelrahman (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CLOUDSTACK-241) AWS Style Regions
Date Mon, 01 Oct 2012 23:33:08 GMT
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

Mime
View raw message