Neutron资源的租户隔离介绍

Neutron是一个支持多租户的系统，所以租户隔离是Neutron必须支持的特性。在Neutron的资源模型中，有一个字段：tenant_id。这个字段的目的就是为了资源的租户隔离。

说到租户，稍微有点尴尬，因为从Newton版本开始，tenant_id存在的意义只是为了后向兼容，变成了一个历史的印记而已。它与模型中的另外一个字段project_id的解释都是：The ID of the project。不过无论是tenant_id也好，还是project也好，它们除了起到传统的ID作用外，还有一个更深层次的意义：租户隔离！

租户隔离，顾名思义，是为了隔离。其更深层次的目的是为了共享。

关于租户的说明：

1 租户不是人，租户就是客户，而这里的客户指的就是企业。

2 虽然不能把租户理解为“人”，但有时候还是把租户当做人来看待。

3 租户隔离，其实是“多租户的隔离”（单租户不存在隔离的必要）。

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

租户隔离，在不同的语境下有不同的含义。在Neutron语境下，从租户的视角，或者从需求的视角来讲，租户隔离有三种含义：管理面的隔离、数据面的隔离、故障面的隔离。

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

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

换句话说，一个Tenant只知道它自己的网络，对其他网络毫无察觉。

Neutron的管理面指的就是“控制节点”。虽然Neutron自己称呼那个节点为“控制节点”。但本质上控制节点还有很多很多“管理层面”的工作。

数据面的隔离，指的是数据转发的隔离。不同租户的网络之间，一般来说是不能互通的。从管理权限角度，一个租户感知不到另外一个租户的网络。不仅无法感知，而且还可以“重复”。比如，租户1可以拥有一个私有网段10.0.1.0/24，租户2同样可以拥有这个私有网段。从这个角度来说，数据面的隔离，恰恰是为了复用。

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

这个租户网络的路由器本身出问题了，比如它的路由表凌乱了，不应该影响其他租户的网络，这是正确的。

另一方面，我们知道，Neutron的Router是位于网络节点（不考虑DVR），如果这个网络节点死机了，这个时候我们就不能讲：一个租户网络的路由器出问题了，不应该影响其他租户的网络。要知道，网络节点出问题了，那就是全都出问题了。

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

我们也许可以这么说，一个租户独占一个网络节点，不同租户的VM不能位于同一个Host，这样是不是就做到了租户的故障隔离了呢？

或者，我们可以继续这样追问，如果机架出问题了呢？那么是不是不同租户必须要分布于不同机架？那如果数据中心出问题了呢？是不是不同租户需要分布于不同的数据中心。

这样追问下去没完没了，那么租户隔离中的“故障隔离”到底该怎样理解？我们暂时先忘记这个问题。看看下面理解。

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

Neutron在租户隔离这个层面，不会也无法承担全方位的无限责任。比如故障隔离，就不能承担无限责任！

Neutron在管理面的隔离、数据面的隔离这两个层面，必须承担无限责任，而在故障层面的隔离这个层面，只能承担有限责任。所谓无限责任，就是必须全面保障，如果没有达到隔离目标，必要要修改错误；所谓有限责任，就是只能在某些层面保证故障隔离，而不能全面保证到底是哪些层面。

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

这些物理资源中，数据中心、物理网络是必须共享的，不然云服务商要破产。机架、主机也不是说可以绝对地由哪个租户独占，有时候也是需要共享。所有这些物理资源，云服务商都不承诺“租户隔离”（租户独占）！

这个时候，我们可以给出“故障隔离更细化的理解”：管理面的故障、数据面的故障，必须要做到租户隔离；而物理资源层面，做不到故障隔离！

参考

https://developer.openstack.org/api-ref/network/v2/index.html