<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 12/01/2012 07:49 AM, Vinay Bannai
wrote:<br>
</div>
<blockquote
cite="mid:CAO48XRErB0BmV0KnS+dAooXiM7fi454wpqjvUBN9YNRLbEJkFg@mail.gmail.com"
type="cite">Gary and Mark,
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>- Split scope DHCP (two or more servers split the IP address
and there is no overlap)</div>
<div> pros: simple</div>
<div> cons: wastes IP addresses,</div>
<div><br>
</div>
<div>- Active/Standby model (might have run VRRP or hearbeats to
dictate who is active)</div>
<div> pros: load evenly shared</div>
<div> cons: needs shared knowledge of address assignments, </div>
<div> need hearbeats or VRRP to keep track of failovers</div>
</blockquote>
another one is the IP address waste. we need one VIP, and 2+ more
address for VRRP servers. ( we can use dhcp server's ip if we don't
want to do load balancing behind the VRRP servers)<br>
another one is it will make system complicated.<br>
<blockquote
cite="mid:CAO48XRErB0BmV0KnS+dAooXiM7fi454wpqjvUBN9YNRLbEJkFg@mail.gmail.com"
type="cite">
<div><br>
</div>
<div>- LB method (use load balancer to fan out to multiple dhcp
servers)</div>
<div> pros: scales very well </div>
<div> cons: the lb becomes the single point of failure,</div>
<div> the lease assignments needs to be shared between
the dhcp servers</div>
<div><br>
</div>
</blockquote>
LB method will also wast ip address. First we at lease need a VIP
address. then we will need more dhcp servers running for one network.<br>
If we need to VRRP the VIP, we will need 2+ more addresses.<br>
another one is it will make system complicated.<br>
<blockquote
cite="mid:CAO48XRErB0BmV0KnS+dAooXiM7fi454wpqjvUBN9YNRLbEJkFg@mail.gmail.com"
type="cite">
<div>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. <br>
</div>
</blockquote>
I am not very clear your point. But current RPC is on AMQP.<br>
<blockquote
cite="mid:CAO48XRErB0BmV0KnS+dAooXiM7fi454wpqjvUBN9YNRLbEJkFg@mail.gmail.com"
type="cite">
<div><br>
</div>
<div>Vinay</div>
<div><br>
</div>
<div><br>
</div>
<div class="gmail_quote">On Wed, Nov 28, 2012 at 8:03 AM, Mark
McClain <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mark.mcclain@dreamhost.com" target="_blank">mark.mcclain@dreamhost.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On Nov 28, 2012, at 8:03 AM, gong yong sheng <<a
moz-do-not-send="true"
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
moz-do-not-send="true"
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.<br>
<br>
</div>
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.<br>
<div class="HOEnZb">
<div class="h5"><br>
mark<br>
<br>
<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>
</div>
</div>
</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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>