<br><br><div class="gmail_quote">On Mon, Nov 26, 2012 at 12:38 PM, 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"><div class="im">
    On 11/26/2012 09:20 PM, Mark McClain wrote:
    <blockquote type="cite">
      
      Sorry I realized that my reply did not go back to the list.  
      <div><br>
      </div>
      <div>The DHCP protocol is designed for active/active setups, so we
        don't need to front it with a load balancer.  The protocol
        specifies how clients should handle when servers go offline and
        lease renewals cannot be completed.  You can get HA right now by
        starting more than one DHCP agent instance on other hosts.<br>
      </div>
    </blockquote>
    <br></div>
    If I understand correctly the IP address of the DHCP server is
    passed by Nova to the VM. Which IP address will this be? If a load
    balancer is used the address can be the same - that is a virtual IP.</div></blockquote><div><br></div><div>DHCP server addresses are not passed to the VM, the VM sends a request to broadcast when it boots, and the DHCP server receives this message and responds.  Nova traditionally grabs the DHCP address in order to poke a hole in the VMs inbound security group filters to allow the DHCP server reply to reach the VM. </div>

<div><br></div><div>Dan</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div><div class="h5"><br>


    <br>
    <br>
    <blockquote type="cite">
      <div>
        <div><br>
        </div>
        <div>mark<br>
          <div><br>
          </div>
          <div>
            <div>
              <div>On Nov 26, 2012, at 2:21 AM, Gary Kotton <<a href="mailto:gkotton@redhat.com" target="_blank">gkotton@redhat.com</a>>
                wrote:</div>
              <br>
              <blockquote type="cite">
                
                <div bgcolor="#FFFFFF" text="#000000"> On 11/26/2012
                  06:45 AM, Vinay Bannai wrote:
                  <blockquote type="cite">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. <br>
                    </div>
                  </blockquote>
                  <br>
                  At the moment there are a number of problems with the
                  DHCP agents:<br>
                      - single point of failure<br>
                      - it does not scale<br>
                  <br>
                  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.<br>
                  <br>
                  <blockquote type="cite">
                    <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. <br>
                    </div>
                  </blockquote>
                  <br>
                  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.<br>
                  <br>
                  <blockquote type="cite">
                    <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. <br>
                    </div>
                  </blockquote>
                  <br>
                  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.<br>
                  <br>
                  <blockquote type="cite">
                    <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>
                              <span><Mail Attachment.png></span><br>
                              <br>
                              Ideas, comments or thoughts? <br>
                              <br>
                              Thanks<span><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" target="_blank">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" target="_blank">vbannai@gmail.com</a><br>
                        Google Voice: <a href="tel:415%20938%207576" value="+14159387576" target="_blank">415 938 7576</a><br>
                        <br>
                      </div>
                    </div>
                  </blockquote>
                  <br>
                </div>
                _______________________________________________<br>
                OpenStack-dev mailing list<br>
                <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
              </blockquote>
            </div>
            <br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </div></div></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>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br><div>twitter: danwendlandt<br>

~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div><br>