【说明：阅读本篇文章，需要一定的预备知识“Neutron 网络实现模型”。关注微信公众号“标哥说天下”，回复“NMI” 或者 “nmi”，可以获取该文章。】

第五章 Neutron 逻辑模型

这一章的写作，对我来说，太有挑战。因为 OpenStack 有官网介绍它的 RESTful API。而这些 API 的介绍，就是基于 Neutron 逻辑模型的 CRUD（Create，Retrieve，Update，Delete，增加/查询/修改/删除）讲述。这意味着什么？这意味着官网是“模型 + CRUD”一起介绍，而我这里仅仅介绍模型，我的内心是几乎崩溃的，^_^

好吧，让我们来一场冒险之旅，看看我的功力到底如何，能不能在有官方 wiki 的基础上，写下一篇不一样的文章。

【版权统一申明】不能否认也没法避免，本章统一参考 OpenStack 关于 Neutron  API 的官网：https://developer.openstack.org/api-ref/networking/v2/?expanded=list-floating-ips-detail,show-subnet-details-detail 。

笔者也强烈建议您阅读该网页。

Neutron 把网络相关的逻辑模型，分为如下几个部分：

Layer2 Networking，Layer3 Networking，Security，Resource Management，QoS，LBaaS，Logging Resource (networking-midonet)，Router interface floating IP (networking-midonet)，FIP64 (networking-midonet)，BGP/MPLS VPN Interconnection。

本章也将基本围绕这些分类展开讲述。

Neutron 之所以把这些称为逻辑模型，是因为它的基本原理如下（草图）：

图１ Neutron 实现原理（草图）

这仅仅是一个草图，比较详细的图，我们会在 Neutron 架构分析相关章节描述，这里仅仅表达一个示意。从图中我们看到，所谓 Logic Model，其实直接地讲，只做了两件事情：（1）变身一套 RESTful API；（2）相关 API 操作所产生的数据存储在数据库（DB）里。非常完美，然并卵！

Neutron 要想把网络打通，还需要相关 Plugin/Agent 在计算节点/控制节点上做相关配置（请参见笔者所写的“Neutron 网络实现模型”），当然，Neutron 也可以通过相关的 Plugin 来配置真正的物理网元（这是另外的话题，笔者后面会在相关章节描述）。

总之，这些所谓的“逻辑”模型，真的只是一个逻辑上的表达而已！

我们会在本章后面的描述中，继续体会“逻辑”这两个字。

5.1 二层网络模型（Layer2 Networking Model）

L2(Layer2) Networking Model，主要包括 Network，Port 两个模型。下面我们一个一个讲述。

5.1.1 Network

Network，网络，即使在通信的语境里，也是一个非常大的概念。不过，Neutron 在这里特指 L2 Network。

5.1.1.1 Network 概述

我们直接 copy OpenStack 官网上关于 Network Model 的介绍，直接上表格：

表1 Network Logic Model

这个表格呢，我列在这里，您可以阅读，也可以暂时不阅读，因为我下面要展开描述。

5.1.1.2 租户（Tenant）

说到租户（Tenant），稍微有点尴尬，因为 tenant_id 和 project_id 的解释都是：The ID of the project。而且官网还说“Starting with the Newton release of the Networking service, the Networking API accepts the project_id attribute in addition to the tenant_id attribute in requests. The tenant_id attribute is accepted for backward compatibility. If both the project_id and the tenant_id attribute are provided in the same request, their values must be identical.”

也就是说，从 Newton 版本开始，tenant_id 存在的意义，可能只是为了后向兼容，只是一个历史的印记而已。

换句话说，笔者当年千辛万苦地把租户（Tenant）在脑中做个“脑筋急转弯”，好容易正确地理解了“租户不是人”这句话，好容易接纳了“租户”这个词，人家弃用了。

不过呢，笔者以为，玩笑归玩笑，无所谓是 tenant_id 也好，还是 project_id 也好，它（们）除了起到一个传统的 ID 的作用以外，还有一个更深层次的含义：租户隔离！

租户隔离，这四个字该怎么理解！笔者以为，需要往哲学意义上靠：租户隔离是为了共享！

隔离是为了共享！

这个世界最深沉的爱，不是在一起，而是离开！

好吧，不再感慨，一点一点分析这四个字：租户隔离！

说明几点：

（1）租户不是人，这句话的最简单的解释是：租户就是客户，而这里的客户指的是企业。

（2）虽然不能把租户理解为“人”，但是下文为了行文方便，还是把租户当作人来看待，把租户管理员简称为租户。

（3）租户隔离，其实是“多租户隔离”（单租户，也不存在隔离），但是下文为了行文方便，“多租户隔离”，简称“租户隔离”。

5.1.1.2.1 Neutron 语境下租户隔离的含义

租户隔离，在不同场景，不同语境下，有不同的含义，我们这里只讲述 Neutron 语境下，租户隔离的含义。

Neutron 语境下，从租户的视角，或者从需求的视角来讲，租户隔离有四种含义：管理面的隔离，数据面的隔离，逻辑资源层面的隔离，故障层面的隔离。

（1）管理面的隔离

管理面的隔离，指的是“管理权限”的隔离，如下图所示：

图２ 管理（控制）层面的隔离

图中两个网络，都是 Neutron 的范围，但是 Network1 属于 Tenant1，Network2 属于 Tenant2，这也就意味着：Tenant1 无法管理（增删改查）Tenant2 的网络（Network2）。Tenant2 亦然！

换句话说，一个 Tenant 只知道他自己的网络，其他网络他毫无知晓，毫无感觉。就像我们人类现在对“平行宇宙”的认识一样（如果真有的话）：猜想也许还有其他的平行宇宙吧，但是一无所知，一无所觉。也许，上帝的上帝，也在做租户隔离吧，细思极恐，^_^

需要强调的是，从 Neutron 自身来说，就是指的“控制节点”（虽然 Neutron 称呼自己那个节点叫“控制节点”，实际做了很多很多“管理层面”的工作），但是，作为一个实际的商业系统，比如现在那个最性感的解决方案 SDN（Sex Defined Network），其中某些场景的可能的架构是这样的，如下图所示：

图３ SDN 解决方案中的一种架构

在这个架构中，Neutron（Control Node）解决好自己的租户权限隔离问题，而作为整个解决方案，还需要解决从 APP 到 Controller，每一层的租户权限隔离的问题。

（2）数据面的隔离

