Public bug reported:
This issue is introducing a performance problem for the L2 agent
including LinuxBridge and OVS agent in Compute node when there are lots
of networks and instances in this Compute node (eg. 500 instances)
The performance problem reflect in two aspects:
1. When LinuxBridge agent service starts up(this seems only happened in
LinuxBridge agent not for the OVS agent), I found there were two methods
take too much time:
1.1 get_interface_by_ip(), we should find the interface which was
assigned with the "local ip" defined in configuration file, and to check
whether this interface support "vxlan" or not. This method will iterate
all the interface in this compute node and execute "ip link show
[interface] to [local ip]" to judge the result. I think there should
be a faster way.
1.2 prepare_port_filter() , in this method , we should make sure
the ipset are create correctly. But this method will execute too much
"ipset" commands and take too much time.
2. When devices' sg rules are changed, L2 agent should refresh the
firewalls.
2.1 refresh_firewall() this method will call "modify_rules" to make
the rules predicable, but this method also takes too much time.
It will be very benefit for the large scales of networks if this
performance problem can be fix or optimize.
** Affects: neutron
Importance: Undecided
Status: New
** Description changed:
This issue is introducing a performance problem for the L2 agent
including LinuxBridge and OVS agent in Compute node when there are lots
of networks and instances in this Compute node (eg. 500 instances)
The performance problem reflect in two aspects:
1. When LinuxBridge agent service starts up(this seems only happened in
LinuxBridge agent not for the OVS agent), I found there were two methods
take too much time:
- 1.1 get_interface_by_ip(), we should find the interface which was
+ 1.1 get_interface_by_ip(), we should find the interface which was
assigned with the "local ip" defined in configuration file, and to check
whether this interface support "vxlan" or not. This method will iterate
all the interface in this compute node and execute "ip link show
[interface] to [local ip]" to judge the result. I think that should be
a faster way.
- 1.2 prepare_port_filter() , in this method , we should make sure
+ 1.2 prepare_port_filter() , in this method , we should make sure
the ipset are create correctly. But this method will execute too much
"ipset" commands and take too much time.
+ 2. When devices' sg rules are changed, L2 agent should refresh the
+ firewalls.
- 2. When devices' sg rules are changed, L2 agent should refresh the firewalls.
-
- 2.1 refresh_firewall() this method will call "modify_rules" to make
+ 2.1 refresh_firewall() this method will call "modify_rules" to make
the rules predicable, but this method also takes too much time.
It will be very benefit for the large scales of networks if this
performance problem can be fix or optimize.
-
-
- If this kind of performance problem
** Description changed:
This issue is introducing a performance problem for the L2 agent
including LinuxBridge and OVS agent in Compute node when there are lots
of networks and instances in this Compute node (eg. 500 instances)
The performance problem reflect in two aspects:
1. When LinuxBridge agent service starts up(this seems only happened in
LinuxBridge agent not for the OVS agent), I found there were two methods
take too much time:
1.1 get_interface_by_ip(), we should find the interface which was
assigned with the "local ip" defined in configuration file, and to check
whether this interface support "vxlan" or not. This method will iterate
all the interface in this compute node and execute "ip link show
- [interface] to [local ip]" to judge the result. I think that should be
- a faster way.
+ [interface] to [local ip]" to judge the result. I think there should
+ be a faster way.
1.2 prepare_port_filter() , in this method , we should make sure
the ipset are create correctly. But this method will execute too much
"ipset" commands and take too much time.
2. When devices' sg rules are changed, L2 agent should refresh the
firewalls.
2.1 refresh_firewall() this method will call "modify_rules" to make
the rules predicable, but this method also takes too much time.
It will be very benefit for the large scales of networks if this
performance problem can be fix or optimize.
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1499177
Title:
Performance: L2 agent takes too much time to refresh sg rules
Status in neutron:
New
Bug description:
This issue is introducing a performance problem for the L2 agent
including LinuxBridge and OVS agent in Compute node when there are
lots of networks and instances in this Compute node (eg. 500
instances)
The performance problem reflect in two aspects:
1. When LinuxBridge agent service starts up(this seems only happened
in LinuxBridge agent not for the OVS agent), I found there were two
methods take too much time:
1.1 get_interface_by_ip(), we should find the interface which was
assigned with the "local ip" defined in configuration file, and to
check whether this interface support "vxlan" or not. This method will
iterate all the interface in this compute node and execute "ip link
show [interface] to [local ip]" to judge the result. I think there
should be a faster way.
1.2 prepare_port_filter() , in this method , we should make sure
the ipset are create correctly. But this method will execute too much
"ipset" commands and take too much time.
2. When devices' sg rules are changed, L2 agent should refresh the
firewalls.
2.1 refresh_firewall() this method will call "modify_rules" to
make the rules predicable, but this method also takes too much time.
It will be very benefit for the large scales of networks if this
performance problem can be fix or optimize.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1499177/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
