hi Miguel Ángel,
I am very agree with you about the following point:
> * physical implementation on the hosts (ipsets, nftables, ... )
--this can reduce the load of compute node.
> * rpc communication mechanisms.
--this can reduce the load of neutron server
can you help me to review my BP specs?
At 2014-06-19 10:11:34, "Miguel Angel Ajo Pelayo" <mangel...@redhat.com> wrote:
>
> Hi it's a very interesting topic, I was getting ready to raise
>the same concerns about our security groups implementation, shihanzhang
>thank you for starting this topic.
>
> Not only at low level where (with our default security group
>rules -allow all incoming from 'default' sg- the iptable rules
>will grow in ~X^2 for a tenant, and, the "security_group_rules_for_devices"
>rpc call from ovs-agent to neutron-server grows to message sizes of >100MB,
>generating serious scalability issues or timeouts/retries that
>totally break neutron service.
>
> (example trace of that RPC call with a few instances
> http://www.fpaste.org/104401/14008522/)
>
> I believe that we also need to review the RPC calling mechanism
>for the OVS agent here, there are several possible approaches to breaking
>down (or/and CIDR compressing) the information we return via this api call.
>
>
> So we have to look at two things here:
>
> * physical implementation on the hosts (ipsets, nftables, ... )
> * rpc communication mechanisms.
>
> Best regards,
>Miguel Ángel.
>
>----- Mensaje original -----
>
>> Do you though about nftables that will replace {ip,ip6,arp,eb}tables?
>> It also based on the rule set mechanism.
>> The issue in that proposition, it's only stable since the begin of the year
>> and on Linux kernel 3.13.
>> But there lot of pros I don't list here (leverage iptables limitation,
>> efficient update rule, rule set, standardization of netfilter commands...).
>
>> Édouard.
>
>> On Thu, Jun 19, 2014 at 8:25 AM, henry hly < henry4...@gmail.com > wrote:
>
>> > we have done some tests, but have different result: the performance is
>> > nearly
>> > the same for empty and 5k rules in iptable, but huge gap between
>> > enable/disable iptable hook on linux bridge
>>
>
>> > On Thu, Jun 19, 2014 at 11:21 AM, shihanzhang < ayshihanzh...@126.com >
>> > wrote:
>>
>
>> > > 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, w ith 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
>> >
>>
>
>> > _______________________________________________
>>
>> > 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
>
>_______________________________________________
>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
