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
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
