Linux Cluster案例分析之 Google的Linux集群解决方案(1)

原文地址 http://www.opendigest.org/article.php/538

 

关于Goolge公司的技术架构一直是技术人员感到神秘，本文探讨了Google数以万计的Linux 集群服务器实现技术！

1. 前言

Google 公司于1998 年由Stanford 大学计算机系的两个博士研究生Sergey Brin 和Larry Page 创立^[1] ；2000 年被《Internet Life 》杂志评为 “ 互联网上最好的搜索引擎 ” ^[1] , 今年被世界品牌实验室评为2005 年世界品牌500 强中的第三名^[2] 。与曾经最有影响的搜索引擎Yahoo 相比，Google 在创立之初在技术和经济资源方面并不具备太多优势，是什么原因导致网络用户放弃Yahoo 、接受Google, 我认为对搜索结果质量评价的正确观点可能是最主要的原因。1998 年期间，网络中的Web 页面数量较小，可以采用手工方法对每一个页面进行人工分类。对一个用户查询请求，可以查全所有的Web 页面，然后反馈所有相关页面链接。然而在1998 年，Sergey Brin 和Larry Page 在《Computer Networks 》杂志上合作发表论文[3] 却提出了不同的观点，他们指出：Google 追求的高质量网络搜索不是拥有尽可能高的查全率，而是反馈给用户的前几十条链接必须具有很高的精确率。基于该理念，Sergey Brin 和Larry Page 在Google 搜索引擎中采用了根据链接数量来判定页面质量的PageRank 算法，该算法后来成为网页评价研究中的一个很著名的算法。由于PageRank 算法的分析和改进工作已有很多相关研究和评论，本文不对此进行讨论。本文只关注Google 服务器技术。

1998 年Google 创立之初，该公司的数据中心放置在Larry 在Stanford 大学的宿舍内，且公司的第一笔资金只有100 万美元^[1] 。从当时的服务器、大型机价格来看，100 万 美元即使全部用来购买服务器，也不可能购买十分先进、高档的服务器或大型机。数据中心放置在学生宿舍，受房间面积限制，大型机及附属设备所需占地面积也不 可能得到满足。同时大型机对降温要求很高，一般学生宿舍也很难得到保障。关于大型机所需供电、降温需求，以及普通房屋供电负荷相关参数可参考文献[4] 。因此根据以上信息，可判断1998 年Google 不太可能采用、也很难有条件采用传统的大型机作为搜索引擎的服务器。

1998 年以后互联网发展速度越来越快，无论是Web 页面数量，还是用户提交的搜索请求数量都在短短几年内增长了数十倍甚至上百倍。Google 搜索引擎却没有因为计算量和存储量高速增长而变得不堪重负，相反它一直争取在0.5 秒时间内处理完成用户请求。如今Google 完成查询请求后，还把查询所耗费的时间反馈给用户。以2005 年4 月21 日上午10 时51 分在华中科技大学校园网内输入 “ 华中科技大学 ” 一词进行检索为例，Google 反馈了917,000 个查询结果，查询时间却仅为0.22 秒。对同一个检索词在不同时间段进行检索，搜索引擎消耗的时间不尽相同，因为处理一个请求所需时间不仅受搜索引擎中待检索页面的数量、大小限制，也与整个系统当前的繁忙程度有关。在0.5 秒内完成数据检索，Google 服务器应该是高性能计算的一个成功典范。作为面向全球用户的商业搜索引擎，由于全球存在时差，Google 必须保证每天24 小时都能正常运行，这对Google 服务器的可用性提出了巨大的挑战。

Google 本是数学中的一个名词，它表示一个十分巨大的数：1 后面跟100 个0 （即10 ）^[3] 。Sergey Brin 和Larry Page 使用Google 作为自己的搜索引擎和公司名的主要原因是希望自己设计的Web 搜索引擎将来能够支持十分巨大的Web 页面检索^[3] 。至2005 年4 月21 为止，Google 中所收集的Web 页面数量已经达到8,058,044,651 张（见Google 页面）。虽然该值与Google 所描述数量还相差甚远，但它成为如今世界上收集Web 页面最多的搜索引擎。

本文内容结构安排如下：第二部分介绍Google 集群（机群）的逻辑结构和物理结构；第三部分讨论Google 的文件系统；第四部分介绍Google 的存储系统和存储策略；第五部分讨论Google 的高可用性和可靠性；第六部分讨论Google 集群在计算和存储中的高并行性。最后根据Google 集群的成功经验对大型机或大型集群开发提出一些思考。

 

