[openstack-dev] [Neutron] Alternative approaches for L3 HA
assaf at redhat.com
Wed Feb 22 21:13:45 UTC 2017
On Wed, Feb 22, 2017 at 1:40 PM, Miguel Angel Ajo Pelayo
<majopela at redhat.com> wrote:
> I have updated the spreadsheet. In the case of RH/RDO we're using the same
> 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 agents and services are robust in case of dependent
> services (database, rabbitmq
> ) failures, to make sure they reconnect and continue when those become
Thanks Miguel, I added a little bit of info the spreadsheet as well.
> On Wed, Feb 22, 2017 at 11:28 AM, Adam Spiers <aspiers at suse.com> wrote:
>> Kosnik, Lubosz <lubosz.kosnik at intel.com> 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 was responsible for checking external and internal
>> > connectivity. To detect split brain. Elect master, even keepalived was
>> > running but Peacemaker was automatically killing all services and moving
>> > FIP.
>> > Assaf - is there any change in this implementation in RDO? Or you’re
>> > still doing everything outside of Neutron?
>> > Because if RDO success is build on Peacemaker it means that yes, Neutron
>> > needs some solution which will be available for more than RH deployments.
>> With help from others, I have started an analysis of some of the
>> different approaches to L3 HA:
>> (although I take responsibility for all mistakes ;-)
>> It would be great if someone from RH or RDO could provide information
>> on how this RDO (and/or RH OSP?) solution based on Pacemaker +
>> keepalived works - if so, I volunteer to:
>> - help populate column E of the above sheet so that we can
>> understand if there are still remaining gaps in the solution, and
>> - document it (e.g. in the HA guide). Even if this only ended up
>> being considered as a shorter-term solution, I think it's still
>> worth documenting so that it's another option available to
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev