Dear Thierry,
Thanks for your suggestion. It is submitted as below. http://summit.openstack.org/cfp/create Topic Title (Click to view/edit) Proposer Status Neutron Scaling Network Performance for Large Clouds<http://summit.openstack.org/cfp/details/270> Tina Tsou U Unreviewed Thank you, Tina -----Original Message----- From: Thierry Carrez [mailto:thie...@openstack.org] Sent: Wednesday, April 09, 2014 6:36 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Session suggestions for the Juno Design Summit now open Tina TSOU wrote: > Below is our proposal. Look forward to your feedback. > > -------------- > Description > This session focuses on how to improve networking performance at large scale > deployment. > For example > - having many VMs, thousands to tens of thousands, in a single data > center > - very heavy traffic between VMs of different physical servers > - large quantities of OpenFlow flow tables causing slow forwarding on > OVS and high CPU usage on hypervisor > - VMs belong to various tenants thus requiring traffic isolation and > security and lots of configuration on OVS mainly overlay encapsulation > and OpenFlow tables > - neutron server taking too long time to process requests > > We are introducing a solution designed for the above scenario in this area. > The main idea is to deploy on the hypervisor a new monitor agent which will > periodically check the CPU usage and network load of the NIC and inform SDN > controller through plugin/API extension. If the OVS load goes very high, SDN > controller can reactively off-load the traffic from OVS to TOR with minimum > interruption. It means that initially, the overlay encapsulation might be > done on OVS, but some feature rich TORs also provide this functionality which > makes TOR capable of taking over whenever necessary. The same strategy will > be applied for OpenFlow flow table. By doing this, OVS will have nothing to > do other than sending the traffic to TOR. All the time-consuming jobs will be > taken over by TOR dynamically. This more advanced strategy does require TOR > to be feature-rich so it might cause more TCO. > > We believe this is worth doing for large scale deployment. > -------------- You should file it at summit.openstack.org so that it can be considered for inclusion in the schedule. Regards, -- Thierry Carrez (ttx) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<<inline: image001.gif>>
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
