百度数据中心光互联网络运维实践
发布时间：2018-07-30 10:12:22 热度：2840
7/30/2018，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 统一管控，为业务提供多层次的控制策略。
在移动互联网时代以前，人们上网接入带宽也就是几十到几百 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 统一管控，为业务提供多层次的控制策略。
