改善OpenStack上DHCP的性能的建议

　　你有没有碰到过OpenStack中，VM失去IP地址的问题?如果有的话，你应该知道那可能是什么问题

　　——特别是如果你拥有大量的节点和VM。你的客户会因为无明显原因却断了与VM的连接而感到挫败。甚至云的支持团队会为log文件里无提示却出现问题感到挫败。

　　听起来很熟悉?

　　在这篇blog里，我将会分享我的一些关于Openstack网络的经验，尤其是承担为VM分配IP地址的责任的DHCP子组件。

　　为什么我们会把问题归咎于DHCP组件?因为这些特定的问通常都是由这个小但明显微不足道的OpenStack组件造成的。

　　一、DHCP agent和DNSmasq

　　在OpenStack中，neutron-dhcp-agent为实例提供ip地址。理论上，neutron-dhcp-agent能够支持多种后端，但现在它只支持dnsmasq。当启动一个实例时，分配和配置(ip)的程序包含一个在dnsmasq config中储存ip地址的进程，接着启动或重载dnsmasq。一般情况下，OpenStack在每个网络中只有一个neutron-dhcp-agent负责spawn一个dnsmasq，因此，一个庞大的网络(包含所有子网)中只会有一个dnsmasq提供服务。理论上，并且根据实用的实验室测试，dnsmasq应该能每秒处理1000个DHCP请求，但这里有些事实要说明下：

　　第1点、企图通过显著的增加ip的租赁时间去解决这些性能问题，这会导致neutron释放ip地址这方面的大问题(如果你的云负载均衡地改变)。默认情况下，neutron会为一个VM分配一个ip地址达24小时(neutron will allocate an IP address to a VM for 24 hours)，独立于实际的租赁时间。当然，默认情况下，neutron不会为已经终止了的实例提供ip地址直至24小时。

　　第2点、Ubuntu和CentOS有mac地址表(neighbour table)被限制到/128/512/1024(net.ipv4.neigh.default.gc_thresh1/2/3)个记录。因为如此，不经常使用的 IP 记录将会异常快速老化(IP records that are not frequently used will age abnormally fast)这会影响网络性能并拖慢系统把流量发送至dhcp agent所在节点上的正确的mac地址的能力。

　　第3点、如果你没有在dnsmasq的配置中使用no-ping选项——这是应归于对安全担忧的OpenStack的默认设置——你会因非常慢的服务速度感到痛苦，由于在dnsmasq中，一个分开的pinger进程会被用于检查所提供的ip地址是否已经在使用中。包含no-ping选项，dnsmasq将能在10分钟内为160个请求提供服务并且不会失去它们，尽管这依赖于核心(core)速度和CPU速度。

　　第4点、租赁时间。默认情况下是120s，你大概会知道，在租赁时间内，dhcp客户端会尝试中途延长租赁时间。这意味着每个VM会一分钟更新一次他们的ip地址。

　　第5点、去启动一个包含65535个静态租赁的DNSmasq实例几乎需要4分钟(3分43秒)。一般这会发生在neutron为新的VM分配新的ip地址，接着强行reload DNSmasq时。在这个时候，将没有DHCP服务会为相应的私有Neutron网络提供服务。

　　二、你能够采取的措施

　　幸运的是，你能够做点事解决问题，如果你使用openstack并拥有一个地址空间大于255个地址(/24)的私有网络，

　　接着你应该考虑调整dnsmasq和network节点自身的默认参数。

　　措施1、为DNSmasq的默认参数加上no-ping选项。这个改变能够使其每秒处理多10-20个请求，因为在被实际分配之前，dnsmasq不需再尝试ping那些ip。如果你使用OpenStack作为你的基础设施的一部分，记住，你必须谨慎地考虑这个选项。比如，如果你正使用提供者网络(provider networks)并且你的VM与其他物理服务器、设备、等等是单一L2域的组成部分，IP冲突是可能发生的的,能够造成严重破坏。

　　措施2、增加ip的租赁时间以减少每秒来自VM的尝试更新ip地址的请求数量。根据一般的场景计算新的租赁时间，

　　记住虚拟机生命周期的平均时间。由于一个Bug，设置太大的租赁时间值会强迫OpenStack在数据库中保留这个ip地址为“used”的状态。就算VM已经被删除，因为neutron的租赁时间在数据库中，neutron将不会释放这个ip地址。

　　措施3、增加MAC地址表的尺寸使其能服务至少一千个主机。要做到这样，典型地，你能够设置dhcp-agent所在主机

　　的sysctl变量(通常在/etc/sysctl.conf)。视情况，你能够在所有与网络有关的节点执行以下操作，这些变量

　　设置如下图所示：

　　三、Neutron社区必须思考的改变

　　不幸地，在neutron中没有任何办法能为用户解决24小时ip分配的问题(the problem of 24 hour IP allocation)，这个问题应该从neutron自身的改变去解决。一个简单的解决方法是在neutron或dhcp-agent中增加一个能够配置的参数来修改租赁时间，并把它用作neutron数据库中的分配周期。这个方法表面看上去很完美但是仔细检查一下，你会意识到这会大大增加neutron-api/neutron-db的负载。因此，这不是一个正确的方法或者说这就是一个不正确的方法去解决问题。

　　取而代之的是，neutron应该在实例被终止时简单地从数据库中移除ip地址。这会解决所有问题并在云上实现

　　动态负载和ip地址的完美重用。【实际上，这恰好是Icehouse版本的情况，尽管目前问题有所减轻】

　　四、结论

　　正如我说的，我的所述只是覆盖了一个很小的OpenStack网络的子组件——DHCP服务。正如你所看到的， 如果配置不正确，特别是当你使用了DNSmasq的默认选项将会造成非常多的痛苦。上面我所推荐的希望能帮助你了解怎样选择具体的DNSmasq选项和怎样根据情况调整他们。

　　英文原文：Improving DHCP Performance In OpenStack

　　译文链接：http://www.oschina.net/translate/improving-dhcp-performance-openstack