[openstack-dev] [Neutron] Avoiding dhcp port loss using conductors

Zhongyue Luo zhongyue.nah at intel.com
Thu Mar 13 07:06:20 UTC 2014


Hi folks,

I having working on enhancing the base performance of Neutron using ML2 OVS
during my free cycles for the past few weeks. The current bottleneck in
Neutron is, as we all know, the part when a neutron agent requests
"security_group_rules_for_devices" to the server in order to update its
port's SG rules. This operation takes an average 24secs according to my
observation and it is also the main cause of some VMs not able to receive
DHCP responses in severe conditions.

To enhance the throughput performance of VM provisioning with Neutron, I've
created a neutron-conductor service which currently only handles
"security_group_rules_for_devices" requests. Though it is yet in prototype
status, it works great in my devstack env and in the OpenStack deployment
in our lab. In my all-in-one devstack env with 4cores and 8G mem, I was
able to provision 50 nano flavor VMs without any network failures. In the
lab deployment, which has 16 compute nodes, I was able to provision 500
tiny flavor VMs with 8sec interval between every nova boot. All of which
successfully obtained fixed IPs.

I've pushed my devstack patch which launches the neutron conductor service
to my github account:
https://github.com/zyluo/devstack/tree/havana_neutron_conductor_sg_only

The patch for the neutron-conductor is located at:
https://github.com/zyluo/neutron/tree/havana_conductor_sg_only

If you are interested, feel free to try this on your devstack env.
Instructions are in the commit message:
https://github.com/zyluo/devstack/commit/07382fa11ec9049b5e732390aca67d4bc9a7443b

I've only tested on CentOS 6.4 using ML2 OVS. Any feedback would be
appreciated. Thanks!

-- 
*Intel SSG/STO/DCST/CIT*
880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai,
China
+862161166500
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140313/4a571f3b/attachment.html>


More information about the OpenStack-dev mailing list