AWS-Style Regions Functional Spec

Bug Reference

CLOUDSTACK-241

Branch

regions

https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=shortlog;h=refs/heads/regions

Introduction

Purpose

The objective of this feature is to add AWS EC2 like Regions implementation into CloudStack.  Regions are dispersed and located in separate geographic areas. Availability Zones(or Zones in CloudStack) are distinct locations within a Region that are engineered to be isolated from failures in other Zones and provide inexpensive, low latency network connectivity to other Zones in the same Region

Regions would provide the following benefits:

• 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 each MS Cluster only manages a single Region, if that MS Cluster 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 Cluster 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.  
• Geographical Grouping: Regions allow admins to group AZs (that have low latency and are geographically located nearby) into a broader region construct.

References

Requirements Doc: Regions requirements

Document History

Glossary

Feature Specifications

Introduce the notion of Regions, which will be managed independently by a separate management servers.  With Regions, infrastructure will be organized as follows:

Region -> Zone -> Pod -> Cluster

 Accounts

 User Accounts will be available across Regions. User should be able to use the same account in all Regions. Switching between Regions should not require the user to sign-on again

Templates

 CS Templates are currently zone specific. Templates should be available to all zones within a region. User should be able to migrate templates from one Region to another. This requires S3 like object store

Snapshots

Snapshots also should be available to all zones within a Region. CS currently stores snapshots in secondary storage. Snapshots should instead be stored in the object-store

S3 like Object-store/Integration

Current secondary storage is at zone level. S3 like is object-store or integration with other object-stores(like Hadoop) is required to move data across Regions. Each Region should have object store and the data within it should be available to all zones within the region. Utility to move data across Regions should be supported. Templates and Snapshots will be stored in this object store. Requirements for  S3 based secondary storage.  This is tracked in ticket CLOUDSTACK-714 separately

ELB

ELB will be elevated to Region level. Jira ticket CLOUDSTACK-653

EIP

EIP enhancements CLOUDSTACK-652

Authentication Service

 An authentication service will available for components like object-store to authenticate and get account information using getUser API

Assumptions

Object Store: This feature assumes that S3 like object store is available. Either implemented in CloudStack or through integrations

Templates, Snapshots, EIP and ELP work is not part of this spec. There are being tracked separately as per JIRA tickets mentioned above.

Usage

Usage records will be generated by each Region separately. Portal layer above CS should combine usage across Regions into a consolidated invoice.

Use cases

1. Create Account

   Create Account A1 in Region1 (Region Id 1). Publish account creation event. Source Region Id for A1 will be 1. External Id(UUID) for the Account should be same in all Regions. Account DB Ids could be different for each Region. 

2. Update Account (update/disable/enable Account)

   Account update actions are forwarded to the source Region. After source Region is successfully updated, account update event is published. Account update fails if the source Region cannot be updated or is unavailable. 

3. Delete Account

   Delete Account is forwarded to the source Region. After account is successfully  deleted in the source Region, delete event is published. Account delete fails if the delete in source Region fails or is unavailable. 
4. Login to Region A and move to Region B without providing credentialsSimilarly for users and domains.

Architecture and Design description

Database

Each Region will have a separate database. Below data will be common to all databases across Regions:

1. Account
2. User
3. Domain

Remaining data is expected to be per-Region(including projects, global config, resource limits) and not shared across databases in other Regions. 

New Tables

Changes to existing tables

Data synchronization

Accounts:

• When creating the account, it is created first in the Region that the user is logged into
• Account table will include region_id column, indicating the Region that it is created from
• This Region publishes account creation event
• Account deletion/modification is always forwarded to the Region that originally created the account 
• Admin user api_key/secret_key are used to make API calls to peer regions. api_key/secret_key are provided while adding the Region.

The same applies for Domains and Users.

Create: For any resource created in Region A, MS is Region A  will publish an event along with external Id of the resource.

Update/Remove: Request is forwarded to the source region.

Event framework

Events are published using the event framework. Cloud operator is expected to implement consumers for these events and apply the changes in the peer regions.

Authentication

Once logged in User should be able to switch from one Region to another without providing credentials again

web services APIs

New APIs

addRegion

Registers a region into another region

Parameters

1. id: (int) Region Id 
2. name: (String) Name of the Region
3. endpoint: (String) Region end point. e.g. http://10.147.30.11:8080/client 
4. userapikey: (String)API key of the Admin user
5. usersecretkey: (String)Secret key of Admin user

Admin user api_key/secret_key are used to make sync API calls to peer regions.

updateRegion

Updates region details

Parameters

