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