谷歌云计算架构详解.docx
《谷歌云计算架构详解.docx》由会员分享，可在线阅读，更多相关《谷歌云计算架构详解.docx（11页珍藏版）》请在冰点文库上搜索。
从整体来看，Google的云计算平台包括了如下的技术层次。
l网络系统：
包括外部网络（ExteriorNetwork），这个外部网络并不是指运营商自己的骨干网，也是指在Google云计算服务器中心以外，由Google自己搭建的由于不同地区/国家，不同应用之间的负载平衡的数据交换网络。
内部网络（InteriorNetwork），连接各个Google自建的数据中心之间的网络系统。
l硬件系统：
从层次上来看，包括单个服务器、整合了多服务器机架和存放、连接各个服务器机架的数据中心（IDC）。
l软件系统：
包括每个服务器上面的安装的单机的操作系统经过修改过的RedhatLinux。
Google云计算底层软件系统（文件系统GFS、并行计算处理算法Mapreduce、并行数据库Bigtable，并行锁服务ChubbyLock，云计算消息队列GWQ）
lGoogle内部使用的软件开发工具Python、Java、C++等
lGoogle自己开发的应用软件GoogleSearch、GoogleEmail、GoogleEarth
外部网络系统介绍
当一个互联网用户输入的时候，这个URL请求就会发到GoogleDNS解析服务器当中去，Google的DNS服务器会根据用户自身的IP地址来判断，这个用户请求是来自哪个国家、哪个地区。
根据不同用户的IP地址信息，解析到不同的Google的数据中心。
进入第一道防火墙，这次防火墙主要是根据不同端口来判断应用，过滤相应的流量。
如果仅仅接受浏览器应用的访问，一般只会开放80端口http，和443端口https（通过SSL加密）。
将其他的来自互联网上的非Ipv4/V6非80/443端口的请求都放弃，避免遭受互联网上大量的DOS攻击。
在大量的web应用服务器群（WebServerFarm）前，Google使用反向代理（ReverseProxy）的技术。
反向代理（ReverseProxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给Internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。
Google使用的是SquidCache的软件方式来实现反向代理应用的，SquidCache是一个流行的自由软件（GNU通用公共许可证）的代理服务器和Web缓存服务器。
Squid有广泛的用途，从作为网页服务器的前置cache服务器缓存相关请求来提高Web服务器的速度。
在Googleweb应用服务器需要调用Google内部存储的信息和资源的时候，在通过一个防火墙进入内部的网络，来访问其他的基于自身GFSII系统的应用服务和数据库。
内部网络架构介绍
Google自己已经建设了跨国的光纤网络，连接跨地区、跨国家的高速光纤网络。
内部网络已经都是IPv6的协议在运行。
网络中的路由交换设备主要还是来自Juniper、Cisco、Foundry、HP这四家公司。
内部网关协议（IRP）是基于OSPF（开放式最短路径优先）进行修改的。
在每个服务器机架内部连接每台服务器之间网络是100M以太网，在服务器机架之间连接的网络是1000M以太网。
在每个服务器机架内，通过IP虚拟服务器（IPVirtualServer）的方式实现传输层负载Linux内核内的平衡，这个就是所谓四层LAN交换。
IPVS使一个服务器机架中的众多服务成为基于Linux内核虚拟服务器。
这就像在一堆服务器前安装一个负载均衡的服务器一样。
当TCP/UDP的请求过来后，使一群服务器可以使用一个单一的IP地址来对外提供相关的服务支撑。
大规模IDC部署战略
Google应该是目前世界上存储信息最多的企业了。
而且还在一直不断的致力于将传统信息尽可能地数字化。
将这样海量的信息进行存储、进行处理。
就需要大量的计算机服务器。
为了满足不断增长的计算需求。
Google很早就进行了全球的数据中心的布局。
由于数据中心运行后，面临的几个关键问题的就是充足电力供应、大量服务器运行后的降温排热和足够的网络带宽支持。
所以Google在进行数据中心布局的时候，就是根据互联网骨干带宽和电力网的核心节点进行部署的，尽快考虑在河边和海边，想办法通过引入自然水流的方式来降低降温排热的成本。
Dalles是美国俄勒冈州北部哥伦比亚河（ColumbiaRiver）岸上的一个城市，Google在Dalles的边上拥有的30英亩土地，他们在这里建立了几乎是世界上最大，性能最好的数据中心。
四个装备有巨大空调设施的仓库内，放置着数万台Internet服务器，这些服务器每天处理着数十亿条Google网站传递给世界各个角落的用户的数据。
图表1Google在Dalles的数据中心
这个数据中心占用了附近一个180万千瓦水力发电站的大部分电力输出。
对比来看目前中国长江三峡水电站的额定功率是1820万千瓦。
目前Google已经在全球运行了38个大型的IDC中心，超过300多个GFSII服务器集群，超过80万台计算机。
从服务器集群部署的数量来看美国本地的数量第一，欧洲地区第二，亚洲地区第三，在南美地区和俄罗斯各有一个IDC数据中心。
在中国的北京和香港，Google也建设了自己的IDC中心，并部署了自己的服务器农场。
其中目前还在进行建设的第38个IDC是在奥地利的林茨市（Linz）附近的Kronstorf村。
未来，Google还准备在中国台湾地区、马来西亚、立陶宛等地区来进行部署。
从目前的Google数据中心部署的情况来看，中东和非洲地区目前Google还没有建设计划。
图表2Google的IDC中心/服务器农场（GoogleServerFarm）的全球分布图
Google自己设计了创新的集装箱服务器，数据中心以货柜为单位，标准Google模块化集装箱装有30个的机架，1160台服务器，每台服务器的功耗是250KW。
（Google2009年公布的信息）。
这种标准的集装箱式的服务器部署和安装策略可以使Google非常快速地部署一个超大型的数据中心。
大大降低了对于机房基建的需求。
图表3Google模块化集装箱的设计示意图。
自己设计的服务器机架架构
Google的服务器机架有两种规格40U/80U的。
这主要是因为原来每个服务器刀片是1U高，新的服务器刀片都是2U高的。
据说Google后期使用的服务器主板是台湾技嘉，服务器主板可以直接插入到服务器机架中。
图表4Google服务器机架及主板
自己设计的PC服务器刀片
绝大部分企业都会跟诸如戴尔、惠普、IBM或Sun购买服务器。
不过Google所拥有的八十万台服务器都是自己设计打造来的，Google认为这是公司的核心技术之一。
Google的硬件设计人员都是直接和芯片厂商和主板厂商协作工作的。
2009年，Google开始大量使用2U高的低成本解决方案。
标准配置是双核双通道CPU，据说有Intel的，也有AMD的在使用。
8个2GB的DDR3，支持ECC容错的高速内存，采用RAID1的磁盘镜像，来提升I/O效率。
磁盘采用SATA，单机存储容量可以达到1-2TB。
每个服务器刀片自带12V的电池来保证在短期没有外部电源的时候可以保持服务器刀片正常运行。
Google的硬件设计人员认为，这个自带电池的方式，要比传统的使用UPS的方式效率更高。
一般数据中心多倚赖称为不间断电源系统（UPS）的大型中控机型，这基本上算是大电池，会在主电力失效而发电机还来不及启动时，暂时协助供电。
Google的硬件设计人员表示，直接把电力内建到服务器比较便宜，而且成本能直接跟服务器数量相符合。
“这种作法比使用大型UPS节省得多，如此也不会浪费多余的容量。
”效率也是另一个财务考量因素。
大型UPS可达92-95%的效率，这意味着许多电力还是被浪费掉了。
但Google采用的内建电池作法却好很多，Google相关人员表示，“我们测量的结果是效率超过99.9%。
图表5内建电池的服务器刀片
操作系统与云计算文件系统GFS/GFSII
Google服务器使用的操作系统是基于RedhatLinux2.6的内核，并做了大量修改。
修改了GNUC函数库（glibc），远程过程调用（RPC），开发了自己的Ipvs，自己修改了文件系统，形成了自己的GFSII，修改了linux内核和相关的子系统，使其支持IPV6。
采用了Python来作为主要的脚本语言。
Google文件系统中最基础的模块是GFSIIcell。
任何文件和数据都可以利用这种底层模块。
GFSII通过基于Linux分布存储的方式，对于服务器来说，分成了主服务器（MasterServers）和块存储服务器（ChunkServers），GFS上的块存储服务器上的存储空间以64MB为单位，分成很多的存储块，由主服务器来进行存储内容的调度和分配。
每一份数据都是一式三份的方式，将同样的数据分布存储在不同的服务器集群中，以保证数据的安全性和吞吐的效率提高。
当需要对于文件、数据进行存储的时候，应用程序之间将需求发给主服务器，主服务器根据所管理的块存储服务器的情况，将需要存储的内容进行分配，并将可以存储的消息（使用那些块存储服务器，那些地址空间），由应用程序下面的GFS接口在对文件和数据直接存储到相应的块存储服务器当中。
图表6GFS架构
块存储服务器要定时通过心跳信号的方式告知主服务器，目前自己的状况，一旦心跳信号出了问题，主服务器会自动将有问题的块存储服务器的相关内容进行复制。
以保证数据的安全性。
数据被存储时是经过压缩的。
采用的BMDiff和Zippy算法。
BMDiff使用最长公共子序列进行压缩,压缩100MB/s,解压缩约1000MB/s.类似的有IBMHashSuffixArrayDelta
Compression.Zippy是LZW的改进版本,压缩比不如LZW,但是速度更快。
并行计算架构–Mapreduce
有了强大的分布式文件系统，Google遇到的问题就是怎么才能让公司所有的程序员都学会些分布式计算的程序呢？
于是，那些Google工程师们从lisp和其他函数式编程语言中的映射和化简操作中得到灵感，搞出了Map/Reduce这一套并行计算的框架。
Map/Reduce被Google拿来重新了GoogleSearchEngine的整个索引系统。
而DougCutting同样用Java将这一套实现和HDFS合在一起成为Hadoop的Core。
MapReduce是Google提出的一个软件架构，用于大规模数据集（大于1TB）的并行运算。
概念“Map（映射）”和“Reduce（化简）”，和他们的主要思想，都是从函数式编程语言借来的，还有从矢量编程语言借来的特性。
映射和化简
简单说来，一个映射函数就是对一些独立元素组成的概念上的列表（例如，一个测试成绩的列表）的每一个元素进行指定的操作（比如前面的例子里，有人发现所有学生的成绩都被高估了一分，他可以定义一个“减一”的映射函数，用来修正这个错误。
）。
事实上，每个元素都是被独立操作的，而原始列表没有被更改，因为这里创建了一个新的列表来保存新的答案。
这就是说，Map操作是可以高度并行的，这对高性能要求的应用以及并行计算领域的需求非常有用。
而化简操作指的是对一个列表的元素进行适当的合并（继续看前面的例子，如果有人想知道班级的平均分该怎么做？
他可以定义一个化简函数，通过让列表中的元素跟自己的相邻的元素相加的方式把列表减半，如此递归运算直到列表只剩下一个元素，然后用这个元素除以人数，就得到了平均分。
）。
虽然他不如映射函数那么并行，但是因为化简总是有一个简单的答案，大规模的运算相对独立，所以化简函数在高度并行环境下也很有用。
分布和可靠性
MapReduce通过把对数据集的大规模操作分发给网络上的每个节点实现可靠性；每个节点会周期性的把完成的工作和状态的更新报告回来。
如果一个节点保持沉默超过一个预设的时间间隔，主节点（类同GoogleFileSystem中的主服务器）记录下这个节点状态为死亡，并把分配给这个节点的数据发到别的节点。
每个操作使用命名文件的原子操作以确保不会发生并行线程间的冲突；当文件被改名的时候，系统可能会把他们复制到任务名以外的另一个名字上去。
化简操作工作方式很类似，但是由于化简操作在并行能力较差，主节点会尽量把化简操作调度在一个节点上，或者离需要操作的数据尽可能进的节点上了；这个特性可以满足Google的需求，因为他们有足够的带宽，他们的内部网络没有那么多的机器。
在Google，MapReduce用在非常广泛的应用程序中，包括“分布grep，分布排序，web连接图反转，每台机器的词矢量，web访问日志分析，反向索引构建，文档聚类,机器学习，基于统计的机器翻译...”值得注意的是，MapReduce实现以后，它被用来重新生成Google的整个索引，并取代老的adhoc程序去更新索引。
MapReduce会生成大量的临时文件，为了提高效率，它利用Google文件系统来管理和访问这些文件。
并行计算数据库BigTable
有了强大的存储，有了强大的计算能力，剩下的Google要面对的是：
它的应用中有很多结构化、半结构化的数据，如何高效地管理这些结构化、半结构化的数据呢？
Google需要的是一个分布式的类DBMS的系统，于是催生了BigTable这个东西
Google的BigTable从2004年初就开始研发了，BigTable让Google在提供新服务时的运行成本降低，最大限度地利用了计算能力。
BigTable是建立在GFS和MapReduce之上的。
每个Table由行和列组成，并且每个存储单元cell都有一个时间戳，在不同的时间对同一个存储单元cell有多份拷贝，这样就可以记录数据的变动情况。
不同一个单元格的版本都存储在时间戳顺序递减，因此，最近的版本可以首先阅读。
下图是一个使用BigTable存储网页的例子，这一“行”的名字是网页的反向URL——“n.www”，名为“contents:
”的这一“列”存储网页内容，带有名为“anchor”的列存储所有引用该网页的锚（anchor）文本。
CNN的首页被“”和“my.look.ca”这两个网站的首页引用，所以该行就包含了这两列：
“anchor:
”和“anchor:
my.look.ca”。
这两列下的单元都只有一个版本，而“contents:
”这一列下的单元有三个版本，分别是时间戳t3、t5和t6，分别对应着网页变动的情况。
图表7一个BigTable存储网页的例子
BigTable中最重要的选择是将数据存储分为两部分，主体部分是不可变的，以SSTable的格式存储在GFS中，最近的更新则存储在内存（称为memtable）中。
读操作需要根据SSTable和memtable还综合决定要读取的数据的值。
Google的Bigtable是不支持事务，只保证对单条记录的原子性。
事务是好东西，但事务也是导致数据库实现复杂化、性能下降最主要的根源。
BigTable的开发者通过调研后发现其实大家对事务都没什么需求，只要保证对单条记录的更新是原子的就可以了。
这样，为了支持事务所要考虑的串行化、事务的回滚等、死锁检测（一般认为，分布式环境中的死锁检测是不可能的，一般都用超时解决）等等复杂问题都不见了。
系统实现进一步简化。
借鉴与总结
Google的云计算软件系统的完善是一个迭代开发，逐步升级替代的螺旋式上升过程。
今天的整个软件技术架构已经与10年前大相径庭，GFS完成于2003年，MapReduce完成于2004年，Bigtable完成于2006年，并且此外还有持续的修改升级。
每一次应用新的软件系统，都给Google带来了运营效率的极大提升，甚至发生了根本性的变化，如使用MapReduce重新生成Google的整个索引，并取代老的adhoc程序去更新索引。
“云计算”的完整概念并不是在Google建立起实际的云计算系统之初就形成的，而是在经过一系列的升级改造后逐渐稳定下来的软件系统架构上归纳出来的。
并且可以预见，今后随着互联网的发展，还会有很多新的需求驱动着Google云计算软件系统的改进和完善。
如下一代的GoogleBigTable已经在开发中，名为“Spanner”。
对于有计划部署云计算系统的CIO们来说，这是一个动态变化的长期经营过程，而不仅仅是一个静态的有截止期限的建设项目。
首期系统建设之前，要根据企业已有的IT系统和近期需求选用最适合的技术方案；系统建设的过程中，要跟踪最新技术的发展以及建设过程中的测试反馈，及时调整建设方案；系统建设完成交付使用之后，原有的IT运营维护的职责分工和工作方式可能会有显著的变化，这时候必须有一支专职的云计算运维队伍跟进，除了负责云计算系统本身的运维之外，还需要协调云计算系统与其他业务系统的支撑工作，收集实际运行中的反馈和新需求，为系统升级改进提供决策支持，开始新一轮的系统建设周期。
开源软件在Google的软件系统中有着非常重要的地位。
开源软件能够降低开发成本，并且易于修改以适应企业的实际需求，所以Google选择了在RedhatLinux2.6的内核基础上开发自己的服务器操作系统。
成功的开源软件在全世界范围内有着庞大的程序员群体做维护支持工作，这是任何一家商业软件公司无法比拟的，所以成功的开源软件也有着更快的升级速度，更少的漏洞缺陷。
基于这点，Google也把自己的部分软件架构的细节做了公开处理，如BigTable、MapReduce等，期望借助全世界程序员的力量完善自身的软件架构。
在部署云计算的决策过程中，采购成本和维护成本是非常关键的因素，很多开源软件已经被不同行业证明了是一个成熟完善的产品，并且后续版本升级速度不亚于商业软件，完全可以替代同等功能的商业软件。
升级会员 