[Openstack-operators] HA solutions for L3-Agent and metadata-agent ?

Édouard Thuleau thuleau at gmail.com
Fri Mar 7 09:11:56 UTC 2014


And about the HA l3 with VRRP (active/passive) code [2], the code was deferring
to Juno and the developer ask a FFE to push it on the IceHouse release.
I though it must merge for IceHouse, to let the community tries it
and stabilizes it during the Juno release. And for the Juno release, we
will be able to announce it as stable.

Édouard.

[1] https://blueprints.launchpad.net/neutron/+spec/l3-high-availability
[2]
http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg18555.html


On Thu, Mar 6, 2014 at 10:57 PM, George Shuklin <george.shuklin at gmail.com>wrote:

>
> On 03/06/2014 04:50 PM, gustavo panizzo <gfa> wrote:
>
>> On 03/06/2014 09:54 AM, Alvise Dorigo wrote:
>>
>>> Hi,
>>> I opened some time ago a thread about this argument (more in general
>>> about HA for
>>> OpenStack): http://www.gossamer-threads.com/lists/openstack/operators/
>>> 33777.
>>> Now I'm definitely focusing on making the Neutron's agents highly
>>> available.
>>>
>>> As stated in the mentioned thread there's no solution for making L3
>>> agent HA with the active/active paradigm. But I have to use the
>>> active/active paradigm.
>>>
>> there is no active/active route protocol to route ip packages, you can
>> have only one default gw. that's true in virtual as physical world.
>> but....
>>
>> i remember a eNovance guy giving a presentation during HK summit, they
>> have patched neutron in order to use VRRP. you may want to search that
>>
>> if you use it, pls share your results. i haven't a chance to test it
>>
>>  I think there is no needs for the replicating every single packet. Some
> packet loss is sad, but not crucial. Almighty TCP will save souls, so we
> need just replicate (somehow) every new connection and NAT translation. IP
> migration between L3 agents is not a problem (if they are in same network).
> We don't need to keep track on sequence numbers of TCP, so it's just a
> single operation per connection on every new flow.
>
> ... Hm... flow. May be some kind of openflow controller, managing
> translation table outside linux kernel? Some kind of super-fast in-memory
> database with replication, which allow controller to reconfigure other l3
> agents to pick up traffic of broken network node. Seems real for me.
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140307/c6c48674/attachment.html>


More information about the OpenStack-operators mailing list