1、数据中心流量趋势
在移动互联网时代以前,人们上网接入带宽也就是几十到几百 K,上网的主要目的是浏览网页、聊 QQ、听音乐,信息的流向主要是下行,规模不大,数据中心流量主要是南北向的流量;但是随着移动互联网的到来,智能手机的普及,4K 视频、微信、视频、语音、AR/VR等互联网应用等对网络带宽都带来了巨大的增长,信息的流向不在是以下行为主了,上行和下行都在变大,数据中心除了南北向流量外,东西向流量也在同步增长;
下图是 cisco 对未来数据中心流量的预测,预测到2021年全球数据中心流量年增长25%,Google 的数据中心流量从2008年到2014年增长了50倍,百度近几年数据中心流量的年增长比例也在50%以上;
数据中心流量组成中,数据中心内流量占比高达71.5%,在数据中心间占比13.6%,数据中心到用户的流量占比只有14.9%;这么高的内部流量占比,需要一个强有力的数据中心网络架构才能支撑。
2、数据中心网络架构演进
数据中心网络在演进过程中有很多种架构,以 Four-Post 和 Clos最为常见,以下是 Facebook 公开的两种网络架构。
Four-Post
此架构由4台 CSW 交换机组成一个网络集群Cluster,在 Cluster 内每台 RSW(即 TOR) 交换机有4条链路上行至 CSW,网络 Cluster 间通过 FC 交换机互联;该架构,通过复制 Cluster可以满足大规模服务器组网的需求,但该网络在某些方面有些不足,如
1)在冗余度上,单台 CSW 故障流量损失25%;单台 FC 故障Cluster 间流量损失25%;
2)Cluster 集群规模由 CSW 设备端口容量决定;
3)该架构收敛比较高;
4)CSW 设备一般是大型框式设备,供应商少,CAPEX 和 OPEX高;
5)核心设备软件问题和定制化开发难度大;
CLOS Fabric
此架构由三个层级的交换机组成,分别是 Spine SW、Edge SW、RSW。每4台 ESW 和48台 RSW 组成1个 Server Pod,每 RSW 有4条链路上联 ESW,每台 ESW 上联一个 Spine 平面;该架构,通过复制 Server Pod 来扩展网络 Cluster 集群规模,集群扩展很灵活,可支持的服务器规模大,设备和链路的冗余度也大,可靠性高,且网络Cluster 集群内无收敛比,网络吞吐能力高,但在管理运维方面复杂度高,需要部署 SDN 等自动化的管理运维手段。
百度数据中心网络架构;下图是百度在2017年以前的数据中心网络架构,架构和上述 Four-Post 相同,该架构的特点如下:
1)网络Cluster集群的截面带宽(BBW)有100X Tbps;
2)TOR 层级有3:1的收敛比;
3)网络可靠性,单台Leaf设备故障 影响一个 POD 的25%流量;单台 Spine 交换机故障,影响整个网络集群1/8的流量;
4)CLOS 内部互联链路多,运维监控是个挑战;
下图是百度现在的 CLOS 架构;架构同 Facebook 的 Clos 架构类同,但Leaf 节点、Spine 节点仍采用大型的商用框式交换机,后续会使用自研交换机替代。这个架构特点如下:
由上述网络架构演进可见,不管是Four-Post 架构还是 Clos架构,在数据中心内,网络设备和光互联链路的数量非常多,如何有效的进行网络和链路的运维是我们面临的巨大挑战。
数据中心光互联网络运维实践
首先,数据中心光互联网络运维都有哪些挑战:
1)光互联覆盖范围广;1Xm ~100X Km;
2)光互联链路数量和类型很多;在100m 上,有 OM3/OM4,模块有 SR4、ESR4;500m 距离,有单模光纤,PSM4、CWDM4模块;2KM 的数据中心园区场景,有单模光缆、CWDM4、LR4光模块;数据中心间,随着距离的增长也有不同的技术应用,LR4、10G DWDM 彩光、200G OTN 等;
3)难以用一种监控手段覆盖所有的技术类别,存在多种监控系统和平台,运维效率低。
然后,百度针对这些不同互联场景的运维实践,如下:
1)设备或模块故障,采用 基于设备SYSLOG 日志分析的运维监控方法,针对设备上报的日志来及时监控运行状态;
2)针对链路类的故障,采用自动化 ping 程序来监控链路状态,同时部署了多个路由协议探针做链路级故障的分析和判断;
3)针对链路的误码和丢包等质量问题,部署了2套网络质量监控系统来监控,一套是部署在网络核心 IC层级的天网 监控系统,实时监测链路的误码和丢包情况;另一套是业务部门在服务器上部署的 Net-radar 系统,实时感知网络质量异常;
最后,SDN 的部署,整合了上述传统网络监控工具,基于 SDN/IBN 的思想构建了智能管控编排中心,下图是框图:
SDN系统实时采集网络设备各种配置和状态数据;包括单不限于,资产、配置、拓扑、流量、日志等;
整个系统是个闭环系统,当监测到网络异常时,根据不同的策略进行业务编排,下发控制命令,故障隔离,编排处理流程策略;自动或转人工处理;在处理过程中,自动校验检测、自动恢复上线和流量调度;全程都是现场的人和机器人交互,提高沟通效率;
4、从运维角度对数据中心光互联网络的技术需求
1)我们希望设备商、模块商、系统商,更加开放,让用户拥有自主权,可在内部编写 APP 或 AGENT,自定义管理控制功能及接口,提取或主动上报各类运行数据,加速数据中心网络运维自动化进程;
2)我们希望 IP 和光能够进一步融合(软件或硬件层面),便于 SDN 统一管控,为业务提供多层次的控制策略。