Neutron的租户隔离实现方案

Neutron针对数据面、管理面、故障面，分别设计了不同的隔离方案，下面逐个介绍。

一 数据面的租户隔离方案

Neutron在计算节点和网络节点都涉及数据转发，所以这两个节点也都涉及数据转发的租户隔离。

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

上图中，VM1-1和VM1-2分属两个Tenant，当然，也就分属于两个Tenant Network。我们看到，涉及租户网络隔离的组件有：br-ethx/tun（1个）、br-int(1个)，qbr(多个)、router/dvr(多个)。

br-ethx/tun、br-int分别只有一个用例，这个是属于：用“多租户共享”的方案，来实现多租户隔离。比如br-int、br-ethx通过VLAN来隔离各个租户网络数据流量，br-tun通过相应的tunnel来隔离各个租户网络的流量。

qbr跟VM一一对应，这个属于：用“单租户独占”的方案，来实现“多租户隔离”。qbr由于绑定了安全组，它在原生的数据面租户隔离技术的基础上又叠加了一层“安全层”来保证租户隔离。原生的数据面转发（br-ethx/tun、br-int）负责“正常行为”的租户隔离，而安全技术（qbr）负责“异常行为”（非法访问）的租户隔离。

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

网络节点实现模型如下图：

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

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

二 管理面的租户隔离方案

管理面，对于Neutron而言，指的是控制节点。

控制节点实现模型如下图：

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

Neutron管理面的租户隔离方案

通过上表，我们看到，Neutron仅仅在数据库层面做了一些租户隔离。数据库里面的租户隔离方案一般有如下几种。

1 独立数据库

2 共享数据库，独立表（不同的租户，不同的表，而且不同租户之间的表，也没有关联）。

3 共享数据库，共享表，通过表中字段（比如tenant_id来分区不同的租户）。

Neutron所采取就是第3种，所以说，它在数据库层面的租户隔离方案是比较弱的。

三 故障面的租户隔离方案

通过前面的介绍，我们知道，Neutron在数据面、管理面的租户隔离方案可以分为两大类：资源单租户独占（比如Router部件）和资源多租户共享（比如br-int）。

资源共享型方案，没有任何故障层面的租户隔离能力，一旦一个部件发生故障，所有与其关联的租户都要受到影响。资源独占型方案，具有一定的故障层面的租户隔离能力，比如一个租户的Router发生故障了，不会影响到其他租户。

故障面的租户隔离与资源共享度的关系

但是，资源独占是由限度的，一个租户可一独占一个Router，但是有可能与其他租户共享主机，更有可能共享机架，更不用说更大粒度的资源（比如数据中心这个粒度的资源）。

只要存在资源共享，就不可能做到真正的故障租户隔离。所以，Neutron在故障面的目标就不是租户隔离，而是容错——尽量保证不受故障影响。不仅Neutron如此，整个Openstack也是如此。比如对管理面，Neutron就采取高可用等方案，以达到容错目的。