[openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading
A, Keshava
keshava.a at hp.com
Thu Oct 30 09:45:11 UTC 2014
Hi,
Can the VM migration happens across POD (Zone) ?
If so then how reachability of VM is addressed dynamically without any packet loss ?
Thanks & Regards,
keshava
-----Original Message-----
From: Wuhongning [mailto:wuhongning at huawei.com]
Sent: Thursday, October 30, 2014 7:56 AM
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