用 namspace 隔离 DHCP 服务 - 每天5分钟玩转 OpenStack(90)

Neutron 通过 dnsmasq 提供 DHCP 服务,而 dnsmasq 如何独立的为每个 network 服务呢?

答案是通过 Linux Network Namespace 隔离,本节将详细讨论。

在二层网络上,VLAN 可以将一个物理交换机分割成几个独立的虚拟交换机。 类似地,在三层网络上,Linux network namespace 可以将一个物理三层网络分割成几个独立的虚拟三层网络。

每个 namespace 都有自己独立的网络栈,包括 route table,firewall rule,network interface device 等。

Neutron 通过 namespace 为每个 network 提供独立的 DHCP 和路由服务,从而允许租户创建重叠的网络。
如果没有 namespace,网络就不能重叠,这样就失去了很多灵活性。

每个 dnsmasq 进程都位于独立的 namespace, 命名为
qdhcp-<network id>,例如 flat_net,我们有:

ip netns list 命令列出所有的 namespace。
qdhcp-f153b42f-c3a1-4b6c-8865-c09b5b2aa274 就是 flat_net 的 namespace。

其实,宿主机本身也有一个 namespace,叫 root namespace,拥有所有物理和虚拟 interface device。
物理 interface 只能位于 root namespace。

新创建的 namespace 默认只有一个 loopback device。
管理员可以将虚拟 interface,例如 bridge,tap 等设备添加到某个 namespace。

对于 flat_net 的 DHCP 设备 tap19a0ed3d-fe,需要将其放到 namespace qdhcp-f153b42f-c3a1-4b6c-8865-c09b5b2aa274 中,但这样会带来一个问题:
tap19a0ed3d-fe 将无法直接与 root namespace 中的 bridge 设备 brqf153b42f-c3 连接。

Neutron 使用 veth pair 解决了这个问题

veth pair 是一种成对出现的特殊网络设备,它们象一根虚拟的网线,可用于连接两个 namespace。向 veth pair 一端输入数据,在另一端就能读到此数据。

tap19a0ed3d-fe 与 ns-19a0ed3d-fe 就是一对 veth pair,它们将 qdhcp-f153b42f-c3a1-4b6c-8865-c09b5b2aa274 连接到 brqf153b42f-c3。如下图所示:

可以通过 ip netns exec <network namespace name> <command> 管理 namespace。
例如查看 ns-19a0ed3d-fe 的配置:

理解了 namespace,下一节我们分析 instance 从 dnsmasq 获取 IP 的详细过程。

 

时间: 2024-07-29 13:01:20

用 namspace 隔离 DHCP 服务 - 每天5分钟玩转 OpenStack(90)的相关文章

配置 DHCP 服务 - 每天5分钟玩转 OpenStack(89)

前面章节我们看到 instance 在启动过程中能够从 Neutron 的 DHCP 服务获得 IP,本节将详细讨论其内部实现机制. Neutron 提供 DHCP 服务的组件是 DHCP agent. DHCP agent 在网络节点运行上,默认通过 dnsmasq 实现 DHCP 功能. 配置 DHCP agent DHCP agent 的配置文件位于 /etc/neutron/dhcp_agent.ini. dhcp_driver使用 dnsmasq 实现 DHCP. interface_

写在最前面 - 每天5分钟玩转 OpenStack(1)

<每天5分钟玩转 OpenStack>是一个 OpenStack 教程,这是第 1 篇. 这个教程有下面两个特点: 系统讲解 OpenStack 从架构到各个组件:从整体到细节逐一讨论 重实践并兼顾理论 主要从实际操作的角度带着大家学习 OpenStack.   为啥要写这个? 简单回答是:因为OpenStack 学习难度大,但如果掌握了价值会很大 先做一个自我介绍吧. 本人网名CloudMan,在 IT 这个行当已经摸爬滚打了十多年,05年之前是搞上层应用开发的,那时候 Java 比较火,所

获取 dhcp IP 过程分析 - 每天5分钟玩转 OpenStack(91)

前面我们已经讨论了 DHCP agent 的配置以及 namespace 如何隔离 dnsmasq 服务,本节将以 cirros-vm1 为例分析获取 DHCP IP 的详细过程. 在创建 instance 时,Neutron 会为其分配一个 port,里面包含了 MAC 和 IP 地址信息.这些信息会同步更新到 dnsmasq 的 host 文件.如下图所示: 同时 nova-compute 会设置 cirros-vm1 VIF 的 MAC 地址. 一切准备就绪,instance 获取 IP

Neutron Vlan Network 原理- 每天5分钟玩转 OpenStack(92)

前面我们陆续学习了 Neutron local network,flat network 和 DHCP 服务,从本节将开始讨论 vlan network. vlan network 是带 tag 的网络,是实际应用最广泛的网络类型.下图是 vlan100 网络的示例. 1. 三个 instance 通过 TAP 设备连接到名为 "brqXXXX" linux bridge. 2. 在物理网卡 eth1 上创建了 eth1.100 的 vlan interface,eth1.100 连接

Service Plugin / Agent - 每天5分钟玩转 OpenStack(73)

Core Plugin/Agent 负责管理核心实体:net, subnet 和 port.而对于更高级的网络服务,则由 Service Plugin/Agent 管理.Service Plugin 及其 Agent 提供更丰富的扩展功能,包括路由,load balance,firewall等,如图所示: DHCPdhcp agent 通过 dnsmasq 为 instance 提供 dhcp 服务. Routingl3 agent 可以为 project(租户)创建 router,提供 Neu

将 instance 连接到 flat_net - 每天5分钟玩转 OpenStack(88)

上一节我们创建了 "flat_net",本节将在此网络中部署 instance 并验证连通性. launch 新的 instance "cirros-vm1",选择网络 falt_net. cirros-vm1 分配到的 IP 为 172.16.1.103. cirros-vm1 被 schedule 到控制节点,对应的 tap 设备为 tapc1875c7f-cb,并且已经连接到 bridge. 当前 flat_net 的结构如下: 继续用同样的方式 launch

实践 config drive - 每天5分钟玩转 OpenStack(170)

如果 instance 无法通过 metadata service 获取 metadata(无 DHCP 或者 nova-api-metadata 服务),instance 还可以通过 config drive 获得 metadata.   config drive 是一个特殊的文件系统,OpenStack 会将 metadata 写到 config drive,并在 instance 启动时挂载给 instance.如过 instance 安装了 cloud-init,config drive

获取 metadata 的完整例子 - 每天5分钟玩转 OpenStack(166)

我们将通过实验详细分析 instance 从 nova-api-metadata 获取信息的完整过程.   环境介绍 1. 一个 all-in-one 环境(多节点类似). 2. 已创建 neutron 网络 test_net,DHCP 已启动.在这个 metadata 实验中, test_net 的 type 不重要,flat.vlan.vxlan 都可以. 3. 暂无 neutron router. 准备就绪,开始实验.   启动 instance 通过 cirros 镜像部署一个 inst

instance 网卡是如何被拉起来的?- 每天5分钟玩转 OpenStack(172)

instance 的网卡是如何被配置并拉起的?这是理解和用好 cloud-init 非常关键的一步.我们先讨论一个最简单基础的场景:镜像中没有安装 cloud-init. 此时 instance 启动时网卡能不能被拉起来完全 靠运气!是的,就是运气. 因为这种情况下网卡的配置是死的,完全依赖于镜像中 /etc/network/interfaces 原有的配置.比如原镜像中的配置是: auto eth0iface eth0 inet dhcp instance 只有满足下面所有条件网卡才能被拉起来