[
https://issues.apache.org/jira/browse/CLOUDSTACK-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haroon abdelrahman reassigned CLOUDSTACK-241:
---------------------------------------------
Assignee: Kishan Kavala (was: haroon abdelrahman)
> AWS Style Regions
> -----------------
>
> Key: CLOUDSTACK-241
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-241
> Project: CloudStack
> Issue Type: New Feature
> Affects Versions: 4.1.0
> Reporter: haroon abdelrahman
> Assignee: Kishan Kavala
>
> 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
