OpenStack Neutron 组件原生资源模型之租户隔离

OpenStack Neutron 组件原生资源模型之租户隔离

前言

由于neutron是一个多租户的系统，所以租户隔离是一个必须要支持的特效。
其中字段tenant_id和project_id都是为了为了实现租户隔离，二者含义一致，只是tenant_id是之前版本内容。当前存在一致为了向后兼容。
租户隔离当前可以大致三个方向，管理面隔离，数据面隔离，故障面隔离。
其中
管理面隔离主要是管理权限的隔离。即一个租户tenantA（tenant）只能管理tenantA的网络。
数据面的隔离是指数据转发的隔离。不同租户的网络，一般来说是不会互通的（不过当前公有云会有对等连接等服务，来提供将两个租户的网络进行互通）。并且不会感知其他租户的网络，这样其实多个租户的私有网段是可以重复的。一定意义上实现了复用。
故障面隔离简单来说是一个租户网络出现故障，不能影响另一个租户的网络。更细化表达是：管理面的故障，数据面的故障，要做到租户隔离，而物理资源层面，做不到故障隔离。

数据面的租户隔离方案：

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

图中VM1-1和VM1-2分属2个tenant，即分属2个tenant network。
涉及租户网络隔离的组件有br-ethx/br-tun(1个)、br-int(1个)、qbr(多个)、router/dvr(多个)。
br-tun/br-ethx和br-int都只有一个实例，是多租户共享的方案，来实现租户隔离。例如br-int、br-ethx通过VLAN来隔离多个租户网络数据流量，br-tun通过相应的tunnel（网桥）来隔离多个租户的网络流量。
qbr和vm一一对应，属于单租户独占的方案，来实现多租户隔离。qbr绑定了安全组。
router/dvr和每个租户对应，而且每个router/dvr运行在一个namespace中，属于单租户独占（namespace隔离），实现多租户隔离。router/dvr除了可以保证租户间得网络不会相互访问，还解决了逻辑资源（IP地址）冲突的问题。

网络节点的实现模型，如图：

网络节点中，br-ethx/tun、br-int、br-ex分别只有一个实例，属于单租户独占的方案，实现多租户隔离。

管理面租户隔离方案

管理面对于neutron而言，指的是控制节点。对于管理面而言，租户隔离一般涉及几个层面：硬件/操作系统层面、应用程序层面、数据库层面。
硬件/操作系统层面和应用程序层面都无法进行租户隔离，因为都是多租户共享的。
数据库层面可以通过独立数据库、共享数据库（独立表）、共享数据库（共享表，例如tenant_id）来实现比较弱的租户隔离。

故障面的租户隔离方案

随着资源共享度变弱，租户隔离度就变大。
所以只要存在资源共享，就不可能做到真正的故障租户隔离。

小结：

在资源共享的场景下，实现租户隔离，正常情况下是ok的，但是一旦出现故障，就难免做到租户故障隔离了。更应该采取容错方案，将故障的影响降到最低。