Google集群架构..docxVIP

Google集群架构为了能够支持可扩展的并行化，google的网络搜索应用让不同的查询由不同的处理器处理，同时通过划分全局索引，使得单个查询可以利用多个处理器处理。针对所要处理的工作负载类型，google的集群架构由15000个普通pc机和容错软件组成。这种架构达到了很高的性能，同时由于采用了普通pc机，也节省了采用昂贵的高端服务器的大部分花费。?很少有网络服务的单个请求像搜索引擎占用那样多的计算资源。平均来看，在google上的每次查询需要读取数百m的数据耗费数10亿的cpu指令循环。为了能够支持峰值在每秒数千次请求流，需要与世界上最大的超级计算机规模相当的硬件设施。通过容错性软件将15000个普通pc机联合起来，提供了一种比使用高端服务器更廉价的解决方案。?本文我们将介绍google的集群架构，讨论那些影响到设计方案的最重要的因素：能效和性价比。在我们的实际操作中，能效实际上是一个关键的度量标准，因为数据中心的电力是有限的，因此电力耗费和制冷成为运作中的关键。?我们的应用本身可以很容易进行并行化：不同的查询可以运行在不同的处理器上，同时全局索引也划分的使得单个查询可以使用多个处理器。因此，处理器的性价比比峰值性能变得更重要。同时，google的应用是面向吞吐率的，可以更有效的利用处理器提供的并行化，比如并行多线程(SMT)，或者多核处理器(CMP)。??Google架构概览?Google的软件架构来源于两个基本的观点。首先我们需要在软件层面提供可靠性，而不是通过硬件，这样我们就可以使用普通的pc构建廉价的高端集群。其次，我们不断的裁剪设计是为了达到最好的总体请求吞吐率，不是为了提高服务器的峰值响应时间， 因为我们可以通过并行化独立的请求来控制响应时间。?我们相信使用不可靠的廉价pc来构建可靠的计算设施可以达到最好的性价比。通过在不同的机器上备份服务，以及自动化的故障检测和错误处理，为我们的环境提供软件级的可靠性。这种软件级的可靠性在我们的系统设计中几乎随处可见。检查一下一次查询处理的控制流程，有助于理解这种高级的查询服务系统，同时也有助于对于可靠性考虑的理解。?Google的一次查询?当用户在google中输入一次查询，用户浏览器首先通过DNS进行域名解析，将/转换为ip地址。为了对查询可以进行更有效的处理，我们的服务由分布在世界各地的多个集群组成。每个集群大概有数千个机器，这种地理上的分布可以有效的应付灾难性的数据中心失败比如地震，大规模的停电。基于DNS的负载平衡系统，会计算用户的与每一个物理集群地理上的距离来选择一个合适的物理集群。负载平衡系统，需要最小化请求往返时间，同时要考虑各个集群的可用容量。?用户浏览器然后给这些集群中的一个发送一个http请求，之后，对于该集群来说，所有的处理都变成了本地化的。在每个集群中有一个基于硬件的负载平衡器监控当前可用的google web servers(GWS)集合，并在这个集合上将本地的请求处理进行负载平衡。收到一个请求之后，GWS协调这个查询的执行，并将结果格式化为html语言。图1表示了这个过程。??查询执行由两个主要阶段组成，第一个阶段，索引服务器查阅倒排索引(将每个查询词映射到匹配的文档列表)。索引服务器然后决定相关的文档集合，通过对每个查询词匹配的文档列表求交集，为每个文档计算出一个相关性的分值，这个分值决定了在输出结果中的排序。?搜索的过程非常具有挑战性，因为需要处理海量数据：原始网页文档通常具有数十T的未压缩数据，从原始数据中导出的倒排索引本身也有好几T的数据。幸运的是，通过将索引划分到不同的片段，可以将搜索高度并行化，每个片段具有从全布索引中随机选择的一个文档子集。一组机器负责处理对于一个索引片段的请求，在整个集群中每个片段都会有这样的一组机器与之对应。每个请求通过中间负载平衡器选择组内机器中的一个，换句话说每个查询将会访问分配到每个片段的一台机器(或者是一组机器的子集)。如果一个片段的备份坏了，负载平衡器将会避免在查询时使用它，我们的集群管理系统的其他组件将会尝试修复它，实在不行就用另一台机器来取代它。停工期间，系统的容量需要减去那台坏掉的机器所代表的容量。然而，服务仍然是未中断的的，索引仍然是可用的。?第一阶段的查询执行最终输出一个排过序的文档标识符列表。第二阶段则通过获取这个文档列表，然后计算出所有文档的标题和url以及面向查询内容的文档摘要。文档服务器处理这项任务，从硬盘中获取文档，抽取标题以及查询关键词在文档中的出现片段。像索引查找阶段，这里的策略也是对文档进行划分，主要通过：随机分布文档到不同的小片段；针对每个片段的处理具有多个服务器作为备份；通过一个负载平衡器分发请求。文档服务器必须能够访问一个在线的低延时的整个网络的网页的副本。实际上由于对于这个