<div dir="ltr">Hi Joe,<div><br></div><div>I think you misunderstood what Eran proposed.</div><div><br></div><div>Eran proposed a "single service/multi-fake-node" scheme not only to enforce state-sync (as what ZK usually is used for), but also the execution <b><font size="4">order</font></b></div><div><b><font size="4"><br></font></b></div><div><font>It means that even if we implement like what PoC did: multiple-services/one service per bottom node, we still need another upper layer that provide an ordered view of those cascade services.</font></div><div><font><br></font></div><div><font>I think what Eran proposed is that, to make Tricircle as an independent service like we envisioned. Therefore Tricircle only represent one cascade service, which present an state-synced/order-preserved bottom OpenStack instances to the Top, via one set of API or RPC Call interfaces. </font></div><div><font><br></font></div><div><font>When you deploy Tricircle, like any other OpenStack services, you implement multiple necessary process. Fake nodes would be spawn like any other processes, and there is avialable techniques to make these fake nodes synced/ordered, in a active/passive. These are ,as Eran mentioned, implementation details. </font></div><div><font><br></font></div><div><font>In essence, fake nodes is just like those multiple cascade services running in parallel in PoC design. However in order to make Tricircle more like an OpenStack standard service, and better cooperation with Mistral on task order, it would be a good idea to let Tricircle provide an abstract interface all together at the top, and running fake node processes inside.</font></div><div><font><br></font></div><div><font>My 2 cents, not sure if I got it all right :)</font></div><div><font><br></font></div><div><font><br></font></div><div><font><br></font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 29, 2015 at 9:42 AM, joehuang <span dir="ltr"><<a href="mailto:joehuang@huawei.com" target="_blank">joehuang@huawei.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="ZH-CN" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi,
<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">I think you may have some misunderstanding on the PoC design. (the proxy node only to listen the RPC to compute-node/cinder-volume/L2/L3 agent…)<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p style="margin-left:18.0pt">
<u></u><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>1)<span style="font:7.0pt "Times New Roman"">     
</span></span></span><u></u><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">The cascading layer including the proxy nodes are assumed running in VMs but not in physical servers (you can do that). Even in CJK intercloud
 ( China, Japan, Korea ) intercloud, the cascading layer including API,messagebus, DB, proxy nodes are running in VMs<u></u><u></u></span></p>
<p style="margin-left:18.0pt;text-indent:0cm"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p style="margin-left:18.0pt">
<u></u><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>2)<span style="font:7.0pt "Times New Roman"">     
</span></span></span><u></u><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">For proxy nodes running in VMs, it's not strange that  multiple proxy nodes running over one physical server. And if the load of one
 proxy nodes increased, it’s easy to move VM from one physical server to another, this is quite mature technology and easy to monitor, to deal with. And most of virtualization also support hot scale-up for one virtual machine.<u></u><u></u></span></p>
<p><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p style="margin-left:18.0pt">
<u></u><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>3)<span style="font:7.0pt "Times New Roman"">     
</span></span></span><u></u><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">It's already in some scenario that the ZooKeeper is used to manage the proxy node role and membership. And backup node will take over
 the responsibility of the failed node.<u></u><u></u></span></p>
<p><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">So I did not see that “fake node” mode will bring extra benefit. On the other hand, the “fake node” add additional complexity:<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">1 ) the complexity of the code in cascade service, to implement the RPC to scheduler and the RPC to compute node/cinder volume.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">2 ) how to judge the load of a “fake node”.  If all “fake-nodes” will run flatly(no special process or thread, just a symbol) in the same process,
 then how can you judge the load of a “fake node”, by message number ? but message number does not imply the  load. The load is often measured through CPU utilization / memory occupy, so how to calculate the load for each “fake node” and then make decision
 to move which nodes to other physical server? How to manage this “fake-node” in Zookeeper like cluster ware. You may want to make fake-node run in different process or thread space, then you need to manage “fake-node” and process/thread relationship.
