Robotron项目介绍

Facebook Robotron 论文中介绍了一种自顶向下的大型生产网络管理系统。采用“自顶向下”的新型抽象方式，即站在用户的视角上，屏蔽底层网络技术，方便用户以更加直观的方式实现网络资源的分配以及业务的灵活部署。网络工程师只需要向Robotron表达高级的网络管理意图，Robotron系统就可以将其翻译为低级的设备配置并且安全自动的部署到设备上。Facebook从2008年起就已经开始使用Robotron来管理位于全球的数万台网络设备以及相连的数十万服务器。

在网络管理上主要会遇到五个挑战：

• Vendor Differences：在数据中心里很有可能存在不同厂商的设备，每个厂家设备的硬件以及运行的操作系统都不相同。网络管理员需要懂得如何使用特有的命令以及API进行调用，这对管理一个大型网络来说，是十分复杂和繁琐的事情。
• Versioning: 网络拓扑、路由、设备的版本以及配置会随着时间的推移，进行不断的变化。这要求工程师需要懂得如何同时管理多个不同“版本”的网络。
• Distributed Configurations：从高级意图到生成许多设备的配置，是十分复杂和容易出错的。例如迁移一台路由，其中涉及到IP地址、路由表、接口等等一系列的变化。
• Multiple Domains: 一个大型网络中包含不同的网络域，存在“网络中的网络”。例如Facebook网络中包含接入点、骨干网络和多个数据中心。这些网络里面的设备、网络拓扑以及功能职责各不相同。必须所有的配置正确才能保证整个网络的功能正常。
• Dependency: 修改一台设备的网络配置很有可能影响到网络中其他设备的配置。例如，新增加了一台路由到自治域中，意味着其他路由的配置也要进行了改变。这种依赖性对网络工程师是很难处理的。

针对这些挑战，Facebook设计了Robotron网络运维项目，用于管理大型的DC网络。主要目标有以下三点：

• Configuration-as-code: 尽量减少人工干预，通过使用配置模板（templates）生成对应的设备配置，从而提高了使用重复率，并且减少了配置出错的可能（比如不小心写错命令，导致语法出错）。
• Validation: 采用了几种验证机制用于避免配置出错。其中包括：人为检查、通过监控动态网络状态和配置等等。
• Extensibility: 可扩展性。面向设备，提供功能完整的、厂商无关的网络建模接口，这使网络管理员不再需要关心不同厂商设备的差异化。

架构

下图展示了Robotron的架构，其中FBNet作为底层基础，用于描述和储存网络设备模型对象。FBNet由两部分组成，抽象出了物理相关的描述（例如设备，接口等）和逻辑部分（例如BGP协议、IP地址）。另外FBNet模型可以分成理想（desired）和现实推导（derived）的两种。理想的模型是用户或者网络管理员所想描述的理想网络状态，而实际推导出的模型反映的是当前网络状态。通过互相比较，可以找出网络的异常，例如配置错误等等。

网络管理系统采用“自顶向下“的方式进行抽象，一共分为四个阶段，网络设计（Network Design）、配置生成（Config Generation）、配置下发（Deployment）和网络监控（Monitoring）。

网络设计

第一阶段，从high-level的网络设计意图转成FBNet对象，其中包含着具体数据信息（Value）以及对象之间的关系（relationship）。对象(object)是一个抽象类，定义了被管理或被作用的对象，在不同层次中可以被继承或者扩展。下图展示了集群cluster里的设备信息（例如厂商、设备数量）和网络拓扑（设备之间是如何连接的）。根据这些信息，将构建生成多个FBNet对象模型（下图显示了一共生成了94个对象，7个类型的模型，100多个相互关系）。利用抽象出的网络对象模型，实现对网络资源分配。

那么Robotron是如何保证在网络设计这一步骤中不出任何差错的呢？例如在模板中的拓扑缺少了信息或者分配重复的结点等错误。这主要有两种方法避免发生错误，分为自动和手动模式。

• 系统嵌入了自动验证对象object的合法性。当从模板template转译到设备对象object时，这些规则会去检查描述设备的信息（value）和相互之间的关系（relationship）是否正确。
• 系统会在生成FBNet对象前，向用户展示该设计对网络产生的变化。用户可以对其进行检查。
• 系统会记录所有的网络设计变更日志，用于跟踪错误和Bug。同时还记录了管理员的ID，可以通过ID查找到这个管理员对网络设计变更的历史记录。

配置生成

这一阶段是从FBNet对象生成对应厂商的设备配置。不同厂商所对应的设备配置语法会不同，Robotron把设备配置分为两部分：

• 动态的，厂商无关的信息（例如设备的sysname、IP地址）。无论哪一个厂商设备，都是需要这些信息，而这些信息是由用户或者网络管理员来决定的。
• 静态的，厂商相关的模板。（例如带有特殊的语法关键词）

如下图所示，Robotron获取到所有相关的FBNet对象模型，并且从中获取对象信息存入Thrift对象中。最后结合Thrift对象和厂商相关的模板生成对应的设备配置。

Robotron使用了多种方法用于保证配置的正确性：

• 系统会存储设备的配置和模板在Configerator里（版本管理仓库），所有的更改记录都能被查看到，并且能够进行单元测试。
• 系统会备份所有设备当前运行的配置，当出现紧急情况（例如发生灾难）时，可用于快速恢复网络。
• 系统监控当前设备配置变化，当发生违背意图的配置时，会产生警告并且通知网络工程师。

网络部署

数据中心在进行服务器部署时，往往上线一批就要数百上千、甚至上万台，数量非常庞大。如果需要通过手工方式对每一台进行系统升级、下发配置是非常耗时的，也要消耗很多的人力资源。于是出现了一些自动化部署的方案，在不需要网络管理员亲自到现场对设备进行配置的情况下，实现设备上电后即可自动完成部署。在上线后，随着时间的推移，业务需求可能会发生不断改变，对网络性能要求也不断提高，设备的配置也要不断的更新。相比传统的人工部署方式（CLI），自动化网络部署方式不仅提高了部署效率、节约了人力成本，还可以有效地避免配置错误。

Robotron可以分为两种不同的网络部署方式：

• Initial Provisioning：Robotron会清除旧的配置并且复制新的经过验证的配置到设备上。这种方式属于全替代（replace），相比增量式的（直接把新的配置merge到原配置上）更不容易出错。因为每个设备处在全新的状态（clean state）。
• Incremental Updates：增量式的更新配置，为了降低对正在运行的设备造成的影响，Robotron采用了以下几种机制：
  • Dryrun Mode：用户可以在部署前后，查看下发的配置和设备里正在运行的配置，进行对比（diff），并且可以检查出一些异常和错误配置。
  • Atomic Mode：所有的操作应该是原子化的。这是因为通常部署的时候会向多台设备下发配置进行更新，如果在部署期间出现任何错误，应该立马恢复到之前的运行配置。
  • Phased Mode：部署的时候可以分阶段进行。这是因为设备之间联系紧密, 并且存在故障扩散现象。例如下发防火墙规则的时候，通常要求工程师将新的配置分成几个阶段步骤进行下发。Robotron会监控跟踪任务进展，如果中间某一阶段部署失败了，就不会继续进行下去了。
  • Human Confirmation：当部署成功后，工程师可以根据这一段时间内当前网络是否与理想的网络相同，进行最终的确认，否则Robotron会进行回滚。

网络监控

网络的基础监控通过各类接口和协议，通过使用主动和被动监控技术来监控服务器健康状态，以便及时、准确地了解网络中实际的运行状态。 Robotron监控有三种机制：

• Passive Monitoring：被动监控检测一些事件，例如：设备配置更新、路由翻动（route flapping）、设备重启事件等等。其中Syslog监测就是是基于被动式的，针对监控到的日志信息，并且结合正则表达式匹配灵活过滤出关键信息，以便于配置trigger，在发现异常日志信息时触发告警通知。
• Active Monitoring：主动式的监控，进行性能采集（例如CPU、内存使用情况）和监测设备状态（用于生成FBNet Derived模型）。下图描述了主动式的监控分为三个部分：任务管理器（Job Manager）、引擎（Engines）、后端（Backends）。
  • Job Manager 用于管理和分发监控任务，每个任务涉及到采集间隔时间、采集的数据类型、存储到哪一个后端等等。
  • Engines 接收到任务后，会通过各类接口和协议从对应的设备上采集数据。
  • Backends 会把采集到的数据转换成相应的格式储存起来。
• Config Monitoring：Robotron同时使用主动和被动监控技术监控当前设备上运行的配置。当有配置更新时，被动监控检测会检测到新生成syslog日志，然后触发trigger下发一个主动式的任务（job）用于采集设备当前配置。每次采集到的配置会备份到版本管理仓库中，用于跟踪每个设备中的配置历史更新情况。