Page History

Bug Reference

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:

...

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-in again

...

Create Account
1. Create Account in the external provisioning system with unique Id
2. Using CS API create account in all regions using the unique Id created in step1 as UUID. CreateAccount API takes UUID as an optional parameter. When UUID is provided, CloudStack does not generate a UUID and instead will use external ID.
3. External Id(UUID) for the Account should be same in all Regions. Account DB Ids could be different for each Region.
Update Account (update/disable/enable Account)
1. Update account in external provisioning system
2. Update account in all regions via API.
Delete Account
1. Delete account in external provisioning system
2. Delete account in all regions via API

Similarly 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:

Account
User
Domain

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

...

Events are published using the event framework.

Authentication

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

web services APIs

New APIs

...

userapikey: (String)Get user details by API key

Changes to existing APIs

createAccount *# New parameters
1. *## accountid : UUID of the account
  1. userid: UUID for the User
createUser
- New parameter
  - UUID for the User.

...

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

...

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

Default local region will be added with name "Local" and end_point "http://localhost:8080/client". Use updateRegion API to set a different name or end_point for this region

Adding 2nd Region

1. Install a 2nd CS instance.

2. While installing database set region_id using -r option in cloud-setup-databases script (Make sure database_key is same across all regions).

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.

...

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

6. Remove project accounts after copying:

mysql> delete from account where type = 5;

7. Set default zone as null

mysql> update account set default_zone_id = null;

8. Restart mgmt servers in region 2

...

2. While installing database set region_id using -r option in cloud-setup-databases script (Make sure _database_key _is same across all regions).

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

...

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