Here a list of new features in Cloudstack 4.1 from a presentation that Chip Chandler gave.
There are a few new features, but I though I would talk about AWS style regions:
Uhem.. AWS style regions you say? This is a BIG move. It's taking Cloudstack zones and adding a new layer on top. Well why would you want to do that? Cloudstack zones do not spread well geographically. In fact multiple Cloudstack zones are often deployed within a data center to work around the 4095 vlan limit by keep the vlans within a rack and using L3 routing to move to another rack. That is ok, but customers cannot easily route between zones (yet). Having regions will allow additional segregation, with one important new feature which is splitting up the Cloudstack management server, so each CSM will manage one region. This is perfect is your customers are spread geographically.
Here are the requirements around regions in Cloudstack:
• 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. The following operation allows for each CSM server to know about the other CSM in the other region:
Connect To Region
• The CS 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:
Create Region
Delete Region
List Regions
• Admin should be able to create multiple zones within a Region. Management server cluster manages all the zones within the region. Following Zone operations should be supported on per regions basis:
Create Zone
Delete Zone
List 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.
This is key. I create a user in AZ 1 and I want that user to be able to create a VM in AZ2 using the same credentials, api and secret key.
• Authentication credentials – username, password, keys – should be valid across all
regions
^ Oh, I just said that! ^
• Switching between Regions should not require the user to sign-on again (SSO should be supported).
• Resource management should be extended to Region level
• Available compute, storage, network (IPs, VLANs etc.) resources that are currently tracked
should be aggregated and displayed at region level
• Appropriate 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
This is important for billing purposes.
• 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.
As you can see, this really is a big change. How people will be able to upgrade will also be a big area of work. However this is way the product needs to move to ensure that it can keep delivering a top class service.
Here are a couple of links that you can look at to find out how the guys did it. This is why opensource is so great. No hiding, which means we can all get a better idea of how this beast will work
https://issues.apache.org/jira/browse/CLOUDSTACK-241
https://issues.apache.org/jira/browse/CLOUDSTACK-815
No comments:
Post a Comment