数据面的隔离，指的是数据转发的隔离。不同租户的网络之间，是不能互通的（除非租户特殊要求，这个属于抬杠，我们不讨论）。

从管理权限角度，一个租户不能管理另一个租户的网络。同理，不同租户的网络也不能互通。

可能有人会问，说了“管理面”和“数据面”，那么“控制面”呢？对于控制面，我们有两点解释：

A. 控制面，不属于用户视角。或者话句话说，控制面是否隔离，用户不关心，这仅仅是一个内部实现。说的更装逼一点，这不是一个问题。

B. 控制面，分为两种，一种是基于经典 TCP/IP 协议的，一种是基于性感解决方案（SDN）的。基于经典 TCP/IP 协议的，跟数据面一样，这个控制面的隔离也是天然的（因为不同租户的网络，也根本感知不到彼此的存在）；基于 SDN 的控制面，也就是传说中的控制器（Controller），它怎么实现，取决于它自己，用户不关心。

（3）逻辑资源层面的隔离

逻辑资源，其实也有不同的定义，这里我们不纠结逻辑资源的定义本身，而是以举例（我负责举例）加联想（您负责联想）的方式来做个简单定义：逻辑资源指的是 IP 地址，VLANID，甚至可以包括 MAC 地址等等这些网络世界里，为了系统能正常运行，而人为定义的字段的取值范围。（好吧，就这么定义吧，我相信您知道什么叫逻辑资源，^_^）

因为不同租户网络不能感知到彼此的存在，所以说，“逻辑资源层面的隔离”，这句话其实意味着：逻辑资源的复用。

Tenant1 可以有一批私有网络 IP 地址：10.0.1.0/24，Tenant2 可以有一批同样的私有网络 IP 地址。这就是逻辑资源层面的隔离。逻辑资源的隔离，其实是为了解决逻辑资源的冲突，或者更好理解的说法是：逻辑资源的复用。

说到这里，可能也有人会问，既然讲了逻辑资源的隔离，那么物理资源呢？

我们讲，物理资源恰恰不是为了隔离，而是为了共享！

请您先往下看。

（4）故障层面的隔离

这个最有讲究。笔者观点：讲前三个隔离，如果不讲这个，那前三个就是废话！（因为前三个比较直白直接！）

故障隔离的范围太大！

故障隔离，简单地说，一个租户网络出问题了，不能影响另一个租户的网络！这句话太简单了，以至于“不太正确”！

一个租户网络的路由器本身出问题了（注意，我说的是“路由器本身”），比如它的路由表凌乱了，不应该影响其他租户的网络，这是正确的。

但是，我们知道，Neutron 的 Router 是位于控制节点的（不考虑 DVR），如果这个控制节点死机了，这个时候我们就不能讲：一个租户网络的路由器出问题了（注意，我这里没有说“路由器本身”），不应该影响其他租户的网络。要知道，控制节点出问题了，那就是全都出问题了。

我们再看计算节点，我们知道，一个计算节点只有一个 br-int，但是可以有多个 VM，如果这些 VM 可以分属多个租户，那么这个计算节点的 br-int 出问题了，也谈不上租户隔离。

我们也许可以这么说，一个租户一个控制节点（虽然目前还没有这样的解决方案，我们就假设有这样的解决方案），不同租户的 VM 不能在同一个 Host（因为 Host 内的 br-int 是共享的），这样是不是就做到租户的故障隔离了呢？

但是，我们可以这样追问，如果机架嗝屁了呢？那么是不是不同租户必须要不同机架？那如果数据中心嗝屁了呢？是不是不同租户需要不同数据中心？......我们可以一直追问下去，一直追问到：不同租户是不必须不在同一个地球......不在同一个宇宙......

这样的追问不仅没完没了，而且做不到！有的是由于经济学的原因（比如不在同一个数据中心），有的是由于科学技术原因（比如不在同一个地球），有的是由于哲学的原因（比如不在同一个宇宙）！

那么，租户隔离中的“故障隔离”到底该怎么定义？？？

此刻我的心情是这样的：

好吧，我们暂时忘记这个定义，先看下一小节，然后再给出这个定义。

5.1.1.2.2 Neutron 在租户隔离中的无限责任和有限责任

唉，这个标题取的也够装逼的，^_^

其实，我们在上一小节中，也已经有体会，Neutron（其实包含任何一个系统），在租户隔离这个层面，不会也无法承担全方位的无限责任，比如故障隔离，就不能承担无限责任！

我先直接说观点（或者说结论），然后再论述：

Neutron 在“管理面的隔离，数据面的隔离，逻辑资源层面的隔离”这三个层面，必须承担无限责任，而在“故障层面的隔离”的这个层面，只能承担有限责任。

所谓无限责任，就是错了必须修改（只能要求人家修改，你总不能要求人家从此就给你做牛做马）。

而所谓有限责任，就是只能在某些方面保证故障是可以隔离的。（到底是哪些方面，笔者下面会讲述）。

我们在前面讲过，租户隔离的哲学意义是：隔离是为了共享！

共享什么？共享物理资源！

OpenStack（包含 Neutron），是为云而服务的。那么云服务的物理资源是什么：数据中心地产（含房屋、空调、水电等等）、物理网络（数据中心里面的物理路由器、交换机、防火墙等等）、机架、主机。

我们讲，这些物理资源中，数据中心、物理网络是必须要共享的，不然云服务商要破产。（土豪把云服务商给包了，那是另说）

机架一般也是需要共享的，这取决于租户到底有多大。土豪租户可以独占机架。

主机有时候，也是需要共享的，这取决于租户到底有多小。屌丝租户（只租一两个虚机），也得共享主机。

所有这些物理资源，云服务商都不承诺“租户隔离”！

换句话说，这些资源的所谓“租户隔离”取决于租户自己到底有多壕，而不取决于技术层面的解决方案！

这个时候，我想，我们可以给出“故障隔离”的定义：管理面的故障，数据面的故障，逻辑资源层面的故障，必须要做到租户隔离；而物力资源层面的故障隔离，取决于租户的壕度，不是单纯的技术问题！

5.1.1.2.3 Neutron 的租户隔离实现方案

（一）数据面和逻辑资源层面

讲数据转发，离不开逻辑资源（VLANID, IP 地址等等），所以两者放在一起讲。

Neutron 在计算节点和网络节点都涉及到了数据转发。

（1）计算节点

计算节点实现模型如下图所示：

