[openstack-dev] [Neutron] Status of A/A HA for neutron-metadata-agent?

Gary Kotton gkotton at vmware.com
Sun Aug 3 11:25:14 UTC 2014

The link below is broken. Please see -
In short this will give a highly available service without the need for
the metadata proxy.
It will also have one less hop => better performance.

On 8/3/14, 1:07 PM, "Gary Kotton" <gkotton at vmware.com> wrote:

>Happy you asked about this. This is an idea that we have:
>Below is a suggestion on how we can improve the metadata service. This can
>be done by leveraging the a Load balancers supports X-Forwarded-For.The
>following link has two diagrams. The first is the existing support (may be
>a little rusty here, so please feel free to correct) and the second is the
>Metadata proxy support: the proxy will receive the HTTP request. It will
>then perform a query to the Neutron service (1) to retrieve the tenant id
>and the instance id from the neutron service. A proxy request will be sent
>to Nova for the metadata details (2).
>Proposed support:
>1. There will be a load balancer vip ­ (this can be
>reached either via the L3 agent of the DG on the DHCP.
>2. The LB will have a server farm of all of the Nova API's (this makes the
>soon highly available)
>     1. Replace the destination IP and port with the Nova metadata IP and
>     2. Replace the source IP with the interface IP
>     3. Insert the header X-Fowarded-For (this will have the original
>source IP of the VM)
>1. When the Nova metadata service receives the request, according to a
>configuration variable
>#L134), will interface with the neutron service to get the instance_id and
>the tenant id. This will be done by using a new extension. With the
>details provided by Neutron Nova will provide the correct metadata for the
>2. A new extension will be added to Neutron that will enable a port
>lookup. The port lookup will have two input values and will return the
>port ­ which has the instance id and the tenant id.
>1. LB source IP ­ this is the LB source IP that interfaces with the Nova
>API. When we create the edge router for the virtual network we will have a
>mapping of the edge LB ip <-> network id. This will enable us to get the
>virtual network for the port
>2. Fixed port IP ­ this with the virtual network will enable us to get the
>specific port.
>Hopefully in the coming days a spec will be posted that will provide more
>On 8/1/14, 6:11 PM, "marios at redhat.com" <mandreou at redhat.com> wrote:
>>Hi all,
>>I have been asked by a colleague about the status of A/A HA for
>>neutron-* processes. From the 'HA guide' [1], l3-agent and
>>metadata-agent are the only neutron components that can't be deployed in
>>A/A HA (corosync/pacemaker for a/p is documented as available 'out of
>>the box' for both).
>>The l3-agent work is approved for J3 [4] but I am unaware of any work on
>>the metadata-agent and can't see any mention in [2][3]. Is this someone
>>has looked at, or is planning to (though ultimately K would be the
>>earliest right?)?
>>thanks! marios
>>[1] http://docs.openstack.org/high-availability-guide/content/index.html
>>[2] https://wiki.openstack.org/wiki/NeutronJunoProjectPlan
>>OpenStack-dev mailing list
>>OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list