Open Stack

On 10/29/2012 10:16 PM, Nachi Ueno wrote:
> Hi Gary
>
> Thank you for posting this.
>
>> 1. HA for the L3 agents - this can be achieved by using VRRP
>> (http://en.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol).
> IMO, sending garp is enough if we have bulid-in heartbaet method.

Does the heartbeat make sure that there is network connectivity? When 
using VRRP one can have an active/backup or active/active setup. That 
is, if one of the devices fails then the other will take responsibility 
of the others IP addresses.

I am not sure if the garp covers this.
>
>> 2. Scale - when traffic is sent from the nodes to the L3 agent for floating
>> IP's we change the destination MAC address to the MAC address of the L3
>> agent. This will make the L3 agents transparent. Each plugin can offer this
>> support - for example if one is using OpenvSwitch then a flow entry can be
>> created that will override the destination MAC. For the linux bridge I
>> assume that this can be done by the tcpbridge interface.
>> In both of the above cases we will need to have some kind of health check (a
>> process on each node checking ICMP or ARP's to the L3 agent). This can and
>> should be added to Nova to ensure that there is connectivity between the
>> compute node and the L3 agent. If a failure of connectivity is detected then
>> the "flows" can be rebuilt to ensure that the traffic is redirected to
>> another L3 agent.
> +1 for that idea.
>
> IMO, this should be done by common service infrastructure by openstack-common.
> https://blueprints.launchpad.net/openstack-common/+spec/service-infrastructure
> This work is make service.py move to openstack-common.
> l3-agent and dhcp-agent should bese this common service infrastructure
>
> Thanks
> Nachi
>
>> Is this worthwhile exploring?
>> Thanks
>> Gary
>>
>> [1] The DHCP agent listens to notification - a tap device and namespace (to
>> provide overlapping IP's) will be created for each network. In the case of
>> dnsmasq a process will be run to provide the DHCP service. I wonder what the
>> limits are for the amount of networks that can be supported. It may be worth
>> considering limiting.
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev