<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/02/2012 11:16 PM, Gary Kotton
wrote:<br>
</div>
<blockquote cite="mid:50BB70CA.7040009@redhat.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
On 12/01/2012 03:31 AM, gong yong sheng wrote:
<blockquote cite="mid:50B95DF3.4050506@linux.vnet.ibm.com"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<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. <br>
</div>
</blockquote>
</blockquote>
<br>
I am not sure that I understand the need for a scheduler when it
comes to the DHCP agent. In my opinion this is unnecessary
overhead and it is not necessarily required. <br>
<br>
Last week Mark addressed the problem with all of the DHCP agents
all listening on the same message queue. In theory we are able to
run more than one DHCP agents in parallel. This offers HA at the
expense of an IP per DHCP agent per subnet. <br>
<br>
I think that for the DHCP agents we need to look into enabling the
DHCP agents to treat specific networks. This can be done in a very
rudimentary way - have a configuration variable for the DHCP agent
indicating a list of networks to be treated by the agent. A
orchestration tool can just configure the network ID's and launch
the service - then we will have scalable and highly available DHCP
service. I would prefer not to have to add this into the Quantum
API as it just complicates things.<br>
<br>
<br>
<br>
</blockquote>
I think we should not write configure item on the side of dhcp
agents. we should allow to add dynamically dhcp agent and then
configure it through quantum server.<br>
zero configuration (except the quantum server and message queue
configuration) on dhcp agents will help a lot.<br>
We just start a new dhcp agent, and then config it through quantum
API (maybe extension) or schedule networks auto to newly added dhcp
agents.<br>
<blockquote cite="mid:50BB70CA.7040009@redhat.com" type="cite"> <br>
<blockquote cite="mid:50B95DF3.4050506@linux.vnet.ibm.com"
type="cite">
<blockquote
cite="mid:CAO48XRErB0BmV0KnS+dAooXiM7fi454wpqjvUBN9YNRLbEJkFg@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a moz-do-not-send="true" 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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a moz-do-not-send="true" 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>
<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>