分享
分享赚钱 收藏 举报 版权申诉 / 6

类型漫谈数据中心CLOS网络架构.docx

  • 上传人:jinchen
  • 文档编号:5601697
  • 上传时间:2019-03-09
  • 格式:DOCX
  • 页数:6
  • 大小:65.35KB
  • 配套讲稿:

    如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。

    特殊限制:

    部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。

    关 键  词:
    漫谈数据中心CLOS网络架构.docx
    资源描述:

    1、漫谈数据中心 CLOS网络架构1、数据中心网络架构挑战随着技术的发展,数据中心的规模越来越大,一个数据中心的服务器容量从几年前的几千台服务器发展到今天的几万甚至几十万台。为了降低网络建设和运维成本,数据中心网络的设计者们也竭力将一个网络模块的规模尽可能扩大。同时,数据中心网络内部东西向流量也日益增加,在一些集群业务的需求驱动下,数据中心网络设计者们甚至开始讨论一个网络模块内 10000 台千兆线速服务器的可能性。常见的数据中心网络模块的典型架构是双核心交换机TOR 接入交换机两级结构,如下图所示:图 1 典型数据中心网络模块架构那么,在这种更大规模数据中心的发展趋势下,这样的数据中心网络架构(

    2、其实另外一种典型的三层结构也一样)会面临什么挑战那?首先,我们会看到单个网络模块的规模直接受限于核心交换机设备的端口密度。比如,对应 10000 台千兆服务器 1:1 超载比接入的要求,每台核心交换机应该提供至少 500 个线速无阻塞万兆端口,这已经在挑战商业市场主流交换机产品的极限了。如果需要更大规模的网络那?貌似只能等待厂商推出更高密度的产品了。其次,随着核心交换机设备越来越庞大,端口数量越来越多,核心交换机的功耗也据高不下,很轻易的达到接近 10kw 的量级。这个电源的要求虽然对很多财大气粗的互联网企业自建的数据中心来说是小菜一碟,但对于大部分企业来说,这意味着 23 个月以上的机架电源

    3、改造周期,要知道,在国内大多数 IDC 机房,单机架的供电能力仅 3kw 左右。于是,数据中心网络设计工作者开始研究是否有其它的架构设计方案。2、CLOS 网络架构登场在讨论正题之前让我们一起看看业内人士经常挂在嘴边的 CLOS 到底是何方神圣。CLOS 是一种多级交换架构,目的是为了在输入输出增长的情况下尽可能减少中间的交叉点数。典型的对称 3 级 CLOS 架构如下图所示:图 2 对称 3 级 CLOS 交换网络事实上 CLOS 架构并不是什么新鲜的东西,早在 1953 年,贝尔实验室 Charles Clos 博士在无阻塞交换网络研究论文中提出这种架构,后被广泛应用于 TDM 网络(多半

    4、是程控交换机),为纪念这一重大成果,便以他的名字 CLOS 命名这一架构。现在我们再回到数据中心网络设计的话题。实际上,前面提到的严重依赖厂商产品端口密度的架构设计方法让很多设计者们如鲠在喉,让他们找到了挑战的兴奋点。犹如 Linux 社区的开源之风一般,他们更希望的是摆脱厂商产品限制,找到一种架构设计方法,最好是可以使用廉价、普通的小盒子设备来搭建一个规模可以非常庞大的网络。在美国加利福尼亚大学计算机科学与工程系以 Mohammad Al-Fares 为代表的几位教授的研究下,这种思路达到了登峰造极的程度。在他们于 2008 年发表于 SIGCOMM 的论文A Scalable, Commo

    5、dity Data Center Network Architecture中,明确提出了一种三级的,被称之为胖树(Fattree)的 CLOS 网络架构。利用这种架构方法,可以采用一种固定数量端口的盒式交换机搭建一个大规模服务器接入的网络。具体的说,当采用端口数为 k 的交换机时,核心交换机数量为(k/2)2 个,共有 k 个 Pod,每个 Pod 各有(k/2)个汇聚和接入交换机,可接入的服务器数量为 k3/4。并且这种架构可以保证接入、汇聚、核心的总带宽一致,保证服务器接入带宽 1:1 的超载比。下图所示的是该架构当 k4 的示例。图 3 k 4 时的胖树 CLOS 网络显然,当 k48,

    6、即采用 48 端口千兆盒式交换机时,这个架构的核心交换机数量为 576 个,一共有 48个 Pod,每个 Pod 有 24 台汇聚交换机和 24 台接入交换机,共 2880 个交换机,可以支持到 27648 台千兆服务器的 1:1 超载比接入。设备的数量虽然看上去很惊人,但毫无疑问的确是一种可扩展的架构,而且似乎对设备没有特别的要求。更令人鼓舞的是,这几位教授除了纸上谈兵外,还非常注重实战,论文中详细的对 IP 地址划分、路由策略、流量调度算法等进行了详细设计,也和传统的设计方法进行了成本和功耗方面的对比。更匪夷所思的是,大概这几位老大也意识到交换机数量庞大带来的设备摆放和互联线缆问题,甚至还

    7、给出了设备打包和机架安排方案。一言以蔽之,只要你严格按照这篇论文进行设计,一个几万台 1:1 带宽超载比的千兆服务器数据中心网络就呼之欲出,几乎所有重要的问题都被周密的考虑到了。另外,也可以将上述方案做一些变化,比如,将汇聚和核心设备换成全万兆端口的交换机,如现在流行的64 端口万兆交换机,接入换成万兆上联的交换机,如现在流行的 4 万兆48 千兆的交换机,这样同样规模的网络情况下,设备和互联链路的数量可以大大减少。更具体的设计情况大家可以照猫画虎自己研究一下:)3、迷雾重重到这里,似乎问题都解决了,数据中心网络的设计工作者们多了一个选择,对业界主流厂商设备端口密度也不那么饥渴了。喜爱钻研的设

    8、计者很快发现,其实 CLOS 网络架构是采用一个等价于三级 CLOS 的部分替代了传统设计的两台核心设备,如下图所示:图 4 传统网络架构和 CLOS 网络架构或者进一步说,是采用一个三级 CLOS 的部分替代一台核心设备。为什么说是一个三级 CLOS 的部分,因为汇聚和核心都是双向通信,等价于一个标准的三级 CLOS 折叠以后把输入、输出单元合并的情况。主流厂商的核心设备被一堆廉价的小盒子替代了,这是一个令人振奋的消息,同时令人迷惑。首先是无阻塞的问题。大家都知道网络核心无阻塞的重要性。商业市场的主流核心设备通常都较为复杂,为了实现无阻塞,交换矩阵都有一定的加速比,还采用 VoQ 等技术,还

    9、要有调度仲裁或自路由的设计。那么,一堆廉价的小盒子如何实现无阻塞那?其次,紧接着的一个很明显的问题,CLOS 网络架构上下行的带宽一致,是否就可以实现无阻塞?还有,交换机的输入输出缓存设计一直都是各主流设备厂家各执一词的,在 CLOS 网络架构中这部分如何体现的?再有,CLOS 网络架构的多条等价路径如何做到负载均衡?HASH 算法是基于流的,不同流的差异无法解决;数据包是变长的,即便轮询也难以均衡。要知道,核心交换机通常内部都会用定长的信元把数据包重新封装以便于尽可能的均衡分布。那么 CLOS 网络架构是否需要一个集中的控制系统做流量调度?继续思考下去,就可能会发现更多不容易回答的问题。似乎

    10、 CLOS 网络架构也并不是那么简单了。4、如何实现无阻塞首先我们看看什么是有阻塞无阻塞。内部阻塞(Blocking)。若出、入线空闲,但因交换网络级间链路被占用而无法接通的现象,称为多级交换网络的内部阻塞。无阻塞(Non-blocking)。不管网络处于何种状态,任何时刻都可以在交换网络中建立一个连接,只要这个连接的起点、终点是空闲的,而不会影响网络中已建立起来的连接。可重排无阻塞(Re-arrangeable non-blocking)。不管网络处于何种状态,任何时刻都可以在交换网络中直接或对已有的连接重选路由来建立一个连接,只要这个连接的起点、终点是空闲的,而不会影响网络中已建立起来的连

    11、接。广义无阻塞(Scalable non-blocking)。指一个给定的网络存在着固有的阻塞可能,但又可能存在着一种精巧的选路方法,使得所有的阻塞均可避免,而不必重新安排网络中已建立起来的连接。那么 CLOS 网络架构的阻塞情况如何那?根据数据中心的网络架构,我们研究之前图 2 中的对称 3 级结构的 CLOS 网络的情况就可以了。这种对称 3 级 CLOS 网络,第一级的入线和第三级出线均为 n,第二级的单元数量为 m。为了确保链路无阻塞,完成 a 到 b 的信息交换,至少还应该存在一条空闲链路,即中间级交换单元要有(n-1)+ (n-1 )+1 = 2n-1 个,因此无阻塞的条件为:m=

    12、2n-1。如下图所示:图 5 对称 3 级 CLOS 网络无阻塞条件为 m=2n-1另外,Slepian-Duguid 定理也证明了,当 m=n 的时候,对称 3 级 CLOS 网络为可重排无阻塞。可重排无阻塞意味着要对交换网络做端到端的调度。这也就直接证明了 CLOS 网络中无阻塞的设计,汇聚到核心的带宽应该至少是接入到汇聚的带宽的(2n-1)/n=2-1/n 倍,接近 2 倍。实际上,加利福尼亚大学那几位教授也在他们的论文中明确的指出了设计采用带宽超载比 1:1 的胖树CLOS 架构是可重排无阻塞的,需要采用合适的调度算法尽可能满足可重排条件。那是不是满足 m=2n-1 的条件,就可以高枕

    13、无忧,肯定可以避免端到端的阻塞了那?当然不是,我们可以看到这时候无阻塞的模型前提是入向、出向信息均匀分布,如果分布不均匀就可能导致入向或出向阻塞。这时候我们就需要考虑入向、出向缓存以及加速比的情况。5、玄妙的加速比 Speedup加速比的概念很直接,它是一种降低输入输出阻塞的方法。如果一个交换网络可以在一个信元时间内将一个输入端口的 N 个信元传输至输出,则这个交换网络的加速比 S=N。通俗的说,加速比是交换网络在“多打一”的情况下的处理能力。加速比越大,交换网络的中间单元数越多,成本越高。我们很容易就可以算出,前面我们研究的交换网络,对称 3 级 CLOS 架构,在无阻塞条件 m=2n-1

    14、时,加速比 S=(2n-1)/n=2-1/n,接近于 2。而在可重排无阻塞条件 m=n 时,加速比为 1。在加速比为 1 时,为了避免入向的阻塞即所谓的“头端阻塞”,我们需要在交换网络的入方向有足够大的缓存,此时端到端的延迟将变得不可控,或者可能会非常大。如下图所示:图 6 入方向缓存的交换模型,S=1随着加速比的增加,入方向的阻塞可能性越来越小,但出方向的阻塞可能性却越来越大,因此,在加速比比 1 大的时候,我们需要在交换网络的出方向有足够大的缓存。当 S=N(N 为入方向端口总数)时,入方向无需缓存,仅需要出方向的缓存,此时,交换网络的成本最为昂贵,但延迟最小。如下图所示:图 7 出方向缓

    15、存的交换模型,S=N因此,加速比让交换网络设计者们既爱又恨,但他们把爱和恨都转化成了一个问题,那就是,有没有可能进行巧妙的设计,在加速比 1SN 的情况下,获得接近 S=N 的性能和接近 S=1 的成本。答案是有可能的。经过努力,业界人士得到的结论是,2S5 的范围是比较合理的,通过匹配适当的入向、出向缓存,采用合适的调度算法,可以获得性能和成本较为均衡的一个交换网络。据小道消息,业界部分产品的交换矩阵的加速比如下(无官方确认,仅供参考):Cisco Cat6500:4 Nexus7000:3.x CRS-1: 2.5H3C S12500: 1.8Juniper T MX Series: S2

    16、.25好了,绕了一大圈,我们再回过来看看对于我们的 CLOS 网络架构,加速比如何选择比较合适。还是先看加利福尼亚大学那几位教授的设计方案。这个方案在加速比为 1 的情况下,采用了全局集中的流量调度系统 FlowScheduler 直接控制汇聚和核心设备的路径选择,以获得较好的流量分布,同时在每个接入交换机都内置 FlowReporter 收集流信息。即便如此,在随机流的测试中网络的带宽利用率也不超过 75。显然这个方案并不完美,并且难以在普通商业产品上实施,对于大多数希望采用 CLOS 架构的设计者来说,这是一个难以实现的方案。也许随着 OpenFlow 等 SDN 技术的发展,这方面可以取

    17、得更大进展。Juniper 的QFabric 从某种程度来看,也类似一个有集中控制和调度的 CLOS 网络架构,目前很多设计细节还未披露,实际使用的效果如何也有待大规模商用的考验。按照之前的分析,如果没有流量调度系统,在实际的情况下是无法避免入向或出向的阻塞的,只能尽可能降低阻塞的可能性。考虑到多条等价路径负载均衡的不完美,以及廉价盒式设备具备少许的输入输出缓存,但无法全局统筹调配使用,显然一定的加速比是需要的。兼顾成本因素,选择加速比为 23 也许是一个较为理想的选择。准确的加速比选择,需要进一步的实验室测试和验证,和设备选型也有关。6、总结在数据中心网络中,可以采用商用市场普通盒式交换机搭建胖树 CLOS 网络架构,实现可扩展、不依赖特定厂商产品的网络架构。但如果没有全局集中的流量调度和仲裁机制,也没有全局的入向和出向缓存供调配使用,将难以实现目前商业市场核心设备的无阻塞转发能力,在网络发生阻塞时对应用的性能会产生一定的影响。通过适当的加速比选择,如建议的 23 ,可以减少阻塞。CLOS 网络架构的设计需要进一步的研究、测试和验证,在将来通过 SDN 来共同实现可能更为理想。

    展开阅读全文
    提示  道客多多所有资源均是用户自行上传分享,仅供网友学习交流,未经上传用户书面授权,请勿作他用。
    关于本文
    本文标题:漫谈数据中心CLOS网络架构.docx
    链接地址:https://www.docduoduo.com/p-5601697.html
    关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服 - 联系我们

    道客多多用户QQ群:832276834  微博官方号:道客多多官方   知乎号:道客多多

    Copyright© 2025 道客多多 docduoduo.com 网站版权所有世界地图

    经营许可证编号:粤ICP备2021046453号    营业执照商标

    1.png 2.png 3.png 4.png 5.png 6.png 7.png 8.png 9.png 10.png



    收起
    展开