2 、Google 集群的逻辑结构和物理结构

为Google 搜索引擎提供硬件支持的不是传统的大型机和服务器，而是技术含量低、廉价的集群技术。至2003 年4 月，Google 集群已集成15,000 台PC 机，成为当时世界上最大的PC 机集群系统^[4] 。文献[5] 中指出预计到2004 年底，Google 集群中的PC 机台数会超过18,000 台，外存储器容量达到5PB 。在2000 年，Google 集群中的CPU 个数（每台PC 机中仅有一个CPU ）只有4,000 个，2003 年初它便增加到30,000 （每台PC 机中有两个CPU ），因此有理由判断如今Google 集群中的CPU 个数可能达到或者超过40,000 个。为了获得Google 集群的最新信息，在本文写作过程中，我曾通过电子邮件向Google Fellow Urs H ö lzle 博士（文献[4] 的通信作者）询问Google 集群当前的PC 机数目、PC 机具体配置等问题，但没有得到回复。以往向国外学者询问论文所涉及的问题，一般都能很快得到详细答复。本文写作过程中，我曾在IEEE, ACM, ScienceDirect 等专业科研论文数据库中进行多次检索，以及在Yahoo, Google 等通用Web 搜索引擎中进行搜索，还查看了Google Lab 主页中列出的论文清单，但获得的最新报道仅仅是2004 年4 月发表的文献[5] 。因此，不妨可猜测：Google 集群中的PC 机数量、PC 机具体配置信息可能是搜索引擎公司的重要商业秘密，不便公开。

文献[3] 早在1998 年就介绍了Google 搜索引擎的逻辑结构如图1 所示。文献[3] 是至今关于Google 搜索引擎逻辑结构描述最为清晰的一篇论文，并且该文献中作者明确表示这也是他们阅读范围内第一篇详细描述Web 搜索引擎结构的论文。由于图1 仅是Google 搜索引擎的逻辑结构图，我们根据图1 判断服务器采到底是采用SMP 构架的服务器，或者是MPP 构架的服务器，还是集群服务器。图1 对理解搜索引擎的逻辑功能模块和检索操作流程很有帮助，对我们在后面分析系统的并行性有帮助。

图1 中同一个功能模块如果出现多次，如crawlers ，则表示该模块存在多个并行的实例。多个并行实例既可以理解为一台机器中的多个进程或线程，也可以理解成在多台PC 机上执行的进程。以crawlers 为例，在Google 原型系统设计之初，可能就是同一台机器上多个线程，而在2000 年以后可能就是多台PC 机上都在运行crawlers 程序。文献[3] 中对每个功能模块都进行详细说明，感兴趣者可直接阅读文献[3] 。

 

图 1 、 Google 的逻辑结构图

图2 是最新的关于Google 服务器系统结构的介绍[4], 该文通信作者Urs H ö lzle 博士由于对Google 公司的发展作出了突出贡献，被授予Google Fellow 荣誉称号。文献[4] 是我们收集到的资料中唯一专门讨论Goolge 集群的系统结构的论文。从1998 年到2003 年，时间相隔五年，但比较图1 和图2 却发现二者并没有本质区别。图1 中的系统结构五年后依然在更复杂、数据和计算更密集的应用环境中继续使用，这验证了图1 中的Web 搜索引擎逻辑功能结构具有很好的可扩展性。

 

图2 Google 的逻辑结构图

关于Google 集群的物理结构最早的全面介绍可能是2001 年出版的计算机系统结构经典教材《Computer Architecture: A Quantitative Approach 》一书^[6] 。文献[6] 中专门把Google 集群作为大型集群的综合性实例，从PC 机内部配置，PC 机在机柜中的布局、集群系统的能耗和散热处理、网络交换设备、存储设备等多个方面进行介绍。由于文献[6] 在计算机系统结构教科书中的权威地位，它的出版使Google 集群得到了大家的广泛关注。由于文献[4] 发表时间比文献[5] 晚两年，以下用文献[4] 中公布的PC 机配置信息来估算Google 集群的计算性能，以及它在TOP500 中的排名位置。

