摘要：
大量服务提供商投资越来越多的更大数据中心来保证基础计算需求以支持他们的服务。因此,研究人员和行业从业者都集中了大量的努力设计网络结构有效互连和管理流量以保证这些数据中心的性能。不幸的是,数据中心运营商通常对于分享他们的应用程序的实际需求有所保留,使得评估任何特定设计的实用性具有挑战性。
此外,大规模负载信息的文献有限,无论是好是坏,到目前为止由单个数据中心运营商提供的用例并不普遍。在本文中,我们报告的网络流量中观察到一些Facebook的数据中心。Facebook运行Hadoop等传统数据中心服务,其核心Web服务和支持缓存基础结构表现出的行为与那些在文献中报道的形成了对照。我们报告对比Facebook的数据中心的网络流量位置、稳定性和可预测性,评论他们对网络结构,流量管理,交换机设计的影响。
介绍:
我们发现文献中流量的研究并不能完全代表Facebook的需求。这种情况尤其严重当考虑新型网络结构、流量管理和交换机设计。
比如，数据中心连接的拓扑结构的最好选择取决于主机间的联系方式。然而，因为缺乏具体的数据，研究者经常根据最坏的情况设计一个all-to-all的流量模型，即是主机之间的联系都是依照相同的频率和强度，而这并不值得。如果需求可以被预计或者保持稳定在合理的时间段内，不均匀的结构是可行的，即连接数据中心的不同部分用不同的方式，通过混合设计包括光纤和无线连接。
而另外一种提升性能的方式是提升交换机本身的性能，特别是,有些人提出简单修改像减少缓冲,端口数,交换机各层结构的复杂性,也有人提出,取代传统交换用circuit或混合设计,利用流量需求的局部性（locality）,持久性和可预测性。更极端的是，基于主机的解决方案提倡直接连接主机。显然，无论如何，这些方案的价值取决于它们的负载。
在之间的研究里，一些建议不能被很好的评估因为缺乏大规模数据中心。几乎所有的先前的研究大规模数据中心的研究考虑的是微软数据中心。而Facebook数据中心和微软的有很多相似的地方，比如避免虚拟机，它们也有一些不同。而一些关键的不同，会导致不同的结论，我们描述这些差异并解释背后的原因。
我们的研究发现对重要结构的影响包括:
流量既不是局部框架（rack-local）也不是全局（all-to-all）的;局域性取决于服务而不是总是稳定的无论时间区间的单位是秒还是天。高效的结构可能受益于变量程度的超额认购和框架内的带宽小于通常部署。
许多流存在周期长但不是很大。负载均衡有效地分配流量;流量需求相当稳定甚至超过次秒级时间间隔。因此,大流量对象并不比中值流大很多,大流量对象集合改变的很快。突如其来的大流量对象在较长时间是频繁的而不是流量很大,可能混淆许多流量管理方法。
包是小(non-Hadoop流量的平均长度小于200字节),不显示on/off到来的行为(即是连续的到达)。服务器与100台主机和机架并发连接(在5ms间隔),但大多数的流量往往是注定(很少)10台机架。
文章的第二节主要讲以前的研究数据中心的流量的主要发现。主要体现在三个方面：第一，流量是局部框架的（rack-local），即80%的服务器的流量在框架内。第二，流量是突发的而且不稳定的在各种各样的时间尺度内。最后，包的的大小有两种，要么最大（MTU），要么很小（TCP ACK segment）。
第三节详细描绘了Facebook的数据中心,包括它们的物理结构（Facebook’s 4-post cluster design）、支持的服务（通过HTTP请求是如何服务）和收集数据的方法（包括Fbflow和Port mirroring）。
数据中心连接的设计,规模,甚至技术的合适程度在很大程度上依赖于其流量的需求。在第四节中,文章量化的流量的强度,局域性,和稳定性在Facebook数据中心的三个不同类型的集群（即Hadoop, Frontend machines serving Web requests和 Cache）中。
之前的研究表明,数据中心流量的稳定性取决于观测的时间尺度。在第5节中,我们分析Facebook的流量在合适的时间尺度下,以期了解各种流量管理和负载平衡方法可能会在这种情况下的适用性。
第六节主要描绘了top-of-rack交换机设计的各个方面。特别是,我们考虑包的大小和到达过程,以及到任何特定的终端主机并发的目的地的数量。此外,我们测试短时间内突发性的影响及其它对交换缓冲的影响。
总结：
Facebook的数据中心网络支持各种不同的服务,表现出不同的流量模式。我们发现几个服务与文献中的大幅偏离。不同的应用程序,结合Facebook的数据中心网络规模(成百上千的节点)和速度(10-gbps边缘链接)导致工作负载和以前公布的数据集的多种方式做对比。因为文章篇幅的限制，我们不能提供一个详尽的解释,我们描述可能对拓扑结构,流量管理,top-of-rack交换机设计的影响。
我们的方法强加一些限制在这项研究的范围内。使用终端主机捕获和时间戳数据包介绍了基于调度变化时间戳精度。此外,我们一次只能从几个主机捕获流量。同时,这些约束阻止我们评估影响像incast或微爆发,指出作为贡献者的可怜的应用程序的性能。此外,每个主机包转储必然是anecdotal和特别的,依赖同一框架内一个未使用的主机的存在作为目标。当Fbflow部署在数据中心时,它所提供的庞大的测量数据提出了另一个挑战，即数据处理和数据保存。我们因此认为有效的网络监视和分析是一个持续的和不断发展的问题。