yahoo-eng-team team mailing list archive

[Assaf Muller <amuller@xxxxxxxxxx>]

Public bug reported:

How to reproduce:
On a setup with two L3 agents, create ten HA routers, the scheduler will place them on both agents, but the same agent will host the active instance of all ten routers. This defeats the idea of load sharing traffic across all L3 agents.

Solutions:
This can be solved in one of two ways:
1) Enable preemptive elections for HA routers. Keepalived enables a configuration value that causes VRRP pre-emptive elections. This way we can set a random VRRP priority for each router instance, and the elections process will guarantee a random distribution of active routers on the available agents. Preemptive elections have a major downside - If an agent that's hosting a master instance drops, the backup router will come in to play, but when the node is fixed the old master will re-assume its role. This second state transition is costly and redundant. 
2) With non-preemptive elections the first router instance to come up will become the master. We can exploit this and send the notification from the server to the agents in a random order.

** Affects: neutron
     Importance: Undecided
         Status: New


** Tags: l3-ha vrrp

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1365429

Title:
  All HA routers become active on the same agent

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  How to reproduce:
  On a setup with two L3 agents, create ten HA routers, the scheduler will place them on both agents, but the same agent will host the active instance of all ten routers. This defeats the idea of load sharing traffic across all L3 agents.

  Solutions:
  This can be solved in one of two ways:
  1) Enable preemptive elections for HA routers. Keepalived enables a configuration value that causes VRRP pre-emptive elections. This way we can set a random VRRP priority for each router instance, and the elections process will guarantee a random distribution of active routers on the available agents. Preemptive elections have a major downside - If an agent that's hosting a master instance drops, the backup router will come in to play, but when the node is fixed the old master will re-assume its role. This second state transition is costly and redundant. 
  2) With non-preemptive elections the first router instance to come up will become the master. We can exploit this and send the notification from the server to the agents in a random order.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1365429/+subscriptions