从互联网云计算平台看数据中心接入层网络隔离设计

1、何为云计算平台

说到云计算平台，不得不提开放平台。去年以来，开放平台这个字眼可谓是炙手可热。自Facebook、Apple将开放平台的成功演绎至极致，中国互联网界便掀起了一股“开放潮”，新浪、百度、淘宝、360、人人、腾讯等互联网巨头，甚至是当当和京东等电子商务巨头，都放言“逐鹿”开放平台。

开放平台有三层含义：

应用平台，为用户提供应用的统一入口，如Apple、Google、腾讯WebQQ的Appstore。

商务平台，为第三方开发者提供统一的商务接口，减少和不同平台接口之间的商务沟通成本。

云计算平台，通过技术能力的开放，为第三方应用提供实时可伸缩的计算资源、海量用户运维和客服、信息安全等后台支持和应用托管，可以在整个平台实现第三方应用的单一实例，如Google的GAE、Amazon的EC2、腾讯的opensns.qq.com。

无疑，这三者中，云计算平台才能真正解决第三方开发者面临海量用户的诸多挑战，对第三方开发者有着莫大的吸引力，可以实现互联网巨头们寡头经济和长尾经济两手硬的如意算盘，被视为未来互联网的制胜利器。因此，各互联网巨头也不惜投入巨资建设云计算平台争夺市场。据互联网公开的资料，腾讯的云计算平台 opensns.qq.com开始建设仅4个月就取得出人意料的收获：

已有108多款第三方应用跑在腾讯云计算平台上；

4个月应用总安装次数超过3亿次；

日活跃用户总数达到2千5百万，最高同时在线用户超过400万；

有三款应用平均日登录超过千万，超过10款应用平均日登录过百万；

单个游戏月度分成收入超过1000万；

2、VLAN和IP规划面临挑战

那么，和原有仅支撑内部应用的数据中心相比，云计算平台的数据中心会面临什么样的新挑战？

显然，由于云计算平台的核心是诸多第三方应用的托管，业务隔离是首当其冲的要解决问题，否则无法确保第三方应用及数据的安全性。

从网络的角度，业务隔离必须要从接入层能够将各业务的服务器分开。网络大师们不暇思索的给出了解决方案：VLAN。

不料，问题马上来了。VLAN的规模如何确定，IP网络划分按照什么粒度进行？

云计算平台是典型的长尾经济商业模式，这也就意味着托管的应用数量庞大，大部分应用的规模较小，但谁也无法预知一觉醒来哪个应用的用户数量会暴涨，因此计算资源的伸缩性要求很大。

如果VLAN和IP网络的粒度较粗，由于大部分应用规模较小，这会带来IP地址等资源的巨大浪费。

如果VLAN和IP网络的粒度较细，意味着当应用长大时会分割在不同的VLAN和网络中，如果涉及HA、虚机迁移等特殊需求还可能需要将业务进行跨 VLAN和网络的整合和迁移，这会招致业务部门的不满。更糟糕的是，服务器虚拟化技术发展很快，当服务器虚拟化1：4的时候，意味着网络设备硬件端口规模不变的情况下网络容量变成原来的4倍，如果服务器虚拟化在1：4的基础上进一步变成1：10网络容量就会猛增为最初的10倍，很轻易就会击穿VLAN和 IP网络的规划，应用也将被迫进行的跨VLAN和IP网络的迁移，应用的中断将不可避免。

可是VLAN和IP网络的粒度放大到什么程度才合适那？似乎暂时没有答案。长尾应用和服务器虚拟化的发展很难准确预知。

网络大师们总是追求完美的，希望应用尽可能避免迁移，于是，另一个方案出台了。

网络大师们现在不划分细颗粒的VLAN和IP网络了，干脆创建一个大VLAN，应用的隔离通过PVLAN进行，这样IP网络的划分问题也迎刃而解了。似乎一切都完美了。

还没等网络大师们喘上两口气，就发现这个方案似乎也行不通。#p#

首先，从技术角度，单个VLAN的规模是有限制的，由于大量生成树节点的计算会对作为根节点的三层设备的CPU产生冲击，通常一个二层网络难以超过 2000台服务器（包括虚拟机）的规模。这样规模的网络对云计算平台来说太小，需要建设多个网络模块，整个数据中心的网络结构的层次要增加，跨模块的网络性能又成为另外一个浮起的瓢。

其次，在服务器虚拟化的环境下，由于目前交换机还无法直接通过端口区分虚拟机，如果想使用PVLAN隔离虚拟机，服务器虚拟化平台就必须支持PVLAN TRUNK，或者说母机内置的虚拟交换机必须支持PVLAN TRUNK。目前业界仅Cisco的Nexus1000v可以支持，但限于vmware平台，而更受互联网行业青睐的开源解决方案尚无踪影。

前一个问题，即将出台的IETF的Trill标准，或者现在业界已有的解决方案，如Cisco的Fabric Path，可以在某种程度上解决，但后一个问题，网络大师们就无解了。

正当网络大师们行将崩溃的时候，一根救命稻草飘然而至，那就是即将发布的IEEE的802.1Qbg、Qbh标准。不管Qbg和Qbh双方如何争相表明己方的优势，事实上两者的最终目标是一致的，那就是要在接入交换机上通过虚拟端口的方式提供虚拟机在网络端口层面上的感知。

于是，当Qbg和Qbh商用后，接入层交换机就可以使用PVLAN的手段进行业务隔离，不管是物理机还是虚拟机。

然而事情还没结束，Qbg和Qbh并不是原有的交换机和服务器网卡所能支持的。交换机可以在建设数据中心时适当超前选择hardware ready的设备，当标准出来软件升级即可，甚至可以在原有数据中心更换接入层交换机。可是服务器的网卡选择并不是由网络大师们确定的，互联网企业定制的服务器要更换新型网卡也不是那么容易，更何况现存的大量服务器更换网卡几乎不太可能。最重要的一点，目前没有任何网络设备厂商承诺Qbg和Qbh会有 PVLAN的特性支持，也许他们目前的重点是确保能够成为标准之一，还顾不上这样的细节。

终于，网络大师两眼一黑，昏倒在地。

3、VLAN+ACL卷土重来

网络大师被速效救心丸救醒，因为云计算平台正在建设中，网络规划不可缺少。

吸取了之前的经验和教训，网络大师们决定暂时抛开那些尚未发布的标准，立足于目前可用的技术。

于是，VLAN和IP网络划分又开始了，这次网络大师们仍然决定做一个尽可能大的二层网络，所不同的是，不再考虑PVLAN的隔离方式，而采用VLAN ACL的方式进行访问控制实现隔离，虚拟机的母机和接入层交换机采用vlan trunk的方式连接。这样现有的交换机和虚拟化平台都可以支持，唯一需要新增加的，就是ACL管理的工具系统，这对于研发能力超强的互联网企业，算是小菜一碟了。

还有一个对于网络大师们是好消息的事情是，业界有些网络设备厂商已经开始支持基于标签的访问控制，比如Cisco的TrustSec，可以将访问控制的矩阵规模极大的缩小，虽然需要新的网络设备型号才能完全支持，但至少事情已经在网络大师们可控制的范围内了。

网络大师们兴冲冲的带着最新的方案去和业务部门研讨，希望得到业务部门的支持，赶紧把ACL管理系统开发出来。

业务部门的一席话差点又让网络大师眼前一黑：“我们现在在服务器上用IPTables和Ptables做业务隔离，如果性能会不够，再考虑别的方式”。