前几个星期,社区通过了一个 Patch 来解决一个遗留很久的 DHCP 相关的问题,这个 Patch 并不复杂(review 地址是 https://review.openstack.org/#/c/185486/),但为什么这么做却有一点故事,拿出和大家聊一聊。
事情从 DHCP HA 说起。我们知道 Neutron 的架构是每个“网络”(Network),都会有一个相应的 namespace 名为 qdhco-XXX(XXX 为网络的 UUID)运行在网络节点上。这个网络命名空间内会有一个 tuntap 设备,名为 tapXXX(XXX 为 port 的 ID),然后有一个 dnsmasq 进程与之绑定。
这样,每当新的虚拟机启动,自动广播 DHCP 请求,namespace 下的 dnsmasq 将收到这个广播包并根据 dhcp-hostfile 里的内容对 VM 给予回应,分配并确认其 IP 地址。这一切都挺好的,先不考虑网络规模很大时 dnsmasq 的承载能力, 不考虑将 dhcp 分布式时,it works。
但如果我们想尝试将 DHCP 做 HA 呢?考虑到如果这个 dnsmasq 进程挂掉了,或者这个网络节点上的 ovs 异常了,甚至网络节点挂掉了…… 嗯,让我们先从 DHCP 的流程说起。
IPv4 版的 DHCP 是按照 RFC 2131 Dynamic Host Configuration Protocol 标准的,先撇开其具体细节,大概的 DHCP 流程是这样的:
[caption id="" align="alignnone" width="640"]
首先在 DHCP 发现阶段,客户端发送目的地址为 255.255.255.255 的 UDP 广播包,然后服务端回复 DHCP OFFER,包含分配的 IP、默认路由、租约有效期等等。为了避免同一个网络下有多个 DHCP 服务端,而客户端只接受一个 DHCP 结果,所以客户端需要再发广播通知所有 DHCP 服务端自己接受了哪个 DHCP 分配结果,这个包里含有它自己给自己确定的 IP 地址,这个 IP 地址来自于哪个 DHCP 服务端(服务端的 IP 地址)。最后服务端广播一条 ACK 作为结束。 … Read More →
近期评论