图４ 计算节点实现模型

我们在“Neutron 网络实现模型”那一章中，也介绍了计算节点的实现模型，这里是以另外一种稍有不同的方式展现（只是展现形式稍有区别，模型本身是一样的，不能换个章节，模型就变了，^_^）。

图中，VM1-1，VM1-2，分属两个Tenant，当然，也就分属两个 Tenant Network。我们看到，涉及到租户网络隔离的组件有：br-ethx/tun（一个），br-int（一个），qbr（多个），router/dvr（多个）。

br-ethx/tun，br-int 分别只有一个实例，这个是属于“多租户共享一个组件”的方案，实现了“多租户隔离”的目的。

qbr 跟 VM 一一对应，这个属于“多租户隔离的组件”，实现了“多租户隔离”的目的。qbr 由于绑定了安全组，它是原生的二层转发租户隔离技术的基础上，再叠加一层“安全层”来保证租户隔离。原生二层转发（br-ethx/tun，br-int）负责“正常行为”的租户隔离，而安全技术（qbr）负责“异常行为”的租户隔离。（“异常行为”指的是一个租户网络非法访问另一个租户网络）

router/dvr 跟 Tenant 对应，而且每个 router/dvr 运行在一个 namespace 中，这个属于“多租户隔离的组件”并且“多租户 namespace 隔离”的方案，实现了“多租户隔离”的目的。Router/dvr 除了保证租户间网络不会互相访问以外，还解决了逻辑资源（IP 地址）冲突的问题。

（2）网络节点

网络节点的是实现模型，如下图所示：

图５ 网络节点实现模型

网络节点中，br-ethx/tun，br-int, br-ex 分别只有一个实例，这个是属于“多租户共享一个组件”的方案，实现了“多租户隔离”的目的。

router 跟 Tenant 对应，而且每个 router 运行在一个 namespace 中，这个属于“多租户隔离的组件”并且“多租户 namespace 隔离”的方案，实现了“多租户隔离”的目的。Router/dvr 除了保证租户间网络不会互相访问以外，还解决了逻辑资源（IP 地址）冲突的问题。

（3）小结

我们直接上图：

图６ 数据面及逻辑资源面租户隔离方案小结

我们看到，租户隔离度与资源共享度是成反比的。

（二）管理面的租户隔离方案

管理面，对于 Neutron 而言，指的是控制节点。是的，它虽然叫“控制节点”，笔者还是把它归为管理面。Openstack（Neutron）控制节点的实现模型如下图所示：

图７ OpenStack（Neutron）控制节点的实现模型

我们可以把控制节点当作一个普通的软件系统，或者类比为 SaaS（Software as a Service），当然只是类比，不能完全等同。

我们看到，OpenStack（Neutron）的控制节点，它的租户隔离方案也是没sei了：它基本等于没有！

抛开多实例及 HA（High Available，高可用性），控制节点的租户隔离方案就是：简单、粗暴、几乎没有。

硬件/操作系统层面隔离：没有！（就是运行在一个主机上）

应用程序层面隔离：没有！（就是单实例）

数据库层面隔离：几乎没有！

数据库层面的租户隔离方案一般有如下几种：

l 独立数据库

l 共享数据库，独立 Schema（简单地说，就是独立表的意思，不同的租户，不同的表，而且不同租户之间的表，也没有关联）

l 共享数据库，共享 Schema，共享表

OpenStack（Neutron）控制节点，数据库层面所采取的租户隔离方案就是“共享数据库，共享 Schema，共享表”，在表中加了一个字段“tenant_id”来区分不同的租户。

但是，OpenStack（Neutron）的控制节点，就是靠这个方案，基本上也实现了管理面的租户隔离的需求了吧。

写到这里，笔者想起一个题外话。那是在笔者的工作中，参加的一次两个部门之间的讨（si）论（bi）会（zhan）。其中一个部门的童鞋说：我们这个方案好啊，我们是多租户（隔离）的。另外一个部门童鞋弱弱地说了一句：啥多租户啊，不就是数据库表中加了一个tenant_id”字段吗？

我在那里硬憋着不笑，因为我也是那个实现了多租户方案的部门的。

5.1.1.2.4 租户隔离方案的思考

我们还是要做哲学的思考，这句话真不是装逼！思考一个事物的本质，就是要做哲学的思考。而哲学的本质，就是矛盾！（哲学的本质，就是矛盾。这句话是我说的，欢迎拍砖）

租户隔离的目的，是为了共享！这是我们的第一层哲学思考：事物是矛盾的和谐！

或者说，租户隔离，就是：用共享的组件，提供租户隔离的技术，达到租户隔离的目的。

比如，我们前面讲过，计算节点中的 br-int，是共享的组件，但是它提供了 VLAN 的技术，我们可以利用 VLAN 这种技术，从而达到租户隔离的目的。

但是，无论这个组件提供多么酷炫的租户隔离的技术，它本身仍然是共享的，它本身的租户隔离怎么做呢？这是一个实现层面的矛盾！

这个时候，我们需要第二层哲学思考：解决实现层面的矛盾，一定要跳出问题本身，不然就会死循环。

我们的实现方案，就是“共享组件实现租户隔离”，这个时候我们不能再纠缠于“共享组件本身如何实现租户隔离”，这样的纠缠是无解的。

我们一定要跳出问题本身，另外思考出路。

或者说，我们一定要跳出问题本身，重新思考问题的本质：问题到底是什么？

“共享组件实现租户隔离”，这个问题的本质，不是“共享组件本身如何实现租户隔离”，而是：

（1）这个共享组件真的能做到租户隔离吗？

（2）这个共享组件故障了怎么办（因为它故障了，影响的就不是一个租户）？

（3）这个共享组件的性能会是瓶颈吗？

对于第（1）个问题，答案是：增强！于是我们看到，在 br-int 的基础上，叠加 qbr，也就是叠加安全组。在后面的章节中，我们还会看到，其实 Neutron 还会继续叠加“FWaaS（Firewall as a Service）”。这些“叠加”都是“增强”，增强租户隔离的技术！

对于第（2）个问题，答案是：HA！

对于第（3）个问题，答案是：集群/分布式！

HA，集群/分布式，本身是另外的话题，这里我就不展开了。我应该会写一篇关于 Neutron 的 HA、集群/分布式方案的文章，敬请期待！

当然，我们还可以继续思考问题......但是最重要的一点是：实现层面，如果要解决矛盾的问题，一定要跳出问题，而不能陷入死循环！

