e-works数字化企业网  »  文章频道  »  基础信息化  »  运维管理

京东大规模数据中心网络运维监控之眼

2017/11/30    来源:运维派    作者:王大泳      
关键字:京东  数据中心  
网络,相当于是互联网服务的神经系统和循环系统。监控,是网络运维团队了解网络服务的眼睛。
    一、京东网络现状
 
    从数据量表上来看京东的业务增长,下面是京东的一张覆盖了2014年618到2017年618所有的出口和专线的数据流量的图表。蓝色是专线DCI,红色是互联网的公网流量。
 
    京东
 
    大家可以看到2017年618的DCI流量增长非常非常快;对比上一年,它已经翻了将近一倍,主要的原因是大数据和一些后台的日志分析等系统占了很大比例的流量。
 
    2017年最大的一个变化就是很多独立的业务部署了自己的数据中心,而以前京东的各个业务混杂到一起。由于不同的业务出现了自己的数据中心,说明了不同的业务对网络的一些硬件和结构、性能和品质有了不同要求。
 
    而以前(特指代:在2013年和2014年期间)京东是仅仅来解决基本的通讯问题,比如:带宽或者简单基础的硬件可靠性问题。
 
    1.1、网络架构的持续优化
 
    在网络架构的持续优化上实际有很多小的细节优化,但是抽象出来的只有四个方面进行了持续的投入
 
    架构
 
    全国骨干网结构升级
 
    对于全国骨干网来说,京东在很长一段时间内是部署在北方地区也就是北京,而CDN却是部署在全国;中后期在广州也部署了一些核心的节点,以及部分海外节点。
 
    但是,当时并没有形成一个整体全国性的传输网络。今年,我们完成了改造的最重要的第一阶段:启动了在北京、上海、广州三地双平面的全国100G传输网络平台,目前处于建设初期。
 
    互联网接入层建设改造
 
    互联网接入层主要是自建BGP,解决的是互联网质量的业务体验问题,而我们没办法简单通过单线、第三方互联网解决。在方案的设计过程中发生了还有一些细节的变化,比如说:城域网从原来的四核心改为双核心结构,所有的数据中心都会双接到这两个核心上,这样结构简单、流量易于调度,在管理、自动化、可视等各个方面都有优势。
 
    在未来我们想达到这样一个理想效果,当南北运营商网络出现大面积网络异常的时候,我们在纯粹路由的层面完成业务切换。
 
    DCN二层到三层的改造
 
    我们最近一年半最痛苦的问题是网络规模太大了,现在一个网络里面至少10个POD,有大量的服务器和Docker,当前架构下设备的性能、稳定性达到了上限。
 
    网络设备不能简单地关注端口密度、带宽容量、电源容量等,还要考虑ARP、路由等各类表项资源,都是影响系统的重要因素。在二层网络里我们做一次网络核心的故障处理,从故障状态到可用状态整个过程大概经历了五六个小时以上而且是两天完成,整个过程就像拆弹一样,操作复杂且有极高风险。
 
    所以我们后来在运维、基础架构上列了几个规矩:第一,网络可以做到可以在10分钟内完成应急案处理。第二,部分网络损失不对网络造成致命伤害。第三,结构要非常简单的,具备较好的可扩展性、可运维性。
 
    提高网络割接的可靠性
 
    网络主要有运维和建设两个方向。过去一年半里,京东网络团队有60%以上的精力消耗到建设上,因为发展太快了。已发生的夜间割接,2016年300多次、2017上半年超过300次。
 
    为了确保网络操作的可靠性,建立了标准化的SOP操作文档、技术方案审核、双人操作等多种机制。并且,在推动自动化工具逐步替代手工操作。
 
    1.2、网络环境愈发严峻
 
    除上述的问题外,如今的网络环境也愈发严峻。目前的网络规模越来越大,变更次数越来越高,业务场景越来越复杂(比如:上面我们提到过的为业务特别树立的一个独立的数据中心,就会出现了特有的故障)。
 
    另外网络抖动问题会越发明显,通常这抖动网络上不易感知,而应用系统或用户对抖动问题却很敏感。从做事情的角度,从提供良好服务的角度,我们应该分析到底原因是什么,该怎样解决谁来解决。
 
    运维工作量和效率也是非常大的挑战,例如:业务方提出500台服务器的从单网卡改为双网卡的Bond,同期发生几起不易定位原因的故障需要分析排查,每件工作都是对运维力量的剧烈消耗。
 
    当人员大量消耗在着些事务性工作上的时候就没办法做好架构优化、工作改进的工作了。从团队利用率上来说我们的工作效率实际上是下降了的。
 
