MaglevAFastandReliableSoftwareNetworkLoadBalancer

Maglev:AFastandReliableSoftwareNetworkLoadBalancerAbstractMaglev是谷歌的网络负载均衡系统。它是一个大型的运行在商业服务器上的分布式软件系统。不同于传统的硬件网络负载均衡设备，它不需要一个专门的物理机部署，其容量可以通过添加或删除服务器容易调整。Maglev通过等价多路径（ECMP）均匀分发网络路由包；每个Maglevmachines相匹配的数据包对应的服务并散布均匀的服务端点。为了适应高和不断增长的传输，Maglev是专为数据包处理性能进行了优化。一个单一的Maglev机能够用小包10Gbps链路。Maglev还配备了一致的散列和连接跟踪功能，以尽量减少意外故障和故障对面向连接的协议的负面影响。自2008以来，Maglev一直在为谷歌的交通服务。它持续了谷歌服务的快速全球增长，它也为谷歌云平台提供了网络负载平衡。1.Introduction谷歌是全球互联网流量的主要来源[29,30]。它提供了数百个面向用户的服务，除了许多更多的服务托管在快速增长的云平台[6]。受欢迎的谷歌服务，如谷歌搜索和Gmail从世界各地收到查询每秒几百万，放在基本服务基础设施的巨大需求。为了满足这种高需求在低延迟，谷歌服务是托管在一个多个服务器位于世界各地的多个集群。在每个集群中，它是必不可少的，均匀地分配流量负载在这些服务器上，以有效地利用资源，使没有一个单一的服务器超载。因此，网络负载平衡器的形式，谷歌的生产网络基础设施的重要组成部分。网络负载平衡器通常是由多个设备逻辑上位于路由器和服务端点（通常是TCP或UDP服务），如图1所示。负载均衡器负责匹配的每个数据包转发到相应的服务器。网络负载平衡器通常被实现作为专用的硬件设备[1，9，3，5，12，2，13]，这种方法有几个局限性。1）他们可扩展性通常由最大容量限制一个单一的单位，使它不可能跟上随着谷歌的流量增长。2）他们不满足谷歌的高可用性的要求。虽然经常成对部署以避免单点故障，他们只提供1+1冗余。3）他们缺乏快速迭代所需的灵活性和可编程性，因为它通常是困难的，如果不是不可能的，修改硬件负载平衡器。4）他们是昂贵的升级。增加硬件负载平衡器的能力通常包括购买新的硬件以及作为物理部署。因为所有这些限制，我们调查和追求替代解决方案。托管在集群充满商品服务器的所有服务，我们可以建立网络负载平衡器作为一个分布式的软件系统对这些服务器的运行。一个软件负载平衡系统比它的硬件对应的许多优点。我们可以解决可扩展性，采用扩展模型，在负载平衡器的容量可以通过增加系统中的机器数的改进：通过ECMP转发，流量可以均匀地分布在所有的机器。可用性和可靠性提高，因为系统提供了n+1冗余。通过控制整个系统本身，我们可以快速添加、测试和部署新的功能。同时，对负载均衡器本身部署大大简化：系统只使用现有的服务器集群内。我们也可以将多个服务之间的负载平衡器的碎片以相同的集群实现性能隔离。尽管所有的好处，一个软件网络负载均衡器的设计与实现是非常复杂和具有挑战性的。首先，系统中的每一台机器必须提供高吞吐量。让N是系统中的机器的数量，T是一台机器的最大吞吐量。该系统的最大容量是N×T.如果不够高，它将不为系统提供足够的所有服务[22]能力。系统作为一个整体也必须提供连接持久性：属于同一个连接的数据包应该总是指向同一个服务端点。这保证了服务质量，集群是非常动态的，失败是很常见的[23，40]。本文介绍了Maglev，一个快速，可靠的软件网络负载平衡系统。Maglev一直是谷歌的前端服务基础设施，自2008以来的一个关键组成部分，而目前承载几乎所有的谷歌的传入的用户流量。利用近年来高速服务器网络技术[18，41，35，31]，每个Maglev能够实现线速的小数据包吞吐量。通过一致的散列和连接跟踪，Maglev提供了可靠的数据包传输，尽管频繁的变化和意想不到的失败。虽然本文中所描述的一些技术已经存在多年，本文展示了如何使用这些技术来建立一个操作系统。本文的主要贡献是：1）介绍了Maglev的设计和实现，2）在全球范围内运营的Maglev的经验，3）展示了Maglev的能力，通过广泛的评估。2.SystemOverview本节提供Maglev网络负载平衡器是如何工作的。我们给谷歌的前端服务体系结构作了简要介绍，接着说明Maglev系统配置。2.1FrontendServingArchitectureMaglev是部署在谷歌的前端服务的地点，包括不同大小的簇。为了简单起见，我们只专注于在较小的集群在本文中的设置，并简要地描述了较大的集群设置如下。图2显示了谷歌的前端在小集群安装服务体系结构概述。谷歌的所有服务都有一个或多个虚拟IP地址（VIPs）。一个VIP是不同于一个物理IP，它没有被分配到一个特定的网络接口，而是由多个服务端点背后的Maglev。Maglev结合每个VIP隐匿一套后台服务提供在BGP路由器；反过来路由器发布VIP到谷歌的骨干网。聚合VIP网络发布到互联网使其全局访问。Maglev只处理IPv4和IPv6的流量，下面的讨论同样适用。当一个用户试图访问一个谷歌服务，她的浏览器首先DNS查询，得到一个响应（可能缓存）来自谷歌的一个权威DNS服务器。DNS服务器将用户附近的前端位置，考虑到她的地理位置，并返回一个VIP属于反应[16]到选定的位置。浏览器将尝试建立一个新的连接到VIP。当路由器接收到一个VIP包，它将数据包通过ECMP转发到一个Maglev集群中的机器，因为所有的Maglev宣布VIP是相同的。当Maglev机器接收数据包，选择从服务端点与VIP相关设定一个终点，并且封装的数据包使用通用路由封装（GRE）与外部IP头注定的终点。当数据包到达选定的后台服务器，并脱壳。响应包，putintoanIPpacketwiththesourceaddressbeingtheVIPandthedestinationaddressbeingtheIPoftheuser。我们直接使用服务器返回（DSR）发送响应直接到路由器，Maglev不需要处理返回的数据包，这是典型的大。本文重点介绍的传入用户流量的负载平衡。DSR协议的实现是超出了本文的范围。大型集群的安装更为复杂：在建规模的集群，我们要避免把Maglev机作为路由器在layer-2领域，所以硬件encapsulators部署在路由器的后面，管道包从路由器到Maglev机。2.2MaglevConfiguration在上一小节介绍，Maglev是负责宣布VIPs到路由器和转发VIP流量到后台服务器。因此，每一个Maglev机包含一个controller和forwarder如图3所示。两个controller和forwarder获知VIP信息是从配置中，这是从文件中读取或接收从外部系统通过RPC。在每台Maglev上，controller定期检查forwarder的健康状况。根据结果，controller决定是否宣布或撤回所有VIPsviaBGP。这将确保路由器只转发数据包到健康的Maglev。Maglev接收的所有VIP数据包由forwarder处理。在forwarder，每个VIP配置一个或多个后端池。除非另有规定，Maglev的后端服务。后端池可能包含后台服务器的IP地址；它也可以递归地包含其他后端池，所以通常后端不需要指定重复。每个后端池，根据其具体要求，与一个或多个健康的检查方法，其所有的后端验证相关；包只被转发到后端的健康的后台。相同的服务可以被包含在多个后端池，健康检查是重覆的IP地址来避免额外的开销。在更改forwarder状态之前，forwarder的配置管理器负责解析和验证配置对象。所有的配置更新将自动。在同一集群内的Maglev机器的配置可能会暂时停止，同步由于在配置推送或健康检查的延迟。然而，consistenthashing将使Maglevs和后台池之间的链接震荡，大部分成功，在很小的窗口期。同一个集群部署多组Maglevs分片是可能的。不同的Maglev碎片配置不同和服务于不同类型的VIP。分片是用于提供性能隔离和保证服务质量。它也有好处，测试新的功能，而不干扰正常的交通。为简单起见，我们假设在本文中只用一个分片。3.ForwarderDesignandImplementationforwarder是Maglev的一个重要组成部分，因为它需要快速可靠地处理大量的数据包。本部分介绍了Maglevforwarder的关键模块的设计和实现细节，以及设计背后的理论基础。3.1OverallStructure图4说明了Maglevforwarder的整体结构。forwarder从网卡接收数据包（NIC），改写了他们适当的GRE/IP报头，然后将它们发送到网卡。在这个过程中不涉及到linux的内核。通过网卡接收到的数据包首先交给forwarder的steeringmodule进行处理，计算出5-tuplehash的数据包，并将它们分配给不同的hASH1接收队列根据散列值。每个接收队列是连接到一个包重写线程。包线程首先试图将每个包匹配到配置的VIP。这一步骤过滤掉不需要的数据包，不针对任何VIP。然后重新计算5-tuplehash，查找连接跟踪表的哈希值（见3.3节）。我们不重用从转向模块的哈希值，以避免交叉线程同步。连接表存储最近连接的后端选择结果。如果找到一个匹配和选定的后端仍然是健康的，结果是简单地重复使用。否则，线程协商一致性哈希模块（包括3.4节）并选择一个新的包后端；然后增加到连接表中。如果没有可用的后端，一个数据包被删除。forwarder保持每包线程的一个连接表，以避免访问争用。在后台选择后，分组线程封装适当的GRE/IP报头发送给连接传输队列。muxingmodule然后发送到所有传输队列和传递数据包的网卡。steering模块执行5-tuplehashing替代round-robin的原因有两个：首先，它有助于降低数据包重新排序的概率在一个连接的不同处理不同包线速度造成的。第二，与连接跟踪，forwarder只需要执行后端选择一次为每个连接，节省时钟周期，并消除了不同的后端选择结果的可能性，造成的种族条件与后端健康更新。在极少数情况下，一个给定的接收队列满时，steering模块回到轮转调度和传播到其他可用的队列的数据包。这种可依赖的机制是特别有效的，在处理大规模的峰值包请求时，针对同一个5-tuple。（The5-tupleofapacketreferstothesourceIP,sourceport,destinationIP,destinationportandIPprotocolnumber.）3.2FastPacketProcessingMaglevforwarder需要尽快处理数据包，以成本有效地扩大谷歌的服务能力要求。今天，我们的工程师将它转发数据包的线速–通常10Gbps在谷歌集群。这意味着813kpps（每秒数据包）1500字节的IP数据包。然而，我们的要求是更严格的：我们必须处理非常小的数据包，有效地，因为传入的请求通常是小的。如果IP数据包的大小平均为100字节，forwarder必须能够处理数据包在9.06mpps。这部分介绍了我们采用的关键技术，我们达到和超过这个数据包处理速度。Maglev是一个用户空间应用程序，运行在商业的Linux服务器上。由于linux内核的网络堆栈是相当昂贵的计算，而Maglev不需要任何的的的堆栈的功能，他设计用来可让Maglev绕过linux内核，来完成数据包处理。从网卡硬件的支持，我们已经开发了一种机制去移动网络包，在forwarder和网卡之间，没有任何内核的参与，如图5所示。当Maglev启动时，预分配一个包池，网卡和forwarder之间共享。无论是steeringandmuxing模块维护一个指针指向的数据包池包环形队列。steering和muxing模块保持三点特性。在接收端，网卡的地