<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Yes we will have to monitor the dhcp agents. </div><div><br></div><div>To scale "vertically" (as Mark put it), we need to adopt some of these redundancy and failover techniques. We may end up having to provide all the options to the users and let them pick at the time of creation of their networks. </div>
<div><br></div><div>Vinay<br><br>On Nov 30, 2012, at 4:54 PM, "Bhandaru, Malini K" <<a href="mailto:malini.k.bhandaru@intel.com">malini.k.bhandaru@intel.com</a>> wrote:<br><br></div><blockquote type="cite">
<div>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Vinay, good summary of the options and their pros-cons!</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The simple solution does not waste IP addresses, same we have 2 servers and the first exhausts its address pool, then the second server is the only one with
addresses left, we it will get used. A negative is that if one of the servers were to go down, we have lost access to half the address space .. but if and when the server comes back, all shall be good. In the meantime, guess we would need to monitor the dhcp
agents along with all other services/servers to see if they are alive.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal">- Split scope DHCP (two or more servers split the IP address and there is no overlap)</p>
<p class="MsoNormal"> pros: simple</p>
<p class="MsoNormal"> cons: wastes IP addresses,</p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Vinay Bannai [<a href="mailto:vbannai@gmail.com">mailto:vbannai@gmail.com</a>]
<br>
<b>Sent:</b> Friday, November 30, 2012 3:49 PM<br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> Re: [openstack-dev] [Quantum] continuing todays discussion about the l3 agents</span></p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Gary and Mark,</p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">You brought up the issue of scaling horizontally and vertically in your earlier email. In the case of horizontal scaling, I would agree that it would have to be based on the "scheduler" approach proposed by Gong and Nachi. </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">On the issue of vertical scaling (I am using the DHCP redundancy as an example), I think it would be good to base our discussions on the various methods that have been discussed and do pro/con analysis in terms of scale, performance and
other such metrics. </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">- Split scope DHCP (two or more servers split the IP address and there is no overlap)</p>
</div>
<div>
<p class="MsoNormal"> pros: simple</p>
</div>
<div>
<p class="MsoNormal"> cons: wastes IP addresses,</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">- Active/Standby model (might have run VRRP or hearbeats to dictate who is active)</p>
</div>
<div>
<p class="MsoNormal"> pros: load evenly shared</p>
</div>
<div>
<p class="MsoNormal"> cons: needs shared knowledge of address assignments, </p>
</div>
<div>
<p class="MsoNormal"> need hearbeats or VRRP to keep track of failovers</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">- LB method (use load balancer to fan out to multiple dhcp servers)</p>
</div>
<div>
<p class="MsoNormal"> pros: scales very well </p>
</div>
<div>
<p class="MsoNormal"> cons: the lb becomes the single point of failure,</p>
</div>
<div>
<p class="MsoNormal"> the lease assignments needs to be shared between the dhcp servers</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">I see that the DHCP agent and the quantum server communicate using RPC. Is the plan to leave it alone or migrate it towards something like AMQP based server in the future when the "scheduler" stuff is implemented. </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Vinay</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">On Wed, Nov 28, 2012 at 8:03 AM, Mark McClain <<a href="mailto:mark.mcclain@dreamhost.com" target="_blank">mark.mcclain@dreamhost.com</a>> wrote:</p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
On Nov 28, 2012, at 8:03 AM, gong yong sheng <<a href="mailto:gongysh@linux.vnet.ibm.com">gongysh@linux.vnet.ibm.com</a>> wrote:<br>
<br>
> On 11/28/2012 08:11 AM, Mark McClain wrote:<br>
>> On Nov 27, 2012, at 6:33 PM, gong yong sheng <<a href="mailto:gongysh@linux.vnet.ibm.com">gongysh@linux.vnet.ibm.com</a>> wrote:<br>
>><br>
>> Just wanted to clarify two items:<br>
>><br>
>>>> At the moment all of the dhcp agents receive all of the updates. I do not see why we need the quantum service to indicate which agent runs where. This will change the manner in which the dhcp agents work.<br>
>>> No. currently, we can run only one dhcp agent since we are using a topic queue for notification.<br>
>> You are correct. There is a bug in the underlying Oslo RPC implementation that sets the topic and queue names to be same value. I didn't get a clear explanation of this problem until today and will have to figure out a fix to oslo.<br>
>><br>
>>> And one problem with multiple agents serving the same ip is:<br>
>>> we will have more than one agents want to update the ip's leasetime now and than.<br>
>> This is not a problem. The DHCP protocol was designed for multiple servers on a network. When a client accepts a lease, the server that offered the accepted lease will be the only process attempting to update the lease for that port. The other DHCP instances
will not do anything, so there won't be any chance for a conflict. Also, when a client renews it sends a unicast message to that previous DHCP server and so there will only be one writer in this scenario too. Additionally, we don't have to worry about conflicting
assignments because the dhcp agents use the same static allocations from the Quantum database.<br>
> I mean dhcp agent is trying to update leasetime to quantum server. If we have more than one dhcp agents, this will cause confusion.<br>
> def update_lease(self, network_id, ip_address, time_remaining):<br>
> try:<br>
> self.plugin_rpc.update_lease_expiration(network_id, ip_address,<br>
> time_remaining)<br>
> except:<br>
> self.needs_resync = True<br>
> LOG.exception(_('Unable to update lease'))<br>
> I think it is our dhcp agent's defect. Why does our dhcp agent need the lease time? all the IPs are managed in our quantum server, there is not need for dynamic ip management in dhcp server managed by dhcp agent.</p>
</div>
<p class="MsoNormal">There cannot be confusion. The dhcp client selects only one server to accept a lease, so only one agent will update this field at a time. (See RFC2131 section 4.3.2 for protocol specifics). The dnsmasq allocation database is static in
Quantum's setup, so the lease renewal needs to propagate to the Quantum Server. The Quantum server then uses the lease time to avoid allocating IP addresses before the lease has expired. In Quantum, we add an additional restriction that expired allocations
are not reclaimed until the associated port has been deleted as well.</p>
<div>
<div>
<p class="MsoNormal"><br>
mark<br>
<br>
<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></p>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
</p>
<div>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">-- <br>
Vinay Bannai<br>
Email: <a href="mailto:vbannai@gmail.com">vbannai@gmail.com</a><br>
Google Voice: 415 938 7576</p>
</div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>OpenStack-dev mailing list</span><br><span><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a></span><br>
<span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br></div></blockquote></body></html>