Open Stack

Hello,

As what we discussed in the yesterday’s meeting, the contradict is how to scale out cascade services.


1)      In PoC, one proxy node will only forward to one bottom openstack, the proxy node will be added to a regarding AZ, and multiple proxy nodes for one bottom OpenStack is feasible by adding more proxy nodes into this AZ, and the proxy node will be scheduled like usual.



Is this perfect? No. Because the VM’s host attribute is binding to a specific proxy node, therefore, these multiple proxy nodes can’t work in cluster mode, and each proxy node has to be backup by one slave node.



2)      The fake node introduced in the cascade service.

Because fanout rpc call for Neutron API is assumed, then no multiple fake nodes for one bottom openstack is allowed.

And because the traffic to one bottom OpenStack is un-predictable, and move these fake nodes dynamically among cascade service is very complicated, therefore we can’t deploy multiple fake nodes in one cascade service.

At last, we have to deploy one fake node one cascade service.

And one cascade service one bottom openstack will limit the burst traffic to one cascade openstack.

And you have to backup the cascade service.



3)      From the beginning, I prefer to run multiple cascade service in parallel, and all of them work in load balance cluster mode.
API of (Nova, Cinder, Neutron… ) calling cascade service through RPC, and the RPC call will be only forwarded to one of the cascade service ( just put the RPC to message bus queue, and if one of the cascade service pick up the message, the message will be remove from the queue, and will not be consumed by other cascade service ). When the cascade service received a message, will start a task to execute the request. If multiple bottom openstacks will be involved, for example, networking, then the networking request will be forwarded to regarding multiple bottom openstack where there is resources (VM, floating IP)  resides ).

To keep the correct order of operations, all tasks will store necessary data in DB to prevent the operation be broken for single site. (if a VM is creating, reboot is not allowed, such kind of use cases has already been done on API of (Nova.Cinder,Neutron,…) side )

Through this way, we can dynamically add cascade service node, and balance the  traffic dynamically.


Best Regards
Chaoyi Huang ( Joe Huang )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150827/d4006f5d/attachment.html>