Open Stack

Hi,
There were two ideas discussed at the summit the first is the LBaaS and 
the second was improvements for the DHCP agent (multinode). I think that 
we can leverage the LBaaS to support a highly available and robust 
Quantum DHCP service.

This can be achieved as follows:

1. For each network that supports a DHCP service there will be a VIP for 
the DHCP address (this will also have the relevant health checks etc.)
2. Each DHCP running agent will be registered as a member (I hope that I 
have the terminology correct here). Basically vip = {dhcps1, dhcps2, ...}
3. All of the DHCP requests and lease updates will be sent via the VIP 
for the DHCP. The load balcner will select a DHCP server if this is the 
first time a request from the client has been made or it will forward to 
a existing server entry.

Please see the diagram below. This will enable a cluster of hosts on the 
same network tenant to get a highly available DHCP service - the DHCP 
server IP is the virtual IP (it is ideal to have an active backup load 
balancing pair to ensure HA - this could either be by VRRP or some 
propriatery method that any of the vendors support). My thinking is that 
if we can use this for the first LBaaS integration example then we are 
certainly moving in the right direction and we have killed two birds 
with one stone.

In the example below there will be 2 DHCP agents. The traffic will be 
load balanced by the active load balancer (in an active back 
configuration the persistent sessions will be maintained :)).

A few minor changes may be required when Nova receives the DHCP address 
- we should return the VIP address.



Ideas, comments or thoughts?

Thanks
Gary

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121125/3999ea98/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 25497 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121125/3999ea98/attachment.png>