On 03/08/14 13:07, Gary Kotton 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/19JCirhj2NVVFZ0Vbnsxhyxrm1jjzEAS3ZAMzfBR > 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.py > #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 for that info Gary, the diagram in particular forced me to go read a bit about the metadata agent (i was mostly just proxying for the original question). I obviously miss a lot of the details (will be easier once the spec is out) but it seems like you're proposing an addition (port-lookup) that will change the way the metadata agent is called; in fact does it make the neutron metadata proxy obsolete? I will keep a look out for the spec, thanks, marios > Thanks > Gary > > > > On 8/1/14, 6:11 PM, "[email protected]" <[email protected]> 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=eH0pxTUZo8NPZyF6h >> goMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=TZXQIMHmAX22lC0YOyItiXOrAA%2FegHqY5cN >> I73%2B0jJ8%3D%0A&s=b81f4d5919b317628f56d0313143cee8fca6e47f639a59784eb19da >> 3d88681da >> [4] >> http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/l3-h >> igh-availability.rst >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