也许您会说，你这太会装逼了，你这根本就是错的。

好吧，人生，谁不希望犯一次错误呢？！

【说明：阅读本篇文章，需要一定的预备知识“Neutron 网络实现模型”。关注微信公众号“标哥说天下”，回复“NMI” 或者 “nmi”，可以获取该文章。】

第五章 Neutron 逻辑模型

这一章的写作，对我来说，太有挑战。因为 OpenStack 有官网介绍它的 RESTful API。而这些 API 的介绍，就是基于 Neutron 逻辑模型的 CRUD（Create，Retrieve，Update，Delete，增加/查询/修改/删除）讲述。这意味着什么？这意味着官网是“模型 + CRUD”一起介绍，而我这里仅仅介绍模型，我的内心是几乎崩溃的，^_^

好吧，让我们来一场冒险之旅，看看我的功力到底如何，能不能在有官方 wiki 的基础上，写下一篇不一样的文章。

【版权统一申明】不能否认也没法避免，本章统一参考 OpenStack 关于 Neutron  API 的官网：https://developer.openstack.org/api-ref/networking/v2/?expanded=list-floating-ips-detail,show-subnet-details-detail 。

笔者也强烈建议您阅读该网页。

Neutron 把网络相关的逻辑模型，分为如下几个部分：

Layer2 Networking，Layer3 Networking，Security，Resource Management，QoS，LBaaS，Logging Resource (networking-midonet)，Router interface floating IP (networking-midonet)，FIP64 (networking-midonet)，BGP/MPLS VPN Interconnection。

本章也将基本围绕这些分类展开讲述。

Neutron 之所以把这些称为逻辑模型，是因为它的基本原理如下（草图）：

图１ Neutron 实现原理（草图）

这仅仅是一个草图，比较详细的图，我们会在 Neutron 架构分析相关章节描述，这里仅仅表达一个示意。从图中我们看到，所谓 Logic Model，其实直接地讲，只做了两件事情：（1）变身一套 RESTful API；（2）相关 API 操作所产生的数据存储在数据库（DB）里。非常完美，然并卵！

Neutron 要想把网络打通，还需要相关 Plugin/Agent 在计算节点/控制节点上做相关配置（请参见笔者所写的“Neutron 网络实现模型”），当然，Neutron 也可以通过相关的 Plugin 来配置真正的物理网元（这是另外的话题，笔者后面会在相关章节描述）。

总之，这些所谓的“逻辑”模型，真的只是一个逻辑上的表达而已！

我们会在本章后面的描述中，继续体会“逻辑”这两个字。

5.1 二层网络模型（Layer2 Networking Model）

L2(Layer2) Networking Model，主要包括 Network，Port 两个模型。下面我们一个一个讲述。

5.1.1 Network

Network，网络，即使在通信的语境里，也是一个非常大的概念。不过，Neutron 在这里特指 L2 Network。

5.1.1.1 Network 概述

我们直接 copy OpenStack 官网上关于 Network Model 的介绍，直接上表格：

表1 Network Logic Model

这个表格呢，我列在这里，您可以阅读，也可以暂时不阅读，因为我下面要展开描述。

5.1.1.2 租户（Tenant）

说到租户（Tenant），稍微有点尴尬，因为 tenant_id 和 project_id 的解释都是：The ID of the project。而且官网还说“Starting with the Newton release of the Networking service, the Networking API accepts the project_id attribute in addition to the tenant_id attribute in requests. The tenant_id attribute is accepted for backward compatibility. If both the project_id and the tenant_id attribute are provided in the same request, their values must be identical.”

也就是说，从 Newton 版本开始，tenant_id 存在的意义，可能只是为了后向兼容，只是一个历史的印记而已。

换句话说，笔者当年千辛万苦地把租户（Tenant）在脑中做个“脑筋急转弯”，好容易正确地理解了“租户不是人”这句话，好容易接纳了“租户”这个词，人家弃用了。

不过呢，笔者以为，玩笑归玩笑，无所谓是 tenant_id 也好，还是 project_id 也好，它（们）除了起到一个传统的 ID 的作用以外，还有一个更深层次的含义：租户隔离！

租户隔离，这四个字该怎么理解！笔者以为，需要往哲学意义上靠：租户隔离是为了共享！

隔离是为了共享！

这个世界最深沉的爱，不是在一起，而是离开！

好吧，不再感慨，一点一点分析这四个字：租户隔离！

说明几点：

（1）租户不是人，这句话的最简单的解释是：租户就是客户，而这里的客户指的是企业。

（2）虽然不能把租户理解为“人”，但是下文为了行文方便，还是把租户当作人来看待，把租户管理员简称为租户。

（3）租户隔离，其实是“多租户隔离”（单租户，也不存在隔离），但是下文为了行文方便，“多租户隔离”，简称“租户隔离”。

5.1.1.2.1 Neutron 语境下租户隔离的含义

租户隔离，在不同场景，不同语境下，有不同的含义，我们这里只讲述 Neutron 语境下，租户隔离的含义。

Neutron 语境下，从租户的视角，或者从需求的视角来讲，租户隔离有四种含义：管理面的隔离，数据面的隔离，逻辑资源层面的隔离，故障层面的隔离。

（1）管理面的隔离

管理面的隔离，指的是“管理权限”的隔离，如下图所示：

图２ 管理（控制）层面的隔离

图中两个网络，都是 Neutron 的范围，但是 Network1 属于 Tenant1，Network2 属于 Tenant2，这也就意味着：Tenant1 无法管理（增删改查）Tenant2 的网络（Network2）。Tenant2 亦然！

换句话说，一个 Tenant 只知道他自己的网络，其他网络他毫无知晓，毫无感觉。就像我们人类现在对“平行宇宙”的认识一样（如果真有的话）：猜想也许还有其他的平行宇宙吧，但是一无所知，一无所觉。也许，上帝的上帝，也在做租户隔离吧，细思极恐，^_^

需要强调的是，从 Neutron 自身来说，就是指的“控制节点”（虽然 Neutron 称呼自己那个节点叫“控制节点”，实际做了很多很多“管理层面”的工作），但是，作为一个实际的商业系统，比如现在那个最性感的解决方案 SDN（Sex Defined Network），其中某些场景的可能的架构是这样的，如下图所示：

图３ SDN 解决方案中的一种架构

