Open Stack

Single IP per DHCP is nice.

And move dhcp agent away from network node gives important thing: you 
can create isolated tenant networks without headache with dhcp-agents 
scheduling. Neutron does not supports now AZ from nova, and DHCP is just 
yet another thing to mess up with isolation.

Some ideas:

1. You should create separate table(s) for DHCP with persistent rules 
(not 'disk-persistent', but 'not expiring') to helps debug problems. 
Rules in that table will have counters (bytes, packets and inactive time 
counter) - this really helps to see what happens.
2. Some kind of watching (tail -f style) utility to watch for instances 
requests.
3. Rejecting to start/stop instance (configure port) if dhcp agent on 
the host is not available. Get "ERROR" with meaningful trace is much 
better than 'oh instance does not reply to pings after reboot and we 
don't know why'.

On 10/06/2014 10:09 AM, Mike Kolesnik wrote:
> Hi operators,
>
> I wanted to ask for feedback on a design issue regarding DHCP agent and IP per
> agent.
>
> So a short introduction first - I want to propose a spec to have a distributed
> DHCP agent that can run directly on the compute node, and service only the VMs
> running locally on it.
> This will help balance out the DHCP agent accross the cloud and each node will
> only get the information it requires (no more MB size messages which get the
> queue stuck).
> It will also limit the scope of failure of the DHCP agent and/or service to
> that compute node alone.
>
> Now, regarding the IP consumption there are two possible alternatives:
> 1. Use single IP per serviced subnet for all the servers. (similar to DVR)
> 2. Use IP per server per subnet per host where VMs are serviced.
>
> So in a theoretical cloud with 100 running VMs for 10 subnets and 10 compute
> nodes, per subnet the 1st approach will take only 1 IP while the second will
> take a minimum of 1 IP and a maximum of 10 (limited by amount of compute nodes).
>
> Now, I know the 1st solution seems very appealing but thinking of it further
> reveals very serious limitations:
> * No HA for DHCP agents is possible (more prone to certain race conditions).
> * DHCP IP can't be reached from outside the cloud.
> * You will just see a single port per subnet in Neutron, without granularity of
> the host binding (but perhaps it's not that bad).
> * This solution will be tied initially only to OVS mechanism driver, each other
> driver or 3rd party plugin will have to support it individually in some way.
>
> So basically my question is - which solution would you prefer as a cloud op?
>
> Is it that bad to consume more than 1 IP, given that we're talking about private
> isolated networks?
>
> Regards,
> Mike
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators