在VPC功能实现第一篇中，简单介绍了一下VPC网络对租户间隔离能力的提升以及基于路由提供的一系列网络功能。在这一篇中，将继续介绍VPC网络中十分重要的一个内容：网络带宽的控制，共享以及分离。

首先是对第一篇中，端口转发功能的样例代码，all-in-one http service 风格的实现。

核心功能：

Git repo地址

opencloudshare/Op_portforward

在readme中有简单的介绍，通过最基本的rest请求即可实现功能。

Demo级的代码，逻辑十分好理解，根据输入的router_uuid ，找到 L3 节点上的命名空间，修改iptables实现转发功能即可。

如果要在环境中正式使用，建议引入数据库作为转发记录的存储。引入了数据存储后推荐加入额外的两个流程：

1. 一致性

在通过commands或popen等执行系统命令的时候，通过不同的return status 及回显作逻辑分支或try-exception。保证调用功能时的数据库里的存储规则和nat表上规则一致性。

如果nat规则的写入和代码里不同——不是直接在preforward主链而是在neutron-l3的子链里写入，会发现执行某些网络操作之后，nat规则会丢失，这是因为Neutron-l3-agent在router所控制的floating_ip发生变动时，自身会重写nat表中自身子链的规则，这是neutron自己对l3数据一致性的保证。

2. 恢复

在l3节点所有配置清零重置后，能够恢复之前各命名空间内的nat规则。这个功能简单说就是一个读取数据库规则并解析执行的批量过程，也和Neutron的sync过程相似。

另外，从安全角度考虑，结合 keystone 加一层认证是更好的。

接下来进入带宽控制的主题。

Neutron在以OVS组网时提供的 qos_policy功能实际上调用的是 ovs已有的对挂接在ovs-br上port的bandwidth limit，但只能控制 port 的出流量，是单向的。

如同：

底层都绕不开linux TC: Tc (Linux) - Wikipedia

Tc控发不控收，注意发送指的是发出/上传/出网/上行 的意思，因此原生ovs bandwidth limit在单纯的对外提供数据的服务场景下是足够适用的。但是在提供用户上传功能、云主机软件更新等需要下行流量的场景则无法约束，更别提当云主机被入侵，攻击者植入程序产生或作为肉鸡发起对其它被攻击对象的爆发性大规模下行流量了。在做了双向的流量控制后，也更能分担监控、抗D等系统的压力。因此无论是用户业务需求还是平台层考量，双向QoS都是有意义的。

tc中的htb(令牌桶)算法简单描述：

在用原生tc代替neutron qos policy时，可以使用两种模式：

1. 云主机模式

即只对云主机做流量控制，这里要提一下计算节点上云主机连接网卡的原理。

在计算节点ip a的话，我们可以看到大量的虚拟网卡，在libvirt的虚机xml文档中，可以明确看到云主机与连接网卡的信息。

但除了tap设备外，计算节点上还有qvo,qvb,qbr。这些分别是什么呢。

openstack neutron 解释的很详细，可以直接参考。

不难归纳出 上行流量控制：

下行流量控制：

由前文，tc控制网卡设备的发出流量，所以当我们对上行或下行想做限制的时候，实际tc生效的设备只能是方向路径上的设备。故云主机模式的qos控制，可以分别对 qvo和 qvb设备进行规则写入，即可实现上下行双向控制。

上面即是对qvo233这个设备的带宽控制，实际为下行规则。默认子类为100 (10mb)，但是当源地址为 10.0.0.0/8 和 172.16.0.0/12、192.168.0.0/16 时，使用子类101 （100mb），这样保证私有地址间带宽为百兆，而公网流量的带宽为十兆。

为什么私有地址间的流量也要做限制？是因为即使是用户VPC内云资产产生的东西向流量，仍要占用计算节点物理网卡的实际带宽，以及用于构建 VXLAN 网络的交换机处理能力，考虑到云资产较多的情景，因此是不得不注意的。

顺带一提，公网流量既包含 L3 节点的南北向流量，也包含L3节点上网关路由到实际云资产所在宿主机的东西向流量。 带宽在 L3 处更容易出现瓶颈。

2. VPC模式

对VPC与外网间的流量控制可以更灵活，在系列第一篇里介绍了VPC的路由，而这个路由实际上通过至少两张网卡连接了租户内网与外部网络，

上图左上角的路由，有两张网卡，内连VPC的router_interface 与外连外部网络的 router_gateway。

在 L3_agent上也可以看出来：

qg为外部网络的网卡，qr为VPC内某一网络的网关。

在限制vpc总体的上行流量时，实际将 tc 规则写在 qg 即可，在限制VPC总体下行流量时，将tc 规则写在 qr 即可。

这是VPC共享带宽的一种思路。

如此实现了VPC内所有云资产的公网流量共享，无需再限制云主机单台的公网带宽，其实这种在公有云场景更满足用户预期，因为这样用户就不必为每一台VPC内的云资产带宽买单，只用支付总体带宽费即可。

在实现了VPC内云资源和外网流量的共享后，就有了新的问题，当发生资源抢占时该怎么办。

如果任由抢占，那么我们使用的随机序列算法就会生效，每隔10秒重新分配队列。

但这对有良好业务规划的用户来说并不合理，用户可能需要某些业务能保持一定的独占性。

所以我们通过对 不同子类带宽的划分 以及 filter 规则的细化，即可实现源或目的不同转发路径的带宽控制，对floating IP 以及 上一篇中的 NAT 功能同样适用 。

上图的样例设计即可满足 部分云资产的带宽独占性，同时在总共享带宽未满的情况下，可以进行借用的场景功能。

系列下一篇 《深入浅出新一代云网络——VPC中的那些功能与基于OpenStack Neutron的实现（三）》中将给出实现QOS带宽控制的类似开头DNAT功能 rest api 的demo代码，并展开下一块内容——VPC网络中实现互联互通的路由技术与隧道技术，和场景案例。