Difference between revisions of "OpenStack cascading solution"
Chaoyi Huang (talk | contribs) |
Chaoyi Huang (talk | contribs) |
||
Line 34: | Line 34: | ||
For detailed architecture design, please refer to following links. | For detailed architecture design, please refer to following links. | ||
+ | <br /> | ||
Please leave your comments in the Google Doc or send mail to PoC team member ( Listed in PoC team section) . | Please leave your comments in the Google Doc or send mail to PoC team member ( Listed in PoC team section) . | ||
Line 39: | Line 40: | ||
* Slide Share: [http://www.slideshare.net/JoeHuang7/building-large-scale-cloud-with-openstack-cascading Building large scale cloud with OpenStack cascading] | * Slide Share: [http://www.slideshare.net/JoeHuang7/building-large-scale-cloud-with-openstack-cascading Building large scale cloud with OpenStack cascading] | ||
+ | <br /> | ||
The OpenStack cascading includes cascading of Nova, Cinder, Neutron, Glance and Ceilometer. KeyStone will be global service shared by cascading and cascaded OpenStacks, and Heat will consume cascading OpenStack API. Therefore no cascading is required for KeyStone and Heat. | The OpenStack cascading includes cascading of Nova, Cinder, Neutron, Glance and Ceilometer. KeyStone will be global service shared by cascading and cascaded OpenStacks, and Heat will consume cascading OpenStack API. Therefore no cascading is required for KeyStone and Heat. | ||
Revision as of 06:56, 25 July 2014
Contents
Overview
OpenStack cascading solution is designed for large scale distributed cloud, for example, a cloud with million level VMs in several data centers.
OpenStack cascading mainly concentrate on API aggregation, merging multiple child OpenStacks to work as a single Openstack in the tenant access API interface(Nova/Cinder/Neutron/Glance/Ceilometer API). For tenants, it is a single region, and multiple child OpenStacks are not visible which had already been aggregated and hidden by the parent OpenStack. The tenant can see multiple "available zones", and each child OpenStack exactly work internally as Amazon like availability zone.
- The parent OpenStack expose standard OpenStack API
- The parent OpenStack manage many child OpenStacks by using standard OpenStack API
- Each child OpenStack functions as a Amazon like available zone and is hidden by the parent OpenStack
- Cascading OpenStack: the parent OpenStack, providing API and scheduling and orchestration of Cascaded OpenStacks
- Cascaded OpenStack: the child OpenStack, provisioning the VM, Volume and virtual Networking resources
Challenges when building large scale cloud
To build large scale OpenStack based cloud, for example, the cloud includes 1 million VMs or 100k hosts. There are big challenges
Naturally, there are two ways to do that:
1. scale up a single monolithic OpenStack region, but
- It’s a big challenge for a single OpenStack to manage scale for example 1 million VMs or 100K hosts.
- Can not obtain real fault isolation area like EC2’s available zone, all of the cloud are tighten up into one OpenStack because of shareing RPC message bus and database.
- Single huge monolithic system bring high risk with OAM & trouble shooting, and big challenge for even the most skilled Op team to handle SW rolling upgrade and configuration changes, etc.
- Difficult for heterogeneous vendor’s infrastructure integration, multi-vendor's infrastructure co-existence is high demand for large scale cloud
2. setup hundreds of OpenStack Regions with discrete API endpoint, but
- Have to buy or develop his own cloud management platform to integrate the discrete cloud into one cloud, and also, OpenStack API ecosystem is lost.
- Or, leave customer with splitted resource island without any association…
Architecture of OpenStack cascading
For detailed architecture design, please refer to following links.
Please leave your comments in the Google Doc or send mail to PoC team member ( Listed in PoC team section) .
- Google Doc: Building large scale cloud with OpenStack cascading
- Slide Share: Building large scale cloud with OpenStack cascading
The OpenStack cascading includes cascading of Nova, Cinder, Neutron, Glance and Ceilometer. KeyStone will be global service shared by cascading and cascaded OpenStacks, and Heat will consume cascading OpenStack API. Therefore no cascading is required for KeyStone and Heat.
- Nova-Proxy: Transfer the VM operation to cascaded Nova. Also responsible for attach volume and network to the VM in the cascaded OpenStack.
- Cinder-Proxy: Transfer the volume operation to cascaded Cinder.
- L2-Proxy: Finish L2-networking in the cascaded OpenStack, including cross OpenStack networking.
- L3-Proxy: Finish L3-networking in the cascaded OpenStack, including cross OpenStack networking.
- FW-Proxy: implementation not started
- LB-Proxy: implementation not started
- VPN-Proxy: implementation not started
- Sync-Manager: Synchronize image among the cascading and policy determined Cascaded OpenStacks
- Ceilometer-Proxy: Transfer the request to destined Ceilometer or collect information from several Ceilometer. Implementation not started
Advantage of the architecture
[tbd]
Use Case
- Use Case 1:
The cloud admin wants to provide one cloud to tenants with one OpenStack api. The cloud is very large scale, and the cloud will include resources distributed in multiple data centers. The cloud will grow with capacity expansion gradually, to avoid vendor-lock in, multiple vendors to build the cloud is also required.
- Use Case 2:
The cloud admin wants to provide one cloud to tenants with one OpenStack api. The cloud is very large scale, and the cloud will be one standalone region in one big data center. The cloud will grow with capacity expansion gradually, to avoid vendor-lock in, multiple vendors to build the cloud is also required.
Blueprints
To start an incubation project or register blueprint under different project with one umbrella blueprint, it's a tough decision. None of current contribution methodology can work for OpenStack cascading: many projects like Nova/Cinder/Neutron/Glance/Ceilometer are involved, they work together to make cascading work. After the OpenStack cascading is introduced, the CI is quite different from the current single OpenStack instance CI environment, the CI enrionment for OpenStack cascading needs at least one cascading OpenStack and two cascaded OpenStack.
Your comments are welcome.
The blueprints are:
[tbd]
Proof of Concept
The PoC team welcome discussion on any topic of OpenStack cascading solution. Please send mail to all PoC team member for any topic.
Member | Role | |
---|---|---|
Chaoyi Huang | joehuang@huawei.com | inventor, designer of Nova/Cinder/Glance cascading, code reviewer |
Hongning Wu | wuhongning@huawei.com | inventor, designer of Neutron cascading, code reviewer |
Fan Qin | qinfan@huawei.com | developer of Nova cascading |
Chi Zhang | z.zhangchi@huawei.com | developer of Cinder cascading |
Haojie Jia | jiahaojie@huawei.com | developer of Neutron cascading |
Dong Jia | jiadong.jia@huawei.com | developer of Glance cascading |
Hands on lab
coming soon, hopefully in August, 2014
[tbd]
Source Code Repository
coming soon, the source code will be available from Github, hopefully in August, 2014
[tbd]
CI Environment
Ask for help. Warmly welcome CI guru to help build the CI environment for OpenStack cascading solution.
How to Play
Your comments are welcome. [tbd]
Mail-list
The OpenStack cascading solution PoC team has no special mail-list currently. You can also use OpenStack dev list to reach us, please include [openstack-dev] [cascading] in the mail title.
Meetings
[tbd]
Technology Hub
- Blog of Joe Huang: https://www.linkedin.com/today/author/23841540
- more info here [tbd]
Last update
July 23, 2014