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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
