Open Stack

Hi,
The link below is broken. Please see -
https://docs.google.com/drawings/d/19JCirhj2NVVFZ0Vbnsxhyxrm1jjzEAS3ZAMzfBR
C-0E/edit
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.
Thanks
Gary

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

>Hi,
>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
>proposal. 
>https://docs.google.com/drawings/d/19JCirhj2NVVFZ0Vbnsxhyxrm1jjzEAS3ZAMzfB
>R
>C-0E/edit?usp=sharing
>
>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 ­ 254.169.254.169 (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
>port
>     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
>(https://github.com/openstack/nova/blob/master/nova/api/metadata/handler.p
>y
>#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
>instance
>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
>details
>
>Thanks
>Gary
>
>
>
>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
>>[3] 
>>https://urldefense.proofpoint.com/v1/url?u=https://launchpad.net/neutron/
>>%
>>2Bmilestone/juno-3&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6
>>h
>>goMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=TZXQIMHmAX22lC0YOyItiXOrAA%2FegHqY5c
>>N
>>I73%2B0jJ8%3D%0A&s=b81f4d5919b317628f56d0313143cee8fca6e47f639a59784eb19d
>>a
>>3d88681da
>>[4]
>>http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/l3-
>>h
>>igh-availability.rst
>>
>>_______________________________________________
>>OpenStack-dev mailing list
>>OpenStack-dev at lists.openstack.org
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>