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. <div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>Just my thoughts. </div><div>Vinay<br><div><br><div class="gmail_quote">On Sun, Nov 25, 2012 at 5:56 AM, Gary Kotton <span dir="ltr"><<a href="mailto:gkotton@redhat.com" target="_blank">gkotton@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    Hi,<br>
    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.<br>
    <br>
    This can be achieved as follows:<br>
    <br>
    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.)<br>
    2. Each DHCP running agent will be registered as a member (I hope
    that I have the terminology correct here). Basically vip = {dhcps1,
    dhcps2, ...}<br>
    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.<br>
    <br>
    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. <br>
    <br>
    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 :)). <br>
    <br>
    A few minor changes may be required when Nova receives the DHCP
    address - we should return the VIP address. <br>
    <br>
    <img src="cid:part1.02000706.01080102@redhat.com" alt=""><br>
    <br>
    Ideas, comments or thoughts? <br>
    <br>
    Thanks<span class="HOEnZb"><font color="#888888"><br>
    Gary<br>
    <br>
  </font></span></div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Vinay Bannai<br>Email: <a href="mailto:vbannai@gmail.com">vbannai@gmail.com</a><br>Google Voice: 415 938 7576<br><br>
</div></div>