<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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><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">gkotton@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
On 11/26/2012 06:45 AM, Vinay Bannai wrote:
<blockquote cite="mid:CAO48XRHQg3jXDCVFbOyrwRJYzPWvXSYZej7TwE7vBsqKKWObhA@mail.gmail.com" 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 cite="mid:CAO48XRHQg3jXDCVFbOyrwRJYzPWvXSYZej7TwE7vBsqKKWObhA@mail.gmail.com" 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 cite="mid:CAO48XRHQg3jXDCVFbOyrwRJYzPWvXSYZej7TwE7vBsqKKWObhA@mail.gmail.com" 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 cite="mid:CAO48XRHQg3jXDCVFbOyrwRJYzPWvXSYZej7TwE7vBsqKKWObhA@mail.gmail.com" 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 moz-do-not-send="true" 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 class="HOEnZb"><font color="#888888"><br>
Gary<br>
<br>
</font></span></div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true" 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 moz-do-not-send="true" href="mailto:vbannai@gmail.com">vbannai@gmail.com</a><br>
Google Voice: 415 938 7576<br>
<br>
</div>
</div>
</blockquote>
<br>
</div>
_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote></div><br></div></div></div></body></html>