Open Stack

To avoid dependency of data plane on control plane it is possible to deploy
a separate key-value storage cluster on data plane side, using the same
network nodes.
I'm proposing to make some changes to enable experimentation in this field,
we are yet to come up with any other concrete solution.

On Mon, Feb 13, 2017 at 2:01 PM <cristi.calin at orange.com> wrote:

> Hi,
>
>
>
>
>
> We also operate using Juno with the VRRP HA implementation and at had to
> patch through several bugs before getting to the Mitaka release.
>
> An pluggable, drop-in alternative would be highly appreciated. However our
> experience has been that the decoupling of VRRP from the control plane is
> actually a benefit as when the control plane is down the traffic is not
> affected.
>
> In a solution where the L3 HA implementation becomes tied to the
> availability of the control plane (etcd cluster or any other KV store) then
> an operator would have to account for extra failure scenarios for the KV
> store which would affect multiple routers than the outage of a single L3
> node which is the case we usually have to account now.
>
>
>
>
>
> Just my $.02
>
>
>
> Cristian
>
>
>
> *From:* Anna Taraday [mailto:akamyshnikova at mirantis.com]
> *Sent:* Monday, February 13, 2017 11:45 AM
> *To:* OpenStack Development Mailing List (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
> agent which is active for current HA router.
>
>
>
> On Mon, Feb 13, 2017 at 7:02 AM zhi <changzhi1990 at gmail.com> wrote:
>
> 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  data
> plan is busy. If we were used etcd (or other), does every router instance
> register one "id" in etcd ?
>
>
>
>
>
> Thanks
>
> Zhi Chang
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
>
> Regards,
> Ann Taraday
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Regards,
Ann Taraday
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170213/6bd95f22/attachment.html>