在这个架构中，Neutron（Control Node）解决好自己的租户权限隔离问题，而作为整个解决方案，还需要解决从 APP 到 Controller，每一层的租户权限隔离的问题。

（2）数据面的隔离

数据面的隔离，指的是数据转发的隔离。不同租户的网络之间，是不能互通的（除非租户特殊要求，这个属于抬杠，我们不讨论）。

从管理权限角度，一个租户不能管理另一个租户的网络。同理，不同租户的网络也不能互通。

可能有人会问，说了“管理面”和“数据面”，那么“控制面”呢？对于控制面，我们有两点解释：

A. 控制面，不属于用户视角。或者话句话说，控制面是否隔离，用户不关心，这仅仅是一个内部实现。说的更装逼一点，这不是一个问题。

B. 控制面，分为两种，一种是基于经典 TCP/IP 协议的，一种是基于性感解决方案（SDN）的。基于经典 TCP/IP 协议的，跟数据面一样，这个控制面的隔离也是天然的（因为不同租户的网络，也根本感知不到彼此的存在）；基于 SDN 的控制面，也就是传说中的控制器（Controller），它怎么实现，取决于它自己，用户不关心。

（3）逻辑资源层面的隔离

逻辑资源，其实也有不同的定义，这里我们不纠结逻辑资源的定义本身，而是以举例（我负责举例）加联想（您负责联想）的方式来做个简单定义：逻辑资源指的是 IP 地址，VLANID，甚至可以包括 MAC 地址等等这些网络世界里，为了系统能正常运行，而人为定义的字段的取值范围。（好吧，就这么定义吧，我相信您知道什么叫逻辑资源，^_^）

因为不同租户网络不能感知到彼此的存在，所以说，“逻辑资源层面的隔离”，这句话其实意味着：逻辑资源的复用。

Tenant1 可以有一批私有网络 IP 地址：10.0.1.0/24，Tenant2 可以有一批同样的私有网络 IP 地址。这就是逻辑资源层面的隔离。逻辑资源的隔离，其实是为了解决逻辑资源的冲突，或者更好理解的说法是：逻辑资源的复用。

说到这里，可能也有人会问，既然讲了逻辑资源的隔离，那么物理资源呢？

我们讲，物理资源恰恰不是为了隔离，而是为了共享！

请您先往下看。

（4）故障层面的隔离

这个最有讲究。笔者观点：讲前三个隔离，如果不讲这个，那前三个就是废话！（因为前三个比较直白直接！）

故障隔离的范围太大！

故障隔离，简单地说，一个租户网络出问题了，不能影响另一个租户的网络！这句话太简单了，以至于“不太正确”！

一个租户网络的路由器本身出问题了（注意，我说的是“路由器本身”），比如它的路由表凌乱了，不应该影响其他租户的网络，这是正确的。

但是，我们知道，Neutron 的 Router 是位于控制节点的（不考虑 DVR），如果这个控制节点死机了，这个时候我们就不能讲：一个租户网络的路由器出问题了（注意，我这里没有说“路由器本身”），不应该影响其他租户的网络。要知道，控制节点出问题了，那就是全都出问题了。

我们再看计算节点，我们知道，一个计算节点只有一个 br-int，但是可以有多个 VM，如果这些 VM 可以分属多个租户，那么这个计算节点的 br-int 出问题了，也谈不上租户隔离。

我们也许可以这么说，一个租户一个控制节点（虽然目前还没有这样的解决方案，我们就假设有这样的解决方案），不同租户的 VM 不能在同一个 Host（因为 Host 内的 br-int 是共享的），这样是不是就做到租户的故障隔离了呢？

但是，我们可以这样追问，如果机架嗝屁了呢？那么是不是不同租户必须要不同机架？那如果数据中心嗝屁了呢？是不是不同租户需要不同数据中心？......我们可以一直追问下去，一直追问到：不同租户是不必须不在同一个地球......不在同一个宇宙......

这样的追问不仅没完没了，而且做不到！有的是由于经济学的原因（比如不在同一个数据中心），有的是由于科学技术原因（比如不在同一个地球），有的是由于哲学的原因（比如不在同一个宇宙）！

那么，租户隔离中的“故障隔离”到底该怎么定义？？？

此刻我的心情是这样的：

好吧，我们暂时忘记这个定义，先看下一小节，然后再给出这个定义。

5.1.1.2.2 Neutron 在租户隔离中的无限责任和有限责任

唉，这个标题取的也够装逼的，^_^

其实，我们在上一小节中，也已经有体会，Neutron（其实包含任何一个系统），在租户隔离这个层面，不会也无法承担全方位的无限责任，比如故障隔离，就不能承担无限责任！

我先直接说观点（或者说结论），然后再论述：

Neutron 在“管理面的隔离，数据面的隔离，逻辑资源层面的隔离”这三个层面，必须承担无限责任，而在“故障层面的隔离”的这个层面，只能承担有限责任。

所谓无限责任，就是错了必须修改（只能要求人家修改，你总不能要求人家从此就给你做牛做马）。

而所谓有限责任，就是只能在某些方面保证故障是可以隔离的。（到底是哪些方面，笔者下面会讲述）。

我们在前面讲过，租户隔离的哲学意义是：隔离是为了共享！

共享什么？共享物理资源！

OpenStack（包含 Neutron），是为云而服务的。那么云服务的物理资源是什么：数据中心地产（含房屋、空调、水电等等）、物理网络（数据中心里面的物理路由器、交换机、防火墙等等）、机架、主机。

我们讲，这些物理资源中，数据中心、物理网络是必须要共享的，不然云服务商要破产。（土豪把云服务商给包了，那是另说）

机架一般也是需要共享的，这取决于租户到底有多大。土豪租户可以独占机架。

主机有时候，也是需要共享的，这取决于租户到底有多小。屌丝租户（只租一两个虚机），也得共享主机。

所有这些物理资源，云服务商都不承诺“租户隔离”！

换句话说，这些资源的所谓“租户隔离”取决于租户自己到底有多壕，而不取决于技术层面的解决方案！

这个时候，我想，我们可以给出“故障隔离”的定义：管理面的故障，数据面的故障，逻辑资源层面的故障，必须要做到租户隔离；而物力资源层面的故障隔离，取决于租户的壕度，不是单纯的技术问题！

5.1.1.2.3 Neutron 的租户隔离实现方案

（一）数据面和逻辑资源层面

