<div dir="ltr">@Nachi: Yes that could a good improvement to factorize the RPC mechanism.<div><br></div><div>Another idea:</div><div>What about creating a RPC topic per security group (quid of the RPC topic scalability) on which an agent subscribes if one of its ports is associated to the security group?</div>
<div><br></div><div>Regards,</div><div>Édouard.</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 20, 2014 at 4:04 AM, shihanzhang <span dir="ltr"><<a href="mailto:ayshihanzhang@126.com" target="_blank">ayshihanzhang@126.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><div>hi <span style="font-family:arial;white-space:pre-wrap;line-height:21.203636169433594px;font-size:14px">Miguel Ángel,</span></div>
<div><span style="font-family:arial;white-space:pre-wrap;line-height:21.203636169433594px;font-size:14px">I am very agree with you about the following point:</span></div><div><div class=""><pre>> * physical implementation on the hosts (ipsets, nftables, ... )</pre>
</div><pre> --this can reduce the load of compute node.
> * rpc communication mechanisms.</pre><pre> --<span style="font-size:14px;line-height:1.7">this can reduce the load of neutron server</span></pre><pre><span style="font-size:14px;line-height:1.7">can you help me to review my BP specs?</span></pre>
<pre><br></pre></div><div><div class="h5"><br><br><br><br><div></div><div></div><br><pre><br>At 2014-06-19 10:11:34, "Miguel Angel Ajo Pelayo" <<a href="mailto:mangelajo@redhat.com" target="_blank">mangelajo@redhat.com</a>> 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
> <a href="http://www.fpaste.org/104401/14008522/" target="_blank">http://www.fpaste.org/104401/14008522/</a>)
>
> 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 < <a href="mailto:henry4hly@gmail.com" target="_blank">henry4hly@gmail.com</a> > 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 < <a href="mailto:ayshihanzhang@126.com" target="_blank">ayshihanzhang@126.com</a> >
>> > 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" < <a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a> > 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" < <a href="mailto:ayshihanzhang@126.com" target="_blank">ayshihanzhang@126.com</a> > 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:
>> > > > > <a href="https://bugs.launchpad.net/neutron/+bug/1302272" target="_blank">https://bugs.launchpad.net/neutron/+bug/1302272</a> 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:
>> > > > > <a href="https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security" target="_blank">https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security</a>
>> > > >
>> > >
>> >
>>
>> > > > > There are other people interested in this it?
>> > > >
>> > >
>> >
>>
>
>> > > > > _______________________________________________
>> > > >
>> > >
>> >
>>
>> > > > > OpenStack-dev mailing list
>> > > >
>> > >
>> >
>>
>> > > > > <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
>> > > >
>> > >
>> >
>>
>> > > > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
>> > > >
>> > >
>> >
>>
>
>> > > _______________________________________________
>> >
>>
>> > > OpenStack-dev mailing list
>> >
>>
>> > > <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
>> >
>>
>> > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
>> >
>>
>
>> > _______________________________________________
>>
>> > OpenStack-dev mailing list
>>
>> > <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
>>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
>>
>
>> _______________________________________________
>> OpenStack-dev mailing list
>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
>
>_______________________________________________
>OpenStack-dev mailing list
><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre></div></div></div><br><br><span title="neteasefooter"><span></span></span><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>