Open Stack

On 11/26/2012 06:45 AM, Vinay Bannai wrote:
> I would agree that having a active/standby for DHCP agent makes a lot 
> of sense. We might want to leverage the VRRP infastructure for that.
> I am not sure I understand clearly the need to have the DHCP agents 
> sit behind the load balancers. What are we trying to load balance 
> here? The amount of DHCP intermittent and transient to say the least 
> with a heavy bias towards more traffic at the time of a VM booting up.

At the moment there are a number of problems with the DHCP agents:
     - single point of failure
     - it does not scale

A simple solution to addressing the above is making use of a standard 
load balancer (as depicted in the diagram below). This enables us to 
scale and to have HA for the DHCP agents. I really like the solution and 
it addresses a number of problems and concerns about the DHCP agents.

>
> If we were to truly load balance we would need to keep the state of 
> the DHCP servers in sync (dynamically) as they would be allocating 
> from a common pool of resources. That might not be a problem that we 
> would want to inherit.

Yes, a load balcner maintaining a persistent entry will ensure that the 
leasing works correctly. In the event that a DHCP agent terminates 
(maintenance, network issues, excpetion etc.) the the load balcner will 
select another active DHCP agent. The advantage here is that the current 
implementation has the DHCP agents all having the relevant host 
information - i.e. the routes, ip address and mac address.

>
> On the other hand, your suggestion to use VRRP would be a great idea 
> for those use cases where the L3 agent and the DHCP agent would be 
> co-located. The problem of keeping the state in sync would still have 
> to be dealt with but is not as severe as the load balancing case.

VRRP is a way of providing the high availability. All off the shelf load 
balancers today support this. Some may have their own proprietary ways 
of performance HA. This will ensure that the load balancer is not a 
single point of failure. Originally I was in favor of implementing VRRP 
on the L3 agents but now that the LBaaS is starting to crystallize this 
is a far better solution for the infrastructure and Openstack as a whole.

>
> Just my thoughts.
> Vinay
>
> On Sun, Nov 25, 2012 at 5:56 AM, Gary Kotton <gkotton at redhat.com 
> <mailto:gkotton at redhat.com>> wrote:
>
>     Hi,
>     There were two ideas discussed at the summit the first is the
>     LBaaS and the second was improvements for the DHCP agent
>     (multinode). I think that we can leverage the LBaaS to support a
>     highly available and robust Quantum DHCP service.
>
>     This can be achieved as follows:
>
>     1. For each network that supports a DHCP service there will be a
>     VIP for the DHCP address (this will also have the relevant health
>     checks etc.)
>     2. Each DHCP running agent will be registered as a member (I hope
>     that I have the terminology correct here). Basically vip =
>     {dhcps1, dhcps2, ...}
>     3. All of the DHCP requests and lease updates will be sent via the
>     VIP for the DHCP. The load balcner will select a DHCP server if
>     this is the first time a request from the client has been made or
>     it will forward to a existing server entry.
>
>     Please see the diagram below. This will enable a cluster of hosts
>     on the same network tenant to get a highly available DHCP service
>     - the DHCP server IP is the virtual IP (it is ideal to have an
>     active backup load balancing pair to ensure HA - this could either
>     be by VRRP or some propriatery method that any of the vendors
>     support). My thinking is that if we can use this for the first
>     LBaaS integration example then we are certainly moving in the
>     right direction and we have killed two birds with one stone.
>
>     In the example below there will be 2 DHCP agents. The traffic will
>     be load balanced by the active load balancer (in an active back
>     configuration the persistent sessions will be maintained :)).
>
>     A few minor changes may be required when Nova receives the DHCP
>     address - we should return the VIP address.
>
>
>
>     Ideas, comments or thoughts?
>
>     Thanks
>     Gary
>
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> -- 
> Vinay Bannai
> Email: vbannai at gmail.com <mailto:vbannai at gmail.com>
> Google Voice: 415 938 7576
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121126/f8c74f3b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 25497 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121126/f8c74f3b/attachment.png>