[openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

joehuang joehuang at huawei.com
Thu Oct 30 05:36:57 UTC 2014


Hello, Keshava,

Wu described the simplified pictures of cascading as following, if you attend Paris summit, you can join the cross-project design summit session "approached for scaling out", cascading will also be discussed in this session, we can have f2f talk in more detail.

Best Regards

Chaoyi Hunag ( joehuang )
________________________________________
From: Wuhongning [wuhongning at huawei.com]
Sent: 30 October 2014 10:25
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

Hi keshava,

Thanks for interested in Cascading. Here are some very simple explanation:

Basically Datacenter is not in the 2-level tree of cascading. We use term "POD" to represent a cascaded child openstack (same meaning of your term Zone?). There may be single or multiple PODs in one Datacenter, Just like below:

(A, B, C)  ...  (D, E)  ...  (F)  ...   (G)
Each character represent a POD or child openstack, while parenthesis represent a Datacenter.

Each POD has a corresponding virtual host node in the parent openstack, so when scheduler of any projects (nova/neutron/cinder...) locate a host node, the resource POD is determined, also with its geo-located Datacenter by side effect. Cascading don't schedule by Datacenter directly, DC is just an attribute of POD (for example we can configure host aggregate to identify a DC with multiple PODs). The upper scale of POD is fixed, maybe several hundreds, so a super large DC with tens of thousands servers could be built by modularized PODs, avoiding the difficult of tuning and maintaining such a huge monolithic openstack.

Next do you mean networking reachability? Sorry for the limitation of mail post I can just give some very simple idea: in parent openstack the L2pop and DVR is used, so L2/L3 agent-proxy in each virtual host node can get all the vm reachability information of other POD, then they are set to local POD by Neutron REST API. However, cascading depends on some feature not exists yet in current Neutron, like L2GW, pluggable external network, WE Fwaas in DVR, centralized FIP in DVR... so we have to do some little patch in the front. In the future if these features is merged, these patch code can be removed.

Indeed Neutron is the most challenge part of cascading, without considering those proxies in the parent openstack virtual host node, Neutron patchs account for 85% or more LOC in the whole project.

Regards,
Wu
________________________________________
From: keshava [keshava.a at hp.com]
Sent: Wednesday, October 29, 2014 2:22 PM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by     OpenStack cascading

This is very interesting problem to solve.
I am curious to know how the reachability is provided across different
Datacenter.
How to know which VM is part of which Datacenter?
VM may be in different Zone but under same DC or in different DC itself.

How this problem is solved?


thanks & regards,
keshava



--
View this message in context: http://openstack.10931.n7.nabble.com/all-tc-Multi-clouds-integration-by-OpenStack-cascading-tp54115p56323.html
Sent from the Developer mailing list archive at Nabble.com.

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


More information about the OpenStack-dev mailing list