Why Namespace? - 每天5分钟玩转 OpenStack(102)

上一节我们讨论了 Neutron 将虚拟 router 放置到 namespace 中实现了不同 subnet 之间的路由。
今天探讨为什么要用 namespace 封装 router?

回顾一下前面的网络逻辑结构图:


我们需要讨论一个深层次的问题:
为什么不直接在 tape17162c5-00 和 tapd568ba1a-74 上配置 Gateway IP,而是引入一个 namespace,在 namespace 里面配置 Gateway IP 呢?

首先考虑另外一个问题:
如果不用 namespace,直接 Gareway IP 配置到 tape17162c5-00 和 tapd568ba1a-74 上,能不能连通 subnet_172_16_100_0 和 subnet_172_16_101_0 呢?

答案是可以的,只要控制节点上配置了类似下面的路由。

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
172.16.100.0    *               255.255.255.0   U     0      0        0 tapd568ba1a-74
172.16.101.0    *               255.255.255.0   U     0      0        0 tape17162c5-00

既然不需要 namespace 也可以路由,为什么还要加一层 namespace 增加复杂性呢?
其根本原因是:为了支持网络重叠

云环境下,租户可以按照自己的规划创建网络,不同租户的网络是可能重叠的。
将路由功能放到 namespace 中,就能隔离不同租户的网络,从而支持网络重叠。

下面通过例子进一步解释。

Tenant A  vlan100 subnet A-1: 10.10.1.0/24    {"start": "10.10.1.1", "end": "10.10.1.254"}
Tenant A  vlan101 subnet A-2: 10.10.2.0/24    {"start": "10.10.2.1", "end": "10.10.2.254"}

Tenant B  vlan102 subnet B-1: 10.10.1.0/24    {"start": "10.10.1.1", "end": "10.10.1.254"}
Tenant B  vlan103 subnet B-2: 10.10.2.0/24    {"start": "10.10.2.1", "end": "10.10.2.254"}

A,B 两个租户定义了完全相同的两个 subnet,网络完全重叠。

不使用 namespace 的场景

如果不使用 namespace,网络结构如下:

其特征是网关 IP 配置在 TAP interface 上。
因为没有 namespace 隔离,router_100_101 和 router_102_103 的路由条目都只能记录到控制节点操作系统(root namespace)的路由表中,内容如下:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
 10.10.1.0                 *               255.255.255.0   U     0      0        0     tap1
 10.10.2.0                 *               255.255.255.0   U     0      0        0     tap2
 10.10.1.0                 *               255.255.255.0   U     0      0        0     tap3
 10.10.2.0                 *               255.255.255.0   U     0      0        0     tap4

这样的路由表是无法工作的。
按照路由表优先匹配原则,Tenant B 的数据包总是错误地被 Tenant A 的 router 路由。
例如 vlan102 上有数据包要发到 vlan103。
选择路由时,会匹配路由表的第二个条目,结果数据被错误地发到了 vlan101。

使用 namespace 的场景

如果使用 namespace,网络结构如下:

其特征是网关 IP 配置在 namespace 中的 veth interface 上。
每个 namespace 拥有自己的路由表。

router_100_101 的路由表内容如下:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.10.1.0                 *               255.255.255.0   U     0      0        0     qr-1
10.10.2.0                 *               255.255.255.0   U     0      0        0     qr-2

router_102_103 的路由表内容如下:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.10.1.0                 *               255.255.255.0   U     0      0        0     qr-3
10.10.2.0                 *               255.255.255.0   U     0      0        0     qr-4

这样的路由表是可以工作的。

例如 vlan102 上有数据包要发到 vlan103。
选择路由时,会查看 router_102_103 的路由表, 匹配第二个条目,数据通过 qr-4 被正确地发送到 vlan103。

同样当 vlan100 上有数据包要发到 vlan101时,会匹配 router_100_101 路由表的第二个条目,数据通过 qr-2 被正确地发送到 vlan101。

可见,namespace 使得每个 router 有自己的路由表,而且不会与其他 router 冲突,所以能很好地支持网络重叠。

好了,目前我们已经搞清楚了 Neutron 内部 subnet 之间是如何通信的了。
下一节我们将学习 OpenStack 内部网络如何与外部网络通信。

时间: 2024-10-25 13:13:45

Why Namespace? - 每天5分钟玩转 OpenStack(102)的相关文章

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

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

