Now I have not get accurate test data, but I can confirm the following points： 1. In compute node, the iptable's chain of a VM is liner, iptable filter it one by one, if a VM in default security group and this default security group have many members, but ipset chain is set, the time ipset filter one and many member is not much difference. 2. when the iptable rule is very large, the probability of failure that iptable-save save the iptable rule is very large.
At 2014-06-19 10:55:56, "Kevin Benton" <blak...@gmail.com> wrote: This sounds like a good idea to handle some of the performance issues until the ovs firewall can be implemented down the the line. Do you have any performance comparisons? On Jun 18, 2014 7:46 PM, "shihanzhang" <ayshihanzh...@126.com> wrote: Hello all, Now in neutron, it use iptable implementing security group, but the performance of this implementation is very poor, there is a bug:https://bugs.launchpad.net/neutron/+bug/1302272 to reflect this problem. In his test, with default security groups(which has remote security group), beyond 250-300 VMs, there were around 6k Iptable rules on evry compute node, although his patch can reduce the processing time, but it don't solve this problem fundamentally. I have commit a BP to solve this problem:https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security There are other people interested in this it? _______________________________________________ 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
