Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA

2017-02-23 Thread Adam Spiers
Anil Venkata wrote: > On Thu, Feb 23, 2017 at 12:10 AM, Miguel Angel Ajo Pelayo > wrote: > > On Wed, Feb 22, 2017 at 11:28 AM, Adam Spiers wrote: > >> With help from others, I have started an analysis of some of the > >> different

Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA

2017-02-22 Thread Assaf Muller
On Wed, Feb 22, 2017 at 1:40 PM, Miguel Angel Ajo Pelayo wrote: > I have updated the spreadsheet. In the case of RH/RDO we're using the same > architecture > in the case of HA, pacemaker is not taking care of those anymore since the > HA-NG implementation. > > We let systemd

Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA

2017-02-22 Thread Armando M.
of a single L3 >> node which is the case we usually have to account now. >> >> >> >> >> >> Just my $.02 >> >> >> >> Cristian >> >> >> >> *From:* Anna Taraday [mailto:akamyshnik...@mirantis.com] >> *Sent:* Monday, Feb

Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA

2017-02-22 Thread Anil Venkata
On Thu, Feb 23, 2017 at 12:10 AM, Miguel Angel Ajo Pelayo < majop...@redhat.com> wrote: > I have updated the spreadsheet. In the case of RH/RDO we're using the same > architecture > in the case of HA, pacemaker is not taking care of those anymore since the > HA-NG implementation. > > We let

Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA

2017-02-22 Thread Miguel Angel Ajo Pelayo
I have updated the spreadsheet. In the case of RH/RDO we're using the same architecture in the case of HA, pacemaker is not taking care of those anymore since the HA-NG implementation. We let systemd take care to restart the services that die, and we worked with the community to make sure that

Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA

2017-02-22 Thread Adam Spiers
Kosnik, Lubosz wrote: > About success of RDO we need to remember that this deployment utilizes > Peacemaker and when I was working on this feature and even I spoke with Assaf > this external application was doing everything to make this solution working. > Peacemaker

Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA

2017-02-15 Thread Kosnik, Lubosz
About success of RDO we need to remember that this deployment utilizes Peacemaker and when I was working on this feature and even I spoke with Assaf this external application was doing everything to make this solution working. Peacemaker was responsible for checking external and internal

Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA

2017-02-15 Thread Anna Taraday
If I propose some concrete solution that will be discussion about one solution not about making things flexible. At first I wanted to propose some PoC for other approach, but during my experiments I understood that we may have different approaches, but for all of them we need pluggable HA router

Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA

2017-02-14 Thread Assaf Muller
On Fri, Feb 10, 2017 at 12:27 PM, Anna Taraday wrote: > Hello everyone! > > In Juno in Neutron was implemented L3 HA feature based on Keepalived (VRRP). > During next cycles it was improved, we performed scale testing [1] to find > weak places and tried to fix them.

Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA

2017-02-14 Thread Morales, Victor
questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Monday, February 13, 2017 at 10:23 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openst

Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA

2017-02-13 Thread Kosnik, Lubosz
he case we usually have to account now. Just my $.02 Cristian From: Anna Taraday [mailto:akamyshnik...@mirantis.com<mailto:akamyshnik...@mirantis.com>] Sent: Monday, February 13, 2017 11:45 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openst

Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA

2017-02-13 Thread Anna Taraday
t; > > > > Just my $.02 > > > > Cristian > > > > *From:* Anna Taraday [mailto:akamyshnik...@mirantis.com] > *Sent:* Monday, February 13, 2017 11:45 AM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron] Alte

Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA

2017-02-13 Thread cristi.calin
(not for usage questions) Subject: Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA In etcd for each HA router we can store key which will identify which agent is active. L3 agents will "watch" this key. All these tools have leader election mechanism which can be used to get ag

Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA

2017-02-13 Thread Anna Taraday
In etcd for each HA router we can store key which will identify which agent is active. L3 agents will "watch" this key. All these tools have leader election mechanism which can be used to get agent which is active for current HA router. On Mon, Feb 13, 2017 at 7:02 AM zhi

Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA

2017-02-12 Thread zhi
Hi, we are using L3 HA in our production environment now. Router instances communicate to each other by VRRP protocol. In my opinion, although VRRP is a control plane thing, but the real VRRP traffic is using data plane nic so that router namespaces can not talk to each other sometimes when the

[openstack-dev] [Neutron] Alternative approaches for L3 HA

2017-02-10 Thread Anna Taraday
Hello everyone! In Juno in Neutron was implemented L3 HA feature based on Keepalived (VRRP). During next cycles it was improved, we performed scale testing [1] to find weak places and tried to fix them. The only alternative for L3 HA with VRRP is router rescheduling performed by Neutron server,