从互联网云计算平台看数据中心接入层网络隔离设计
作者 zhihuayang | 2011-05-16 07:41 | 类型 云计算, 互联网, 网络安全 | 90条用户评论 »
|
1、何为云计算平台 说到云计算平台，不得不提开放平台。去年以来，开放平台这个字眼可谓是炙手可热。自Facebook、Apple将开放平台的成功演绎至极致，中国互联网界便掀起了一股“开放潮”，新浪、百度、淘宝、360、人人、腾讯等互联网巨头，甚至是当当和京东等电子商务巨头，都放言“逐鹿”开放平台。 开放平台有三层含义：
无疑，这三者中，云计算平台才能真正解决第三方开发者面临海量用户的诸多挑战，对第三方开发者有着莫大的吸引力，可以实现互联网巨头们寡头经济和长尾经济两手硬的如意算盘，被视为未来互联网的制胜利器。因此，各互联网巨头也不惜投入巨资建设云计算平台争夺市场。据互联网公开的资料，腾讯的云计算平台opensns.qq.com开始建设仅4个月就取得出人意料的收获：
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网络的划分问题也迎刃而解了。似乎一切都完美了。 还没等网络大师们喘上两口气，就发现这个方案似乎也行不通。 首先，从技术角度，单个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做业务隔离，如果性能会不够，再考虑别的方式”。 | |
 (4个打分， 平均：5.00 / 5) |
雁过留声
“从互联网云计算平台看数据中心接入层网络隔离设计”有90个回复
精彩，这个规划问题我想了很长时间，没找到很好的答案。比较稳妥的还是粒度大点吧，哎⋯⋯
L2从无限全广播的大HUB到QINQ粒度的隔离，为的是更好的为传统以太业业务提供安全可靠的L2连接，但云计算这种计划外业务给VLAN和一般的L3 ETH造成了严重的不适，主要问题是一般以太网段下的IP地址是要和网段及VLAN couple得难解难分，导致位置迁移非常不便，所以出现了五花八门的解决技术。
还有一种可能的技术是用L3替代所有L2交换机，通过PPPOE做IP连接，利用PPP地址分配不需要同一网段的特点，保持服务器的IP地址永远不变，L3交换机通过PPP学到服务器的IP地址，并进行路由发布。带来的开销就是PPPOE协议栈的处理，PPP只有4-6个字节，overhead开销带来带宽问题不大；进一步，服务器可携带VLAN ID，并保持不变，L3交换机根据服务器的VLAN ID处理业务隔离。
我对数据中心的IP/ETH交换系统不懂，只是随便乱想了一个idea
最后一句话不是太明白，谁给解释下。“我们现在在服务器上用IPTables和Ptables做业务隔离，如果性能会不够，再考虑别的方式”。是说现在业务部门正在为Qbg，Qbh提供支持吗？Qbg和Qbh在服务器端是需要支持虚拟交换机的网卡吧。
有点混乱
互联网厂商开放平台中，对大量第三方APP的隔离根本和物理组网无关，基本都是上层的事情。
GAE，Saleforce，SNS.QQ这些PAAS/SAAS就不说了，都属于应用隔离范畴，不用看到网络配置属性
即便是IAAS，Amazon EC2人家也是在每个Dom0以流的方式动态加载L3/L4 ACL，不需要物理网做任何配合（别人发给过我一份专利，我忘了具体网址了）。至于规模，Clueter内PVLAN大二层没什么问题，部署成宽带接入方式即可，下面不交换也没SPT问题（cluster大约是2K节点，应不超过32K VM IP，主机路由一般的L3完全可以支持）。Amazon不支持跨Cluster的所谓大二层，那玩意除非热迁移根本没用，而热迁移根本就是噱头。
作者是腾讯的吧？ 这篇文章怎么看着有点软。
IAAS下，虚拟机迁移，动态部署和网络弹性是非常复杂。我们现在的方法是在大二层网络下，使用VLAN做业务隔离，同时开发一个service deliver platform,将交换机，路由器看层Service的一个计算属性，和VM一起做到动态部署。
理客的方案貌似想接入网的办法，解决了Service的业务隔离问题，但同时，相同业务的横向流量必须都上升到三层处理。 对L3交换机能力要求太高， 同时，不利于并行计算。
理客方案的思路是正解，但PPPOE不是必须的，PVLAN一样可以有宽带接入效果。（用PPPOE的话L3就成BRAS了，成本太高）。
至于VM间横向流量，这种方案只是没省掉TOR内部的交换。但在真实环境中，TOR内部交换流量又有多少呢？一般这种组网都要求Cluster内部尽量小收敛比，因此全部透到Cluster的Core switch不会有压力。
内部交换容量， 不同业务有不同的需求， 比如分布式文件系统GFS， CEPH等。
PPPOE是很好的解决了纵向的通信问题，而且结合灵活QinQ也能做到很多业务隔离。但是对于横向间的通信，PPPOE的session之间通信都必须经过bras，对bras来说无异于负担又重了…….
不好意思，啥是Ptables?
是内核哪个版本引进的？
用PPPOE只是借尸还魂。
借这个壳解决与位置无关的固化IP地址和动态发布路由问题，部署位置没有限制，对纵向和横向都一样。
所以并不要BRAS，也不需要在转发芯片里支持PPPOE session转发，只在报文解析时多识别和剥离一层PPP header，此外都是标准的L2处理和L3路由转发
如果将来想更多的控制和安全等，有pppoe能做很多事，通过PPPOE把广播网络改造为PPP网络，PPPOE是PPP和以太自然结合的优秀典范，给了PPP第二春
行业在做得事无外乎是：第一，MAC的非结构化，导致对寻址空间空前的需求，要么拼命扩大地址设备容量，要么采用变通方式（如动态寻址）。第二，任何信息如果要做（路径可知）的交换，必须做标记，虚机也不例外，行业无外乎是在从软的（vSwitch）和硬的（vNIC）两方面寻求解决。第三，有了寻址和（路径可知的）交换，其他问题都容易解决了。这里你就看到Cisco牛X的地方，率先控了前两条
pppoe的思路挺新颖，没有对pppoe深入研究过。不过一方面是性能问题，数据中心交换机对pppoe的支持是有限的，况且东西走向的流量都要经过pppoe的终结点，难免会成为瓶颈。另外用pppoe越过接入层之间到L3也会损失很多别的特性，特别是在接入层对数据流不可见。
对于业务部门来说，在操作系统层面做iptable和ptables实现访问控制是很容易的事情，而且不必求助网络部门，有更强的主动性。
其实网络也可以不管隔离的事情，但问题是，如果网络把这些都交给应用了，网络的价值就越来越低了，更谈不上去引导应用了。所以，在网络可以接受的层面上，我觉得还是需要去考虑能否。当然，很多平台网络层不做，实际上也是因为做起来很难。虚拟化环境下的应用隔离网络实现，的确是件不容易的事情。
英雄所见略同！问题是vlan的大小和ip规划粒度如何决定？当然，根据应用的具体情况我相信是可以找到一个合适的平衡，但这需要积累和沉淀。
cisco做了那两条，但未必是控了，呵呵
1、东西问题不是问题，可以把支持PPPOE终结的L3 SWITCH放在边缘，或者用普通L2 SWITCH+ PPPOE L3 SWITCH cluster组成一个线速交换网路
2、PPPOE协议非常简单，数据中心的应用和BRAS无关，也不需要在转发芯片里支持PPPOE session转发，只在报文解析时多识别和剥离一层PPP header，此外都是标准的L2处理和L3路由转发。目前肯定没有这种以太交换芯片，但技术难度很小。openflow也许可以用一下，可能学术会喜欢
3、这个方案的好处是可以充分利用成熟多年的PPPOE协议和所有L3交换路由甚至MPLS等技术，不需要其他标准那么大的改动
理客的想法不错，不过pppoe在支持组播和广播方面缺陷就比较明显了。如果pppoe，是不是不如干脆ipoe那，ipoe+qinq。
我倒是觉得Lisp是个好办法
to asr1k. 你说的lisp是结构化地址和路由的解决方案吗？我对lisp的理解还不是太深入，没有理解lisp用在数据中心内部对网络隔离和IP规划的好处，是提供迁移的便利吗？
数据中心要广播和组播吗？如果需要，则要把PPPOE L3 SWITCH部署在最边缘，就没有这个问题了
很多业务的集群，比如游戏，是使用组播的。
Lisp其实就是一个动态化的可寻址的GRE隧道而已.
云计算服务提供商通常都会在全球建立多个数据中心, 而传统的anycast以及一些其它的寻路规则总是有这样那样的羁绊. 而且虚拟机迁移, 数据中心迁移以后将是常事.
有些位置寄存器的概念以后, 就可以解决一些问题, 就像手机中的HLR一样, 手机全球漫游很方便也是因为这个原因.
PPPOE部署对终端又提出了新的要求，做为server要统一部署PPPOE，这个工作量也不小。
我理解是否要每个虚拟机都要发出一个PPPOE session？如果是这种方式到也可以做到业务间隔离的作用。
这种套用运营商接入网的方案也可行。如果仅仅是维持PPPOE serssion，那么bras倒是也不是必需的了。
但是考虑到组播和广播的问题，会否802.1X更好些？
网络安全就是安全大师们想出来的一个概念，当服务器性能够大时，操作系统级别有自己的安全控制，应用系统又有自己的安全认证，要那么多的安全吗？数据中心的网络是内网，当你真的用到虚拟化时，统一的管理，客户机全是定制的，如果采用VDI技术，全网内可以说没有攻击源，要安全做什么用呢？
to viking, 这里讨论的是第三方应用托管的虚拟化环境。第三方应用之间的隔离是必须的，不管从哪个层次来做，否则相互之间的数据和应用安全难以保障。
PPPOE涉及终端、转发和组播问题。
PC上PPPOE终端很平常，服务器系统上就不清楚了。组播问题，PPPOE L3到边远可以解决，但转发带来的复杂性有点麻烦。
如果数据中心不用全L3的问题主要是IP地址无缝迁移问题，那么PPPOE L3到边缘是有一定可行性的。因为DHCP和ARP和IP subnet/MAC的紧耦合机制，并且已经标准化多年，基本上很难改造，而服务器上跑路由器协议也也是弊远大于利；其他各种数据中心的新协议也是要很大的改造。
之前说到用PPPOE只是借尸还魂，但借到什么程度有很多变化的空间，比如可以把控制和转发分开，也就是把PPPOE当成一种IP地址分配和路由机制来处理，转发还是用FIB+ARP，当然二者之间加一些互动，这种互动不需要修改现有的转发层面的处理，只需要控制层面修改即可。可见couple得太好，河蟹时期还好，在有时世事变迁中，也是大麻烦
To 理客
貌似支持PPPOE封装的L3S在市面上是稀有品种啊？
其实传统simple IP也可以做到，而且不用改交换机，关键是Dom0的参与：下面PVLAN隔离，L3S使用标准ARP学习机制，不使用DHCP。当启动/迁移一个VM时，该物理机Dom0负责为该VM分配其IP(如为DHCP则不出服务器，如为静态配置则更简化)，然后发起一个到L3S网关IP的ARP，L3S即可学习到该VM的IP-MAC映射，同时沿途L2S学习到MAC-Port表。
由于Dom0的介入，杜绝了一切的安全隐患，以及网络上VM的DHCP使用，因此大大简化了对网络设备的需求。
to asr1k
其实Cisco还有另一个类似技术OTV更合适，是专门用来做多个数据中心间二层互联的，它也用GRE封装。此外，广为使用的open vswitch也支持GRE封装方式。这些转发面的大体思路类似，控制面稍有诧异。
我觉得GRE对于构建超大规模跨DC的虚拟二层网，比什么TRILL，802.1AQ之类靠谱得多，首先对网络设备的影响就小得多，如果是基于openvswitch方案压根对网络设备就无需任何改造。
总结几位的想法。lisp更适合面向运营商，特别是整个Internet，简化路由，更有意义。OTV是面向数据中心的，构造跨数据中心的二层。但DC内部的大二层恐怕还是需要别的技术。PPPOE面临交换机和服务器支持的实际问题。
to 根本不相干：关于dom0在这里面的作用，有没有更详细的资料？search了一下好像没有找到。
to 根本不相干:
对于需要比较经常性的进行虚拟机迁移来说，手工配置的GRE会不会太痛苦了点？
to 楼主:
理想和现实是有差距的，这个差距就是技术进步的动力。你这篇文章把理想和现实混在一起说似乎有点不合适。
最近也在思考云DC的组网问题，个人认为云中心组网的问题还有很多，比如MAC地址的规划问题，你提出的很多问题也不是没有方法。我还是回头单独开一贴，把自己的想法写进去吧。
to zeroflag: 你说的很对，很多时候理想和现实是有很大差距的，但作为网络规划和设计者，需要有一些前瞻性。等待拜读你的大作。
PPPOE的L3 SWITCH确实没有，但是目前的其他方案也需要芯片支持，PPPOE方案可以用通用的L2/L3交换芯片，只需要修改控制层面
GRE是必须要转发层面增加IP头的，并且开销更大，没有标准的动态协议，不是一个好东西。
如果要VLAN隔离，那么迁移就要考虑如何突破VLAN，也是个麻烦事。
不要VLAN没有这个麻烦，但L2的收敛时间，可靠性，负载分担等问题还在，所以才会有trill，1AQ等一些复杂的协议。
L3到边缘是最好的方法，只要解决了IP地址固化，利用ARP但和ARP decouple即可。基本方法并不复杂，只要把业务IP和接口IP分离，业务IP，比如虚拟机IP可以永远不变，实际物理接口IP可以随着迁移而变化，但不会对业务有影响，二者之间通过路由关联起来即可。进一步，甚至接口IP都可以不变，因为，只要不发布接口路由，那么这个IP地址只在直连的本地有效，对整个L3网络没有任何影响，充分利用PPP和IP路由的基本特性，就能有神奇的效果，不一定非要复杂的协议，物理层最好的是EHT、链路层最好的是PPP，网络层最好的是TCP/IP，数年数据网络的残酷竞争的优胜劣汰已经清楚的表明这三者是最强的
to 理客：“链路层最好的是PPP” 这点不敢苟同，实际上现在除了运营商用户接入在用外，别的场合已经很少用了。随着新业务的发展，如IPTV，pppoe也不能包打天下了，开始转向IPOE和PPPOE并存。
借此贴给弯曲提个问题和建议。目前网站访问不够流畅，我在北京地区。不知道网站的服务器在哪儿，如果是在南方或者是国外，那应该是ISP的问题。如果服务器也在北方，机房应该可以双线或者是三线接入的好一些。
To 理客
看来我没把两种场景分开说清楚，引起误会。
场景1：小规模组网
这种情况下，没GRE什么事，也没VLAN什么事，由于规模小因此传统双归属基本可以满足需要。具体实现上，不需要PPP，就用普通L2/L3，可以实现所有功能。所有安全控制，Dom0自己可以完成。
场景2：大规模组网，跨多个集群的二层互通
一种思路就是TRILL/AQ等大二层，还有一种就是先L3到边缘，然后GRE实现L2 over L3。封包效率而言GRE确实比PPP差，但这种差距不足以在本质上构成优劣比较。GRE的突出优势在于无状态。当然，这种场景下的安全控制也同样由Dom0完成，无需网络参与。
关于GRE的动态协议，前面zeroflag提了类似问题，质疑其手工配置复杂性，我另开一个回复
To zeroflag
手工配置的GRE会不会太痛苦了点？
问题非常好。事实上不仅对于热迁移，冷迁移，或者即使是普通的在一个二层网段内增加一个虚拟机，意味着所有网段存量VM都要更新GRE，更新数量是N平方。
看起来很吓人，但答案却很乐观:) 首先不会有手工配置场景，其次它比我我们想象的使用起来更简单。当然，我指的是基于Dom0或VMM的vswitch方案，而不是基于网络设备的方案。
前面楼主也问到有没有Dom0的资料，文档确实比较少，推荐看看openvsitch.org网站，细节要看代码。我简单说说：
1) OVS有一个中央数据库，维护所有VM分组状态和位置状态。具体部署时如果该数据库和虚拟机资源管理系统合一，那基本上就没有额外管理负担（这里要跳出单纯网络的思维来全局考虑，因为虚拟机资源管理系统已经天然要管理这些信息，与网络设备无关）
2）组内任何一个VM发生变化（增加、删除、迁移。。），该数据库同步更新到所有组内其它节点
3）每个物理节点上的vswitch维护一张映射表，就是到组内其他VM的MAC走哪条GRE隧道封装，同时会有ACL信息负责安全控制，防止所有的spoofing和非授权访问
4）这里是关键：对于传统Linux网络内核而言，这么多条隧道接口和iptable/ebtable的ACL估计立马系统就崩了。但OVS彻底重写了这里的转发逻辑，用类似流表的方式同时实现海量轻量级的隧道接口和ACL，基本做到CPU性能损失不随隧道数和ACL数同步增长。
这里顺便顶一下楼主最后一段话：业务部门的一席话差点又让网络大师眼前一黑：“我们现在在服务器上用IPTables和Ptables做业务隔离，如果性能会不够，再考虑别的方式”。这句话是精华，基本代表了业界现状。事实上，OVS就是在传统linux的iptable和ebtable性能不够的产物，而且也同样没有“劳烦”网络大师：）
to zhihuayang:链路层，除了金融等领域的异端，主要有三个：
1、从电路交换到包交换转变的：X25/FR/ATM，这一派是最早的，以ATM为辉煌到顶，即使在开始没落时还混了3G很长一段时间，但在EHT/IP/MPLS三座大山压力下，已无力回天，现在已经是无可奈何花落去，正在被phasing out
2、以太：是最自由派成本最低派，以物理广播起家，所以在可靠性、收敛时间、安全性、可维护性等方面先天不足，后天补难，在对这些方面要求高的情况，以太不行，当然广播组播这些基于以太本性的业务支持很好。
3、PPP：和以太正好相反。
以太和PPP上面承载的上层协议最丰富，要比较优劣确实不相上下，各有长短
to 根本不相干:数据中心的规模的大小如何定义？我不知道目前的数据中心服务器用GE还是10GE连接交换机的比例是多少，就按GE算，目前一个单板或slot可以最多支持96个GE，如果一个大交换机有16个槽位，那么大体是1600个GE，如果有公司提供2+4的cluster，那么就是6400个GE口，这样规模的DC算什么规模？这种情况下，每个服务器之间都只有一跳就可以互联，都直接连接在L3网关，还需要什么特别的协议解决迁移、负载分担等问题吗？但还是有问题：如果都在一个L2里面，6400个，安全吗可靠？如果用PVLAN隔离，那如何互通？如果直接用L3，如何迁移？
to 理客
1) 关于规模：你举的例子正好是一个集群的规模。大ICP单集群一般小的1、2千，大的5、6千，这基本算一个单站点的微型数据中心。大型数据中心是若干个这样的集群联合。
2）我的意思和你一样，赞成在这样的规模下，根本不需要任何特别的协议处理迁移与负荷分担。即使是目前普遍的带TOR的两极结构情形，也不需要特别的处理。
3）用L2，安全可靠。原因我上面大概解释过一下，就是Dom0已经保证了VM不可能发出任何非法报文，所有网络看到的流量都可以信任。
另外补充一点：一般单cluster拓扑相对固定，网络设计可以很简单，因此避免很多传统以太在复杂组网下产生的问题。但跨多个cluster的场景不确定性就很大了，最好上L3，因此这种级别的规模简单以太组网会出问题，解决的思路分两派：网络大师们的AQ/TRILL，或者是OTV或者openvswitch的GRE方案
to 理客：数据中心的规模大概是这样的，单个网络模块5000台服务器左右，一个数据中心可能会有多个网络模块。google的单个网络模块通过自研设备降低控制平面开销可以做到6000～20000台规模，facebook使用商用设备调优做到5000～10000的规模。通常搜索这样高性能计算的集群会要求6000～7000台服务器的规模。
网络模块这个叫法有没有来源？看google论文，很多地方原文是cell，少部分叫cluster，我一直头疼选个合适的中文叫法。
一般叫pod 或者 field，网络模块是根据自己的理解翻译的。
多谢二位的专业答复。
这种情况，个人考虑也许可以这样：
1、每个端口都是L3模式，也就是不会有广播到其他端口，安全可靠
2、通过PPPOE或者其他方案解决虚拟机地址迁移问题（软件方案，不需要修改服务器和交换机硬件）
3、如果需要网络做业务隔离，则通过VPN manager来创建和管理基于VLAN三层子接口的VPN。
4、多个网络模块之间的负载分担和备份等，直接通过路由解决
如果这样，为什么还需要trill/1AQ等那么多的复杂协议呢？
to 理客：有很多应用场景需要L2，比如，HA，虚拟机迁移等，另外像组播的应用，L3会比L2复杂很多。所以数据中心目前的趋势还是大二层，而不是L3到端口。总之，应用对网络的要求是尽可能简单，应用不喜欢也不原因考虑复杂网络环境下的情况，并不是不能做，而是应用的强项和重点不在网络上。这也是为什么那么多虚拟调度管理系统都要求L2环境的原因，非不能而是不愿L3而。
但是这里面有一个tradeoff。姑且用“模块”这个概念来阐述吧：我认为模块内部应支持L2，但模块间无需支持L2，用L3互联即可。理由：
1) 热迁移作为资源调配的手段，在模块内这个资源池规模已经足够发挥作用，无需跨模块。跨模块也会带来很多其它问题，如存储带宽
2) 就业务效率而言，显然是相关资源越近越好，不应跨模块，如HA/组播。跨模块不是因为单一模块资源不够，而是要做规避系统风险的容灾（一般甚至要求跨不同机房的模块），此时容灾对象之间并不需要L2连接，它们之间没有太多耦合，基本是独立工作然后由前端balancer负责切换业务流量，这与紧耦合的模块内HA、组播有很大区别。
这里引出另外一个问题，模块内拓扑如此简单的情形下，需要AQ/TRILL来实现二层吗？
我个人比较赞同正文中最后业务部门的观点，“网络大师”们总是折腾出各种复杂的玩意。记得Cisco曾经演示数千公里的广域热迁移，当然这有助于展示技术实力，但我实在困惑实际的场景需求是什么:)
最后，上面不少地方提到组播，顺便想请大家讨论一个，这个我也一直比较困惑：
数据中心里组播到底有没有用？如果有用，商用部署的实际案例有哪些？（希望能搜集一些客户的实际案例，而不是分析认为在某些场合绝对有用）
to 根本不相干：网络模块之间的确是L3，而且模块内部可能也是若干L2区域通过L3连接的。
trill大二层技术一方面是扩展二层网络的规模，另外一方面是可以尽可能利用所有链路和设备，降低收敛比。
组播的场合，我举一个例子。很多游戏业务里面的集群，就是靠组播来同步数据的。
能不能更详细地介绍一下？我也希望能找一些更详细的信息，谢谢！
我问过的盛大和网易，好像都没有用组播。当然我也可能没找对人，你了解的情况是他们用来做哪些数据的同步，具体是如何组网的，规模有多大，服务器和网络如何配合？
to 理客
PPPoE的思路有意思，理客说“借尸还魂”，我觉得目前提出的新思路实际上也借鉴了以前技术的优点，包括PPPoE，具体哪种最终能胜出，综合了各方面的原因，包括部署难度、迁移成本等。
PPPoE目前在数据中心几乎没有曝光率，现在业界的风向是将L2做大，如果重新做回L3，有很多我们没考虑到的问题会冒出来，比如转发效率等等。
to yangzhihua
你提的都是实际问题。
针对这些需求，我觉得Cisco N1000v是目前最靠谱的解决方案了，但就算是N1000v离完美也还很远。
首先N1K整合Qbh/Qbg的路线图还没有确定，这导致了N1K同基于网卡的NIV目前还是割裂开来的模式，客户往往面临一个两难的抉择，不管选哪头，都会丢掉另一头的优势，如果同时选择NIV和N1K，先不说成本压力，管理界面也没法统一。
其次，N1K只支持vmware平台，无他～～
TO 根本不相干
我觉得网络安全解决的是非常态的安全事件，也就是说在主机已经出现问题时，网络还能提供一层防护，这同主机上的防护是不矛盾的。
其次，虚拟化的数据中心内，网络必将是最重要的环节之一。你提到cisco数千公里热迁移的例子，我反倒觉得丝毫没有炫耀的意思，而且我觉得cisco做得远远不够，现在长距离的L2通道，cisco主推的方案只有OTV和VPLS，昂贵且复杂，中小用户根本用不上，但我在客户处真实碰到了远距离虚拟机热克隆的需求。所以说，目前的数据中心网络还远远没有发育成熟。
最后，我相信应用部门能够自己部署一些安全策略，但这涉及到一个值不值的问题，花钱请来的程序员和服务器管理人员做这些能通过网络层完成的工作是否合适呢？是否是他们擅长的呢？
我本人水平一般，但我相信90%的数据库管理员的水平同我差不多。我经历过的部署里面，若一台HOST上多个虚拟机在不同的VLAN，特别是这些VLAN又传递的是控制流量时，只要网络连接出现一点点问题，就能演变成让人崩溃的灾难，如果这个时候还涉及到上联交换机的配置变更，我相信任何一个应用部门的人员都不想再跟debug纠缠下去。
因此，如你所说，数据中心内的最优方案往往是个tradeoff，是权责平衡分配的结果，主机离不开网络，网络离不开主机。
请教几个问题：
1、HA/备份为什么一定要在L2互通？是因为使用的协议，不是IP based？还是因为用的是L2组播地址不用L3组播地址？
2、迁移是否需要一个专门的协议？是否只能在L2互通的范围，一旦过L3就不能迁移（即使可以保证不用更改虚拟机IP地址）？为什么？
3、理论上只有MAC based协议才可能有过L3交换机的问题，数据中心主机上都有哪些协议是MAC based，不是IP based？当然libing说的目前都是在L2环境下运行，如果改成直连L3交换机，很难说会有什么问题冒出来，是的，长期在L2下，L2的问题都已经尽力冒完了，到了L3，确实很难说。如X86 CPU一样，兼容是不得不背的包袱，利弊权衡之下，直到背不下去或者背不动的一天才会考虑大的变化。
4、L3转发的效率和成本问题可能不大，目前主流的核心以太芯片在L2/L3转发上应该说是从性能到成本，区别不大，数据中心即使按照32位路由处理，也很难超过10万。
5、另外一个就是有说法L2的时延小于L3很多？而数据中心也需要这样的低时延？链路故障时，l2冗余链路的恢复非常快，比如是毫秒级？我不知道这是不是真的，还请内行人指点。
To libing
能否具体介绍一下客户的应用类型？
没有别的意思，我只是想了解下，这个客户远距离热克隆的需求，是想要“榔头”，还是想要“钉东西”。
什么样的业务场景一定需要远距离热迁移呢？如果是这样，我不妨推测一下：
1) 首先它是一个关键业务，决不允许停机
2）时延不敏感，否则数千公里存储访问时延不能满足需求
3) 应用本身设计为不支持负载均衡，不支持双击HA，只能单机处理
4) 应用层本身不支持基于日志的状态同步，只能靠底层虚拟机状态同步
感觉有些自相矛盾。我也接触过不少客户的很多上层应用，不少客户开始也会提出类似远距离热迁移的需求（被引到了），但是经过详细探讨和解释后，他们放弃了对采纳这类前沿技术的向往。即使是数据库这类业务，也不需要VM热迁移来实现远程移动。
to 理客
2、迁移是否需要一个专门的协议？是否只能在L2互通的范围，一旦过L3就不能迁移（即使可以保证不用更改虚拟机IP地址）？为什么？
这个我清楚，回答你这一点：
1) 迁移本身可以在IP上运行，不必局限于L2
2）要L2的原因就是VM的IP地址不能改，如果能另外有办法满足这个要求，其实无所谓L2还是L3的。像微软论文中用的是IPinIP，也完全可以
多谢根本不相干。
zhihuayang和libing对其他问题能否解惑一下？
嘻嘻，为啥VM迁移被限制在L2，这个疑问我之前也有过。只能说，L2并不是必备条件，但是目前的主流平台都有这个要求，可能大家认为修改虚拟化平台让其支持L3，和从网络角度解决大二层这两个问题在当下，还是后一个更好解决吧。
我个人觉得虚拟化已经不算啥高新奇的玩意了，在越来越多的中小企业中都会看到虚拟化平台的部署。
我见到的情况，分支机构多、合作伙伴多、一线员工多的中小企业比如旅行社、设计院、各类咨询公司、律所等很可能在各地有多个机房，这类客户规模不大不小，受限于带宽成本和管理能力，目前还没有能力把所有的业务放到一个集中的数据中心内，全国可能有两个到四个的小机房，但他们同样希望在这些机房内统一管理虚拟化业务，比如将广州机房的业务通过热克隆的方式备份到北京。这个业务不一定是一刻不能断的关键业务，但如果没有一个大L2层，他们不得不将虚拟机拷贝出来，发送到北京，再手动在北京上线，整个过程很麻烦，而且要求广州机房有能够简单操作虚拟化软件的IT人员，无形中阻碍了虚拟化的扩展，增加了成本。
实际的IT运维是千差万别的，很多时候适应这些需求的最好方案不是一个技术上的最优方案，而是从用户角度来讲最简单、易行的办法。
我最关心的是数据中心/虚拟机等在系统业务层面到底具体在哪些地方必须是MAC based？因为理论上，如果没有特殊原因，做应用层处理的，在设计上没有理由不是IP based，而做成MAC based，否则不是自己给自己找堵吗
to 理客：1、HA/备份的问题。有很多HA的协议的确是工作在二层的，但也有很多协议实际上使用的是三层组播地址。我猜想既有历史的原因，也有将问题简化的考虑，避免HA的keepalive等信息穿越IP网络导致可靠性降低。
2、迁移问题。就想根本不相干说的，迁移本身二层三层都可以实现，只是系统调度软件的支持问题。
3、数据中心几乎没有应用是mac base的，但由于上述HA、迁移的需求，大二层网络可以把问题简化，对应用的要求也较低。
4、L3转发的问题。这不是问题，现在网络交换机的二层三层的性能基本一致。
5、网络延迟问题。三层网络依靠路由协议的收敛，速度比二层慢很正常。二层网络现在可以做到50～100ms故障链路切换。
大家对热迁移都很感兴趣。为什么要热迁移？HA不好吗？实际上HA可以解决热迁移的问题，但代价很高，资源利用率只有一半不说，系统本身实现HA也不容易，通常关键业务系统大家才愿意去做复杂而效率低的HA。如果能够快速热迁移，就可以在成本和应用可靠性上获得一个平衡。对于互联网企业，由于广泛使用分布式文件系统，image本身是存储在网络上的，在任何一台物理服务器上加载一个虚机都是很容易的。至于为什么热迁移都青睐二层网络，一方面是简单，另外一方面可以实现IP地址不变，保持服务的连续性和热迁移对用户的透明。
to 根本不相干：关于游戏系统使用组播的问题，这实际上是系统设计的问题，实现集群不一定用组播，但组播应该说是较好的设计，高效，简单。我见过核心部分只有数台服务器的游戏业务集群，使用组播。
to zhihuayang，多谢答复
1、工作在二层的情况，能否具体举个例子？比如协议通过MAC做协议交互过程的标记，而不是IP。如果许多HA都是必须要在一个L2，那确实很难改变。
2、你说热迁移可以解决HA的问题，是说如果可以热迁移，就不需要HA了，是吗？
3、游戏用组播是必须L2组播还是L2/L3组播都可以？
1. 关于游戏组播。我现在了得到的情况，大规模商用游戏运营商，基本没有用组播（当然我有可能渠道受限，没能了解到真实情况，希望大家有信息也分享给我一下）。用组播的，都在做技术的Trail。说实话，我不看好组播，这么多年了，还没有从叫好变成叫坐，我们从技术角度再力挺，相信也有不为网络工程师所能控制的客观规律在制约。
2. To libing：你说的让我感到有些困惑了。看你的需求是快照(snapshot)啊，这个对网络根本没什么要求，主要是管理系统要做好自动化，能够方便用户一键克隆。真正对网络有需要的是你克隆后的VM，和原VM保持机器状态级别的完全同步，包括存储和网络IO都完全一致，也就是说广州和北京的VM是远程热备，两套完全冗余的系统，服务于相同的客户，实时同步容灾，你是这个需求吗？
to 根本不相干：并不是说所有游戏都要用组播，但的确有很多游戏是用组播做集群的，包括从韩国引进的一些游戏。只要有这种可能的业务需求，数据中心网络就必须支持。
to 理客：实际上现在基本上所有的HA都是二层三层结合在一起，不管是HSRP/VRRP，还是主机的HA，还是防火墙的HA，都是设计在一个二层网络中进行HA的，三层地址必须在一个网段里面。
HSRP/VRRP一般只需要网关处理，对主机/服务器是透明的，他们并不知道网关是否运行了HSRP/VRRP。当然，如果一些业务，比如防火墙服务是在服务器上运行了HSRP/VRRP实例，在服务器间跑HSRP/VRRP，而不是在L3 gateway上 跑，那确实需要L2
to zhihuayang
我想你可能把“组播特性”和“网络层IP组播”混了。
的确目前很多游戏后端服务器有大量业务层上的组播需求，但据我所知所有实现方案均基于服务器软件自身实现，没有使用任何IP层组播特性。尽管看起来使用IP组播更高效，但事实就是没有，我个人猜测是因为应用系统和网络系统交互的麻烦，让ICP避而远之。
to 根本不相干:那服务器软件自身实现是用L2的组播吗？
to 根本不相干：我说的就是基于IP网络的组播，组播地址224.x.x.x。组播当然要软件来实现，网络只是提供通道而已。
TO 里客 & zhihuayiang
不是，和网络组播无关，和L2更无关，网络上是基于IP的单播。
也就是说，是服务器软件自己保存每个业务组播的IP，然后逐一点对点通信传送。
看起来很奇怪吧？我了解到的事实就是如此。我说的软件方案，就是指这种服务器自己完成的复制。而且，人家并不认为这会带来很大的负担，这点消耗对于其全网server的资源而言微不足道，但却避免了和网络打交道的麻烦
很有意思的现象：大多数和我讨论的网络工程师，都会说视频和游戏用IP层组播很有用。可是我了解到的所有业务运营商，都在用网络的单播，通过服务器点对多点通信，实现类似组播的效果。我也很想找找现实的商用案例参考了解一下，可惜一直未能如愿（是那种真正production网络中的规模商用，不是小局域网搞个技术研究的Trial那种）
这个是有些奇怪，一般用CPU复制，如果份数较多，还是比较耗CPU时间的，除非现在的CPU有独立于CPU计算的手段做内存复制，比如DMA的效率非常高
to 根本不相干：根据我的理解，应用软件的开发工程师对网络的了解都不多，理解组播的更少，我猜测这是业务系统中组播使用较少的主要原因。但实际上，这些年不断的看见有组播的应用，6年前就在一个学校看见视频的组播应用，而且规模很大，几乎那时所有的电视频道都传送，而且跨两个异地校区，真正的运行IP网络的组播协议，dvmrp等，上万的用户。最近的，XX交管局使用的摄像头监控系统，10年前就使用组播，用户在内网任何地方都可以随时点播任何一个摄像头的视频。韩国引进的游戏中，有组播应用的也不是个别。实际上，组播的应用采用单播也可以实现，只是效率低下得多而已，并不影响功能性的实现。
反过来，网络工程师对写应用的人的思路了解也不够。我曾经见到一个应用开发者通过业务逻辑轻易实现网络负载均衡的功能，非常巧妙，而且比网络负载均衡的解决方案可能更适用海量用户的情况。
这也充分说明同在IT圈，大家更需要沟通和交流：）
再to根本不相干：你说的单播实现组播的功能开销并不大，那是在应用的数据并不多的情况下，这时候不管是服务器还是网络，用单播实现都不会有什么问题。但如果是视频或者大量数据的交互，服务器和网络就会有很大的负担了，而且带来的延迟很可能难以满足集群系统同步的要求。相反，组播的延迟随用户增长并不会明显提高。
从这个角度说，你看见的很多应用用单播实现是无可厚非的，也许用组播是杀鸡用牛刀了：）
除了对网络组播理解问题和业务量不够大的问题，是否也因为组播有可靠性问题（比如丢包和时延的重传），而考虑只用单播实现组播模式？
to 74楼和77楼内容：（按人名不确切）
这两个回复都在点子上
1）关于CPU占用率（顺便回复76楼内容关心的开销问题），目前主要挑战有两个：海量通信会话(游戏消息状态传送)，大数据块传送(视频传送)。而目前linux的epoll机制和零拷贝机制，正好能分别有效降低两者CPU开销。你提到的内存拷贝，事实上一个视频文件块从硬盘上出来去网络上，像Nginx这样的高性能web server几乎不经过CPU，大部分由磁盘控制器DMA和网卡DMA完成，CPU仅仅封装包头。
2) 组播理论上也可以实现可靠传送，但太麻烦，需要再引入一套机制，专门针对每个目的单独做ACK。原来在无盘加载中Intel曾经提过MTFTP，后来不了了之，用得也不广。而游戏数据是需要可靠的，用组播很麻烦的。
顺便to 75楼内容
关于韩国游戏利用网络组播，如果不是那种局域网即时对战(那种场景也和数据中心无关)，能否告知具体游戏名字？抱歉我不是抬杠，因为我真的无法想象有互联网游戏会用到网络组播，有些颠覆我的认知，我需要自己确认一下一手信息:)
IPTV的确可能是目前唯一组播还能发挥的场景，但占整个IP视频的比例，也是小数目。首先，流量最大的大规模互联网视频运营商，都用单播的web视频。其二，即使是那些不成气候的电信运营商搞得城域网IPTV，也是对半开，并且趋势是点播。毕竟用户体验讲，IP网能天然实现个性化业务，为什么要倒退回广电广播模式，电信运营商优势如何发挥？
我的一点个人浅见：
做网络System的人与做网络App的人对multicast的理解和要求基本上是两个世界。
做system的人关心的是multicast来的时候，switching的时候不丢packet，能line rate。
做app的人关心的是能保序（Ordering）。
在Ordering方面，通常有Total Ordering和Causual Ordering。Causual Ordering比较难。这就是为什么许多——实际——系统用Total Ordering（例如，通过Uni－cast，单播）来实现Multicast。其实其目的不是Multicast本身，而是实现了Total Ordering
陈首席一语中的，可以结贴了，呵呵。
后续我会继续云计算平台网络安全方面的话题，和大家一起分享和探讨。
zhihuayang很优秀嘛。。。能这么快就理解我说啥了。我还以为许多人不知道我在说啥呢。。。：－）
不理解，为啥把多播包以单播的形式发送，就能做到保序呢？
这个略微涉及到一些分布式系统的基础知识。如果感兴趣的话，可以读一些时序逻辑的文章。或者我以后哪天写一篇文章。
最近比较忙。。。6月中就回国了。。。
In an operation transfer approach, the sequence of applying the operations is very important. At the minimum causal order need to be maintained. Because of the ordering issue, each replica has to defer executing the operation until all the preceding operations has been executed. Therefore replicas save the operation request to a log file and exchange the log among each other and consolidate these operation logs to figure out the right sequence to apply the operations to their local store in an appropriate order.
“Causal order” means every replica will apply changes to the “causes” before apply changes to the “effect”. “Total order” requires that every replica applies the operation in the same sequence.
Total ordering应该是做app的人最喜欢的，最可控了。组播在这个层面上无法确保能够做到，但如果是单播，就可以APP自己完全来控制了。
这也是为什么组播研究主要集中在视频、音频这样允许丢包的业务中，而极少看到用于data的传送，尽管很多象大文件分发之类业务看起来似乎也能用组播，但最后无一例外选择了server自身搞定应用层复制。
对于视频和音频类业务，其实也是一个tradeoff，是要点对点的个性化体验，还是模拟传统广电网络的广播体验。互联网无一例外选择了点对点，原因是1）Internet不支持组播；2)客户体验为上。而城域网IPTV，像广东选择点播，上海选择组播（几年前的信息，不知道有没有更新），大家都在摸索之中。
我之前说的是游戏业务的内部集群用组播，并不是对用户的服务使用组播。
组播的复制发生在网关上，但网关对packet的order并不了解，所以需要协议层就携带sequence的信息，否则无法保序。
从网络的角度看，逐包的multiple path才会发生disordering。
不知道主机端是否有multiple processes导致处理顺序不能保持？
MTV一般用真实的组播，否则网络带宽耗用太大
换一个角度来考虑这个问题，用户端和云端之间使用VPN进行联通。每个用户的应用前面部署一个虚拟VPN设备，把这个用户的所有应用都放在该VPN的后面。每个用户之间使用公网IP进行区分。这样就可以解决隔离问题。
数据中心层三组网，跨地域的互联是如何配置的？
可以通过配置mpls vpn的方式完成，而这个配置一般是要求在PE设备配置的。而PE设备，一般是属于网络运营商的设备。如果配置mpls vpn的话，对于多个虚拟业务群（例子是亚马逊提供的企业私有云业务），每个虚拟业务群，都需要配置一个独立的vpn吗? 这样配置起来，岂不是需要配置很多mpls vpn ？ 配置是否太复杂了？
目前已经实施的l3 互联数据中心是如何解决这个问题的？