云计算Google的技术构架.doc_第1页
云计算Google的技术构架.doc_第2页
云计算Google的技术构架.doc_第3页
云计算Google的技术构架.doc_第4页
云计算Google的技术构架.doc_第5页
已阅读5页,还剩21页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

云计算Google的技术构架一、前言 计算无疑是今年IT 技术界最热点的关键词之一。从谷歌趋势分析来看,国际上Cloud computing 是从2007 年中期开始成为整个业界关注的重点,在中国云计算是从2008 年开始成为中国IT 界和通信界关注的核心。特别是,当中国移动2008 年开始关注 计算,并推动 中国移动相关的业务支撑系统、业务软件平台开始向 计算的平台迁移。使得整个中国IT 界、通信界的相关产业力量更加关注 计算,同时大家也开始意识到了 计算确实可以大大 的节省海量计算的总体拥有成本。 cloud computing 云计算 当业界谈到 计算的时候,都会第一个想到谷歌 Google。我们日常在使用的Google Search,Google Earth,Goolge Map,Google Gmail,Google Doc 等等业务都是Google 基于自 己 计算平台来提供的。Google 也是通过云计算的方式,大量的降低计算成本,使之业务 更具有竞争力。 Google 原先企业初期阶段,获得的投资有限,只能自己攒机,但是很差的机器不可能 发挥服务器的性能和稳定性,于是只有去想该如何提高可靠性,如何利用很多破烂机器获 得更高的性能。这就有了云计算的雏形。 今天我们都知道Google 的规模,而如果我们不去认清 计算的强大,我们就不知道互 - Page 2-联网的未来和规则。Google 在98 年的时候被迫发现了这一规则,然后我们看到了聚合的力 量,今天微软、IBM、雅虎、百度、亚马逊这些企业看到了规则,于是开始进入 计算领域。 所以我们研究 计算,可以系统剖析一下Google 的技术构架,这对于我们搭建自己自身的 计算平台有比较好的借鉴意义和标杆意义! 二、Google 的整体技术构架说明 由于Google 没有官方发布一个自身的技术构架说明。本文主要的信息都来自互联网中 对于Google 网络技术构架的分析,大量信息来自 。 Google 最大的IT 优势在于它能建造出既富于性价比(并非廉价)又能承受极高负载的高 性能系统。因此Google 认为自己与竞争对手,如亚马逊网站(Amazon)、电子港湾(eBay)、微 软(Microsoft)和雅虎 (Yahoo)等公司相比,具有更大的成本优势。其IT 系统运营约为其他互 联网公司的60%左右。 同时Google 程序员的效率比其他Web 公司同行们高出50%100%,原因是Google 已 经开发出了一整套专用于支持大规模并行系统编程的定制软件库。 从整体来看,Google 的 计算平台包括了如下的技术层次。 1)网络系统:包括外部网络(Exterior Network) ,这个外部网络并不是指运营商自己的 骨干网,也是指在Google 计算服务器中心以外,由Google 自己搭建的由于不同地区/ 国 家,不同应用之间的负载平衡的数据交换网络。内部网络(Interior Network),连接各个Google 自建的数据中心之间的网络系统。 2)硬件系统:从层次上来看,包括单个服务器、整合了多服务器机架和存放、连接各 个服务器机架的数据中心(IDC)。 3)软件系统:包括每个服务器上面的安装的单机的操作系统经过修改过的Redhat Linux。 Google 计算底层软件系统 (文件系统GFS、并行计算处理算法 Mapreduce、并行数据库 Bigtable,并行锁服务Chubby Lock, 计算消息队列GWQ ) 4)Google 内部使用的软件开发工具 Python、Java、C+ 等 - Page 3- 5)Google 自己开发的应用软件Google Search 、Google Email 、Google Earth 三、Google 各个层次技术介绍 1、Google 外部网络系统介绍 当一个互联网用户输入 的时候,这个URL请求就会发到Google DNS 解 析服务器当中去,那么Google 的DNS 服务器就会根据用户自身的IP 地址来判断,这个用 户请求是来自那个国家、那个地区。根据不同用户的IP 地址信息,解析到不同的Google 的 数据中心。 进入第一道防火墙,这次防火墙主要是根据不同端口来判断应用,过滤相应的流量。如 果仅仅接受 浏览器应用的访问,一般只会开放80 端口http,和443 端口https (通过SSL 加密)。将其他的来自互联网上的非Ipv4 /V6 非80/443 端口的请求都放弃,避免遭受互联 网上大量的DOS 攻击。 据说Google 使用了思杰科技(Citrix Systems)的Netscaler 应用交换机来做web 应用 - Page 4-的优化。NetScaler 可将Web 应用性能加速高达5 倍。使用高级优化技术如动态缓存时, 或者当网络延迟或数据包丢失增大时,性能增益会更高。这里提到的http multiplexting 技术 是可以是进行 http 的每个session 分解开。从不同的后端服务器 (缓存)来获取内容,这 样可以大大提升web http 性能,同时有效降低后端web 应用服务器的处理和联接压力。 在大量的web 应用服务器 (Web Server Farm)前,Google使用反向代理(Reverse Proxy ) 的技术。反向代理(Reverse Proxy )方式是指以代理服务器来接受internet 上的连接请求, 然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给internet 上请求 连接的客户端,此时代理服务器对外就表现为一个服务器。 Google 使用的是Squid Cache 的软件方式来实现反向代理应用的,Squid Cache 一个流 行的自由软件(GNU 通用公共许可证)的代理服务器和Web 缓存服务器。Squid 有广泛的 用途,从作为网页服务器的前置cache 服务器缓存相关请求来提高Web 服务器的速度。 在Google web 应用服务器需要调用Google 内部存储的信息和资源的时候,在通过一个 防火墙进入内部的网络,来访问其他的基于自身GFS II 系统的应用服务和数据库。 2、Google 内部网络架构介绍 Google 自己已经建设了跨国的光纤网络,连接跨地区、跨国家的高速光纤网络。内部 网络已经都是 Ipv6 的协议在运行。网络中的路由交换设备主要还是来自Juniper, Cisco, Foundry, HP 这四家公司。内部网关协议 (IRP)是基于OSPF(开放式最短路径优先)进行修改 - Page 5-的。在每个服务器机架内部连接每台服务器之间网络是100M 以太网,在服务器机架之间连 接的网络是1000M 以太网。 在每个服务器机架内,通过IP 虚拟服务器(IP Virtual Server)的方式实现传输层负载Linux 内核内的平衡,这个就是所谓四层LAN 交换。IPVS 使一个服务器机架中的众多服务成为基 于 Linux 内核虚拟服务器。这就像在一堆服务器前安装一个负载均衡的服务器一样。当 TCP/UDP 的请求过来后,使一 服务器可以使用一个单一的IP 地址来对外提供相关的服务 支撑。 3、Google 的大规模IDC 部署战略 Google 应该是目前世界上存储信息最多的企业了。而且还在一直不断的致力于将传统 信息仅可能的数字化。将这样海量的信息进行存储、进行处理。就需要大量的计算机服务器。 为了满足不断增长的计算需求。Google 很早就进行了全球的数据中心的布局。由于数据中 心运行后,面临的几个关键问题的就是充足电力供应、大量服务器运行后的降温排热和足够 的网络带宽支持。所以Google 在进行数据中心布局的时候,就是根据互联网骨干带宽和电 力网的核心节点进行部署的,尽快考虑在河边和海边,想办法通过引入自然水流的方式来降 低降温排热的成本。 达拉斯(Dalles)是美国俄勒冈州北部哥伦比亚河 (Columbia river)岸上的一个城市, Google 在Dalles 的边上拥有的30 英亩土地,他们在这里建立了几乎是世界上最大,性能最 好的数据中心。四个装备有 大空调设施的仓库内,放置着数万台Internet 服务器,这些服 务器每天处理着数十亿条Google 网站传递给世界各个角落的用户的数据。 - Page 6- Google 达拉斯这个数据中心占用了附近一个180 万千瓦(1.8GW)水力发电站的大部分 电力输出。对比来看目前中国长江三峡水电站的额定功率是1820 万千瓦。 目前Google 已经在全球运行了38 个大型的IDC 中心,超过300 多个GFSII 服务器集 ,超过 80 万台计算机。从服务器集 部署的数量来看美国本地的数量第一,欧洲地区第 二,亚洲地区第三,在南美地区和俄罗斯各有一个IDC 数据中心。 目前Google 在中国的北京和香港建设了自己的IDC 中心,并部署了自己的服务器农场。 其中目前还在进行建设的第38 个IDC 是在奥地利的林茨市(Linz)附近的Kronstorf 村。 未来,Google 还准备在中国台湾地区、 来西亚、立陶宛等地区来进行部署。从目前 的Google 数据中心部署的情况来看,中东和非洲地区目前Google 还没有建设计划。 下图是Google 的IDC 中心/服务器农场 (Google Server Farm)的全球分布图。 - Page 7- Google 自己设计了创新的集装箱服务器,数据中心以货柜为单位, 标准谷歌模块化集装箱装有30 个的机架,1160 台服务器,每台服务器的功耗是250KW。 (Google2009 年公布的信息)。下图是Google 模块化集装箱的设计示意图。这种标准的 集装箱式的服务器部署和安装策略可以是Google 非常快速的部署一个超大型的数据中心。 大大降低了对于机房基建的需求。 4、Google 自己设计的服务器机架构架 Google 的服务器机架有两种规格40U/80U 的。这主要是因为原来每个服务器刀片是1U - Page 8-高,新的服务器刀片都是2U 高的。据说Google 后期使用的服务器主板是台湾技嘉,服务器 主板可以直接插入到服务器机架中。 5、Google 自己设计的PC 服务器刀片 绝大部分企业都会跟诸如戴尔、惠普、IBM 或Sun 购买服务器。不过Google 所拥有的 八十万台服务器都是自己设计打造来的,Google 认为这是公司的核心技术之一。Google 的 硬件设计人员都是直接和芯片厂商和主板厂商协作工作的。 2009 年,Google 开始大量使用2U 高的低成本解决方案。标准配置是双核双通道CPU, 据说有Intel 的,也有AMD 的在使用。8 个2GB 的DDR3,支持ECC 容错的高速内存,采用 RAID 1 的磁盘镜像,来提升I/O 效率。磁盘采用SATA,单机存储容量可以达到1-2TB 。每个 服务器刀片自带 12V 的电池来保证在短期没有外部电源的时候可以保持服务器刀片正常运 行。Google 的硬件设计人员认为,这个自带电池的方式,要比传统的使用UPS 的方式效率 更高。 一般数据中心多倚赖称为不间断电源系统(UPS)的大型中控机型,这基本上算是大电池, - Page 9-会在主电力失效而发电机还来不及启动时,暂时协助供电。Google 的硬件设计人员表示, 直接把电力内建到服务器比较便宜,而且成本能直接跟服务器数量相符合。“这种作法比使 用大型UPS 节省得多,如此也不会浪费多余的容量。” 效率也是另一个财务考量因素。大型UPS 可达92-95%的效率,这意味着许多电力还是 被浪费掉了。但Google 采用的内建电池作法却好很多,Google 相关人员表示,“我们测量的 结果是效率超过99.9% 。 年份 Google 服务器刀片硬件配置 1999/2000 PII/PIII 128MB+ 2003/2004 Celeron 533, PIII 1.4 SMP, 2-4GB DRAM, Dual XEON 2.0/1-4GB/40-160GB IDE - SATA Disks via Silicon Images SATA 3114/SATA 3124 2006 Dual Opteron/Working Set DRAM(4GB+)/2x400GB IDE (RAID0?) 2009 2-Way/Dual Core/16GB/1-2TB SATA 6、Google 服务器使用的操作系统 Google 服务器使用的操作系统是基于Redhat Linux2.6 的内核,并做了大量修改。修改 了GNU C 函数库(glibc),远程过程调用 (RPC),开发了自己的Ipvs,自己修改了文件系统,形 成了自己的GFSII,修改了linux 内核和相关的子系统,是其支持IPV6。采用了Python 来作为主要 的脚本语言。 下表是一些大型互联网公司使用的操作系统对比。 网站 操作系统 Web 应用服务器 Google Linux Google Web Server - Page 10- 微软 Windows server IIS ebay Windows server IIS 阿里巴巴 Linux Apache 新浪 Free BSD Apache 百度 Linux Apache 163 Linux Apache 搜狐 Sco Unix Apache 7、Google 计算文件系统GFS/GFSII GFSII cell 是Google 文件系统中最基础的模块。任何文件和数据都可以利用这种底层模 块。GFSII 通过基于 Linux 分布存储的方式,对于服务器来说,分成了主服务器 (Master Servers)和块存储服务器(Chunk Servers),GFS 上的块存储服务器上的存储空间以64MB 为 单位,分成很多的存储块,由主服务器来进行存储内容的调度和分配。每一份数据都是一式 三份的方式,将同样的数据分布存储在不同的服务器集 中,以保证数据的安全性和吞吐的 效率提高。当需要对于文件、数据进行存储的时候,应用程序之间将需求发给主服务器,主 服务器根据所管理的块存储服务器的情况,将需要存储的内容进行分配,并将可以存储的消 息(使用那些块存储服务器,那些地址空间),有应用程序下面的GFS 接口在对文件和数据 直接存储到相应的块存储服务器当中。 块存储服务器要定时通过心跳信号的方式告知主服务器,目前自己的状况,一旦心跳信 号出了问题,主服务器会自动将有问题的块存储服务器的相关内容进行复制。以保证数据的 安全性。 数据被存储时是经过压缩的。采用的BMDiff 和Zippy 算法。BMDiff 使用最长公共子序 列进行压缩, 压缩 100MB/s, 解压缩约 1000MB/s.类似的有 IBM Hash Suffix Array Delta Compression.Zippy 是 LZW 的改进版本, 压缩比不如 LZW, 但是速度更快. - Page 11-8、Google 并行计算构架 Mapreduce 有了强大的分布式文件系统,Google 遇到的问题就是怎么才能让公司所有的程序员都 学会些分布式计算的程序呢?于是,那些Google 工程师们从lisp 和其他函数式编程语言中 的映射和化简操作中得到灵感,搞出了Map/Reduce 这一套并行计算的框架。Map/Reduce 被Google 拿来重新了Google Search Engine 的整个索引系统。而Doug Cutting 同样用Java 将 这一套实现和HDFS 合在一起成为Hadoop 的Core。 MapReduce 是Google 提出的一个软件架构,用于大规模数据集(大于1TB)的并行运 算。概念“Map (映射)”和“Reduce (化简)”,和他们的主要思想,都是从函数式编程语 言借来的,还有从矢量编程语言借来的特性。 映射和化简 简单说来,一个映射函数就是对一些独立元素组成的概念上的列表(例如,一个测试成 绩的列表)的每一个元素进行指定的操作(比如前面的例子里,有人发现所有学生的成绩都 被高估了一分,他可以定义一个“减一”的映射函数,用来修正这个错误。)。事实上,每个 元素都是被独立操作的,而原始列表没有被更改,因为这里创建了一个新的列表来保存新的 答案。这就是说,Map 操作是可以高度并行的,这对高性能要求的应用以 并行计算领域 的需求非常有用。 而化简操作指的是对一个列表的元素进行适当的合并(继续看前面的例子,如果有人想 知道班级的平均分该怎么做?他可以定义一个化简函数,通过让列表中的元素 跟自己的相 - Page 12-邻的元素相加的方式把列表减半,如此递归运算直到列表只剩下一个元素,然后用这个元素 除以人数,就得到了平均分。)。虽然他不如映射函数那么并 行,但是因为化简总是有一个 简单的答案,大规模的运算相对独立,所以化简函数在高度并行环境下也很有用。 分布和可靠性 MapReduce 通过把对数据集的大规模操作分发给网络上的每个节点实现可靠性;每个 节点会周期性的把完成的工作和状态的更新报告回来。如果一个节点保 持沉默超过一个预 设的时间间 ,主节点 (类同Google File System 中的主服务器)记录下这个节点状态为死 亡,并把分配给这个节点的数据发到别的节点。每个操作使用命名文件的原子操作以确保不 会发生并行线程间 的冲突;当文件被改名的时候,系统可能会把他们复制到任务名以外的 另一个名字上去。(避免副作用)。 化简操作工作方式很类似,但是由于化简操作在并行能力较差,主节点会尽量把化简操 作调度在一个节点上,或者离需要操作的数据尽可能进的节点上了;这个特性可以满足 Google 的需求,因为他们有足够的带宽,他们的内部网络没有那么多的机器。 在Google,MapReduce 用在非常广泛的应用程序中,包括“分布grep,分布排序,web 连接图反转,每台机器的词矢量,web 访问日志分析,反向索引构建,文档聚类,机器学习, 基于统计的机器翻译.”值得注意的是,MapReduce 实现以后,它被用来重新生成Google 的整个索 引,并取代老的ad hoc 程序去更新索引。MapReduce 会生成大量的临时文件,为 了提高效率,它利用Google 文件系统来管理和访问这些文件。 - Page 13-9、Google 并行计算数据库 Bigtable 有了强大的存储,有了强大的计算能力,剩下的Google 要面对的是:它的应用中有很 多结构化、半结构化的数据,如何高效地管理这些结构化、半结构化的数据呢?Google 需 要的是一个分布式的类DBMS 的系统,于是催生了BigTable 这个东西 Google 的BigTable 从 2004 年初就开始研发了,BigTable 让Google 在提供新服务时的 运行成本降低,最大限度地利用了计算能力。BigTable 是建立在 GFS ,Scheduler ,Lock Service 和 MapReduce 之上的。 每个Table 都是一个多维的稀疏图sparse map。Table 由行和列组成,并且每个存储单 元 cell 都有一个时间戳。在不同的时间对同一个存储单元cell 有多份拷贝,这样就可以记 录数据的变动情况。数据存储的结构是(row:string, column:string, time:int64) - string 行: 表中的行键 (目前任意字符串至64KB 的大小)。每一个读取或写入的数据下单行的关键是 原子 (不论数目不同的列被读取或行中写的),更容易为客户的原因关于系统中的行为同时存 在对同一行的更新。 列: - Page 14- 列项分为集合称为列的家族,它们形成了访问控制的基本单位。所有数据在一列中存储 的家族通常是同一类型。当数据以这个列键值被存储之前,列的家族必须被创建。家族内的 任何列键值可以使用。因为,重叠的列键值比较少,与此相反,一个表可能有无限的列数。 时间戳: Bigtable 的每一个细胞中可以包含多个版本同样的数据,这些版本的时间戳索引。Bigtable 的时间戳64 位整数。它们可以被分配由Bigtable 的,在这种情况下,他们真正代表联聪以微秒 的时间,或明确指定的客户端应用程序。应用程序需要避免冲突必须创造自己独特的时间戳。 不同一个单元格的版本都存储在时间戳顺序递减,因此,最近的版本可以首先阅读。 为了管理 大的Table,把Table 根据行分割,这些分割后的数据统称为:Tablets 。每个 Tablets 大概有 100-200 MB,每个机器存储100 个左右的Tablets 。底层的架构是:GFS。由 于GFS 是一种分布式的文件系统,采用Tablets 的机制后,可以获得很好的负载均衡。比如: 可以把经常响应的表移动到其他空闲机器上,然后快速重建。Tablets 在系统中的存储方式 是不可修改的immutable 的SSTables,一台机器一个日志文件。 BigTable 中最重要的选择是将数据存储分为两部分,主体部分是不可变的,以SSTable 的格式存储在GFS 中,最近的更新则存储在内存(称为memtable)中。读操作需要根据SSTable 和memtable 还综合决定要读取的数据的值。 - Page 15- Google 的Bigtable 是不支持事务,只保证对单条记录的原子性。事务是好东西,但事 务也是导致数据库实现复杂化、性能下降最主要的根源。BigTable 的开发者通过调研后发现 其实大家对事务都没什么需求,只要保证对单条记录的更新是原子的就可以了。这样,为了 支持事务所要考虑的串行化、事务的回滚等、死锁检测(一般认为,分布式环境中的死锁检 测是不可能的,一般都用超时解决)等等复杂问题都不见了。系统实现进一步简化。 10、Google 并行锁服务Chubby lock 在 Google 这种的分布式系统中,需要一种分布式锁服务来保证系统的一致性。于是 Google 有了Chubby lock service。而同样是Yahoo !Research 向开源贡献了Zookeeper,一 个类似Google Chubby 的项目。 在Google File System(GFS)中,有很多的服务器,这些服务器需要选举其中的一台作为 master server。Value 就是master server 的地址,GFS 就是用Chubby 来解决的这个问题,所 有的server 通过Chubby 提供的通信协议到Chubby server 上创建同一个文件,当然,最终只 有一个server 能够获准创建这个文件,这个server 就成为了master,它会在这个文件中写 入自己的地址,这样其它的server 通过读取这个文件就能知道被选出的master 的地址。 Chubby 首先是一个分布式的文件系统。Chubby 能够提供机制使得 client 可以在Chubby service 上创建文件和执行一些文件的基本操作。说它是分布式的文件系统,是因为一个 Chubby cell 是一个分布式的系统。但是,从更高一点的语义层面上,Chubby 是一个 lock service,一个针对松耦合的分布式系统的lock service。所谓lock service,就是这个service 能够提供开发人员经常用的“锁”,“解锁”功能。通过 Chubby,一个分布式系统中的上千 个client 都能够 对于某项资源进行“加锁”,“解锁”。 Chubby 中的“锁”就是建立文件,在上例 中,创建文件其实就是进行“加锁”操作, - Page 16-创建文件成功的那个server 其实就是抢占到了“锁”。用户通过打开、关闭和读取文件,获 取共享锁或者独占锁;并且通过通信机制,向用户发送更新信息。 11、Google 消息序列处理系统Google Workqueue GWQ (Google Workqueue)系统是负责将Mapreduce 的工作任务安排各个各个计算单 位的(Cell/Cluster)。仲裁 (进程优先级)附表,分配资源,处理故障,报告情况,收集的 结果- 通常

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论