<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">I admit that the proposal 3 is much more complex to make it work for the flexible load balance. We have to record relative stamp for each message
 in the queue, pick the message from message bus, and put the message into task queue for each site in DB, then execute this task in order.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">As what has been described above that the proposal 2 does not bring extra benefit, and if we don’t want to strive for the 3^rd direction,
 we’d better fallback to the proposal 1. <u></u><u></u></span></p><span class="">
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal" style="text-align:justify;text-justify:inter-ideograph"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">Best Regards<u></u><u></u></span></p>
<p class="MsoNormal" style="text-align:justify;text-justify:inter-ideograph"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">Chaoyi Huang ( Joe Huang )</span><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
</span><div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> <a href="mailto:eran@gampel.co.il" target="_blank">eran@gampel.co.il</a> [mailto:<a href="mailto:eran@gampel.co.il" target="_blank">eran@gampel.co.il</a>]
<b>On Behalf Of </b>Eran Gampel<br>
<b>Sent:</b> Thursday, August 27, 2015 7:07 PM<br>
<b>To:</b> joehuang; Irena Berezovsky; Eshed Gal-Or; Ayal Baron; OpenStack Development Mailing List (not for usage questions); caizhiyuan (A); Saggi Mizrahi; Orran Krieger; Gal Sagie; Orran Krieger; Zhipeng Huang<br>
<b>Subject:</b> Re: [openstack-dev][tricircle] multiple cascade services<u></u><u></u></span></p>
</div><div><div class="h5">
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">Hi, <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Please see my comments <span style="color:red">
inline  </span><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">BR,<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:black">Eran </span><span lang="EN-US"><u></u><u></u></span></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">Hello,
</span><span lang="EN-US"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><span lang="EN-US"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">As what we discussed in the yesterday’s meeting, the contradict is how to scale out
 cascade services.</span><span lang="EN-US"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><span lang="EN-US"><u></u><u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">1)</span><span lang="EN-US" style="font-size:7.0pt;font-family:"Times New Roman","serif";color:#1f497d">     
</span><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">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.
</span><span lang="EN-US"><u></u><u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><span lang="EN-US"><u></u><u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">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.</span><span lang="EN-US"><u></u><u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US"><u></u> <u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:red">[Eran] I agree with this point - In the PoC you had a limitation of single active proxy per bottom site.  In addition, each proxy could only
 support a Single bottom site by-design.</span><span lang="EN-US"><u></u><u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><span lang="EN-US"><u></u><u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">2)</span><span lang="EN-US" style="font-size:7.0pt;font-family:"Times New Roman","serif";color:#1f497d">     