1. id: (int)Region Id
2. name: (String)Name of the Region
3. endpoint: (String)Region end point. e.g. https://10.147.30.11:8080/client
4. userapikey: (String)API key of the Admin user
5. usersecretkey: (String)Secret key of Admin user

removeRegion

Removes region from current region.

Parameters

1. id: (int)id of the Region to  be removed

listRegions

list all Regions. Can be filtered by id or name

Parameters

1. id: list by Region Id
2. name: (String)list by Region Name

getUser

Admin only API. Get user details by api_key. 

Parameters 

1. userapikey: (String)Get user details by API key 

Changes to existing APIs

• createAccount 
  1. New parameters
     1. accountid : UUID of the account
     2. userid: UUID for the User
     3. regionid: Id of the source Region where Account creation request was initiated
• createUser
  1. userid: UUID for the User. 
  2. regionid: Id of the source Region where User creation request was initiated
• createDomain
  • New parameters
    • domainid: UUID for the Domain
    • regionid: Id of the source Region where Domain creation request was initiated

Limitations

1. Since all update/delete operations are forwarded to the source region (i.e the region where the resource was initially created), if the source region is down, these operations will fail

Upgrade

During upgrade, flexibility will be provided to move existing zones into any Region.

Upgrade scenarios:

• Each zone becomes part of a separate Region: Copy existing DB to all Regions and disable all zones except one in each Region.
  • Upgrade existing MS to 4.1. This MS will become region 1
  • Disable all the zones in region 1
  • Dump region 1 DB
    • mysqldump -u cloud -p -h <region1_db_host> cloud  > region1.sql
  • Install 4.1 MS in the remaining Regions
    • Set the region_id while installing the DB
    • cloud-setup-databases cloud:<dbpassword>@localhost --deploy-as=root:<password> -e <encryption_type> -m <management_server_key> -k <database_key> -r <region_id>
  • Copy region 1 DB to other regions
    • mysql -u cloud -p -h <region2_db_host> cloud < region1.sql
  • Start all management servers. At this point all the zones are disabled
  • Selectively enable zones in the required regions
• All zones remain in the same Region: Nothing to do here. 
• Zones are divided among Regions:  Copy existing DB to all regions and disabling the zones in all Regions other than the selected Region
• First Region Id will become the source Region Id for all Account/User/Domain resources 

Scripts

Offline scripts will be provided to move data across regions to ease

• upgrade 
• add new region
• remove region

UI flow

• 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.
• Users should be able to switch between various regions for UI using Single Sign-On.

Sample Workflow

Single Region

If an environment has only 1 region, functionality will be same as the current CS installation.  Id of this region will be 1. All accounts/users/domains will have region_id as 1

Adding 2nd Region

1. Install a 2nd CS instance.

2. While installing database set region_id using -r option in cloud-setup-databases script.

cloud-setup-databases cloud:<dbpassword>@localhost --deploy-as=root:<password> -e <encryption_type> -m <management_server_key> -k <database_key> -r <region_id>

3. Start mgmt server

4. Using addRegion API, add region 1 to region 2 and also region 2 to region 1.

5. copy account/user/domain tables from Region1 DB to Region2 DB:

• mysqldump -u cloud -p -h <region1_db_host> cloud account user domain > region1.sql
• mysql -u cloud -p -h <region2_db_host> cloud < region1.sql      

Adding 3rd and subsequent Regions

1. Install CS in all new regions

2. While installing database set region_id using -r option in cloud-setup-databases script.

cloud-setup-databases cloud:<dbpassword>@localhost --deploy-as=root:<password> -e <encryption_type> -m <management_server_key> -k <database_key> -r <region_id>

3. Start mgmt server

4. Using addRegion API, add existing regions to region n and also region n to all existing regions

5. copy account/user/domain tables from any existing Region DB to RegionN DB. 

• mysqldump -u cloud -p -h <region1_db_host> cloud account user domain > region1.sql
• mysql -u cloud -p -h <regionN_db_host> cloud < region1.sql  

Remove Region

1. Ownership of all the resource created in the region being removed(say Region 3) should change to another region. Set region_id =1 (or one of the other regions) for account/user/doman tables where region_id = 3

    Below steps need to be repeated in all regions.

• mysql> update account set region_id = 1 where region_id = <id_of_region_being_removed>;
• mysql> update user set region_id = 1 where region_id = <id_of_region_being_removed>;
• mysql> update domain set region_id = 1 where region_id = <id_of_region_being_removed>;

2. Remove region from all other regions using removeRegion API

Appendix

Appendix A:

Appendix B: