Facebook最近简单介绍了它在Iowa州Altoona建设的新数据中心的高度模块化和可扩展网络。这个社交网络巨头一直很开放地对外展示它的数据中心网络建设方法，因为它正在尝试围绕其开放计算项目打造一个网络设备与软件生态系统。Facebook的目标是创建一个基于分散硬件和软件的数据中心交换市场，降低运营成本和难度。根据开放计算网络项目的问题，Facebook推出了一个原型交换机(Wedge)及FBOSS(基于Linux的网络操作系统)。
虽然Wedge和开放计算都无法在现阶段的Facebook立即发挥重要作用，但是可以想象到它们在将来的前景。FacebookAltoona数据中心网络通过简单性和创新架构方法实现其可扩展性和模块化。它仅仅使用BGP和Equal Cost Multi-Path(ECMP)路由来保持拓扑简单性和供应商独立性，而且它采用一种大规模叶脊网络，其中每一层在设计上都可以独立扩展。
Facebook可以通过计算Pod和***机架(ToR)交换机的形式横向扩展叶子层。网络拥有多个并行运行的独立脊干交换机“平面”。此外，它还可以给网络设计引入“边界Pod”来扩展外部连接。每一个边界Pod都包含多个机架的高带宽交换机，它们负责将脊干层连接到外部网络。Facebook的网络设计允许根据需要独立增加脊干容量、服务器访问容量或边界容量。
而且，Altoona网络有一个内部开发的BGP控制器，当特定的应用程序和服务器需要使用一条专用网络路径时，它可以重载标准BGP路由。这个网络有一个大规模编制器，它带有准确定义的网络配置，并且可以自动将配置下发到各个交换机上。***，这个公司还开发了一个管理平台，它能够自动诊断和修复网络问题。我希望更多地了解Facebook在Altoona数据中心的网络设计，因此我采访了设计数据中心的Facebook工程师Alexey Andreyev。
您能谈谈Facebook Altoona网络的设计目标是什么吗?
Alexey Andreyev：我们在尝试解决扩展性问题和消除过载网络的限制——在数据中心实现支持任何扩展需求的容量，而且能够在一种非常简单统一的框架中向不同的维度扩展。当我们需要扩大容量时，只需要增加脊干交换机。当我们需要更多连接时，只需要增加边界Pod。这是一个非常结构化和可预测框架，我们可以用它实现无限扩展的容量目标。我们希望能够更轻松地处理网络，而不会因为拓扑或复杂性增加而受到限制。
像这种运营上的简单性是如何实现的?
Andreyev：关键的一点是我们用这个软件方法去创建一个结构，然后由它来完成自动管理。我们会配置数据中心;但是我们不会配置各个组件。组件配置主要由我们的系统在上层设置中创建的。我们定义好数据中心的结构，以及构成数据中心的特定结构拓扑形状因数。所有必要的特定配置，如各个设备配置、组件配置、关于连接设备数量的端口映射及路由策略解析等，所有这些都源自于高级设置，它们会被解析为特定的平台设置。
这种解析又是如何做到的?
Andreyev：我们定义了一个非常简单可用设备转换方法。我们会检查所有网络服务，预期的路由状态、预期的拓扑及拓扑的属性。我们用这些信息为每一个组件创建出完全抽象且与供应商无关的逻辑视图。然后，我们将它们转换为一个特定的实现。例如，一个交换机有X个端口，而这些端口对应X个地址，而不是一些固定的路由。这是非常普遍的方法，然后当我们生成这个逻辑视图之后，我们只需要将解析为任何真实的组件。
您是通过什么方式将这种高层次策略下发到交换机上的?
Andreyev：我们会使用适合特定组件的方法。我们在我们知识库中部署了专门为这些组件准备的配置。我们有一些机制可以在大量组件上调度这些操作。我们的最终目标之一是尽可能保持简单。我们的自动化和扩展层次都是非常分散的，这样我们就可以根据需要更换任何组件，而不需要对软件执行大修改。因此我们可以非常快速地应用新的组件。
这种与供应商无关的方法是如何与许多数据中心运营商的目标有什么关系，特别对于开放网络用户组成员来说?这种方法如何转变和应用到更大范围的数据中心行业?
Andreyev：一个重要的要求是保持简单，一个组件只有最少必要的功能，而且也只有功能部署及组件操作的最少必要步骤。例如，对于任何的组件，我们都定义一个操作(步骤)，轻松地从服务器提取组件或者将它轻松地放回服务，或者只是部署配置，等等。我们找到了各种不同类型事物的共性部分。而且它越是简单，共性就越多。这就是为什么我们提出这个方法的原因所在。这相对简单一些，我们认为所有人都可以从中受益。
您之前提到，除了ECMP之外，BGP是FacebookAltoona数据中心使用的唯一一种路由协议。这就是保持简单性的一种体现吗?
Andreyev：是的。我们还使用最少的特性组合去运行这种拓扑。BGP遍布整个网络，从机架交换机上行链路到边界链路。
Altoona的BGP控制器是如何工作的?
Andreyev：每一个交换机都能够让BGP与控制器通信。这里有两个基本组件。一是能够查看交换要有哪些BGP路由信息，二是通过注入路由来构造一条从设备到设备、端到商的路径。采用了这种路由设计方法，我们就可以支持大多数网络流，包括BGP和ECMP。但是，如果需要一个不同于BGP决策的自定义路径，那么我们可以使用控制器功能逐个跳地部署它。而且，我们可以快速实现部署。决定我们采取何种方式的依据只是一个软件选择问题。
BGP控制器是自动作出决策的，还是由工程师来作决策?
Andreyev：我们支持两种方法。因为我们的结构拓扑及结构中的所有配置都由软件创建，我们能够完全监控穿越不同域的路由，以及哪些组件应该有哪些软件信息。知道了所有的信息，我们就有非常快速灵活的方法可以修正特定的路由路径。所以我们有关于它状态的信息。我们的控制器可以控制每一个组件的信息，我们的控制 器能够将特定的路由下发到不同的网络位置，编程实现我们需要的路径。
您是否将这种BGP控制器定性为一种SDN控制器?
Andreyev：它的行为基于软件决策，所以它可以这样定性。关于结构的所有方面都是由软件驱动的。其中完全不需要像日志这样的定义和配置，也不需要为各个设备创建配置。当我们定义网络时，我们只是面向整个网络从非常高的层面上去处理配置。所有其他方面都源于软件。我们可以定义非常多的实现方法。
相同的方法同样用在了运营、监控和故障修改，因为大多数问题都是自动解决的。我们几乎不需要操作各个设备。在增加新设备时，我们有一些机制可以发现设备在拓扑中的角色，然后从一个知识库部署配置。
所以说您为这个网络开发了一个自动修复平台?
Andreyev：是的。当我们检测到问题，系统就会检查问题，如果发现是一个已知问题，则会马上修复问题，然后通知操作者它已经修复了问题。在修复问题之后，如果发现了新问题，那么我们就会想办法让它变成可以自动检测。这样当它再一次出现时，相同的自动修复功能就会出现并修复它。这非常像我们一直以来用于管理服务器的方式。我们一直在使用FBAR(Facebook Auto-Remediation)去管理服务器运维，我们在尽力用服务器上的相同方法和概念实现网络的可管理性。无论出现什么问题，或者说无论修复问题需要采取哪些特定的操作，它们都只针对于该问题。它是一个普适框架，可以检测问题并给出解决问题操作——以及验证这些操作并报告操作。
这里的关键实际上不在于工具，而在于概念。它考虑的是如何简体运营，是指通过各种手段去监控问题的概念——包括SNMP池化或系统日志等，并且能够响应这些事件，能够增加更多的修复操作，并且通知人们关于这些操作的进展。它更多是关于我们是如何实现整个框架的，以及如何让这样一个大规模分布式网络变得更具可管理性。