讲数据转发，离不开逻辑资源（VLANID, IP 地址等等），所以两者放在一起讲。

Neutron 在计算节点和网络节点都涉及到了数据转发。

（1）计算节点

计算节点实现模型如下图所示：

图４ 计算节点实现模型

我们在“Neutron 网络实现模型”那一章中，也介绍了计算节点的实现模型，这里是以另外一种稍有不同的方式展现（只是展现形式稍有区别，模型本身是一样的，不能换个章节，模型就变了，^_^）。

图中，VM1-1，VM1-2，分属两个Tenant，当然，也就分属两个 Tenant Network。我们看到，涉及到租户网络隔离的组件有：br-ethx/tun（一个），br-int（一个），qbr（多个），router/dvr（多个）。

br-ethx/tun，br-int 分别只有一个实例，这个是属于“多租户共享一个组件”的方案，实现了“多租户隔离”的目的。

qbr 跟 VM 一一对应，这个属于“多租户隔离的组件”，实现了“多租户隔离”的目的。qbr 由于绑定了安全组，它是原生的二层转发租户隔离技术的基础上，再叠加一层“安全层”来保证租户隔离。原生二层转发（br-ethx/tun，br-int）负责“正常行为”的租户隔离，而安全技术（qbr）负责“异常行为”的租户隔离。（“异常行为”指的是一个租户网络非法访问另一个租户网络）

router/dvr 跟 Tenant 对应，而且每个 router/dvr 运行在一个 namespace 中，这个属于“多租户隔离的组件”并且“多租户 namespace 隔离”的方案，实现了“多租户隔离”的目的。Router/dvr 除了保证租户间网络不会互相访问以外，还解决了逻辑资源（IP 地址）冲突的问题。

（2）网络节点

网络节点的是实现模型，如下图所示：

图５ 网络节点实现模型

网络节点中，br-ethx/tun，br-int, br-ex 分别只有一个实例，这个是属于“多租户共享一个组件”的方案，实现了“多租户隔离”的目的。

router 跟 Tenant 对应，而且每个 router 运行在一个 namespace 中，这个属于“多租户隔离的组件”并且“多租户 namespace 隔离”的方案，实现了“多租户隔离”的目的。Router/dvr 除了保证租户间网络不会互相访问以外，还解决了逻辑资源（IP 地址）冲突的问题。

（3）小结

我们直接上图：

图６ 数据面及逻辑资源面租户隔离方案小结

我们看到，租户隔离度与资源共享度是成反比的。

（二）管理面的租户隔离方案

管理面，对于 Neutron 而言，指的是控制节点。是的，它虽然叫“控制节点”，笔者还是把它归为管理面。Openstack（Neutron）控制节点的实现模型如下图所示：

图７ OpenStack（Neutron）控制节点的实现模型

我们可以把控制节点当作一个普通的软件系统，或者类比为 SaaS（Software as a Service），当然只是类比，不能完全等同。

我们看到，OpenStack（Neutron）的控制节点，它的租户隔离方案也是没sei了：它基本等于没有！

抛开多实例及 HA（High Available，高可用性），控制节点的租户隔离方案就是：简单、粗暴、几乎没有。

硬件/操作系统层面隔离：没有！（就是运行在一个主机上）

应用程序层面隔离：没有！（就是单实例）

数据库层面隔离：几乎没有！

数据库层面的租户隔离方案一般有如下几种：

l 独立数据库

l 共享数据库，独立 Schema（简单地说，就是独立表的意思，不同的租户，不同的表，而且不同租户之间的表，也没有关联）

l 共享数据库，共享 Schema，共享表

OpenStack（Neutron）控制节点，数据库层面所采取的租户隔离方案就是“共享数据库，共享 Schema，共享表”，在表中加了一个字段“tenant_id”来区分不同的租户。

但是，OpenStack（Neutron）的控制节点，就是靠这个方案，基本上也实现了管理面的租户隔离的需求了吧。

写到这里，笔者想起一个题外话。那是在笔者的工作中，参加的一次两个部门之间的讨（si）论（bi）会（zhan）。其中一个部门的童鞋说：我们这个方案好啊，我们是多租户（隔离）的。另外一个部门童鞋弱弱地说了一句：啥多租户啊，不就是数据库表中加了一个tenant_id”字段吗？

我在那里硬憋着不笑，因为我也是那个实现了多租户方案的部门的。

5.1.1.2.4 租户隔离方案的思考

我们还是要做哲学的思考，这句话真不是装逼！思考一个事物的本质，就是要做哲学的思考。而哲学的本质，就是矛盾！（哲学的本质，就是矛盾。这句话是我说的，欢迎拍砖）

租户隔离的目的，是为了共享！这是我们的第一层哲学思考：事物是矛盾的和谐！

或者说，租户隔离，就是：用共享的组件，提供租户隔离的技术，达到租户隔离的目的。

比如，我们前面讲过，计算节点中的 br-int，是共享的组件，但是它提供了 VLAN 的技术，我们可以利用 VLAN 这种技术，从而达到租户隔离的目的。

但是，无论这个组件提供多么酷炫的租户隔离的技术，它本身仍然是共享的，它本身的租户隔离怎么做呢？这是一个实现层面的矛盾！

这个时候，我们需要第二层哲学思考：解决实现层面的矛盾，一定要跳出问题本身，不然就会死循环。

我们的实现方案，就是“共享组件实现租户隔离”，这个时候我们不能再纠缠于“共享组件本身如何实现租户隔离”，这样的纠缠是无解的。

我们一定要跳出问题本身，另外思考出路。

或者说，我们一定要跳出问题本身，重新思考问题的本质：问题到底是什么？

“共享组件实现租户隔离”，这个问题的本质，不是“共享组件本身如何实现租户隔离”，而是：

（1）这个共享组件真的能做到租户隔离吗？

（2）这个共享组件故障了怎么办（因为它故障了，影响的就不是一个租户）？

（3）这个共享组件的性能会是瓶颈吗？

对于第（1）个问题，答案是：增强！于是我们看到，在 br-int 的基础上，叠加 qbr，也就是叠加安全组。在后面的章节中，我们还会看到，其实 Neutron 还会继续叠加“FWaaS（Firewall as a Service）”。这些“叠加”都是“增强”，增强租户隔离的技术！

对于第（2）个问题，答案是：HA！

对于第（3）个问题，答案是：集群/分布式！

