OK,
You may  need to think of brining BGP routing between POD to support Live 
migration.


Thanks & Regards,
keshava

-----Original Message-----
From: joehuang [mailto:joehu...@huawei.com] 
Sent: Thursday, October 30, 2014 4:58 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack 
cascading

Hello, Keshava

Live migration is allowed inside one pod ( one cascaded OpenStack instance ), 
not support cross pods live migration yet. 

But cold migration could be done between pods, even cross data centers.

Live migration cross pods will be studied in the future.

Best Regards

Chaoyi Huang ( joehuang )

________________________________________
From: A, Keshava [keshav...@hp.com]
Sent: 30 October 2014 17:45
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack 
cascading

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:wuhongn...@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 [keshav...@hp.com]
Sent: Wednesday, October 29, 2014 2:22 PM
To: openstack-dev@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

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

Reply via email to