京东大规模数据中心网络运维监控之眼
 
    大家看上面这张图,这是2016年部分时期的可用性统计指标。图中有几个结果很差的互联网可用性,通常是有一些故障和问题导致的,这些问题大量的消耗我们的运维资源,是我们最优先要去解决的问题。
 
    1.3、业务要求日益增高
 
    之前业务要求相对简单,带宽不够则尽量做成1:1收敛比,设备可靠性不够则增加冗余,容量不够则扩大规模;现在业务对超大规模数据中心、超大路由表项、低延时、25G/40G差异化接入都提出了更高的要求,特别是网络的稳定性,网络团队需要更全面、精细的感知网络,快速发现和定位问题,减少重复问题的发生,制定有效的应急预案,确保高水准的网络可用性。
 
    另外,业务希望获得更多的网络信息和数据,以帮助业务进行更好的部署、管理和调度,例如及时准确的主机IP网络接入位置信息、流量和网络质量信息等,需要网络团队开放更多的API和功能支持上层应用。
 
    最后,网络排障和问题分析,是各个业务团队的常规需求,要么是网络运维团队协助排障,要么是开发出友好的工具提供给业务自助完成,显然后者是良性发展的必然选择。
 
    二、监控设计思考
 
    2.1、明确监控目标
 
  • 首先,“网络是不是好的”,核心是定义“好”的标准;
 
  • 其次,要准确感知到网络异常,关键是做到对网络核心监控项准确监控;
 
  • 最后,要快速定性问题并触发应对措施,核心是决策机制,确定严重程度、影响面;
 
    2.2、定义网络“好”的标准
 
    什么是网络“好”的标准?用户觉得好才是真的好。网络工程师在面对问题时的本能是排查分析问题的原因、尝试修复故障,往往眼里只有网络设备、功能协议的运行情况,异常状态和现象,而忽视了网络服务的核心是满足业务的联通性需要。
 
    当网规模到了一定程度之后,一两条链路或几台设备的好与坏说明不了整体网络服务是不是好的问题。网络团队要站在更高的层面,脱离只关注白盒、只关注网络设备的思维,从用户视角看网络服务情况。
 
    2.3、找到感知网络的有效方法
 
    知道什么是好网络,我们就要搞定感知网络,就要模拟用户的视角,做黑盒监控。京东网络团队在2016年下半年开始在黑盒监控方向走的比较快,进行了大量的实践和尝试。黑盒监控本质上还是白盒,但需要改变思维方式。
 
    例如:交换机板卡重启仅仅是导致网络抖动的原因之一,用户视角看到的是网络抖动,在处理逻辑上要先定性网络出现了抖动再定位是什么原因引起的。另外,在做网络核心项监控时,要抓大放小,不要什么都想一步做好,把最常见的、最严重的故障优先识别出来,首先解决核心问题。
 
    2.4、网络异常处理的预案与决策机制
 
    网络异常主要有两类:
 
  • 第一类是依靠网络自身的健壮性,可以自愈或承受的,往往这种仅降低网络的健康度、增加了不可用的风险;这类异常不是我们关注的重点。
 
  • 第二类是明显影响了网络局部或全部服务的可用性,但又没有导致网络服务中断或完全不可用,只能通过人工干预来执行应急预案的异常事件;这种问题才是最关键的、需要及时处理的。
 
    2.5、网络监控到底要做什么?
 
    这是一个简单的总结,网络监控要干吗?第一句话随着监控的深入,我们发现想象的网络质量跟我们主观实际测出到的确实不一样。
 
    监控要看啥呢?故障可用性、健康度、交付质量就是我一个新的网络建设完以后这部署立刻部署上完成验收、操作的影响我们做一个专线切换真的就是平滑的吗?我们下线板卡没有影响吗?但是因为没有数据我们以为是好的、还有运行状态。做好以上这些才是网络监控要做的事情。
 
    三、京东监控实践
 
    3.1、监控的前期准备
 
    准备工作如下:
 
    AAA [ http://www.pro-bono-publico.de/projects/tac_plus.html ]
 
    NTP [ http://www.ntp.org ]
 
    SNMP [ python + go ]
 
    SYSLOG [ http://www.balabit.com/network-security/syslog-ng/ ]
 
    CMDB [ mysql + php + python ]
 
    特别是需要手工维护的信息(例如:设备管理IP、互联网出口、专线接口等)
  
    在前期,我们需要为监控做一些基础的工作。
 
  • 首先,一定要有AAA,解决设备的统一管理问题。
 
  • 第二,就是NTP,设备时间一定要正确。
 
  • 第三,要具备基本的SNMP采集能力。
 
    今年京东618的流量采集比以往有一个突破,以前的采集密度是分钟极,今年到了10秒级,并给我们带来巨大的震撼。这个震撼就是我们发现原来的流量统计偏差很大,10秒采集的结果数值增加了20%,也就是说如果跑了80%的带宽,实际上是96%甚至百分之百。
 
  • 第四,SYSLOG可以帮我们了解很多未发现问题,进行回溯和追踪;前三点都是看事中出了什么问题,而SYSLOG是看事后出现什么问题,所以SYSLOG很重要,特别捕捉事前没见过的日志。
 
  • 最后一个就是基础信息,基础信息是整个监控的基础,需要注意的是很多基础信息是必须手工定义的,例如:哪些接口是专线?某台设备是什么角色等等。这类信息我称之为管理信息,是很难脱离人为因素完全自动化的。
 
    3.2、基本面监控
 
    核心逻辑是:
 
    有一些显而易见的状况,说明网络一定出了问题;
 
    那么就找到并呈现出来,先回答是否有问题(是不是好的);
 
    目前京东网正在使用的有:
 
    互联网出口、POD上联、DCI的实时流量和近24小时流量峰值;
 
    近6小时互联网、DCI的总流量环比;
 
    近24小时全网syslog、drop、crc的总量;

责任编辑:李欢
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