云计算研究之数据中心.docx
《云计算研究之数据中心.docx》由会员分享，可在线阅读，更多相关《云计算研究之数据中心.docx（27页珍藏版）》请在冰豆网上搜索。
云计算研究之数据中心
云计算专题研究之数据中心
1.Google数据中心
从整体来看，Google的云计算包括了如下的技术层次。
1）网络系统：
包括外部网络（ExteriorNetwork），这个外部网络并不是指运营商自己的骨干网，也是指在Google云计算服务器中心以外，由Google自己搭建的由于不同地区/国家，不同应用之间的负载平衡的数据交换网络。
内部网络（InteriorNetwork），连接各个Google自建的数据中心之间的网络系统。
2）硬件系统：
从层次上来看，包括单个服务器、整合了多服务器机架和存放、连接各个服务器机架的数据中心（IDC）。
3）软件系统：
包括每个服务器上面的安装的单机的操作系统经过修改过的RedhatLinux。
Google云计算底层软件系统（文件系统GFS、并行计算处理算法Mapreduce、并行数据库Bigtable，并行锁服务ChubbyLock，云计算消息队列GWQ）
4）Google内部使用的软件开发工具Python、Java、C++等
5）Google自己开发的应用软件GoogleSearch、GoogleEmail、GoogleEarth
Google将40台服务器编为一个集群，而在全球范围，Google拥有36个数据中心。
每个数据中心有150个服务器集群。
1.1数据访问
1.1.1.外部访问
当一个互联网用户输入的时候，这个URL请求就会发到GoogleDNS解析服务器当中去，那么Google的DNS服务器就会根据用户自身的IP地址来判断，这个用户请求是来自那个国家、那个地区。
根据不同用户的IP地址信息，解析到不同的Google的数据中心。
进入第一道防火墙，这次防火墙主要是根据不同端口来判断应用，过滤相应的流量。
如果仅仅接受浏览器应用的访问，一般只会开放80端口http，和443端口https（通过SSL加密）。
将其他的来自互联网上的非Ipv4/V6非80/443端口的请求都放弃，避免遭受互联网上大量的DOS攻击。
据说Google使用了思杰科技（CitrixSystems）的Netscaler应用交换机来做web应用的优化。
NetScaler可将Web应用性能加速高达5倍。
使用高级优化技术如动态缓存时，或者当网络延迟或数据包丢失增大时，性能增益会更高。
这里提到的httpmultiplexting技术是可以是进行http的每个session分解开。
从不同的后端服务器（缓存）来获取内容，这样可以大大提升webhttp性能，同时有效降低后端web应用服务器的处理和联接压力。
在大量的web应用服务器群（WebServerFarm）前，Google使用反向代理（ReverseProxy）的技术。
反向代理（ReverseProxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。
Google使用的是SquidCache的软件方式来实现反向代理应用的，SquidCache一个流行的自由软件（GNU通用公共许可证）的代理服务器和Web缓存服务器。
Squid有广泛的用途，从作为网页服务器的前置cache服务器缓存相关请求来提高Web服务器的速度。
在Googleweb应用服务器需要调用Google内部存储的信息和资源的时候，再通过一个防火墙进入内部的网络，来访问其他的基于自身GFSII系统的应用服务和数据库。
1.1.2.内部访问
Google自己已经建设了跨国的光纤网络，连接跨地区、跨国家的高速光纤网络。
内部网络已经都是Ipv6的协议在运行。
网络中的路由交换设备主要还是来自Juniper,Cisco,Foundry,HP这四家公司。
内部网关协议（IRP）是基于OSPF（开放式最短路径优先）进行修改的。
在每个服务器机架内部连接每台服务器之间网络是100M以太网，在服务器机架之间连接的网络是1000M以太网。
在每个服务器机架内，通过IP虚拟服务器（IPVirtualServer）的方式实现传输层负载Linux内核内的平衡，这个就是所谓四层LAN交换。
IPVS使一个服务器机架中的众多服务成为基于Linux内核虚拟服务器。
这就像在一堆服务器前安装一个负载均衡的服务器一样。
当TCP/UDP的请求过来后，使一群服务器可以使用一个单一的IP地址来对外提供相关的服务支撑。
1.2.关键技术
1.2.1Google分布式文件系统GFS/GFSII
GFS是Google文件系统中最基础的模块。
任何文件和数据都可以利用这种底层模块。
GFS通过基于Linux分布存储的方式，对于服务器来说，分成了主服务器（MasterServers）和块存储服务器（ChunkServers），GFS上的块存储服务器上的存储空间以64MB为单位，分成很多的存储块，由主服务器来进行存储内容的调度和分配。
每一份数据都是一式三份的方式，将同样的数据分布存储在不同的服务器集群中，以保证数据的安全性和吞吐的效率提高。
当需要对于文件、数据进行存储的时候，应用程序之间将需求发给主服务器，主服务器根据所管理的块存储服务器的情况，将需要存储的内容进行分配，并将可以存储的消息（使用那些块存储服务器，那些地址空间），有应用程序下面的GFS接口在对文件和数据直接存储到相应的块存储服务器当中。
块存储服务器要定时通过心跳信号的方式告知主服务器，目前自己的状况，一旦心跳信号出了问题，主服务器会自动将有问题的块存储服务器的相关内容进行复制。
以保证数据的安全性。
数据被存储时是经过压缩的。
采用的BMDiff和Zippy算法。
BMDiff使用最长公共子序列进行压缩,压缩100MB/s,解压缩约1000MB/s.类似的有IBMHashSuffixArrayDeltaCompression.Zippy是LZW的改进版本,压缩比不如LZW,但是速度更快。
1.2.2.Google并行计算构架–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文件系统来管理和访问这些文件。
Mapreduce编程模型
1.2.3.Google分布式数据库技术Bigtable
BigTable用来管理应用中那些结构化、半结构化的数据，BigTable是建立在GFS，Scheduler，LockService和MapReduce之上的。
上图是一个存储Web网页的范例列表片断。
行名是一个反向URL｛即n.www｝。
contents列族存放网页内容，anchor列族存放引用该网页的锚链接文本。
CNN的主页被SportsIllustrater和MY-look的主页引用，因此该行包含了名叫“anchor:
”和“anchhor:
my.look.ca”的列。
每个锚链接只有一个版本｛由时间戳标识，如t9，t8｝；而contents列则有三个版本，分别由时间戳t3，t5，和t6标识。
每个Table都是一个多维的稀疏图sparsemap。
Table由行和列组成，并且每个存储单元cell都有一个时间戳。
在不同的时间对同一个存储单元cell有多份拷贝，这样就可以记录数据的变动情况。
数据存储的结构是（row:
string,column:
string,time:
int64）-->string
行：
表中的行键（目前任意字符串至64KB的大小）。
每一个读取或写入的数据下单行的关键是原子（不论数目不同的列被读取或行中写的），更容易为客户的原因关于系统中的行为同时存在对同一行的更新。
列：
列项分为集合称为列的家族，它们形成了访问控制的基本单位。
所有数据在一列中存储的家族通常是同一类型。
当数据以这个列键值被存储之前，列的家族必须被创建。
家族内的任何列键值可以使用。
因为，重叠的列键值比较少，与此相反，一个表可能有无限的列数。
时间戳：
Bigtable的每一个细胞中可以包含多个版本同样的数据，这些版本的时间戳索引。
Bigtable的时间戳64位整数。
它们可以被分配由Bigtable的，在这种情况下，他们真正代表联聪以微秒的时间，或明确指定的客户端应用程序。
应用程序需要避免冲突必须创造自己独特的时间戳。
不同一个单元格的版本都存储在时间戳顺序递减，因此，最近的版本可以首先阅读。
1.2.4.Google并行锁服务Chubbylock
在Google这种的分布式系统中，需要一种分布式锁服务来保证系统的一致性。
于是Google有了Chubbylockservice。
而同样是Yahoo！
Research向开源贡献了Zookeeper，一个类似GoogleChubby的项目。
在GoogleFileSystem（GFS）中，有很多的服务器，这些服务器需要选举其中的一台作为masterserver。
Value就是masterserver的地址，GFS就是用Chubby来解决的这个问题，所有的server通过Chubby提供的通信协议到Chubbyserver上创建同一个文件，当然，最终只有一个server能够获准创建这个文件，这个server就成为了master，它会在这个文件中写入自己的地址，这样其它的server通过读取这个文件就能知道被选出的master的地址。
Chubby首先是一个分布式的文件系统。
Chubby能够提供机制使得client可以在Chubbyservice上创建文件和执行一些文件的基本操作。
说它是分布式的文件系统，是因为一个Chubbycell是一个分布式的系统。
但是，从更高一点的语义层面上，Chubby是一个lockservice，一个针对松耦合的分布式系统的lockservice。
所谓lockservice，就是这个service能够提供开发人员经常用的“锁”，“解锁”功能。
通过Chubby，一个分布式系统中的上千个client都能够对于某项资源进行“加锁”，“解锁”。
Chubby中的“锁”就是建立文件，在上例中，创建文件其实就是进行“加锁”操作，创建文件成功的那个server其实就是抢占到了“锁”。
用户通过打开、关闭和读取文件，获取共享锁或者独占锁；并且通过通信机制，向用户发送更新信息。
1.2.5.Google消息序列处理系统GoogleWorkqueue
GWQ（GoogleWorkqueue）系统是负责将Mapreduce的工作任务安排各个各个计算单位的（Cell/Cluster）。
仲裁（进程优先级）附表，分配资源，处理故障，报告情况，收集的结果-通常队列覆盖在GFS上的。
消息队列处理系统可以同时管理数万服务器。
通过API接口和命令行可以调动GWQ来进行工作。
1.2.6.Google分布式存储技术Megastore
Megastore是谷歌一个内部的存储系统，它的底层数据存储依赖Bigtable，也就是基于NoSql实现的，但是和传统的NoSql不同的是，它实现了类似RDBMS的数据模型（便捷性），同时提供数据的强一致性解决方案（同一个datacenter，基于MVCC的事务实现），并且将数据进行细颗粒度的分区（这里的分区是指在同一个datacenter，所有datacenter都有相同的分区数据），然后将数据更新在机房间进行同步复制（这个保证所有datacenter中的数据一致）。
Megastore的数据复制是通过paxos进行同步复制的，也就是如果更新一个数据，所有机房都会进行同步更新，因为使用paxos进行复制，所以不同机房针对同一条数据的更新复制到所有机房的更新顺序都是一致的，同步复制保证数据的实时可见性，采用paxos算法则保证了所有机房更新的一致性，所以个人认为megastore的更新可能会比较慢，而所有读都是实时读（对于不同机房是一致的），因为部署有多个机房，并且数据总是最新。
Scalablereplication
为了达到高可用性，megastore实现了一个同步的，容错的，适合长距离连接的日志同步器
为了达到高可扩展性，megastore将数据分区成一个个小的数据库，每一个数据库都有它们自己的日志，这些日志存储在NoSql中。
Megastore将数据分区为一个EntityGroups的集合，这里的EntityGroups相当于一个按id切分的分库，这个EntityGroups里面有多个EntityGroup（相当于分库里面的表），而一个EntityGroup有多个Entity（相当于表中的记录）。
OperationAcrossEntityGroups
在同一个EntityGroup中（相当于单库）的多个Entity的更新事务采用single-phaseACID事务，而跨EntityGroup（相当于跨库）的Entity更新事务采用two-phaseACID事务（2段提交），但更多使用Megastore提供的高效异步消息实现。
需要说明的一点是，这些事务都是在同一个机房的，机房之间的数据交互都是通过数据复制来实现的。
1.3.数据中心灾备
灾难备份与恢复有两个指标，一个是RPO（RecoveryPointObjective），一个是RTO（RecoveryTimeObjective），也就是数据丢失率和恢复间隔。
对传统的SAN或异地备份，这两个指标基本取决于成本，指标越好，成本越高，Google在这方面，使用的是同步复制技术，同步复制使RPO接近于0，而RTO接近实时，也就是说，灾难发生时，Google所有在线应用的数据丢失基本为0，恢复间隔接近实时，使用户完全觉察不到（可是，Gmail的几次宕机是怎么回事）。
数据同步复制技术应用到所有Google在线应用（包括Gmail，GoogleCalendar，GoogleDocs，以及GoogleSites等），用户需要保存的任何数据，都同步存储到Google的两个不同地理位置的数据中心，当任何一个数据中心发生故障，系统会立即切换到另一个数据中心。
Google的备用数据中心并不是在灾难发生时才启用，而是一直在使用中，Google始终在这些数据中心之间进行平衡，保证没有资源浪费。
Google的数据中心之间有他们自己的高度连接网络，保证数据快速传送。
2.微软数据中心
微软的动态数据中心方案通过WindowsServer自带的Hyper-V技术和SystemCenter完美整合，提供了高可用、动态资源调配、配置管理和数据备份等功能，通过部署VirtualMachineManager还能对异构的虚拟化环境做统一的管理。
微软的动态数据中心方案集成了Hyper-V，ClusterService以及SystemCenter四大核心产品，能对宿主机（包括WindowsServer2008/2008R2/2003R2，ServerCore或Hyper-VServer2008R2）以及不同类型的虚拟机（包括Windows2000，WindowsServer2003/WindowsXP，WindowsServer2008/WindowsVista，WindowsServer2008R2/Windows7，SUSE/RedHatLinux）做统一的管理，例如配置兼容性管理、点对点服务监控、数据保护和备份等，而不是仅仅对虚拟机做一些配置管理。
微软动态数据中心
2.1.数据访问
应用程序与存储数据的工作有许多不同的方式。
有时人们需要的只是简单的块，而其他情况下则要求有条理的方式来存储信息。
在某些情况下，人们真正需要的是一种不同部分之间的交换数据指令。
对于Azure允许的Windows数据存储块，表格和队列，所有通过HTTP进入同样的REST方式，使用RESTAPI访问StorageService。
当前模式会产生的瓶颈
微软云计算WindowsAzure解决方案
2.2.关键技术
2.2.1.AzureBlobStorage
Blob可以看做文件系统。
是的，它确实和文件系统有非常多的相似之处。
Blobstorage有两个概念：
Container：
可以类比成文件夹
Blob：
可以类比成文件
和文件系统一样，用户可以针对每个container设置访问权限，可以对某个blob进行加锁（lease）从而防止concurrency问题，还可以使用诸如创建，删除，复制，备份，等众多功能。
从存储结构上来说，我们提供了两种类型的blob：
Blockblob：
其存储方式类似于传统的文件系统中的簇（cluster）的概念。
一个blob被分成一个或多个block进行存储。
Pageblob：
Pageblob对随机读写进行了优化，大家可以把它类比成大型文件，例如.vhd和.mdf文件。
Account下可以有许多Container，Container下可以有许多Blob，每个Blob最大50GB，不同Container可以位于不同的存储节点。
2.2.2.AzureTableStorage
千万不要把tablestorage和关系型数据库混淆起来。
WindowsAzure的tablestorage提供了一种结构化的存储方式。
通俗来说，一个table可以被想象成一个xml文件。
在xml文件中我们存放各种各样的数据，在一个table中我们也可以存放各种各样的entity。
同一个table可以存储结构完全不同的两个entity，这和关系型数据库中需要对每张表制定统一的schema是不同的。
Tablestorage的可变的schema充分体现出了其灵活性。
例如，你的业务需要扩展，需要往数据结构中添加新的字段，你可以在完全不修改tableschema，完全不影响现有entity的情况下，对新的entity添加新的字段。
如果你的程序可以被二次开发，第三方开发人员也完全可以在不影响你的程序所需要的entity的情况下，在同一张表中存储他们的程序所需要的，结构不同的entity。
Account下可以有许多Table，Table可以划分为无限多的Partition，通过partition来扩展，不同Partition可以位于不同的存储节点，Table是Entity的集合，Entity是属性的集合，两个关键属性：
PartitionKey提供可扩展性，RowKey唯一标示该partition中的Entity，相同PartitionKey的Entity存在同个存储节点，使数据操作更有效。
AzureTableStorage-例子
TablePartition是拥有相同partition键值的所有Entity的集合，高效地获取所有版本的FAQDoc文档（单一Partition查询），该两个partition可以由不同服务器提供，实现高扩展的访问性能
WindowsAzure的Table及Blob存储通过Account自然实现
•
示例
2.2.3.Queue
Queue提供了一种先进先出的存储方式。
它通常被用于各种不同的程序间的通信。
例如一个经典的应用场景：
WebRole接受用户请求，针对每个请求，在一个queue中创建一条消息（message）。
WorkerRole则不断的从queue中取出消息，并且一一处理。
2.2.4.Drive
目前尚处于beta阶段的drivestorage让开发人员能够使用标准的NTFSAPI读写文件。
一个drive可以被挂接（mount）到某个特定的实例上，当作该实例对应的虚拟机的一块硬盘使用。
由于drive在后台是由pageblob实现的，因此你往drive中写入的文件也会自动被写入后台的pageblob。
这样一来数据便得到了持久化，即使万一运行当前实例的虚拟机出了问题，你还可以在其它实例中再次挂接这块虚拟硬盘，数据并不会丢失。
需要注意的是，当前一个drive在同一时间只能被单个实例挂接。
如果你需要在不同的实例中同时访问文件，还是推荐使用blob。
Dive更常被用于移植现有的那些需要执行大量I/O操作的程序。
2.2.5.SQLAzure
SQLAzure是微软提供的一个云数据库系统，由微软SQLServer2008为主，建构在Windo
升级会员 