浮点数峰值速率是大型机设计、开发和评价的一个重要指标。TOP500 在对大型机进行性能排名时有两个重要指标，一个是系统的理论浮点数运算速率，另一个是实际的Linpack 测试浮点数运算速率^[7] 。文献[6] 中指出每台PC 机中只有一个奔腾800MHZ 的CPU ，文献[3] 中报道在2002 年底一台PC 机中有两个2G Intel Xeon 的处理器。15,000 台PC 机则意味着Google 集群中有30,000 个并行的CPU 。从因特网上不难查到2GHZ Xero 处理器每个时钟周期内可完成两次浮点数运算，因此可得到2002 年底Google 集群的理论浮点数运算速率为2G ×2 ×30,000=120,000Gflops=120TFlops 。对比2002 年11 月份的全球TOP500 排名列表[7] ，发现其中排名第一的地球模拟器的峰值速率是40,960Gflops ，Google 集群的峰值速率是地球模拟器的近三倍。由于地球模拟器采用向量计算机技术，我们不放把Google 集群与TOP500 中排名第二的ASCI Q 作比较。

ASCI Q 是NASA(National Aeronautics and Space Administration) 第五台高性能计算机，在参加2002 年11 月份的TOP500 测试时它的基本配置是4096 个1.25GHZ 处理器，Linpack 测试速度7727GFlops ，峰值速率为10240Gflops 。ASCI Q 在2002 年没有还没有完全开发完毕，它计划在未来达到11,968 个处理器、12TB 内存以及600TB 的磁盘容量的规模。比较2002 年底的Google 集群与ASCI Q, 发现Google 集群的处理器个数几乎是ASCI Q 的八倍，且每个CPU 的主频较高，理论峰值速率Google 集群是ASCI Q 的十二倍。

鉴于Google 集群是Google 公司自己搭建，且没有采用如MyriNet 价格昂贵通信效率高的大型机专用高速通信网络设备互连。由于无法收集到Google 集群作Linpack 测试的数据，但可以基本肯定的是它作Linpack 测试的可实际运用速率与峰值速率之比要低于地球模拟器和ASCI Q 。因此在Google 集群上作Linpack 测试的实际速率不一定比ASCI Q 高，但由于它的理论峰值太高，即使可利用率低至0.5% （观察TOP500 中的记录，可知该数值一般都大于30% ），它依然在TOP500 的前一百名之内（因为第100 名机器是558GFlops ）。

本文写作过程中，我查阅了2000 年以来TOP500 的十次排名记录，都没有发现Google 集群。参与TOP500 排名的机器是遵循自愿原则（可以在网上填表），可以推测Google 有进入前100 名的实力，却没有上榜，其最大可能就是没有参与TOP500 排名。Google 集群不愿意公布性能数据，从很难检索到关于它系统结构分析的论文也是一个反映。

因此尽管在TOP500 中没有发现Google 集群，但无需质疑的是它无论是在浮点数计算能力还是存储容量方面都是世界上最顶级的计算机之一。某些大型机有很高的性能，且有很高的技术含量，却没有出现在TOP500 名单中的情况其实在我国也有。如众所周知的神威巨型计算机，它不仅具备很高的峰值速率，也具有良好的实际性能，至少在国内它与曙光公司、联想公司开发的巨型机具有相当的性能，然而在TOP500 上一直没有出现它的名字。

国外关于利用集群技术开发大型机的Beowulf 论坛中已有人提出：设计大型机，并注重它能否进入TOP500 以及在TOP500 中的名次只是学术界的一个游戏而已^[9] 。利用集群构架开发的大型机，进入TOP500 其实不能代表太高的技术水平，这应该是近年来关于大型机开发的一个共识。如今国内的大型机开发技术已经达到较高的水平，未来几年无需再把能否进入TOP500 前十名当作十分重要的目标。因为我们过去设计的一些大型机由于应用效率不高，已经造成了不少资源闲置现象，关于该类报道在互联网上比较多。

Google 集群完全能进TOP500 ，但它却不参加排名。Google 集群能否进入TOP500 ，丝毫不影响大家对它高性能、高可用性和高可扩展性的怀疑。作为集群系统的典型例子进入教科书，就是对Google 集群的极大肯定。文献[3] 中作者再三强调Google 集群是由Google 公司自行开发的集群系统，并不采用最先进的技术（一般最先进的技术都比较昂贵）。Google 集群设计和维护中无处不体现强烈的追求最大性价比、实用的特点。Google 集群的设计者不一次性购买很多资源，而是不够时再投入。总之，Google 集群构建和维护过程中始终坚持的实用主义特点，值得我们在大型机设计和购买过程中学习。

 

