A-A+

云时代如何简化数据中心网络运维?

2016年08月19日 Linux 新闻 暂无评论 阅读 507 次

SDN,在经历了犹豫彷徨、百家争鸣之后,目前已成为企业CTO的坚定选择。

SDN时代的网络展现出两面性:一方面让客户使用更加简单,另一方面却让运维更加复杂。而当前,整个行业的目光多聚焦在前者而忽略了后者。

随着SDN的部署如火如荼,一丝忧患也隐隐浮现。2015年12月,管理行业研究机构EMA(Enterprise Management Associates)针对100多家企业的调查结果显示:70%左右的客户对于现有管理运维体系是否适用于SDN场景表示担忧。Gartner于 2015年7月发布的通信网络技术成熟度曲线(The Hype Cycle)也显示,SDN相关的运维技术处于泡沫化的底谷期(Trough of Disillusionment),将在2~5年内进行大规模商用部署。

华为早在全面拥抱SDN初期,就把SDN运维作为关键课题进行研究和实践,下面分别从WHY、WHAT、HOW这3个纬度展示华为对SDN运维的思考。

WHY:SDN运维的新变化

相对于传统网络,SDN时代的网络有如下的特征:

动态网络:动态是指根据应用需求按需创建和删除逻辑网络。比如某企业用户反馈,在运维中需要投入50%的工作在防火墙的规则上,主要原因是随着应用的变迁,防火墙规则没有随之变迁,造成网络沉淀和碎片。

实时响应:传统网络的设计主要是面向人的界面,基于分钟级别慢速的原则,比如使用了几十年的SNMP机制。这种慢速机制,在SDN的快节奏中成为“吐槽”点。某企业客户抱怨其轻载的网络存在瞬态的突发丢包,怀疑存在毫秒级别的微突发流量,但是在分钟级别的 SNMP机制下无法观察到,更无法优化。

大规模:大规模有两个含义,其一是管理的设备数量。从物理网元到逻辑网元vSwitch/vRouter,其数量增加了50倍;其二是处理的故障数量。据LinkedIn披露,从2010年到2015年,需要处理的故障增加了18倍,但管理人员仅增加了几个。

要应对上述SDN网络的3大问题,传统的“人工运维”方式贤德捉襟见肘、难以为继。

WHAT:SDN运维内涵

为了满足SDN下“动态性、实时性、大规模”的挑战,华为提出需要对整个运维架构进行变革,才能让SDN“管用、好用”。新的SDN运维架构需要围绕下面几个方面打造:

可视化:看得见,看得清

俗话说“You Can’t Manage What You Can’t See”。“看得见”有两个方面的含义:

观察对象可视:可监控物理和逻辑对象,包括网元级别的节点和接口等,也包括网络级别的链路、逻辑路径和应用质量等。

观察的实时性:支持毫秒级别现象的感知(比如流量微突发)、低频率(<10-4)的丢包,以及大象流和老鼠流的识别等。

“看得清”意味着针对观察的准确性,需要采集和分析海量的数据。包括:

精确计费:采集的比例需要从8K:1到2K:1,甚至1:1全量采集。

疑难问题定位:基于采集的“大数据”和实时分析,及时发现偶发性丢包和流量黑洞等。

自动化:自修复,自优化

传统的网络运维架构是一个单向的系统,而不是一个负反馈系统。网络运维包括两个方向:管理员在下行方向配置网络,然后通过上行方向获得网络的状态,也就是说,网络的部署和状态是割裂的,通过管理员进行有限的沟通。这种机制显然无法满足网络故障自修复和网络自优化的需求。自动化的运维需要构建 “闭环”运维架构,具体包括:

延迟修复:发现故障后,首先隔离故障,不影响现有业务。

诊断修复:结合采集的“大数据”和经验数据库,进行自动修复或给出明确的修复方案。

网络优化:及时发现网络存在的“病态”,如流量不均衡和流量拥塞风险等,通过闭环系统,由网络部署系统自动进行调整,把故障消灭在萌芽状态。

HOW:SDN运维方案

基于SDN下的运维新变化,华为分解了运维的生命周期,构建了“闭环”的运维负反馈系统,称为Fabric Insight架构,包括如下4个模块:

Monitor:监视

为了解决实时,海量的数据监视,需要在如下两个方面改进方案:

改造采集通道,满足海量数据上报:对于中规模的数据上报,采用gRPC等高效的采集通道替代SNMP等;对于大规模的数据上报,直接采用数据面基于UDP的采集通道,消除管理面CPU的带宽限制。

改造采集点,满足高频采集:在数据中心交换机上设计专门的高频采集部件,满足毫秒级的事件采集。

Detector:探测

未来及时发现端到端业务路径的质量,需要通过实时发送探测报的方式,对网络进行“扫描”。区别于传统机制的“随机扫描”,华为结合网络的拓扑和路由,支持更精确的“定向扫描”,可以做到真正的全网全覆盖。基于这种能力,管理员就不再是“救火员”,而是运筹帷幄的“诸葛亮”。

Metrics:度量

在某些情况下,网络质量显示正常,但是应用体验下降。探测机制无法解决这种问题,就需要基于真实的业务流进行度量,发现该业务流是否存在丢包和时延问题,如果丢包,丢包位置在哪?如果时延大,是什么因素造成的?

Diagnosis:诊断

诊断就像老中医看病,通过Monitor、Detector和Metrics进行“望闻问切”后,再结合经验库的案例,定位出问题的根因。诊断部件由一系列的工具组成,每个工具针对特定的问题。比如环路诊断工具、丢包诊断工具等。

华为秉承开放的理念,开放基本的运维API,客户可自助地开放和定制自己的诊断工具集。

给我留言

Copyright © SEARU.ORG 保留所有权利.   Theme  Ality 网站地图 360网站安全检测平台

用户登录

分享到: