接上阅读《走近Facebook Altoona数据中心网络（上）》

您之前提到，除了ECMP之外，BGP是FacebookAltoona数据中心使用的唯一一种路由协议。这就是保持简单性的一种体现吗？

Andreyev：是的。我们还使用最少的特性组合去运行这种拓扑。BGP遍布整个网络，从机架交换机上行链路到边界链路。

Altoona的BGP控制器是如何工作的？

Andreyev：每一个交换机都能够让BGP与控制器通信。这里有两个基本组件。一是能够查看交换要有哪些BGP路由信息，二是通过注入路由来构造一条从设备到设备、端到商的路径。采用了这种路由设计方法，我们就可以支持大多数网络流，包括BGP和ECMP。但是，如果需要一个不同于BGP决策的自定义路径，那么我们可以使用控制器功能逐个跳地部署它。而且，我们可以快速实现部署。决定我们采取何种方式的依据只是一个软件选择问题。

BGP控制器是自动作出决策的，还是由工程师来作决策？

Andreyev：我们支持两种方法。因为我们的结构拓扑及结构中的所有配置都由软件创建，我们能够完全监控穿越不同域的路由，以及哪些组件应该有哪些软件信息。知道了所有的信息，我们就有非常快速灵活的方法可以修正特定的路由路径。所以我们有关于它状态的信息。我们的控制器可以控制每一个组件的信息，我们的控制 器能够将特定的路由下发到不同的网络位置，编程实现我们需要的路径。

您是否将这种BGP控制器定性为一种SDN控制器？

Andreyev：它的行为基于软件决策，所以它可以这样定性。关于结构的所有方面都是由软件驱动的。其中完全不需要像日志这样的定义和配置，也不需要为各个设备创建配置。当我们定义网络时，我们只是面向整个网络从非常高的层面上去处理配置。所有其他方面都源于软件。我们可以定义非常多的实现方法。

相同的方法同样用在了运营、监控和故障修改，因为大多数问题都是自动解决的。我们几乎不需要操作各个设备。在增加新设备时，我们有一些机制可以发现设备在拓扑中的角色，然后从一个知识库部署配置。

所以说您为这个网络开发了一个自动修复平台？

Andreyev：是的。当我们检测到问题，系统就会检查问题，如果发现是一个已知问题，则会马上修复问题，然后通知操作者它已经修复了问题。在修复问题之后，如果发现了新问题，那么我们就会想办法让它变成可以自动检测。这样当它再一次出现时，相同的自动修复功能就会出现并修复它。这非常像我们一直以来用于管理服务器的方式。我们一直在使用FBAR（Facebook Auto-Remediation）去管理服务器运维，我们在尽力用服务器上的相同方法和概念实现网络的可管理性。无论出现什么问题，或者说无论修复问题需要采取哪些特定的操作，它们都只针对于该问题。它是一个普适框架，可以检测问题并给出解决问题操作——以及验证这些操作并报告操作。

这里的关键实际上不在于工具，而在于概念。它考虑的是如何简体运营，是指通过各种手段去监控问题的概念——包括SNMP池化或系统日志等，并且能够响应这些事件，能够增加更多的修复操作，并且通知人们关于这些操作的进展。它更多是关于我们是如何实现整个框架的，以及如何让这样一个大规模分布式网络变得更具可管理性。