共计 3302 个字符，预计需要花费 9 分钟才能阅读完成。
你有没有碰到过 OpenStack 中，VM 失去 IP 地址的问题？如果有的话，你知道那可能是什么问题
——特别是如果你拥有大量的节点和 VM。你的客户会因为没有明显原因却断了与 VM 的连接而感到 挫败。甚至云的支持团队会为 log 文件里没有提示却出现问题感到挫败。
听起来很熟悉？
在这篇 blog 里，我将会分享我的一些关于 Openstack 网络的经验，特别是承担为 VM 分配 IP 地址的责任的 DHCP 子组件。
为什么我们会把问题归咎于 DHCP 组件？因为这些特定的问通常都是由这个小但明显微不足道的 OpenStack 组件导致的。
在 Ubuntu 12.10 上安装部署 Openstack http://www.linuxidc.com/Linux/2013-08/88184.htm
Ubuntu 12.04 OpenStack Swift 单节点部署手册 http://www.linuxidc.com/Linux/2013-08/88182.htm
OpenStack 云计算快速入门教程 http://www.linuxidc.com/Linux/2013-08/88186.htm
企业部署 OpenStack：该做与不该做的事 http://www.linuxidc.com/Linux/2013-09/90428.htm
CentOS 6.5 x64bit 快速安装 OpenStack http://www.linuxidc.com/Linux/2014-06/103775.htm
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. 租赁时间。默认情况下是 120s，你大概会知道，在租赁时间内，dhcp 客户端会尝试中途延长租赁时间。这意味着每个 VM 会一分钟更新一次他们的 ip 地址。
2. 去启动一个包含 65535 个静态租赁的 DNSmasq 实例几乎需要 4 分钟（3 分 43 秒）。一般这会发生在 neutron 为新的 VM 分配新的 ip 地址，接着强行 reload DNSmasq 时。在此时，将没有 DHCP 服务会为相应的私有 Neutron 网络提供服务。
3. 如果你没有在 dnsmasq 的配置中使用 no-ping 选项——这是应归于对安全担忧的 OpenStack 的默认设置——你会因非常慢的服务速度感到痛苦，因为在 dnsmasq 中，一个分开的 pinger 进程会被用于检查所提供的 ip 地址是否已经在使用中。包含 no-ping 选项，dnsmasq 将能在 10 分钟内为 160 个请求提供服务并且不会失去它们，尽管这依赖于核心（core）速度和 CPU 速度。
4.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 地址的能力。
5. 企图通过显著的增加 ip 的租赁时间去解决这些性能问题，这会导致 neutron 释放 ip 地址这方面的大问题（如果你的云负载均衡地改变 )。默认情况下，neutron 会为一个 VM 分配一个 ip 地址达 24 小时（neutron will allocate an IP address to a VM for 24 hours），独立于实际的租赁时间。当然，默认情况下，neutron 不会为已经终止了的实例提供 ip 地址直至 24 小时。
你可以采取的措施
幸运的是，你可以做点事解决问题，如果你使用 openstack 并拥有一个地址空间大于 255 个地址（/24）的私有网络，
接着你应该考虑调整 dnsmasq 和 network 节点自身的默认参数。
1. 增加 ip 的租赁时间以减少每秒来自 VM 的尝试更新 ip 地址的请求数量。根据一般的场景计算新的租赁时间，
记住虚拟机生命周期的平均时间。由于一个 Bug，设置太大的租赁时间值会强迫 OpenStack 在数据库中保留这个 ip 地址为“used”的状态。即使 VM 已经被删除，因为 neutron 的租赁时间在数据库中，neutron 将不会释放这个 ip 地址。
2. 增加 MAC 地址表的尺寸使其能服务至少一千个主机。要做到这样，典型地，你可以设置 dhcp-agent 所在主机
的 sysctl 变量（通常在 /etc/sysctl.conf）。视情况，你可以在所有与网络有关的节点执行以下操作，这些变量
如此设置：
net.ipv4.neigh.default.gc_thresh1 = 1024 net.ipv4.neigh.default.gc_thresh2 = 4096 net.ipv4.neigh.default.gc_thresh3 = 81923. 为 DNSmasq 的默认参数加上 no-ping 选项。这个改变能够使其每秒处理多 10-20 个请求，因为在被实际分配之前，dnsmasq 无需再尝试 ping 那些 ip。如果你使用 OpenStack 作为你的基础设施的一部分，记住，你必须谨慎地考虑这个选项。比如，如果你正使用提供者网络（provider networks）并且你的 VM 与其他物理服务器、设备、等等是单一 L2 域的组成部分，IP 冲突是可能发生的的, 可以造成严重破坏。
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 选项和如何根据情况调整他们。
Linux 系统下构建 DHCP 服务器 http://www.linuxidc.com/Linux/2013-06/86531.htm
CentOS 下配置主从 DNS 服务器以及 DHCP 下的 DDNS http://www.linuxidc.com/Linux/2013-06/85634.htm
SUSE Linux 11 pxe+DHCP+tftp+ftp 无人值守安装 http://www.linuxidc.com/Linux/2013-06/85481.htm
Linux 下架设 DHCP 服务器过程及 3 种测试 http://www.linuxidc.com/Linux/2013-05/84832.htm
Linux 上一步一步实现 DHCP 服务器 http://www.linuxidc.com/Linux/2013-04/82244.htm