3 、Google 的文件系统

作为一个巨大的数据检索系统，Google 并没有采用常见的数据库管理系统来管理Web 文件及相关数据。Google 集群如今收集了80 多亿个Web 文档，平均每天执行两亿多次用户查询请求。文件数目太多，则检索速度慢；且每个文件大小相差甚远，容易导致硬盘文件存储管理费用巨大。文献[3] 中介绍，Google 把多个Web 文件汇集到一个巨大的文件中进行存储、管理，当然对一个大文档有相关记录信息。关于大文件说明信息的格式如图3 所示^[3] 。另外因为Web 文件数量太多，所占存储区间太大，Google 采用ZLIB 压缩算法先对原始Web 页面信息进行压缩，然后只存储压缩后的结果。ZLIB 压缩算法对WEB 文档的压缩比为3 ：1 ，因此一个64MB 的大文件，实际上包含192MB 的原始Web 文档。

 

图3 Web 文件的描述信息

Google 集群中的硬盘是普通的IDE 接口的PC 机硬盘，虽然便宜但可靠性较低。Google 集群维护人员在工作中发现，存储器出现故障在Google 集群中并不是少见的异常现象，而是频繁发生。三万个硬盘(15,000 台PC 机，每台机器中有两个硬盘) 同时工作，都不出现故障，用概率计算的方法一算就知道几乎是不可能事件。Google 集群总在频繁的执行文件读操作，硬盘出现故障的可能性就更大。硬盘常出故障的现实环境与传统分布式文件系统设计的基本假设有冲突。Google 集群应该设计具备持续监视、错误检测、容错和自动恢复功能的分布式文件系统。

Google 集群运行过程中还发现了许多来自应用、操作系统、用户、存储器、网络等多方面存在的软件故障。Google 集群中的文件操作有一个特性：每个文件基本上是只执行一次写入操作，以后都是频繁执行只读操作，随机写操作几乎不发生。当crawlers 从网络中采集到一个Web 文件，在内存中完成相关处理后，就写入到一个大文件中，以后每次查询只是执行一次数据读取操作。银行、电子商务等常见的大型数据管理系统中则没有这个特性。针对来自应用领域的特征，Google 公司的研发人员在分布式文件系统开发中采用了不同于传统分布式文件系统I/O 操作的假设。

Google 开发了公司内部的分布式文件系统Google File System （GFS ），该文件系统的系统结构如图4 所示。GFS 中包括单一的GFS Master ，多个GFS chunkserver 。文献[3] 和文献[10] 发表时间相差五年，但不难判断文献[3] 中的大文件就是文献[10] 中的chunk 。图4 表示GFS 不是完全在操作系统层设计的分布式文件系统，而是在已有的Linux 文件系统之后再封装的分布式文件系统，因此它依赖传统的Linux 文件系统。GFS master 中存储了三种重要的元数据：文件和chunk 的命名空间、文件到chunk 的映射表以及chunk 及其备份的位置信息（为了提高文件存储的可靠性，GFS 中对同一份数据一般存储在三台不同的主机上。对一个chunk 而言，它就有两个分布在其它PC 机上的备份）。GFS chunkserver 中每个chunk 大小为64MB ，关于每个chunk 大小的具体数值选择并不是随意的，而是很有技巧。关于64MB 大小的chunk 设置的优点和缺点在文献[9] 中有很详细的讨论。

 

图4 Google 文件系统的结构

GFS 中执行一个简单的读数据操作工作流程如下：首先，应用客户端把文件名和文件在一个chunk 中的偏移量转换成一个包含该文件数据的chunk 索引；然后，客户端向GFS master 发送请求，请求中包括所需要的文件名以及chunk 索引。当GFS master 收到请求并通过chunk 映射表映射后，它向客户端作出响应，反馈给客户端相应的chunk 句柄以及该chunk 备份的位置。客户端收到反馈信息后，将以文件名和chunk 索引为关键词进行缓存。有了所需文件chunk 索引和位置信息，客户端一般从多个chunk 服务器中选择一个离自己最邻近的chunkserver 发出数据访问请求。一般数据访问存在空间局部性，以后如果该应用客户端需要访问同一chunkserver 中的数据，它不再向GFS server 发送请求，而是直接向chunk 服务器发送数据读取请求。关于GFS 更详细的讨论在此不再进行更深入讨论，如果希望进一步了解可以参考文献[9] 。