</span><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">The fake node introduced in the cascade service.
</span><span lang="EN-US"><u></u><u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">Because fanout rpc call for Neutron API is assumed, then no multiple fake nodes for one bottom openstack is allowed.</span><span lang="EN-US"><u></u><u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US"><u></u> <u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:red">[Eran] In fact, this is not a limitation in the current design.  We could have multiple "fake nodes" to handle the same bottom site, but only
 1 that is Active.  If this Active node becomes unavailable, one of the other "Passive" nodes can take over with some leader-election or any other known design pattern (it's an implementation decision).</span><span lang="EN-US"><u></u><u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">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.</span><span lang="EN-US"><u></u><u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US"><u></u> <u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:8.5pt;font-family:"Calibri","sans-serif";color:red">[Eran] I'm not sure I follow you on this point... as we see it, there are 3 places where load is an issue (and potential bottleneck):</span><span lang="EN-US"><u></u><u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:8.5pt;font-family:"Calibri","sans-serif";color:red">1. API + message queue + database</span><span lang="EN-US"><u></u><u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:8.5pt;font-family:"Calibri","sans-serif";color:red">2. Cascading Service itself (dependency builder, communication service, DAL)</span><span lang="EN-US"><u></u><u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:8.5pt;font-family:"Calibri","sans-serif";color:red">3. Task execution</span><span lang="EN-US"><u></u><u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US"><u></u> <u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:8.5pt;font-family:"Calibri","sans-serif";color:red">I think you were concerned about #2, which in our design must be a single-active per bottom site (to maintain task order of execution).  </span><span lang="EN-US"><u></u><u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:8.5pt;font-family:"Calibri","sans-serif";color:red">In our opinion, the heaviest part is actually #3 (task execution), which is delegated to a separate execution path (Mistral workflow or otherwise).</span><span lang="EN-US"><u></u><u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:8.5pt;font-family:"Calibri","sans-serif";color:red">In case we have one Cascading Service handling multiple Bottom sites and at some point in time we wish to handle just one Bottom site and move
 the rest of them to a different Cascading Service instance, it is possible.</span><span lang="EN-US"><u></u><u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:8.5pt;font-family:"Calibri","sans-serif";color:red">The way we see it, is we have multiple Fake Nodes running in multiple Cascading Services, in Active-Passive.  That way, when one Cascading
 Service instance becomes overloaded, it can give up its "Leadership" on active fake nodes, and some of the other Cascading Services will take over (leader election, or otherwise).  This is a very common design pattern, we don't see anything special or complicated
 here.</span><span lang="EN-US"><u></u><u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US"><u></u> <u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">At last, we have to deploy one fake node one cascade service.</span><span lang="EN-US"><u></u><u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">And one cascade service one bottom openstack will limit the burst traffic to one cascade openstack.</span><span lang="EN-US"><u></u><u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">And you have to backup the cascade service.</span><span lang="EN-US"><u></u><u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US"><u></u> <u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:8.5pt;font-family:"Calibri","sans-serif";color:red">[Eran] This is correct.  In the worst case of traffic burst to a single bottom site, a single Cascading Service will handle a single Fake Node
 exclusively, and it is not possible to handle a single Bottom Site with more than a single Fake Node at any given time.</span><span lang="EN-US"><u></u><u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:8.5pt;font-family:"Calibri","sans-serif";color:red">Having said that, we don't see a scenario where the Fake Node / Cascading Service will become a bottleneck.  We think that #3 (task execution)
 and #1 (message queue, API and database) will choke before, probably because the OpenStack components in the Top and Bottom sites will not be able to handle the burst (which is a completely different story).</span><span lang="EN-US"><u></u><u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><span lang="EN-US"><u></u><u></u></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">3)</span><span lang="EN-US" style="font-size:7.0pt;font-family:"Times New Roman","serif";color:#1f497d">     
</span><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">From the beginning, I prefer to run multiple cascade service in parallel, and all of them work in load balance cluster mode.</span><span lang="EN-US"><u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:red">[Eran] I believe we already discussed this before - It is actually not possible.  </span><span lang="EN-US"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:red">If you did that, you would have race condition and miss-ordering of actions, and an inconsistent state in the Bottom sites.</span><span lang="EN-US"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:red">For example, if the Top user did:</span><span lang="EN-US"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:red">#1 create security group "111" </span><span lang="EN-US"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:red">#2 update security group "111" with "Allow *"</span><span lang="EN-US"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:red">#3 update security group "111" with "Drop *"</span><span lang="EN-US"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:red">If you have more than a single Cascading service that is responsible for site "A", you don't know what will be the order of actions.</span><span lang="EN-US"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:red">In the example I gave, you may end up with site "A" having security group "111" with "Allow *" or with "Deny *".</span><span lang="EN-US"><u></u><u></u></span></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-left:12.0pt">
<span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">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 ).</span><span lang="EN-US"><u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:12.0pt">
<span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><span lang="EN-US"><u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:12.0pt">
<span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">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 )</span><span lang="EN-US"><u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:red">[Eran] This will not enforce order - Only keep state between non-racing actions.  It will not guarantee consistency in common scenarios of multiple updates to a specific resource within a short period,
 as I just gave with the security group.</span><span lang="EN-US">   <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:red">Maybe it will work for a few predictable use cases, but there will always be something else that you did not plan for.</span><span lang="EN-US"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:red">It is ultimately an unsafe design.</span><span lang="EN-US"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:red">If you propose to make the database the coordinator of this process (which I don't see how), you will end-up with an even worse bottleneck - in the database.</span><span lang="EN-US"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-left:12.0pt">
<span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><span lang="EN-US"><u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:12.0pt">
<span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">Through this way, we can dynamically add cascade service node, and balance the  traffic dynamically.
</span><span lang="EN-US"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">  </span><span lang="EN-US"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><span lang="EN-US"><u></u><u></u></span></p>
<p class="MsoNormal" style="text-align:justify;text-justify:inter-ideograph">
<span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">Best Regards</span><span lang="EN-US"><u></u><u></u></span></p>
<p class="MsoNormal" style="text-align:justify;text-justify:inter-ideograph">
<span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">Chaoyi Huang ( Joe Huang )</span><span lang="EN-US"><u></u><u></u></span></p>
</div>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
</div>
</div></div></div>
</div>

</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Zhipeng (Howard) Huang</div><div dir="ltr"><br></div><div dir="ltr">Standard Engineer</div><div>IT Standard & Patent/IT Prooduct Line</div><div dir="ltr">Huawei Technologies Co,. Ltd</div><div dir="ltr">Email: <a href="mailto:huangzhipeng@huawei.com" target="_blank">huangzhipeng@huawei.com</a></div><div dir="ltr">Office: Huawei Industrial Base, Longgang, Shenzhen</div><div dir="ltr"><br></div><div dir="ltr">(Previous)<br><div>Research Assistant</div><div>Mobile Ad-Hoc Network Lab, Calit2</div><div>University of California, Irvine</div><div>Email: <a href="mailto:zhipengh@uci.edu" target="_blank">zhipengh@uci.edu</a></div><div>Office: Calit2 Building Room 2402</div><div><br></div><div>OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado</div></div></div></div></div></div></div>
</div>