03-Neutron的资源模型-Part1

一、千七百怪的问题

问题：network、subnet、port的对应关系是什么？

network：表示一个虚拟的二层网络
subnet：表示一个子网，同时包含dhcp、dns、路由等信息
port：对应虚拟机的vNIC，配置mac地址和ip地址。

问题：network是什么？有什么作用？

Network是Neutron的一个二层网络的资源模型，它支持的网络类型有：Local、Flat、VLAN、VXLAN、GRE、Geneve等

• Local仅仅是主机内的网络类型，普遍用于测试环境。
• VXLAN、GRE、Geneve属于隧道类型网络
• Flat喝VLAN属于非隧道类型网络。
  从某种意义来说，Network是Neutron的根，subnet、port都绑定在network上。Neutron对外提供二层网络服务接口，租户可以通过这个服务创建并管理自己的网络，这种网络也称为租户网络。

在Host/主机内部配置的vlan时，Neutron的network的物理承载实体为OVS上配置的VLAN，例如交换机设备上配置VXLAN时，物理网络和Neutron的网络映射模型如下：

问题：Subnt是什么？发挥了什么作用？

Subnet（子网）在一般的概念中，有两个基本含义：

• 这个子网的网段（CIDR）和ip版本
• 这个子网的路由信息（含默认路由、DNS、DHCP、IPAM等）

事实上Subnet模型确实有两个字段CIDR和IP_version，分别表示一个子网网段和ip版本，另外subnet模型还有两个字段gateway_ip和host_routes表示一个子网的路由信息。

• gateway_ip表示这个子网的默认网关ip地址。
• host_routes存储这个subnet的路由信息，destionation表示目的地址的CIDR，nexthop表示下一跳（网关）的ip地址。

问题：Port是什么？有什么作用

在Neutron中，对于三层转发首先要配置就是IP地址，而承载IP地址的就是Port。Neutron中并没有VM的概念，而是以Port指代，所以对于Port的理解可以理解为Port是VM的虚拟口（vNIC），对应Linux虚拟化网络的中，tap就对应vNIC，真实层层嵌套。

在Neutron中，虚拟机需要绑定Port，路由器也需要绑定Port，既然是虚拟网口，与物理网口类比，肯定具有ip地址和mac地址。在Port的配置的ip地址中，ip地址不能孤立存在，他必须属于一个subnet，同时也意味着ip地址必须在subnet范围内，同时Port也需要属于一个Network，靠port模型中的network_id来表达。

Port是如此重要,但是也不能凭空存在,它必须得绑定到一个实化本上才有意义。Port有两个字段与实体绑定相关。其中一个是device id,标识谁使用了这个Port,比如一个Router(路由器)。另一个字段是device_owner,它标识使用这个Port的实体的类型。比如一个虚拟机绑定了这个端口,那么这个实体类型就
是compute:nova。

问题：network、port、subnet的对应关系是什么？

Port与Subnet之间的关系是m:n,但是为了表达清楚特意画了两根线。这个图表明,一个Network可以有多个Subnet,一个Subnet只能归属一个Network。同时一个Network可以有多个Port,而一个Port可以与其所在的Network中的所有Subnet相关联。当然一个个Subnet也可以有多个Port。

二、Neutron资源的租户隔离

Neutron是支持多租户的系统，租户隔离是Neutron必须要支持的特性。在Neutron的资源模型中，有一个字段：tenant_id，字段的目的就是为了实现租户隔离，在后续的发展过程中更改为Project_id，除了字段名改了外，其他都是为了实现：租户隔离。

租户隔离，本质上不可能两个不同的硬件，硬件不行逻辑来实现，那么在底层肯定是在共享的设备上实现隔离的效果咯。租户隔离在Neutron语境下，从租户视角，或者从需求的视角来讲，租户隔离有三种含义：管理面隔离、数据面的隔离、故障面的隔离。

管理面隔离：一个tenant只知道自己的网络，对其他网络毫无感知。
数据面的隔离：数据转发的隔离，不同租户之间不能互相通信。
故障隔离：租户故障不会影响另一个租户的业务（往往有对应的限制要求）。
PS：管理面故障、数据面的故障必须要做到租户隔离，而物理层面做不到故障隔离。

2.1 数据面的租户隔离方案

2.1.1 计算节点

Neutron在计算节点和网络节点都涉及数据转发，那此时也都涉及租户隔离。

计算节点通过上图发现，br-eth/tun、br-int只有一个实例，此时通过“多租户共享”方案来实现多租户隔离。

• br-int、br-ethx通过vlan来隔离各租户网络数据流量。
• br-tun通过相应的tunnel_id来隔离各自租户网络流量。

qbr与VM一一对应，属于“单用户独占”的方案来实现“多租户隔离“

• qbr由于绑定了安全组，在原生的数据面租户隔离的基础上又叠加了一层“安全层”来保证租户隔离。

原生的数据面转发（ br-ethx/tun 、br-int）负责“正常行为”的租户隔离，而安全技术（ qbr)负责“异常行为”（非法访问）的租户隔离 。

2.1.2 网络节点

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

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

2.2 管理面的租户隔离方案

管理面对于Neutron而言，指的是控制节点。openstack(neutron)控制节点的实现模型如下图：

对于管理面，租户隔离一般涉及几个层面：硬件/操作系统层面、应用程序层面、数据库层面。Neutron在这几个层面隔离方案：

对于多租户隔离方案，Neutron仅仅在数据库层面做了一些租户隔离。数据层面租户隔离方案相对较弱，普遍采取第三种：

• 独立数据库
• 共享数据库，独立表：不同租户，不同表，而且不同租户之间的表也没有关联性（类比设备中的VRF）
• 共享数据库，共享表：通过表中字段，如tenant_id来区分不同的租户。

2.3 故障面的租户隔离方案

Neutron在数据面、管理面的租户隔离方案可以分为两类：

• 资源但租户独占（如router）：具有一定的故障层面租户隔离能力，如一个租户的Router发生故障，不会影响到其他租户。
• 资源多租户共享（br-int）：没有任何故障层面的隔离能力，一旦一个部件发生故障，所有与其关联的租户都将要收到影响。
  

资源独占是相对的，而不是绝对的。一个租户可以独占一个Router，但是可能与其他租户共享主机，更有可能共享Rack（机架），更不用说共享更大颗粒度的资源数据中心了，这不是技术问题，而是云服务器的商业本质。

只要存在资源共享，就不可能做到真正的故障租户隔离，所以Neutron在故障面的目标就不是租户隔离，而是容错。尽量保证不受故障影响，不仅Neutron如此，openstack也是如此。

本文参考：《深入理解Openstack Neutron》——李宗标