h3c数据中心云计算解决方案技术白皮书

h3c数据中心云计算解决方案技术白皮书内容摘要：

下的负载均衡。 但是 ,这个简单策略加大了写的代价 ,因为一个写操作需要传输block 到多个机架。 为了降低整体的带宽消耗和读延时 ,HDFS会尽量让 reader读最近的副本。 如果在 reader 的同一个机架上有一个副本 ,那么就读该副本。 如果一个 HDFS 集群跨越多个数据中心 ,那么 reader 也将首先尝试读本地数据中心的副本。 HDFS 支持数据的均衡分布处理 ,如果某个 Datanode 节点上的空闲空间低于特定的临界点 ,那么就会启动一个计划自动地将数据从一个 Datanode 搬移到空闲的 Datanode。 当对某个文件的请求突然增加 ,那么也可能启动一个计划创建该文件新的副本 ,并分布到集群中以满足应用的要求。 我们可以看到 ,Hadoop 系统在开发过程中关注了数据交换对象计算节点之间的距离 ,实际上是考虑了网络构建模型中带宽不匹配因素。 这种因素的引入 ,不仅编程人员需要关心 ,业务部署人员、网络维护人员也都要关心 ,在小规模环境下还能够勉强运行 ,但是如果要支持全互联网级的大规 模应用 ,集群可能达到数千台、数万台 ,业务的部署、扩展、运行、支撑都会存在很多问题。 如图 13 是一种高扩展要求的集群模型 ,这类集群应用自身是分层架构 ,每一层应用都是一个大规模集群 ,采用传统方式构建交换网络 ,必将存在诸多限制 ,无法发挥云计算巨型计算的服务能力。 大规模集群架构 随着网络交换万兆技术的发展和设备成本的不断降低 ,目前大规模集群的构建也发展到新的阶段 ,需要新的网络结构来支持和运行 : 无阻塞网络架构 :满足集群环境中所有服务器的对等通信要求 ,任意节点之间可以达到相等带宽当前是以千兆为主 ,服务器应用 程序不再关注数据交互节点是在一个机架内还是在其它机架。 大规模集群能力 :当前 2 千台规模的服务器集群已经在互联网行业广泛部署 ,随着云计算业务的开发提供 ,更大规模的集群 50001 万台将成为支持云计算的主流网络结构 ,无阻塞架构是这种网络的基本要求。 足够扁平化的架构 :所谓扁平化就是极大减少组网结构层次 ,目前数据中心扁平化结构以两层物理网络为主流。 在还是千兆为主的服务器端口条件下 ,接入交换机的用户端口数一般为 48 个千兆 ,要满足无阻塞的跨机架带宽 ,则上行带宽需要 5 个万兆当然也可以只使用 40 个千兆接入 ,4 个万兆上行 ,而核心交换则需要高密的万兆 120 全线速能力。 无阻塞全线速网络 概念 线速 :指的是线路数据传送的实际速率能够达到名义值 ,比如千兆端口能够实际吞吐量到千兆 ,这在交换机是比较轻松的事 ,但是早期的高端路由器端口如果能够达到千兆实际转发速率 ,那是非常了不起的不过现在已经稀疏平常了。 超线速 :如千兆端口能够吞吐的流量超过一千兆一般也就超出一点点 ,这种交换机与标准线速设备对接后容易产生丢包甚至将标准交换机“堵死”。 在数据中心环境下极少数情况也允许满足超线速的组网 ,只是对交换机有特殊要求。 全线速 :交换机的所 有端口能够同时达到线速转发。 这个能力也体现了交换机的性能 ,对于某些性能较低的设备 ,称为达到全线速转发 ,是指达到了设备的最高性能而已 ,有可能离该交换机的端口容量总和还远着呢。 “无阻塞”全线速 :有时候在全线速前面再定义一个“无阻塞” ,其实是强化交换机的全线速能力 ,指的是对交换的任意大小字节的报文均能够达到全线速的能力 ,所有端口都以线速接收帧 ,并能无延迟地处理被称为“无阻塞(Nonblocking)” ,之所以这样叫是因为设备内部没有等待处理的报文 (没有阻塞 )。 但是无阻塞有时也会遇到挑战 ,在很小的概率下即实际 测试中极不容易出现 ,确实能够构造特定测试例使得交换机产生阻塞 ,这是因为传统交换架构下理论上也能分析出阻塞的可能性。 传统交换机的局限性 在“数据中心级交换机”概念出现以前这个概念也是随着云计算发展而产生的 ,此前只有核心交换机、高端交换机的概念 ,盒式交换机一般是单芯片 ,机架式交换机则主要是“交换网 +IO 芯片”结构 ,比较先进的交换网一般采用 crossbar,架构如图 14 所示。 传统高端设备以交换线卡连接 crossbar 高性能交换网 ,数据在 Crossbar内部选路基于实现配置好的规则 ,同一数据流在内部的运 转路径是确定的 HASH算法 ,因此存在特殊情况下在交换不同级层上会发生阻塞的现象 ,如图 14 的数据流 1 和 2 在第一级、数据流 3 和 4 在第二级的阻塞情景有点类似于等价路由或链路捆绑的流量不完全均衡性。 这种架构的交换网容量并不大 ,一般以支持 10GE为主。 这种非真正意义的“无阻塞”在一般性数据中心并不会遇到挑战 ,但在大型互联网数据中心 ,随着近年来 ISP 业务不断丰富、业务规模不断扩大和实际带宽消耗迅猛增长 ,已经出现了传统交换架构在互联网数据中心难以满足性能需求的现状。 传统 Crossbar 交换架构的阻塞分析模型 云计算核心交换平台的基本要求 ?无阻塞交换 到了新一代交换平台产生的时代 ,数据中心级核心交换平台的能力已经确定在 10Tbps 的级别 ,交换系统的架构产生了本质的变化 ,这种变化是为了应对云计算超高速 100G、以及实现今后 10T 环境下的完全无阻塞所带来的挑战而变革产生的架构 ,也就是 CLOS 架构。 那么 ,完全无阻塞的意义就是对一个交换架构无论是理论分析还是实测 ,都能够达到真正的无阻塞交换如果不能全线速 ,完全无阻塞也用处不大了。 完全无阻塞的概念 ,也是在云计算环境下开始逐步强调的 ,因为云计算中心应用密度比之传统数 据中心高得多 ,流量情况更为复杂 ,数据性能要求更为严格 ,如果在交换平台核心不能满足完全无阻塞的交换条件 ,瞬时引起的阻塞必然会导致网络流量异常 ,即使是理论上小概率的瞬时阻塞 ,也可能在云计算网络中反复出现。 这对大型网络来说 ,是存在隐患的 ,因为不断增长的业务和流量可能因为核心平台的隐患而有所限制莫名其妙的情况下发现网络偶然不畅 ,这种潜在问题有时是无法分析清楚的 ,特别是已经在运行的网络。 因此 ,完全意义上的无阻塞交换 ,是云计算核心交换平台的关键而基本的要求。 新一代交换架构三级 CLOSamp。 CELL 交换可支持完全无阻塞 交换 ,是完全遵循复杂业务流要求的 ,能够将大规模密集流量在交换系统内部均匀交换 ,避免了阻塞带来的性能恶化与严重下降。 其实现基本原理如图 15 所示 ,在系统内部采用动态选路方式线卡、交换网保存内部数据转发路径信息 ,如果出现路径不可用或网板、线卡故障 ,选路信息动态改变 ,这一切操作由硬件系统内完成 ,业务线卡接收到的数据包文 ,进行等长切片处理形成定长信元 ,每个信元加载动态选路的标记头长度不够的信元会进行内部填充。 H3C 新一代 CLOS 架构 amp。 Cell 交换实现模型 如何构造无阻塞交换网络 云计算需要超大的计算能力 和网络交换能力 ,通过网络来组织数千台至上万台服务器的协同计算 ,因此云计算的支撑网络也提出了无阻塞的方向。 首先看如何构造大规模的线速网络 ,如图 16 所示 ,从两个方向来扩展 ,在层次上 ,每一层的交换设备上行所有链路带宽与下行的所有链路带宽相等 ,在同一层次 ,按照下一层设备的上行端口数扩展 ,如此直到最高层目前主流构造两层到三层网络结构。 大规模网络扩展方式 构造线速交换网络比较简单 ,但是要达到无阻塞 ,当前的技术实现还不够彻底 ,因为在网络级别只能使用链路负载均衡技术实现对带宽的充分利用。 如图17 所示 ,实现 方式主要有两种。 链路负载均衡 Round robin 方式 :将数据流依次向可用链路均匀转发可以基于统计速率、也可以基于逐包方式 ,一般来说 ,当服务器之间全部使用定长报文如 1500 字节交互数据 ,基本就构成了一个“完全无阻塞交换网络”是定长数据交换条件下 ,但是存在的问题是 ,同一数据流的不同报文可能经过不同网络路径到达目的地 ,经过网络大规模流量浪涌后会存在严重的乱序问题。 HASH 方式 :使用网络设备的硬件负载均衡算法 ,基于数据流的二三层地址信息和四层端口号信息得到不同链路的选路信息 ,能够保证同一数据流 经过相同路径到达目的地 ,避免乱序 ,但是不同数据流因为流量大小有差异 ,使得网络不同链路难以完全均衡 ,不过在当前技术条件下 ,不均衡度已经极小 ,十分接近完全无阻塞交换网络了 云计算核心交换网络的缓存 浪涌 ?云计算环境下的一个网络现象 在云计算环境下 ,性能无疑成为最为关注的核心要素 ,但是 ,有了超高速的交换性能 ,不一定表示网络能够达到理想的效果 ,还需要关注网络浪涌的吸收容量 ,我们从分析端口流量情况和网络实际流量情况入手。 端口流量 图 20 是我们进行毫秒级网络流量研究时得到的流量图 ,不妨称之为微观流量视图 事实上早在 2020 年左右 ,运营商的研究机构已经在 622M 骨干网发现了这个现象。 在秒级、分钟级以上的宏观时间尺度下 ,流量 A 和 B 的采样曲线十分平滑 ,这是因为流量观测的累积平均效果造成的 ,当采样尺度缩小到毫秒级 ,我们发现 ,从端口得到的流量曲线发生了变化 ,最高的流量值可能达到平均流量的23。