创建 Pool & VIP - 每天5分钟玩转 OpenStack(122)

上节完成了 LBaaS 配置,今天我们开始实现如下 LBaaS 环境. 环境描述如下:1. 创建一个 Pool "web servers".2. 两个 pool member "WEB1" 和 "WEB2",均为运行 Ubuntu cloud image 的 instance.3. load balancer VIP 与 floating IP 关联.4. 位于外网的 client 通过 floating IP 外网访问 web server.

每天5分钟 玩转OpenStack

最近在学习OpenStack的相关知识,一直苦于OpenStack的体系庞大以及复杂程度,学习没有进度,停滞不前.偶然机会在51CTO上发现了一个热点的专题关于OpenStack的,题目叫做<每天5分钟 玩转OpenStack>,抱着试试的态度看了几篇,被文章的内容和书写风格吸引了,内容全面,思路清晰,简单易懂,关键是每篇博文的内容很少,绝对是一泡大便的功夫.每周一.周三.周五定时更新,微信也有同步更新.不过大神在博客园cnblogs上的博文没有目录,每次翻阅的时候甚是费劲,可能是大神太忙了,

学习 OpenStack 的方法论 - 每天5分钟玩转 OpenStack(150)

作为 OpenStack 的核心教程,我们已经到了最后总结的部分. OpenStack 目前已经有好几十个模块,本教程讨论的是最最重要的核心模块:Keystone,Nova,Glance,Cinder 和 Neutron.请大家看下图: 此图截自 https://www.openstack.org/software/project-navigator/,这是 OpenStack 官方定义的 6 个 Core Service.每个模块都会从三个维度来衡量: ADOPTION - 采用度 MATUR

cloud-init 典型应用 - 每天5分钟玩转 OpenStack(174)

本节介绍几个 cloud-init 的典型应用:设置 hostanme,设置用户初始密码,安装软件. 设置 hostname cloud-init 默认会将 instance 的名字设置为 hostname.但这样不太方便,有时希望能够将二者分开,可利用 cloud-init 的set_hostname 模块实现.set_hostname 它会查询 metadata 中 hostname 信息,默认值就是 instance 的名字.我们可以指定自己的 hostname,方法是将下面的内容传给 c

Metadata Service 架构详解 - 每天5分钟玩转 OpenStack(165)

下面是 Metadata Service 的架构图,本节我们详细讨论各个组件以及它们之间的关系. nova-api-metadata nova-api-metadata 是 nova-api 的一个子服务,它是 metadata 的提供者,instance 可以通过 nova-api-metadata 的 REST API 来获取 metadata 信息. nova-api-metadata 运行在控制节点上,服务端口是 8775. 通过进程 ID 13415 查看该启动程序. 我们这个环境是

理解 Glance - 每天5分钟玩转 OpenStack(20)

OpenStack 由 Glance 提供 Image 服务. 理解 Image 要理解 Image Service 先得搞清楚什么是 Image 以及为什么要用 Image? 在传统 IT 环境下,安装一个系统是要么从安装 CD 从头安装,要么用 Ghost 等克隆工具恢复.这两种方式有如下几个问题: 如果要安装的系统多了效率就很低 时间长,工作量大 安装完还要进行手工配置,比如安装其他的软件,设置 IP 等 备份和恢复系统不灵活 云环境下需要更高效的解决方案,这就是 Image. Image

获取 metadata 过程详解 - 每天5分钟玩转 OpenStack(167)

接上节,启动 neutron router 后 instance c1 终于拿到了 metadata, 从下面 c1 的启动日志可知: c1 所认为的 metadata 服务地址是 169.254.169.254,端口为 80.我们在 c1 中尝试访问一下 metadata. 确实能够拿到 metadata.但我们知道 nova-api-metadata 是运行在控制节点上的,IP并不是 169.254.169.254,这是怎么实现的呢?下面我们分析一下这个过程. 从 c1 的路由表得访问 16

添加 Pool Member - 每天5分钟玩转 OpenStack(123)

我们已经有了 Load Balance Pool "web servers"和 VIP,接下来需要往 Pool 里添加 member 并学习如何使用 cloud image. 先准备两个 instance: "Web1" 和 "Web2". 使用 Ubuntu Cloud Image 由于 cirros 镜像不能运行 HTTP 服务,我们将使用 Ubuntu Cloud Image.下载地址为 http://uec-images.ubuntu.c