双11背后的网络自动化技术
2016-12-09 16:42
501 查看
阿里巴巴目前拥有全球化的数据中心网络，其网络分布在包括亚洲、美洲、欧洲和大洋洲在内的全球各个大洲，而且部署的数据中心数量和规模随着阿里巴巴的业务增长还会不停扩大。这些数据中心之间由高带宽、低延时的网络进行连接，为的是满足如今许多分布式互联网应用的需求，这些分布式应用需要部署在很多不同的数据中心上，以保证在任何一个数据中心发生故障时可以将用户的流量从一个地方迁移到另外一个地方，保证应用的高可用性。与此同时，这些数据中心之间也存在着大量的数据需要进行同步，所以需要建立一个遍布全球的网络来支持数据传输。除此之外在各个地方部署数据中心的原因还包括提升用户体验的需求，如果用户由与自身距离比较近的数据中心来提供服务，就能体验到更低的延时。众所周知，互联网的延时大多是由信息在光缆中的传输速度和时间所决定的，传输距离越近意味着用户体验越好，所以为了给全球用户提供可靠、高性能的网络服务，需要在全球各地建立自己的数据中心。
但是设计、建设和运营如此巨大的数据中心网络是一项极为复杂的工作，大致需要分为五个步骤进行。
首先需要面对问题就是如何设计数据中心网络的架构。从组成情况来看，数据中心网络包括了骨干网、IDC网络以及城域网等。而从架构设计的角度出发，需要了解如何去设计网络才能满足业务需求；其次是如何保障网络的稳定性，另一方面还需要保证网络资源的灵活性，可以实现资源的灵活调度。
第二步需要面对的就是在网络设计完成之后，如何去建设网络的问题。建网过程包括了如何进行资源分配，包括IP资源的分配以及AS的分配等，之后需要根据资源分配结果生成相应的设备配置，而又因设备往往是由不同的厂家生产的，有不同的型号，在配置生成时需要保证生成的配置与设备相匹配。当配置生成后，下一步就是对网络进行交付，之后还需要对交付完成的网络进行一系列的检验。因为网络规模非常大，存在很多的连线，检验时需要确保所有的连线是正确的并且网络是联通的，是可以直接为业务提供服务的。
当网络建设完成之后，下一步就需要保证网络具有足够多的资源来满足业务的需求。这部分资源包括设备资源、带宽资源以及IP地址资源，需要保证各方面的资源是永远是足够多的才能保证服务质量。
还有一部分需要做的事情就是运维。当网络建成之后，在运营期间往往会出现各种各样的事情，所以需要随时监控网络中是否有故障发生，当故障发生之后需要及时进行故障的定位以及恢复。
最后一部分重要的工作就是对网络进行优化。因为网络是按照最初的设计和需求建设的，但随着业务不断的发展，新的技术涌现，新的需求也不停地提出，老的网络需要经过改造之后才能满足当前新的需求，所以需要进行各种各样的优化。优化一部分是由于业务需求变化导致的，另一部分是由于网络自身的调整导致的，比如由于需要进行扩容以及升级硬件和变更路由。还有一类是网络自身产生的优化需求，比如说某些设备存在bug或者有些新的特性需要提供，这样的情况下需要对设备上的软件进行升级。
首先要保证网络具有高性能。高性能包括有足够高的带宽以及足够低的延时，随着数据中心网络技术的不断发展，业务和应用对网络在延时和带宽上的要求也越来越高，当前很多单服务器已经具备了25G甚至40G带宽的能力，而数据中心内部的延时已经可达到微秒级。
还有一个技术挑战就是高可用性。建立如此巨大的网络时，会有很多应用运行在上面，显然无论发生什么样的故障，需要保证网络是可用的，甚至对于是发生在网络外部的故障，比如相关运营商发生故障时也要保证有足够的能力进行快速切换，保证网络的可靠和高效。
另一个技术挑战就是超大规模。这样一张巨大的网络需要服务于全世界上亿的用户以及上百万的企业级用户，此时意味着需要有能力运维上百万台设备组成的巨大网络。
最后一个重要挑战就是低成本的需求。尽管网络的规模不断扩大，但是并不代表可以简单通过提高资金投入去解决问题，而是需要通过技术保证低成本，这里所谓低成本指的是成本增长速度需要远远低于用户增长的速度。
在设计和运数据中心网络时，应对这些挑战的关键就是需要做到网络自动化技术。那么如何通过网络自动化技术解决以上的四个问题呢？
首先对于高性能的要求，其实建立任何一张网络都不可能保证永远有足够多的带宽满足任何时刻所有用户的需求，总会存在某个时刻网络带宽和用户需求不匹配的情况，当这种情况发生的时候，需要网络能够自动地进行带宽的分配和路径的优化。因为不同的应用对于网络的需求是不同，比如电商类应用和搜索类应用对延时的要求比较低，同时对带宽的需求也不是很高，但是对于像大数据应用对于带宽要求就往往会非常高，但是对于延时的要求则比较低，所以在发生网络拥塞或者网络资源不够用的时候，需要能够自动地将网络带宽在不同的应用之间进行合理分配，并且对于路径进行优化，以此来同时满足多个应用的需求。
对于高可用性的要求，一方面需要尽量减少网络中发生故障的数量，另一方面需要在故障发生后尽量减少故障恢复的时间。这就涉及到网络自动化技术中的两点，第一为了减少网络中发生的故障，需要网络能够进行自动隐患排查，在将网络中的隐患提前排查掉之后，网络发生故障的概率会大大降低。另外当故障发生时，需要能够自动进行故障恢复，显然当网络能够进行故障自动恢复的时候，其花费的时间会远远低于人工进行恢复的时间。
对于超大规模的要求，当网络中的设备数量达到百万级以上的时候，显然通过人工进行管理是不现实的，需要通过网络自动化技术对网络进行自动化配置、监控以及优化，尽量减少人在其中需要做的事情。
对于低成本的要求，通过自动化技术管理网络时，所需要的人力成本会大大降低。其实整个网络的成本中主要由两大部分构成，一部分是人力成本，另外一部分就是物理设备的成本。通过自动化技术可以很容易地降低人力成本，在另一方面也可以提高资源的利用率，因此可以采购更少的资源来满足同样的业务需求，降低整个网络的成本。
第一步是网络自动化的基础。任何网络想实现自动化都需要一个安全、可靠、高性能的设备管控平台，没有这个设备管控平台，网络自动化的实现也就无从谈起。这里的高性能指的是需要具有高并发和低延时的特性，同时可以对于大量设备进行操作；可靠是指无论发生什么样的故障，平台本身需要可靠；安全在管控平台中也是非常重要的一点，因为当通过自动化的技术管理网络时，自动化管理系统的任何一个微小的故障或不可预测的行为都可能对网络造成巨大的影响。在这样的情况下，就需要管控平台具有风险管控能力，保证在不可预测的情况下，仍能保障网络安全。
当具有了自动化的管控平台之后，下一步就需要在平台之上实现可自定义的、可扩展的网络自动化应用场景。为什么需要可自定义呢？这是因为网络自动化管理场景是复杂和多样化的，所以必须要保证自动化管理场景具有开放的能力，网络自动化场景不是完全由自动化平台自己构建的，我们将这些场景定义能力开放出去，这样相关的网络工程师、架构师甚至是客户都可以在平台的基础上去定义和开发适合自身的网络自动化运维场景，这样才能够真正地实现网络自动化。还有非常重要的一点就是可扩展性，因为任何时刻我们所能构想到的只是当前的场景，随着应用的发展和网络的变化，很多新的场景会涌现出来，所以打造出的网络自动化系统需要具备良好的可扩展性以便于应对未来的需求。
第三步也是非常重要的一步，其实网络不仅仅是多台设备的集合，其还包括了各种资源之间复杂的依赖关系。举个简单的例子，当将一条链路关闭的时候，受到影响的不仅是经过了这条链路的流量，全网的路由都有可能发生变化，很多其他的链路以及路由设备上的路由表都会相应地发生变化。这就要求在看待网络时不仅仅关注于有多少台设备以及设备的运行状态，而是需要深刻理解设备之间的复杂的依赖关系。这就要求构建全网的复杂网络模型，去真正地模拟和预测网络的变化情况。
由于时间有限，所以我们选取网络自动化模型中的两个例子进行深入的讲解。
T2的整体设计以及用例
我们打造T2的目的是做网络自动化的管控平台，那么首先需要搞清楚的就是T2需要支持什么样的网络自动化运维工作。
最常见的网络运维工作包括网络变更，举例而言就是M机房IP地址段告急，需要紧急扩容一段IP地址到该机房的网络设备上，这种情况属于计划内的变更，当然还存在紧急的变更，比如突然发生的故障需要临时关闭连接或者进行网络切换完成恢复的工作。
还有一大类需要支持的运维工作就是故障处理，举例而言就是当A城运营商网络出现异常，需要快速将业务流量切换到B城同一运营商网络。除去流量切换以外，还需要经常做的操作有对于设备的隔离，包括对于整机的隔离以及对于某个端口的隔离。
另外一类需要支持的运维工作就是网络巡检，举例而言M机房中同一组里面的DSW-XX-YY-1和DSW-XX-YY-2路由条目不一致，往往会造成隐患，需要通过巡检发现。
最后一类非常重要的运维工作就是建设交付，比如在双11之前往往需要新建集群，对于新建设的集群往往需要将新的配置发送到所有的设备上去，这就涉及到配置的下发以及交付的检查工作。
T2的设计思路
T2的设计思路就是将运维的场景和自动化平台进行分离。希望能够使用户通过编写各种各样的模版，灵活的实现各种复杂运维操作，将这种能力开放给用户，同时提供各种常用的系统函数和模板库供用户调用，如此可以大大简化模板的编写工作。
另外从自动化平台的角度来看，平台只需要去高效地执行这些模板即可。为了高效地执行这些模板需要平台具有支持几千台设备并发访问的高性能，比如在巡检场景下可能会需要对于全网设备进行巡检。网络内的设备数量是非常巨大的，也需要平台的高可用性和跨地域的容灾能力。另外平台也需要具备兼容性，对于不同厂商的不同型号的设备往往会使用不同的协议，所以需要兼容地支持这些协议。还有就是平台安全，因为在T2平台上编写场景时有可能发生失误，可能会对大量的设备产生误操作，为了在这样的情况下不对于网络造成太大的影响，所以需要实现读写帐号分离、完善的鉴权机制以及设备并发控制等保证自动化平台的安全。
通过将运维场景和自动化平台进行分离使得运维场景变得非常易于扩展，同时也使得整个系统的复杂度变得可控。
T2系统架构
首先用户需要通过Web页面编辑模板，系统内则会存在模板管理模块，用户模板、单设备模板以及库模板都会沉淀在DB中。当模板编写完成后，用户就可以使用这些模板了。当用户进行日常变更的时候只需要指定是模板以及所需的参数，就可以依靠平台执行这些功能。对于故障恢复，我们希望故障恢复的时间越短越好，对于这类特殊的任务，平台也会将其相应的模板和参数集成在网页按钮后面，当故障发生的时候，不需要再指定模板和参数，只需要点击一个按钮就可以将故障恢复。
当用户完成了任务的创建后，任务管理模块就会将任务通过MessageQueue下发到TaskExecutor里面，TaskExecutor会对模板变更的任务进行解释，将用户编写的任务翻译成为可以执行的指令同样通过MessageQueue下发到Scheduler，Scheduler的主要职责是将设备需要执行的指令根据其所在的安全域地理位置下发到对应的最接近的Agent上，最后Agent会通过与设备相兼容的协议将任务真正地下发到设备上执行。
接下来结合具体例子介绍一下T2模板，借助IP端扩容的实例解释一下模板变更的过程。下图左边显示的是为完成IP扩容段时需要输入的命令，右边显示的是将命令沉淀成模板和参数，当模板编辑完成之后就可以下发到机器上进行批量执行。这样的过程解决了三个问题，首先是标准化的问题，当依靠人工执行这些命令时，工作的质量就取决与网络工程师的能力高低以及其他人为因素，通过标准化过程沉淀成为模板以后就避免了很多人为的失误。另外因为沉淀成为了模板，所以可以批量进行执行，可以实现模板执行的自动化，达到全自动化的运维。另外因为大部分运维场景的操作是类似的，所以可以向模板中传入不同的参数达到运维的复用。
在分享完T2的模板以后，接下来讲解一下T2的模板库，在模板库里面最底层的叫做原子模板，原子模板中包含了系统最底层的调用包括ping检查，以及外部系统的调用如SDN Controller 的API以及CMDB的API等，将这些都封装在原子模板里，以便于用户在编写自己模板时进行调用。
另外一种就是单设备的模板，单设备的模板可以简单地理解为针对于单个设备或者同类型设备的CLI组合，它往往是针对于厂商型号适配后的指令集，单设备模板的目的是为了解决适配问题，支持按照角色、架构、厂商、型号以及操作系统版本来定义模板。
最后一类是用户模板，用户模板可以用来封装用户自动化场景，包括变更的模板和巡检的模板等。通过单设备模板已经将运维的差异性屏蔽了，所以在编写用户模板时就不需要关心底层设备的情况，而只需要关心业务逻辑即可，用户模板里定义的是比较高级的跨设备、跨场景的复杂模板编排，通过用户模板可以实现全自动化的变更流程。
下面使用一个简单的例子解释一下用户如何使用T2系统。这个例子是关于ISP出口一键切换的例子。当某个出口发生故障的时候需要迅速地将流量从地点A切换到地点B，来保证业务的顺畅运行，下图主要是T2系统的截屏。在这里每行的按钮是代表将流量从A城切换到B城，而第二张图的按钮表示将流量切回到B城。在这里面的每个按钮背后其实都对应了上百行的模板脚本，多行的切换按钮覆盖了所有ISP紧急切换场景，这样的切换执行时间与人工切换相比缩短了10倍以上，多次避免了严重的业务故障。
下图是在执行ISP出口一键切换时平台的执行情况。图中红框里面的部分是在执行ISP出口切换时的指令，对于每条指令都可以看到其执行后在的回显情况。通过这样的指令执行过程可以很容易地将问题所在挖掘出来并修复，甚至可以在平台上提供像设置断点这样的高级功能，使得在执行一定的指令后可以停下来观察回显结果，如果结果不符合预期可以选择回滚或者中断执行的过程，这些功能都大大地提高了平台的可用性。
T2系统的现状
T2目前是整个阿里巴巴集团的网络自动化的入口，通过T2平台可以支持多种的网络自动化运维场景，包括自动变更、故障恢复、网络巡检以及建设交付等等。接下来我们会进一步地丰富网络自动化运维的场景，做到真正的全自动化数据中心网络运维。
为什么需要网络巡检
网络巡检其实有很多的使用场景，这里主要分享一些关于故障的网络巡检场景，比如排查故障隐患。当我们了解整个网络的运行状态时，往往就会比较容易发现异常的状况，比如像内存泄漏问题，其实在网络发生问题的时候往往能看到某些设备的内存使用率在不停地上升，这很可能是因为内存泄漏造成的，在这种情况下其实可以通过对设备进行关闭或者重启操作来防止严重的后果。除去对于运行的巡检之外还可以完成一些配置问题的巡检，比方判断BFD配置是否规范等。
另外一类网络巡检工作就是故障的报警和定位，在很多故障发生的时候，首先发现故障问题的往往是运行在网络上的应用，应用会发现网络在丢包或者网络的延时比通常大很多，这种情况下就需要通过巡检所提供的网络拓扑和应用发出的报警结合在一起来定位究竟是哪一个设备和端口引起故障。
还有一类网络巡检任务就是自动化变更。很多的故障是在变更中引起的，所以在进行变更时也需要进行实时地检查网络运行状况以及配置的变化，以便于在发生故障时通过回滚或者终止措施来降低故障所带来的影响。
网络巡检所面临的挑战
一个很重要的挑战就是设备的多样性问题，因为在一个巨大的网络中往往会有多样的设备厂商、型号以及操作系统版本，对于每一种设备型号都需要进行数据项的采集，而且这些数据项的采集和解析规则往往都是不一样的。
另外一个重要的挑战就是巡检平台需要支持多维度的巡检规则。因为当将多维度的数据项采集回来之后，如何去设计数据项规则判断数据项是否正常也是一个复杂的工作。当去表达这样的规则时可以使用比较、正则表达式等，另外还需要确定规则的对象，因为数据项采集的对象可能是单台的设备，可能是逻辑设备也可能是设备组。另一重要维度是时间维度，一些数据项可能不仅需要看最新的数据，还要看历史数据项来判断变更是否正常。除去以上三种规则还需要基于网络模型的复杂巡检规则，比方判断网络中是否存在黑洞，所用的IP端是否在骨干网上可见，因为比较复杂，所以往往需要通过建立模型来进行表达。
网络巡检系统的架构
首先用户在使用网络巡检系统时需要输入一些网络状态巡检或者配置巡检的模板，当用户录入这些巡检项时需要同时指定设备类型以及型号信息，以及针对这样的类型设备应该采取什么样的方式去采集配置，对应的命令是什么，以及将这些所需要的状态采集回来之后怎样从中间提取并且解析所需要的数据项，最后就是与这些数据项相关的规则是什么。当用户完成这些指令以后，就可以将相对应的巡检模板放入巡检系统里面。
巡检系统包含了三类接口，包括巡检模板管理、解析模板管理以及巡检基线管理，其中使用基线可以判断巡检数据是否正确。当用户完成了所有巡检项的录入之后，网络自动化平台的巡检系统就可以通过设备管控平台T2触发相应的巡检任务，去设备上将相应的信息采集回来，采集回来的信息会被输入对应用户录入的解析模板，通过解析模板对于相关的数据项解析回来，最后解析出来的数据项会根据相应的巡检规则判断是否正常，并进行相应的处理。同时相应的信息也会输入到网络模型中，用于生成整个现网的模型，之前提到的巡检规则中人工可以录入的往往是比较简单的，还有一类是比较复杂的巡检规则是通过网络模型定义转换的。
除此以外，巡检系统也会提供一些对外的服务，比如巡检系统在网络中巡检出来的网络资源和物理资源等信息都可以输出到信息监控系统中，另外像快速变更系统和快速故障恢复系统也可以通过巡检系统实时获取到网络资源配置信息。
下面通过简单的案例介绍用户如何使用巡检系统。当用户拿到巡检系统后，第一步需要通过Web页面填写设备的厂商、型号以及操作系统版本等信息，根据这些信息可以判断使用什么样的方式去采集所需的巡检项。比如用户需要采集设备上操作系统的版本号信息，那么所对应的命令就是display version。当用户完成采集命令之后，下一步就需要确定命令对应的在设备上的输出是什么，采集回来的显示信息称之为KV的格式也就是key-Value的格式，也就是说前面的Key是Version的时候，后面我们所关系心的数据项就是操作系统的版本信息。在知道了大概的反馈信息之后，下一步就可以选择对于数据解析的模板，也就是说如何将采集的信息在输出中解析出来。在KV的典型模式下，用户只需要定义前面的关键字Key比如是Version，后面获取的变量就是Version的值。最后在完成解析规则之后，就需要去关联相应的巡检规则模板，之后使用规则比较来判断数据项是否符合要求。
网络巡检系统的现状
目前我们使用网络巡检系统定期地巡检阿里的设备。目前的巡检项有上百个状态，比如硬件的问题，像光纤和电源等，还有软件的问题，比如路由表和内存泄漏等，除去状态巡检外还会进行数十类的配资巡检，比如核心网私网地址路由规模过大问题、全网静态路由和默认路由规范检测等。通过各种状态巡检可以提前发现并且修复多种隐患，以保证在重大时间节点期间的网络运行稳定性。
什么叫智能化呢？我们认为智能化有三个特征就是学习能力、预测能力以演进能力。学习能力是指能够通过之前的经验学习到东西；而预测能力是指不仅仅能够通过之前的知识学习到一些东西，还能够具备对未来的预测能力；在预测能力的基础之上，智能化还需要演进能力也就是根据将来要发生的事情对系统或自身进行优化来适应未来。
学习能力很重要，因为当前的网络规则是由专家定义的，所以需要系统学习。但是因为是由人定义的，所以难免会有疏漏，并且当规则发生变化时，往往需要重新定义，此过程的成本会非常高。而未来希望对规则进行完善和重新定义的过程由机器自动完成，这就需要机器学习的能力，机器通过现有的大量数据中寻找新的规则，可以大大降低成本。
预测能力也是非常重要的，目前的网络自动化是当某些事情发生之后如何进行快速的反映，比如故障发生时如何去快速恢复，而不是如何避免故障。但我们知道当故障发生前往往会有一些各种各样的现象，所以希望未来可以在故障发生前进行预测，真正地避免故障。
同样演进能力也极为重要，目前自动化可以完成线网中的运维工作，但是网络的优化还是由人主导的。但人受限于计算能力，所以无法把握全局，而计算机的计算能力却是无限的（相对于人脑），所以希望未来能够由机器依靠强大的计算能力挑选出网络全局优化的方案。
但是设计、建设和运营如此巨大的数据中心网络是一项极为复杂的工作，大致需要分为五个步骤进行。
首先需要面对问题就是如何设计数据中心网络的架构。从组成情况来看，数据中心网络包括了骨干网、IDC网络以及城域网等。而从架构设计的角度出发，需要了解如何去设计网络才能满足业务需求；其次是如何保障网络的稳定性，另一方面还需要保证网络资源的灵活性，可以实现资源的灵活调度。
第二步需要面对的就是在网络设计完成之后，如何去建设网络的问题。建网过程包括了如何进行资源分配，包括IP资源的分配以及AS的分配等，之后需要根据资源分配结果生成相应的设备配置，而又因设备往往是由不同的厂家生产的，有不同的型号，在配置生成时需要保证生成的配置与设备相匹配。当配置生成后，下一步就是对网络进行交付，之后还需要对交付完成的网络进行一系列的检验。因为网络规模非常大，存在很多的连线，检验时需要确保所有的连线是正确的并且网络是联通的，是可以直接为业务提供服务的。
当网络建设完成之后，下一步就需要保证网络具有足够多的资源来满足业务的需求。这部分资源包括设备资源、带宽资源以及IP地址资源，需要保证各方面的资源是永远是足够多的才能保证服务质量。
还有一部分需要做的事情就是运维。当网络建成之后，在运营期间往往会出现各种各样的事情，所以需要随时监控网络中是否有故障发生，当故障发生之后需要及时进行故障的定位以及恢复。
最后一部分重要的工作就是对网络进行优化。因为网络是按照最初的设计和需求建设的，但随着业务不断的发展，新的技术涌现，新的需求也不停地提出，老的网络需要经过改造之后才能满足当前新的需求，所以需要进行各种各样的优化。优化一部分是由于业务需求变化导致的，另一部分是由于网络自身的调整导致的，比如由于需要进行扩容以及升级硬件和变更路由。还有一类是网络自身产生的优化需求，比如说某些设备存在bug或者有些新的特性需要提供，这样的情况下需要对设备上的软件进行升级。
建立DCN网络所面对的挑战
建立和运维如此巨大的DCN网络显然会带来很多技术挑战。首先要保证网络具有高性能。高性能包括有足够高的带宽以及足够低的延时，随着数据中心网络技术的不断发展，业务和应用对网络在延时和带宽上的要求也越来越高，当前很多单服务器已经具备了25G甚至40G带宽的能力，而数据中心内部的延时已经可达到微秒级。
还有一个技术挑战就是高可用性。建立如此巨大的网络时，会有很多应用运行在上面，显然无论发生什么样的故障，需要保证网络是可用的，甚至对于是发生在网络外部的故障，比如相关运营商发生故障时也要保证有足够的能力进行快速切换，保证网络的可靠和高效。
另一个技术挑战就是超大规模。这样一张巨大的网络需要服务于全世界上亿的用户以及上百万的企业级用户，此时意味着需要有能力运维上百万台设备组成的巨大网络。
最后一个重要挑战就是低成本的需求。尽管网络的规模不断扩大，但是并不代表可以简单通过提高资金投入去解决问题，而是需要通过技术保证低成本，这里所谓低成本指的是成本增长速度需要远远低于用户增长的速度。
在设计和运数据中心网络时，应对这些挑战的关键就是需要做到网络自动化技术。那么如何通过网络自动化技术解决以上的四个问题呢？
首先对于高性能的要求，其实建立任何一张网络都不可能保证永远有足够多的带宽满足任何时刻所有用户的需求，总会存在某个时刻网络带宽和用户需求不匹配的情况，当这种情况发生的时候，需要网络能够自动地进行带宽的分配和路径的优化。因为不同的应用对于网络的需求是不同，比如电商类应用和搜索类应用对延时的要求比较低，同时对带宽的需求也不是很高，但是对于像大数据应用对于带宽要求就往往会非常高，但是对于延时的要求则比较低，所以在发生网络拥塞或者网络资源不够用的时候，需要能够自动地将网络带宽在不同的应用之间进行合理分配，并且对于路径进行优化，以此来同时满足多个应用的需求。
对于高可用性的要求，一方面需要尽量减少网络中发生故障的数量，另一方面需要在故障发生后尽量减少故障恢复的时间。这就涉及到网络自动化技术中的两点，第一为了减少网络中发生的故障，需要网络能够进行自动隐患排查，在将网络中的隐患提前排查掉之后，网络发生故障的概率会大大降低。另外当故障发生时，需要能够自动进行故障恢复，显然当网络能够进行故障自动恢复的时候，其花费的时间会远远低于人工进行恢复的时间。
对于超大规模的要求，当网络中的设备数量达到百万级以上的时候，显然通过人工进行管理是不现实的，需要通过网络自动化技术对网络进行自动化配置、监控以及优化，尽量减少人在其中需要做的事情。
对于低成本的要求，通过自动化技术管理网络时，所需要的人力成本会大大降低。其实整个网络的成本中主要由两大部分构成，一部分是人力成本，另外一部分就是物理设备的成本。通过自动化技术可以很容易地降低人力成本，在另一方面也可以提高资源的利用率，因此可以采购更少的资源来满足同样的业务需求，降低整个网络的成本。
如何实现网络自动化
分享完网络自动化的优势以后，再聊聊如何实现网络自动化。在我们为阿里构建自动化网络系统的时候，经历了如下的几个步骤：第一步是网络自动化的基础。任何网络想实现自动化都需要一个安全、可靠、高性能的设备管控平台，没有这个设备管控平台，网络自动化的实现也就无从谈起。这里的高性能指的是需要具有高并发和低延时的特性，同时可以对于大量设备进行操作；可靠是指无论发生什么样的故障，平台本身需要可靠；安全在管控平台中也是非常重要的一点，因为当通过自动化的技术管理网络时，自动化管理系统的任何一个微小的故障或不可预测的行为都可能对网络造成巨大的影响。在这样的情况下，就需要管控平台具有风险管控能力，保证在不可预测的情况下，仍能保障网络安全。
当具有了自动化的管控平台之后，下一步就需要在平台之上实现可自定义的、可扩展的网络自动化应用场景。为什么需要可自定义呢？这是因为网络自动化管理场景是复杂和多样化的，所以必须要保证自动化管理场景具有开放的能力，网络自动化场景不是完全由自动化平台自己构建的，我们将这些场景定义能力开放出去，这样相关的网络工程师、架构师甚至是客户都可以在平台的基础上去定义和开发适合自身的网络自动化运维场景，这样才能够真正地实现网络自动化。还有非常重要的一点就是可扩展性，因为任何时刻我们所能构想到的只是当前的场景，随着应用的发展和网络的变化，很多新的场景会涌现出来，所以打造出的网络自动化系统需要具备良好的可扩展性以便于应对未来的需求。
第三步也是非常重要的一步，其实网络不仅仅是多台设备的集合，其还包括了各种资源之间复杂的依赖关系。举个简单的例子，当将一条链路关闭的时候，受到影响的不仅是经过了这条链路的流量，全网的路由都有可能发生变化，很多其他的链路以及路由设备上的路由表都会相应地发生变化。这就要求在看待网络时不仅仅关注于有多少台设备以及设备的运行状态，而是需要深刻理解设备之间的复杂的依赖关系。这就要求构建全网的复杂网络模型，去真正地模拟和预测网络的变化情况。
网络自动化蓝图
接下来分享一下究竟该如何构建网络自动化系统。我们可以将网络自动化系统分成五个层次来看，首先最底层是设备层，设备层里包含了所有可能出现的网络设备，包括路由器、交换机等设备；在设备层之上需要构建通道层，通道层的作用就是可以通过其控制设备层的设备，通过网络协议去管理和读写底层的设备；在通道层之上需要构建管控层，所谓管控层就是网络自动化的管控平台，我们可以通过管控层平台去管控所有的设备并对其进行操作；在管控层之上就是应用层，在这个层面可以实现各种各样的自动化的运维场景，比如说最常见的包括网络的监控、故障发现和定位、架构的定义以及自动的交付系统；在应用层之上还存在模型层，比如在应用层的故障自动定位的应用在操控设备的时候往往不仅是对于设备进行读写操作，更多地需要对于全网进行理解，需要了解网络的拓扑以及IP地址分配等，在模型层里会存储全网的模型，包括物理拓扑、设备情况、设备之间的逻辑关系以及协议关系。由于时间有限，所以我们选取网络自动化模型中的两个例子进行深入的讲解。
T2平台
第一个在是管控层打造的网络自动化管控平台Terminal2（T2）。大家通常对于设备的操作都需要Terminal，而这个网络自动化管理平台区别于其他的终端所以称之为Terminal2。T2的整体设计以及用例
我们打造T2的目的是做网络自动化的管控平台，那么首先需要搞清楚的就是T2需要支持什么样的网络自动化运维工作。
最常见的网络运维工作包括网络变更，举例而言就是M机房IP地址段告急，需要紧急扩容一段IP地址到该机房的网络设备上，这种情况属于计划内的变更，当然还存在紧急的变更，比如突然发生的故障需要临时关闭连接或者进行网络切换完成恢复的工作。
还有一大类需要支持的运维工作就是故障处理，举例而言就是当A城运营商网络出现异常，需要快速将业务流量切换到B城同一运营商网络。除去流量切换以外，还需要经常做的操作有对于设备的隔离，包括对于整机的隔离以及对于某个端口的隔离。
另外一类需要支持的运维工作就是网络巡检，举例而言M机房中同一组里面的DSW-XX-YY-1和DSW-XX-YY-2路由条目不一致，往往会造成隐患，需要通过巡检发现。
最后一类非常重要的运维工作就是建设交付，比如在双11之前往往需要新建集群，对于新建设的集群往往需要将新的配置发送到所有的设备上去，这就涉及到配置的下发以及交付的检查工作。
T2的设计思路
T2的设计思路就是将运维的场景和自动化平台进行分离。希望能够使用户通过编写各种各样的模版，灵活的实现各种复杂运维操作，将这种能力开放给用户，同时提供各种常用的系统函数和模板库供用户调用，如此可以大大简化模板的编写工作。
另外从自动化平台的角度来看，平台只需要去高效地执行这些模板即可。为了高效地执行这些模板需要平台具有支持几千台设备并发访问的高性能，比如在巡检场景下可能会需要对于全网设备进行巡检。网络内的设备数量是非常巨大的，也需要平台的高可用性和跨地域的容灾能力。另外平台也需要具备兼容性，对于不同厂商的不同型号的设备往往会使用不同的协议，所以需要兼容地支持这些协议。还有就是平台安全，因为在T2平台上编写场景时有可能发生失误，可能会对大量的设备产生误操作，为了在这样的情况下不对于网络造成太大的影响，所以需要实现读写帐号分离、完善的鉴权机制以及设备并发控制等保证自动化平台的安全。
通过将运维场景和自动化平台进行分离使得运维场景变得非常易于扩展，同时也使得整个系统的复杂度变得可控。
T2系统架构
首先用户需要通过Web页面编辑模板，系统内则会存在模板管理模块，用户模板、单设备模板以及库模板都会沉淀在DB中。当模板编写完成后，用户就可以使用这些模板了。当用户进行日常变更的时候只需要指定是模板以及所需的参数，就可以依靠平台执行这些功能。对于故障恢复，我们希望故障恢复的时间越短越好，对于这类特殊的任务，平台也会将其相应的模板和参数集成在网页按钮后面，当故障发生的时候，不需要再指定模板和参数，只需要点击一个按钮就可以将故障恢复。
当用户完成了任务的创建后，任务管理模块就会将任务通过MessageQueue下发到TaskExecutor里面，TaskExecutor会对模板变更的任务进行解释，将用户编写的任务翻译成为可以执行的指令同样通过MessageQueue下发到Scheduler，Scheduler的主要职责是将设备需要执行的指令根据其所在的安全域地理位置下发到对应的最接近的Agent上，最后Agent会通过与设备相兼容的协议将任务真正地下发到设备上执行。
接下来结合具体例子介绍一下T2模板，借助IP端扩容的实例解释一下模板变更的过程。下图左边显示的是为完成IP扩容段时需要输入的命令，右边显示的是将命令沉淀成模板和参数，当模板编辑完成之后就可以下发到机器上进行批量执行。这样的过程解决了三个问题，首先是标准化的问题，当依靠人工执行这些命令时，工作的质量就取决与网络工程师的能力高低以及其他人为因素，通过标准化过程沉淀成为模板以后就避免了很多人为的失误。另外因为沉淀成为了模板，所以可以批量进行执行，可以实现模板执行的自动化，达到全自动化的运维。另外因为大部分运维场景的操作是类似的，所以可以向模板中传入不同的参数达到运维的复用。
在分享完T2的模板以后，接下来讲解一下T2的模板库，在模板库里面最底层的叫做原子模板，原子模板中包含了系统最底层的调用包括ping检查，以及外部系统的调用如SDN Controller 的API以及CMDB的API等，将这些都封装在原子模板里，以便于用户在编写自己模板时进行调用。
另外一种就是单设备的模板，单设备的模板可以简单地理解为针对于单个设备或者同类型设备的CLI组合，它往往是针对于厂商型号适配后的指令集，单设备模板的目的是为了解决适配问题，支持按照角色、架构、厂商、型号以及操作系统版本来定义模板。
最后一类是用户模板，用户模板可以用来封装用户自动化场景，包括变更的模板和巡检的模板等。通过单设备模板已经将运维的差异性屏蔽了，所以在编写用户模板时就不需要关心底层设备的情况，而只需要关心业务逻辑即可，用户模板里定义的是比较高级的跨设备、跨场景的复杂模板编排，通过用户模板可以实现全自动化的变更流程。
下面使用一个简单的例子解释一下用户如何使用T2系统。这个例子是关于ISP出口一键切换的例子。当某个出口发生故障的时候需要迅速地将流量从地点A切换到地点B，来保证业务的顺畅运行，下图主要是T2系统的截屏。在这里每行的按钮是代表将流量从A城切换到B城，而第二张图的按钮表示将流量切回到B城。在这里面的每个按钮背后其实都对应了上百行的模板脚本，多行的切换按钮覆盖了所有ISP紧急切换场景，这样的切换执行时间与人工切换相比缩短了10倍以上，多次避免了严重的业务故障。
下图是在执行ISP出口一键切换时平台的执行情况。图中红框里面的部分是在执行ISP出口切换时的指令，对于每条指令都可以看到其执行后在的回显情况。通过这样的指令执行过程可以很容易地将问题所在挖掘出来并修复，甚至可以在平台上提供像设置断点这样的高级功能，使得在执行一定的指令后可以停下来观察回显结果，如果结果不符合预期可以选择回滚或者中断执行的过程，这些功能都大大地提高了平台的可用性。
T2系统的现状
T2目前是整个阿里巴巴集团的网络自动化的入口，通过T2平台可以支持多种的网络自动化运维场景，包括自动变更、故障恢复、网络巡检以及建设交付等等。接下来我们会进一步地丰富网络自动化运维的场景，做到真正的全自动化数据中心网络运维。
网络巡检平台
介绍完T2之后再介绍一个位于应用层的网络巡检平台。首先谈一下什么叫做网络巡检，网络巡检覆盖哪些内容。网络巡检其实覆盖了整个网络中全部的资源的信息，这里包含了硬件的状态，比如板卡、磁盘、CPU以及内存等；也包含了物理资源比如整机资源、端口互联状况等；还包括了逻辑资源，比如IP地址、VLAN、MTP等；以及最后的协议资源，因为同一个网络中往往会运行各种网络协议包括ISIS、OSPF、LDP以及BGP等常见的协议，对于所有的协议，我们都希望知道其互联状况是怎样的。为什么需要网络巡检
网络巡检其实有很多的使用场景，这里主要分享一些关于故障的网络巡检场景，比如排查故障隐患。当我们了解整个网络的运行状态时，往往就会比较容易发现异常的状况，比如像内存泄漏问题，其实在网络发生问题的时候往往能看到某些设备的内存使用率在不停地上升，这很可能是因为内存泄漏造成的，在这种情况下其实可以通过对设备进行关闭或者重启操作来防止严重的后果。除去对于运行的巡检之外还可以完成一些配置问题的巡检，比方判断BFD配置是否规范等。
另外一类网络巡检工作就是故障的报警和定位，在很多故障发生的时候，首先发现故障问题的往往是运行在网络上的应用，应用会发现网络在丢包或者网络的延时比通常大很多，这种情况下就需要通过巡检所提供的网络拓扑和应用发出的报警结合在一起来定位究竟是哪一个设备和端口引起故障。
还有一类网络巡检任务就是自动化变更。很多的故障是在变更中引起的，所以在进行变更时也需要进行实时地检查网络运行状况以及配置的变化，以便于在发生故障时通过回滚或者终止措施来降低故障所带来的影响。
网络巡检所面临的挑战
一个很重要的挑战就是设备的多样性问题，因为在一个巨大的网络中往往会有多样的设备厂商、型号以及操作系统版本，对于每一种设备型号都需要进行数据项的采集，而且这些数据项的采集和解析规则往往都是不一样的。
另外一个重要的挑战就是巡检平台需要支持多维度的巡检规则。因为当将多维度的数据项采集回来之后，如何去设计数据项规则判断数据项是否正常也是一个复杂的工作。当去表达这样的规则时可以使用比较、正则表达式等，另外还需要确定规则的对象，因为数据项采集的对象可能是单台的设备，可能是逻辑设备也可能是设备组。另一重要维度是时间维度，一些数据项可能不仅需要看最新的数据，还要看历史数据项来判断变更是否正常。除去以上三种规则还需要基于网络模型的复杂巡检规则，比方判断网络中是否存在黑洞，所用的IP端是否在骨干网上可见，因为比较复杂，所以往往需要通过建立模型来进行表达。
网络巡检系统的架构
首先用户在使用网络巡检系统时需要输入一些网络状态巡检或者配置巡检的模板，当用户录入这些巡检项时需要同时指定设备类型以及型号信息，以及针对这样的类型设备应该采取什么样的方式去采集配置，对应的命令是什么，以及将这些所需要的状态采集回来之后怎样从中间提取并且解析所需要的数据项，最后就是与这些数据项相关的规则是什么。当用户完成这些指令以后，就可以将相对应的巡检模板放入巡检系统里面。
巡检系统包含了三类接口，包括巡检模板管理、解析模板管理以及巡检基线管理，其中使用基线可以判断巡检数据是否正确。当用户完成了所有巡检项的录入之后，网络自动化平台的巡检系统就可以通过设备管控平台T2触发相应的巡检任务，去设备上将相应的信息采集回来，采集回来的信息会被输入对应用户录入的解析模板，通过解析模板对于相关的数据项解析回来，最后解析出来的数据项会根据相应的巡检规则判断是否正常，并进行相应的处理。同时相应的信息也会输入到网络模型中，用于生成整个现网的模型，之前提到的巡检规则中人工可以录入的往往是比较简单的，还有一类是比较复杂的巡检规则是通过网络模型定义转换的。
除此以外，巡检系统也会提供一些对外的服务，比如巡检系统在网络中巡检出来的网络资源和物理资源等信息都可以输出到信息监控系统中，另外像快速变更系统和快速故障恢复系统也可以通过巡检系统实时获取到网络资源配置信息。
下面通过简单的案例介绍用户如何使用巡检系统。当用户拿到巡检系统后，第一步需要通过Web页面填写设备的厂商、型号以及操作系统版本等信息，根据这些信息可以判断使用什么样的方式去采集所需的巡检项。比如用户需要采集设备上操作系统的版本号信息，那么所对应的命令就是display version。当用户完成采集命令之后，下一步就需要确定命令对应的在设备上的输出是什么，采集回来的显示信息称之为KV的格式也就是key-Value的格式，也就是说前面的Key是Version的时候，后面我们所关系心的数据项就是操作系统的版本信息。在知道了大概的反馈信息之后，下一步就可以选择对于数据解析的模板，也就是说如何将采集的信息在输出中解析出来。在KV的典型模式下，用户只需要定义前面的关键字Key比如是Version，后面获取的变量就是Version的值。最后在完成解析规则之后，就需要去关联相应的巡检规则模板，之后使用规则比较来判断数据项是否符合要求。
网络巡检系统的现状
目前我们使用网络巡检系统定期地巡检阿里的设备。目前的巡检项有上百个状态，比如硬件的问题，像光纤和电源等，还有软件的问题，比如路由表和内存泄漏等，除去状态巡检外还会进行数十类的配资巡检，比如核心网私网地址路由规模过大问题、全网静态路由和默认路由规范检测等。通过各种状态巡检可以提前发现并且修复多种隐患，以保证在重大时间节点期间的网络运行稳定性。
展望未来：从自动化到智能化
什么叫智能化呢？我们认为智能化有三个特征就是学习能力、预测能力以演进能力。学习能力是指能够通过之前的经验学习到东西；而预测能力是指不仅仅能够通过之前的知识学习到一些东西，还能够具备对未来的预测能力；在预测能力的基础之上，智能化还需要演进能力也就是根据将来要发生的事情对系统或自身进行优化来适应未来。
学习能力很重要，因为当前的网络规则是由专家定义的，所以需要系统学习。但是因为是由人定义的，所以难免会有疏漏，并且当规则发生变化时，往往需要重新定义，此过程的成本会非常高。而未来希望对规则进行完善和重新定义的过程由机器自动完成，这就需要机器学习的能力，机器通过现有的大量数据中寻找新的规则，可以大大降低成本。
预测能力也是非常重要的，目前的网络自动化是当某些事情发生之后如何进行快速的反映，比如故障发生时如何去快速恢复，而不是如何避免故障。但我们知道当故障发生前往往会有一些各种各样的现象，所以希望未来可以在故障发生前进行预测，真正地避免故障。
同样演进能力也极为重要，目前自动化可以完成线网中的运维工作，但是网络的优化还是由人主导的。但人受限于计算能力，所以无法把握全局，而计算机的计算能力却是无限的（相对于人脑），所以希望未来能够由机器依靠强大的计算能力挑选出网络全局优化的方案。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- Linux网络应用程序设计
- 一个简单的HTTP服务器
- 网络请求runloop
- HTTP接口跨域-服务端接受返回处理
- Linux TCP/UDP小例子
- 手把手教你玩转网络编程模型之完成例程(Completion Routine)篇（下）
- 手把手教你玩转网络编程模型之完成例程(Completion Routine)篇（上）
- http://blog.csdn.net/account/register.html?from=http%3a%2f%2fwrite.blog.csdn.net%2f%3fticket%3dST-93
- TCP协议中的三次握手和四次挥手(图解)
- HttpUrlConnection之gzip相关
- 关于HTTP/1.1的小问题
- LXC快速入门（4）——配置文件简介及网络配置实例
- RxAndroid之简单网络请求，数据操作
- Retrofit+okhttp 缓存的
- TCP\UDP链接的异同
- TCP的三次握手(建立连接）和四次挥手(关闭连接）
- 第25章 网络编程
- NodeJS 最快速搭建一个HttpServer
- 监控InfiniBand网络中HCA卡的端口状态
- Android网络框架xUtils的图片处理操作