数据中心虚拟化需要大二层网络

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




[原文可参阅: http://network.chinabyte.com/481/12516481.shtml]

一、 为什么需要大二层

1.虚拟化对数据中心提出的挑战

传统的三层数据中心架构结构的设计是为了应付服务客户端-服务器应用程序的纵贯式大流量,同时使网络管理员能够对流量流进行管理。工程师在这些架构中采用生成树协议(STP)来优化客户端到服务器的路径和支持连接冗余。

虚拟化从根本上改变了数据中心网络架构的需求。最重要的一点就是,虚拟化引入了虚拟机动态迁移技术。从而要求网络支持大范围的二层域。从根本上改变了传统三层网络统治数据中心网络的局面。

2. 虚拟机迁移与数据中心二层网络的变化

在传统的数据中心服务器区网络设计中,通常将二层网络的范围限制在网络接入层以下,避免出现大范围的二层广播域。

如图1所示,由于传统的数据中心服务器利用率太低,平均只有10%~15%,浪费了大量的电力能源和机房资源。虚拟化技术能够有效地提高服务器的利用率,降低能源消耗,降低客户的运维成本,所以虚拟化技术得到了极大的发展。但是,虚拟化给数据中心带来的不仅是服务器利用率的提高,还有网络架构的变化。具体的来说,虚拟化技术的一项伴生技术—虚拟机动态迁移(如VMware的VMotion)在数据中心得到了广泛的应用。简单来说,虚拟机迁移技术可以使数据中心的计算资源得到灵活的调配,进一步提高虚拟机资源的利用率。但是虚拟机迁移要求虚拟机迁移前后的IP和MAC地址不变,这就需要虚拟机迁移前后的网络处于同一个二层域内部。由于客户要求虚拟机迁移的范围越来越大,甚至是跨越不同地域、不同机房之间的迁移,所以使得数据中心二层网络的范围越来越大,甚至出现了专业的大二层网络这一新领域专题。

图1 数据中心虚拟化与大范围二层网络

3. 传统网络的二层为什么大不起来

在数据中心网络中,“区域”对应VLAN的划分。相同VLAN内的终端属于同一广播域,具有一致的VLAN-ID,二层连通;不同VLAN内的终端需要通过网关互相访问,二层隔离,三层连通。传统的数据中心设计,区域和VLAN的划分粒度是比较细的,这主要取决于“需求”和“网络规模”。

传统的数据中心主要是依据功能进行区域划分,例如WEB、APP、DB,办公区、业务区、内联区、外联区等等。不同区域之间通过网关和安全设备互访,保证不同区域的可靠性、安全性。同时,不同区域由于具有不同的功能,因此需要相互访问数据时,只要终端之间能够通信即可,并不一定要求通信双方处于同一VLAN或二层网络。

传统的数据中心网络技术, STP是二层网络中非常重要的一种协议。用户构建网络时,为了保证可靠性,通常会采用冗余设备和冗余链路,这样就不可避免的形成环路。而二层网络处于同一个广播域下,广播报文在环路中会反复持续传送,形成广播风暴,瞬间即可导致端口阻塞和设备瘫痪。因此,为了防止广播风暴,就必须防止形成环路。这样,既要防止形成环路,又要保证可靠性,就只能将冗余设备和冗余链路变成备份设备和备份链路。即冗余的设备端口和链路在正常情况下被阻塞掉,不参与数据报文的转发。只有当前转发的设备、端口、链路出现故障,导致网络不通的时候,冗余的设备端口和链路才会被打开,使得网络能够恢复正常。实现这些自动控制功能的就是STP(Spanning Tree Protocol,生成树协议)。

由于STP的收敛性能等原因,一般情况下STP的网络规模不会超过100台交换机。同时由于STP需要阻塞掉冗余设备和链路,也降低了网络资源的带宽利用率。因此在实际网络规划时,从转发性能、利用率、可靠性等方面考虑,会尽可能控制STP网络范围。

4. 大二层也是为了流通的要求

随着数据大集中的发展和虚拟化技术的应用,数据中心的规模与日俱增,不仅对二层网络的区域范围要求也越来越大,在需求和管理水平上也提出了新的挑战。

数据中心区域规模和业务处理需求的增加,对于集群处理的应用越来越多,集群内的服务器需要在一个二层VLAN下。同时,虚拟化技术的应用,在带来业务部署的便利性和灵活性基础上,虚拟机的迁移问题也成为必须要考虑的问题。为了保证虚拟机承载业务的连续性,虚拟机迁移前后的IP地址不变,因此虚拟机的迁移范围需要在同一个二层VLAN下。反过来即,二层网络规模有多大,虚拟机才能迁移有多远。

传统的基于STP备份设备和链路方案已经不能满足数据中心规模、带宽的需求,并且STP协议几秒至几分钟的故障收敛时间,也不能满足数据中心的可靠性要求。因此,需要能够有新的技术,在满足二层网络规模的同时,也能够充分利用冗余设备和链路,提升链路利用率,而且数据中心的故障收敛时间能够降低到亚秒甚至毫秒级。

二、 大二层需要有多大

既然二层网络规模需要扩大,那么大到什么程度合适?这取决于应用场景和技术选择。

1. 数据中心内

大二层首先需要解决的是数据中心内部的网络扩展问题,通过大规模二层网络和VLAN延伸,实现虚拟机在数据中心内部的大范围迁移。由于数据中心内的大二层网络都要覆盖多个接入交换机和核心交换机,主要有以下两类技术。

ž 虚拟交换机技术

虚拟交换机技术的出发点很简单,属于工程派。既然二层网络的核心是环路问题,而环路问题是随着冗余设备和链路产生的,那么如果将相互冗余的两台或多台设备、两条或多条链路合并成一台设备和一条链路,就可以回到之前的单设备、单链路情况,环路自然也就不存在了。尤其是交换机技术的发展,虚拟交换机从低端盒式设备到高端框式设备都已经广泛应用,具备了相当的成熟度和稳定度。因此,虚拟交换机技术成为目前应用最广的大二层解决方案。

虚拟交换机技术的代表是H3C公司的IRF、Cisco公司的VSS,其特点是只需要交换机软件升级即可支持,应用成本低,部署简单。目前这些技术都是各厂商独立实现和完成的,只能同一厂商的相同系列产品之间才能实施虚拟化。同时,由于高端框式交换机的性能、密度越来越高,对虚拟交换机的技术要求也越来越高,目前框式交换机的虚拟化密度最高为4:1。虚拟交换机的密度限制了二层网络的规模大约在1万~2万台服务器左右。

ž 隧道技术

隧道技术属于技术派,出发点是借船出海。二层网络不能有环路,冗余链路必须要阻塞掉,但三层网络显然不存在这个问题,而且还可以做ECMP(等价链路),能否借用过来呢?通过在二层报文前插入额外的帧头,并且采用路由计算的方式控制整网数据的转发,不仅可以在冗余链路下防止广播风暴,而且可以做ECMP。这样可以将二层网络的规模扩展到整张网络,而不会受核心交换机数量的限制。

隧道技术的代表是TRILL、SPB,都是通过借用IS-IS路由协议的计算和转发模式,实现二层网络的大规模扩展。这些技术的特点是可以构建比虚拟交换机技术更大的超大规模二层网络(应用于大规模集群计算),但尚未完全成熟,目前正在标准化过程中。同时传统交换机不仅需要软件升级,还需要硬件支持。

2. 跨数据中心

随着数据中心多中心的部署,虚拟机的跨数据中心迁移、灾备,跨数据中心业务负载分担等需求,使得二层网络的扩展不仅是在数据中心的边界为止,还需要考虑跨越数据中心机房的区域,延伸到同城备份中心、远程灾备中心。

一般情况下,多数据中心之间的连接是通过路由连通的,天然是一个三层网络。而要实现通过三层网络连接的两个二层网络互通,就必须实现“L2 over L3”。

L2oL3技术也有许多种,例如传统的VPLS(MPLS L2VPN)技术,以及新兴的Cisco OTV、H3CEVI技术,都是借助隧道的方式,将二层数据报文封装在三层报文中,跨越中间的三层网络,实现两地二层数据的互通。这种隧道就像一个虚拟的桥,将多个数据中心的二层网络贯穿在一起。

另外,也有部分虚拟化和软件厂商提出了软件的L2 over L3技术解决方案。例如VMware的VXLAN、微软的NVGRE,在虚拟化层的vSwitch中将二层数据封装在UDP、GRE报文中,在物理网络拓扑上构建一层虚拟化网络层,从而摆脱对网络设备层的二层、三层限制。这些技术由于性能、扩展性等问题,也没有得到广泛的使用。

三、 结束语

大规模二层网络的需求目前已经非常的清晰,各厂商都提出了有针对性的技术和方案,满足大二层的当前要求和未来扩展需求。但从实际应用情况来看,除了虚拟交换机技术在成熟度和应用性方面得到验证,其他的相关技术仍然在完善过程中。同时,业界也希望加快相关技术的标准化进程,从而加强各厂商设备的兼容性和互通性,降低用户的部署和维护成本。

(3个打分, 平均:3.67 / 5)

雁过留声

“数据中心虚拟化需要大二层网络”有18个回复

  1. 抓狂 于 2013-01-08 9:01 下午

    虚拟机迁移要求IP、MAC不变,那么两个数据中心之间的虚拟机迁移怎么保证网络路由的快速切换?毕竟两个数据中心的出口肯定是不同的

  2. balabala 于 2013-01-09 6:16 上午

    Cisco早就看到大二层的市场了, 其大二层网络应该是最为齐全的。 起初的nexus 1k, 2k, 5k, 7k解决了multichannel, 以及虚拟化的问题. 后来针对这几个平台的线卡充分的提升了性能。 3k 4k 补充了产品线。

    但是cisco 依然没有解决这个二层的问题, 比如 7k 尽管容量很大, 但是依然不能满足数据中心的需求, 还有就是众多的网络设备管理上的难度.

    大家寄希望于SDN可以解决这个问题, 但是SDN会触动这个巨头的利益, 这个nexus 系列对于SDN的支持一直不好。像首席说的, cisco是一个硬件厂商, 卖设备, 是它的本质。

  3. balabala 于 2013-01-09 6:21 上午

    “虚拟交换机技术的代表是H3C公司的IRF、Cisco公司的VSS,其特点是只需要交换机软件升级即可支持,应用成本低,部署简单。目前这些技术都是各厂商独立实现和完成的,只能同一厂商的相同系列产品之间才能实施虚拟化。同时,由于高端框式交换机的性能、密度越来越高,对虚拟交换机的技术要求也越来越高,目前框式交换机的虚拟化密度最高为4:1。虚拟交换机的密度限制了二层网络的规模大约在1万~2万台服务器左右。”

    Cisco 的VSS 是一种多虚一的技术, 而且只能支持两台6500… 多了的话搞不定。

  4. Da Vinci 于 2013-01-09 6:36 上午

    to 抓狂:所以需要VxLAN这样的隧道技术啊。这样能够保证VM的任意迁移。

  5. Da Vinci 于 2013-01-09 6:39 上午

    基于VxLAN的隧道的大二层,如何实现三层的互通?有大牛讲讲么?比如属于两个不同的VNI的VM,需要talk,怎么搞?

  6. seablue 于 2013-01-10 3:24 下午

    这篇介绍有大局观,难得的好文。技术细节,各种方案优劣比较/选择还要靠自己。
    VXLAN,NVGRE之外,还有个新秀STT

  7. zhoucengchao 于 2013-02-04 5:43 下午

    听了太多目前二层网络的问题,但谈到具体应用的时候都是一笔带过,比如“大规模集群”,究竟怎么个大法,要大几十万台?为什么这些集群机器非要在一个二层网络?跨三层通信不可以?希望能看到一个具体将应用的文章

  8. yinc 于 2013-06-05 6:16 上午

    不错

  9. mpc8240 于 2013-06-10 4:23 下午

    VXLAN, NVGRE etc were invented to be used as tunneling protocols on virtual switches. But they themselves are not necessarily software based solution. Such tunneling can be implemented on data center top-of-rack switches, i.e., hardware based solution.

  10. tunnel 于 2013-06-16 6:47 上午

    楼上正解,实际上,现在一些新的IDC,已经发现节点一多,用software switch来做就搞不定了,CPU负荷太高

  11. Virtual Subnet 于 2013-07-24 8:01 下午

    从CISCO最近发布的数据中心网络架构DFA来看,也是使用了主机路由的思路来实现intra-subnet流量的转发,而不再是使用MAC table来实现流量转发,具体见下面的一段描述以及DFA文档:
    Cisco
    DFA advancements include enhanced forwarding, in which IP addresses are used regardless of whether the
    communication is within or between traditional Layer 2 subnets. This feature introduces several optimizations and
    simplifications, including the elimination of a first-hop redundancy protocol, the use of small MAC address tables,
    and optimal forwarding for all unicast frames.

    http://www.cisco.com/en/US/solutions/collateral/ns224/ns945/white_paper_c11-728337.pdf
    http://vimeo.com/39577390

  12. Virtual Subnet 于 2013-07-24 8:04 下午

    这里有一个关于如何使用主机路由扩散来实现大二层网络的IETF草案:http://tools.ietf.org/html/draft-xu-l3vpn-virtual-subnet-00

  13. Virtual Subnet 于 2013-07-24 8:30 下午

    用Vswitch作为network virtualization overlay的边界,好处是消除了网络和服务器的管理边界问题,集中在服务器上完成server和network的virtualizaiton相关的配置管理。但是针对BUM流量的处理,面临新的挑战:1)首先VXLAN文稿中推荐的基于underlay multicast tree的思路存在严重的可扩展性(理论上需要支持16M组播组,而多个租户共用一个组播组的思路在cloud DC中有不太现实,原因是不同tenant的VM部署位置往往不同,尤其上考虑到VM动态增删和移动的因素),因此在一些厂商的VXLAN实现中都采用一些手段避免对underlay multicast的依赖,比如IBM的Dove,以及CISCO的VXLAN改进;2)如果采用ingress replication方式,由于树的叶子结点太多,造成头端的巨大复制压力以及网络带宽的不必要浪费;3)目前多采用集中点复制的思路,但是这种方案导致VXLAN部署方案变的不再简洁。而基于ToR作为NVO边界的方案可以采用ingress replication方案而不用太担心组播复制效率的问题,原因是叶子节点相对host-based overlay少了至少一个数量级,而且尽量终极目标是VM可以部署在任意物理位置,但是从流量转发优化的角度来看,同一tenant的VM往往尽可能部署在相对集中的服务器上,比如连接到同一个ToR下面,这样基于ToR的overlay的ingress replication的效率就更高了。

  14. Virtual Subnet 于 2013-08-15 10:56 下午

    这个Blog (http://demo.ipspace.net/get/1%20-%20Introduction.mp4)介绍如何使用主机路由+ARP proxy来实现数据中心网络虚拟化以及数据中心互连的视频材料,应该是Enterasys公司的解决方案,非常不错,分享给大家。

  15. Virtual Subnet 于 2013-08-15 11:04 下午

    关于overlay,之前大家关注的主要是layer2 overlay(即MAC-in-IP),比如VXLAN,NVGRE,VPLS,EVPN等。但是现在CISCO\Juniper\Enterasys都在实现并宣扬layer3 overlay(即IP-in-IP)的方案,Juniper在contrail Junosv方案中主推的就是XMPP-based L3VPN方案,其实就是一种host-based layer3 overlay方案。CISCO在6月份CISCO live2013上发布的最新数据中心网络架构即DFA(DynamicFabricAutomation)中主打的思路就是layer3 overlay,而Enterasys(也就是我前面发的链接中介绍的)主打的DCI方案同样是layer3 overlay,并且在webinar中专门有一段是说明DCI更适合用layer3 overlay,而不是layer2 overlay的,而在CISCO的一个内部技术交流的资料(http://vimeo.com/39577390)中也有类似说法(11:50处开始播放),即针对跨DC的vm migration而言,cold migration更靠谱,而cold migration不需要layer2 connectivity,因此layer3 overlay更合适。另外,关于cluster对layer2 connectivity的需求,这个video中也有细致的说明(34:15处开始播放),特别重要的一点是,对layer2 connectivity有需求的cluster me之间发送keepalive消息的接口往往和提供业务的接口划分为不同的vlan字接口,也就是意味着只有发送keepalive的vlan字接口才需要layer2 connectivity,而业务接口完全可以使用layer3 overlay来连接。

  16. 抓狂 于 2013-08-19 11:36 下午

    如楼上Virtual Subnet所述,虚拟机迁移要求IP&MAC不变,无非是为了业务不中断。但这个业务不中断有两层含义(1)已有业务不中断(2)新业务可执行。
    基于域名系统可保证(2),那什么场景需要(1)呢?大不了断了重连不行吗?为什么为了一个99%以上不会发生的情况把事情搞复杂?

  17. Virtual Subnet 于 2013-08-19 11:46 下午
  18. Virtual Subnet 于 2013-08-20 12:17 上午

    关于16楼抓狂提的问题,动态DNS确实是一种潜在的解决思路。不过由于多种现实原因(比如DNS cache更新的问题,一些应用程序socket直接调用IP地址,而不是FQDN,一些ACL基于IP地址…),VM迁移后避免IP renumbering在大多数情况下还是必须的。