Neutron是一个支持多租户的系统,所以租户隔离是Neutron必须支持的特性。在Neutron的资源模型中,有一个字段:tenant_id。这个字段的目的就是为了资源的租户隔离。
说到租户,稍微有点尴尬,因为从Newton版本开始,tenant_id存在的意义只是为了后向兼容,变成了一个历史的印记而已。它与模型中的另外一个字段project_id的解释都是:The ID of the project。不过无论是tenant_id也好,还是project也好,它们除了起到传统的ID作用外,还有一个更深层次的意义:租户隔离!
租户隔离,顾名思义,是为了隔离。其更深层次的目的是为了共享。
关于租户的说明:
1 租户不是人,租户就是客户,而这里的客户指的就是企业。
2 虽然不能把租户理解为“人”,但有时候还是把租户当做人来看待。
3 租户隔离,其实是“多租户的隔离”(单租户不存在隔离的必要)。
一 Neutron语境下租户隔离的含义
租户隔离,在不同的语境下有不同的含义。在Neutron语境下,从租户的视角,或者从需求的视角来讲,租户隔离有三种含义:管理面的隔离、数据面的隔离、故障面的隔离。
管理面的隔离,指的是“管理权限”的隔离,如下图所示:
![](https://i-blog.csdnimg.cn/blog_migrate/fc2381435db0e6c7bccdbc96c4edecff.png)
图中的两个网络都是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