HA，集群/分布式，本身是另外的话题，这里我就不展开了。我应该会写一篇关于 Neutron 的 HA、集群/分布式方案的文章，敬请期待！

当然，我们还可以继续思考问题......但是最重要的一点是：实现层面，如果要解决矛盾的问题，一定要跳出问题，而不能陷入死循环！

也许您会说，你这太会装逼了，你这根本就是错的。

好吧，人生，谁不希望犯一次错误呢？！

【说明：阅读本篇文章，需要一定的预备知识“Neutron 网络实现模型”。关注微信公众号“标哥说天下”，回复“NMI” 或者 “nmi”，可以获取该文章。】

感谢陈苍童鞋对我的帮助！

5.1.1.4 租户网络和运营商网络（Tenant Network & Provider Network）

租户网络（Tenant Network，现在新版本已经改为 Project Network，不过笔者还是习惯租户网络这个称呼）与运营商网络（Provider Network），并不是 Network Model 中的属性，它们就是 Network 本身，就是通过命令行或者 RESTful API 所创建的 Neutron Network（create Network）。

简单地说，租户创建的网络，就是租户网络，而管理员（Administrator）创建的网络，就是运营商网络。但是事情并没有这么简单。下面我们就来展开描述。

5.1.1.4.1 运营商网络的创建方法

我们前面说过，运营商网络仍然是一个 Network，它的创建方法仍然是通过命令行或者 RESTful API 来创建网络（create Network），它与租户创建一个租户网络相比，有两个不同点：

（1）必须是管理员或者具备管理员权限的用户

（2）必须传入如下三个参数（Network Model 里面的三个字段），如下表所示：

表1 创建运营商网络必须传入的三个参数

【注】租户创建租户网络，恰恰不能传入这三个参数，这个我们会在下面讲述

上述表格，是原文摘抄的 Neutron 官网，笔者再补充说明一些内容。

字段中，有 provider 前缀，正是通过字段名给一个强烈的含义表达：这是 provider network 所需要的参数（与 tenant network 无关）。

我们知道，local 网络类型，指的是一个 Host 内部的网络，这个显然与 Provider Network 的使用场景不符合，所以，Provider Network 不会包含这种网络类型。而其他类型，都是可以的。

provider:physical_network，我们在上一节介绍过，在网络类型非隧道类型时（FLAT/VLAN），必须填入这个参数，在网络类型是隧道类型时（GRE/VXLAN/GENEVE），必须不能填入这个参数。

【注】关注微信公众号“标哥说天下”，回复“LNM2”，以获取讲述“物理网络”的该篇文章《深入探索 OpenStack Neutron：Neutron 逻辑模型（2）》

provider:segmentation_id，是对各种网络类型中的“ID”一种抽象。如果是 VLAN 网络，则其代表 VLANID；如果是 VXLAN 网络，则其代表 VNI；如果是 GRE 网络，则其代表 GRE Key。

这三个参数，是创建运营商网络与租户网络时的不同。其他参数，则两者的使用方法相同。

5.1.1.4.2 租户网络的创建方法

租户网络，是租户创建的网络。当然，从 Neutron 的权限管理来说，管理员也可以创建租户网络。

租户网络，从创建方法来说，跟运营商网络恰恰相反，它恰恰不能输入上述的“provider：xxx”三个参数。

但是，我们从 Network Model 中知道：除了“provider:network_type”，再也没有字段能表达网络类型；除了“provider:segmentation_id”，再也没有字段可以表达网络“ID”。

那么，问题来了：租户怎么决定他的网络的网络类型和网络“ID”？

租户决定不了！

说的好听点，这是云运营商对租户的一个友好界面，租户不需要感知这么多细节，这些由运营商搞定。

说的难听点，你租户创建一个网络，通了就行了，瞎 BB 个啥？什么网络类型，什么网络“ID”，管那么多干啥？

呵呵，我是开玩笑的。在 Neutron 的设计方案中，对租户封装这些细节，提升易用性，提高满意度，真的是 Neutron 的本意！

但是，既然租户不能填入这些参数，那么 Neutron 又是如何知道的呢？

Neutron 也没法知道，是管理员告诉他的（背后是云服务商老板决定的）。管理员通过配置文件，配置网络类型和网络“ID”。配置信息如下：

tenant_network_types = vxlan

[ml2_type_vxlan]

vni_ranges = 1:1000

还是那句话，我们暂时不用关心这个是哪个配置文件里描述的，我们只关心这些本质的内容（我会在后面的章节中，专门介绍配置文件）。

通过这个配置信息，我们看到，租户网络的网络类型是“VXLAN”，而相应的 VNI，是由 Neutron 根据一定的规则，自动分配，不过 VNI 的范围是“1~1000”。（具体什么规则，我们暂时也忽略，笔者会在后面的章节中讲述，这里可以简单理解为“顺序规则”，即“第一个租户网络的 VNI 是 1，第 2 个租户网络的 VNI 是 2，以此类推”）

5.1.1.4.3 运营商网络的使用场景

笔者以为，这个是重点！

我们知道，OpenStack 是云的解决方案之一，云服务商通过 OpenStack 为租户提供云服务。所以，租户创建一个 Network，是这个云服务里面一个正常的服务，而且租户也需要为使用这个服务而付费（create Network）。

但是，一个管理员为什么要创建一个网络呢？这好比一个饭店的领班，你就好好地做你的领班，你去占用饭店的一个桌位干什么？那个桌位可是要招待客户的，可是要挣钱的。

这个时候，我们就需要仔细分析一下，管理员创建的所谓运营商网络的使用场景。

Neutron 的官网中，是这么描述 Provider Network 的：

Provider networks are created with administrative credentials, specifying the details of how the network is physically realized, usually to match some existing network in the data center.

Provider networks enable administrators to create networks that map directly to the physical networks in the data center. This is commonly used to give projects direct access to a public network that can be used to reach the Internet. It might also be used to integrate with VLANs in the network that already have a defined meaning (for example, enable a VM from the marketing department to be placed on the same VLAN as bare-metal marketing hosts in the same data center).

【注】摘自 https://docs.openstack.org/admin-guide/networking-adv-features.html

这段话，强调了一点：运营商网络指明了物理网络的细节，并且（通常）是为了匹配数据中心已经存在的网络。（注意，这里的物理网络，指的是真正的物理网络，不是“provider:physical_network”这个字段）

指明物理网络的细节，靠的就是前面我们介绍的那三个字段“provider：xxx”。

这段话还提到了运营商网络所涉及的两个使用场景。下面我们就来描述这两个场景。

（一）场景一：VM 外接 Internet

我们在“Neutron 网络实现模型”那一章中提到 Neutron 的实现模型如下：

图１ Neutron 网络实现模型（不考虑 DVR）

为了易于描述，我采取了不考虑 DVR 的网络实现模型（加上 DVR 的网络实现模型，对于这一个场景讲述而言，除了增加讲述的复杂度，并不会有什么原理上的不同）。

图中，我们看到，VM 要访问外部网络（access to a public network that can be used to reach the Internet），必须通过 Router 和 br-ex 两个部件（其他部件我们忽略）。

这个时候，我们需要将这个场景继续细化为两个子场景。

（1）br-ex 是普通的 Ethernet 转发

为了易于描述，我们继续把上述的实现模型简化，删除一些“无关”组件，如下图所示：

图２ Neutron 的简化实现模型

而当 br-ex 作为普通的 Ethernet 转发时，我们甚至可以忽略它的存在（虽然它实际上桥接了 Router 和物理网口），如下图所示：

图３ br-ex 做 Ethernet 转发时的 Neutron 简化实现模型

按道理说，这个时候，是不需要什么所谓的“Provider Network”的，只需要把 Router 相关的路由表配置正确即可。

但是，Neutron 有它的逻辑自洽性。逻辑自洽的意思是，按照它的原则，它能自圆其说，但是不代表它就是合理的。

Neutron 的原则是：一个 Router（这个 Router 指的是虚拟路由器） 如果是对接外部网络（External Network，Neutron 称之为 Public Network）时，那么，Router 这个对象（这个 Router 指的是 Neutron 的一个模型，名字叫 Router）必须与一个 Provider Network（Network Model 的实例）挂钩（本质上是与这个 Provider Network 的 Subnet 挂钩），也就是说，它的路由表，是根据这个 Provider Network 的Subnet 来自动创建的。（Router，Subnet 这两个 Model，笔者会有专门的章节进行描述，这里先这么简单理解）

Router、Network、Subnet 这三个 Model 之间的关系，如下图所示：

图４ 三个 Model 之间的关系

图中，实线表示直接关系，虚线表示间接关系。

所以，到这里我们知道，在这种场景下，并不是真的需要 Provider Network 这个概念和实例，只是 Neutron 自己的设计如此。您完全可以不用 Provider Network 这个概念，一样能达到这样的效果。

不过，它就是这么玩的，咱也不好说什么，^_^。

另外，更关键的，另一种场景，则需要 Provider Network 这个概念。

（2）br-ex 作为隧道终结点

我们直接上图：

图５ br-ex 作为隧道终结点的 Neutron 简化实现模型

图中，隧道类型画的是 VXLAN，实际上，其他类型隧道也可以，比如 GRE。

br-ex 与 DC GW 之间是 VXLAN 连接，两者是此 VXLAN 连接的 VTEP。这个时候，我们看到，必须要有一种方法告知 Neutron/br-ex，这个网络类型是什么（VXLAN），这个网络“ID”（VNI）是什么。

这种场景，Provider Network 就是有必要的了。因为创建 Provider Network 时，会传入参数：provider:network_type, provider:segmentation_id，而这两个参数是必须的。

很美好，是吗？

不是！

br-ex 要成为隧道终结点，无论是 VXLAN 隧道还是 GRE 隧道，它都必须要知道两个信息：自身的 IP 地址，对端的 IP 地址。

这两个信息，Neutron 并没有接口（或者其他方法，比如配置文件）能配置下去。也就是说，这种场景，靠 Neutron 自己的接口是懵逼的，是不自洽的，只能依赖人工另外配置那两个信息。

这个时候，就监介了。（我们的宝岛台湾，竟然发布公告，说尴尬也可以读作“监介”。好吧，我们让 Neutron 也“监介”一次）

（3）两种子场景的总结

我们直接上表格：

表2 两种子场景的总结

呵呵，我都有点心虚了。上一小节，我把“provider:physical_network”批判了一把，这里，又把 Provider Network 监介了一把，^_^

好吧，我们来看看第二个场景吧。

（二）场景二：虚机与主机混合服务

Neutron 是这样描述这个场景的：

It might also be used to integrate with VLANs in the network that already have a defined meaning (for example, enable a VM from the marketing department to be placed on the same VLAN as bare-metal marketing hosts in the same data center).

这个场景，笔者以为，确实是需要 Provider Network 这个概念的。

我们知道，仅仅是为 VM 服务的 Network（类型是 VLAN），如下图所示：

图6 单纯为 VM 服务的 VLAN 网络

上图中的计算节点模型，是一个简化模型。两个计算节点之间，通过 br-ethx，组成一个 Network，VLANID = 100。

通过前面介绍，我们知道，这个 Network 是一个租户网络。而租户网络的创建，我们知道，租户是不能（不需要）填写网络类型和网络“ID”的，这些都是配置在配置文件中。我们同样知道，这个网络类型，很可能配置为“VXLAN”，而网络“ID”，是 Neutron 按照一定的规则自动生成的。

此时，如果遇到云服务商提供“VM（虚机） + Host（主机）”混合服务，如下图所示：

图7 VM + Host 混合服务

这个时候，有两点很关键：

（1）网络类型，不能是通过配置文件来配置，因为配置文件配置的“单纯为虚机服务的租户网络类型”。比如配置文件可能配置为 VXLAN，而此时却需要的是 VLAN。

（2）网络“ID”，不能通过配置文件（配置的是“ID”范围） + Neutron 按照一定的规则来实现。因为这里的网络“ID”根本就没有规则，它是根据实际情况而乱七八糟变化的。

怎么办？必须直接传递参数，告知 Neutron：网路类型是什么，网络“ID”是什么。

这个时候，Tenant Network 就不能胜任了，而 Provider Network 正好可以解决这个问题。

而且，从名称上来讲，图中画的那个交换机，只是一个简单示意，实际可能是一个比较复杂的物理网络 ，而这个网络，确实就是“Provider Network”。

所以，Neutron 提出“Provider Network”这个概念，在这个场景下，无论是从原理上还是从名称上，都是合适的！

给 Neutron 点个赞！（呵呵，我都吐槽它半天了，终于点了一个赞）

（三）运营商网络使用场景总结

我们直接上表：

表3 运营商网络使用场景总结

今天很晚了，明天还要上班，就到这吧！