阅读量:15
云计算由Google提出，随后在互联网界风起“云”涌，随之而来的云计算服务和技术平台成功案例层出不穷，如Google的GFS、 MapReduce、Bigtable、Chubby和App Engine，亚马逊的Dynamo、EC2、S3、SQS、SimpleDB和CloudFront，微软的Azure、SQL、“.Net”和 Live服务，开源云计算平台的HDFS、HBase和Eucalyptus，VMware的虚拟化平台等。
1 云计算的核心技术
云计算主要基于资源虚拟和分布式并行架构两大核心技术，同时互联网上有大量的开源软件为用户提供支撑，如Xen、KVM、Lighttpd、 Memcached、Nginx、Hadoop、Eucalytus等。云计算技术有效地节约了云服务商的硬件投入、软件开发成本和维护成本。
虚拟化技术最早由VMware公司引入并在X86 CPU上实现。虚拟化平台将服务器虚拟为多个性能可配的虚拟机(VM)，对整个集群系统中所有VM进行监控和管理，并根据实际资源使用情况对资源池灵活分配和调度。
分布式并行架构是云计算的另一个核心技术，用于将大量的机器整合为一台超级计算机，提供海量的数据存储和处理服务。整合后的超级计算机通过分布式文件系统、分布式数据库和MapReduce技术，提供海量文件存储、海量结构化数据存储和统一的海量数据处理编程方法和运行环境[1-3]。
2 虚拟化技术
虚拟化技术主要分为两个层面：物理资源池化和资源池管理。其中物理资源池化是把物理设备由大化小，将一个物理设备虚拟为多个性能可配的最小资源单位;资源池管理是对集群中虚拟化后的最小资源单位进行管理，根据资源的使用情况和用户对资源的申请情况，按照一定的策略对资源进行灵活分配和调度，实现按需分配资源[4-7]。
2.1 物理资源的池化
云计算平台如图1所示。物理硬件设备的虚拟化对象包括服务器、存储、网络、安全等多个方面，不同的虚拟化技术从不同角度解决系统的各种问题。
(1)服务器虚拟化
服务器虚拟化对服务器进行资源虚拟和池化，将一台服务器虚拟为多个同构的虚拟服务器，同时对集群中的虚拟服务器资源池进行管理。
(2)存储虚拟化
存储虚拟化主要是对传统的存储区域网络(SAN)、网络附加存储(NAS)设备进行异构，将存储资源按类型统一集中为一个大容量的存储资源，并将统一的存储资源通过分卷、分目录的权限和资源管理方法进行池化，然后将虚拟存储资源分配给各个应用使用，或者是直接分配给最终用户使用。
(3)网络虚拟化
网络虚拟化将一个物理网络节点虚拟成多个虚拟的网络设备(交换机、负载均衡器等)，并进行资源管理，配合虚拟机和虚拟存储空间为应用提供云服务。
2.2 资源池的管理和使用
资源池由云管理平台实现统一的管理、调度和监控，涉及云平台的合理使用和维护管理。云管理平台共分为4个管理层面，分别为：设备的管理、虚拟资源的管理、服务的管理和租户管理。
(1)设备管理
设备管理为云计算平台的硬件设备提供管理和告警功能，主要包括系统管理员在日常的维护工作中查询各物理设备性能情况，并对如应用服务器的CPU使用率、内存使用率、硬盘使用率、网络接口使用率、存储设备的空间使用率、IO情况等关键指标进行监控。用户可以根据应用物理设备的实际配置，设置相应的监控阈值，系统会自动启动对相应指标的监控并报警。
(2)虚拟资源管理
虚拟资源管理为各种应用提供虚拟资源的统一管理、资源分配和灵活调度，同时还包括系统管理员在日常的维护工作中查询各个最小虚拟资源的性能情况，并对应用虚拟机的CPU使用率、内存使用率、硬盘使用率、网络接口使用率，虚拟存储(如亚马逊的EBS)的空间使用率、IO情况等关键指标进行监控。用户可以根据虚拟资源的实际配置，设置相应的监控阈值，系统会自动启动对相应指标的监控并报警。
(3)服务管理
服务管理包括服务模板、服务实例、服务目录等管理。服务管理在虚拟资源的基础上，快速向租户提供用户指定的操作系统、应用软件等软件资源。
(4)租户管理
租户管理对每一个租户对应的资源群进行管理，内容包括资源的种类、数量、分布情况等，同时对租户生命周期进行管理，包括租户的申请、审核、正常、暂停、注销等。
2.3 集群的故障定位与维护
Google的集群维护方式给我们留下了深刻的印象，维护人员推着小推车对损坏的机器进行更换，故障定位通过定制PC的故障灯进行判断(在通用的因特网数据中心(IDC)应用中，计算资源通常使用通用PC机)。目前所有的云平台对物理机和虚拟机的监控、告警，都是按照机器的IP地址作为机器的编号进行管理。对于承载着虚拟机的物理机而言，其Host OS模块的IP地址对应和代表着物理机器在集群中的唯一标志。IP地址的分配一般采用两种方式：采用动态主机配置协议(DHCP)方式自动获取;通过手工指定方式确定。由于集群中机器很多，手工指定工作量非常巨大，因此通常采用DHCP的方式对IP地址进行分配。
但是维护人员在云管理平台上发现物理设备出了故障，维护人员无法通过IP地址对应到故障机器的具体物理位置，通用的PC机又没有故障灯等辅助定位手段。定位故障机器的物理位置并更换或维护它成为一个复杂和繁琐的过程。
在的虚拟化集群中，可以采用简单而有效的方法解决此问题。对于每一台物理机器，配置一个USB接口的KEY，KEY中保存了物理机器的位置信息，同时 USB KEY与物理位置直接绑定(如绑在机架上)。机器在启动时，会到USB KEY中读取物理位置信息，根据读取的物理位置信息，依据固定的算法和物理信息算出机器的IP地址，并在管理平台中体现。这样，每个物理机器的IP地址就与物理位置绑定，在物理机器故障时，维护人员在云管理平台可以准确获取故障机器的IP地址和物理位置。
2.4 资源池的分组与异构
对于服务器的虚拟化，由于架构不同，SUN、IBM等厂家的小型机虚拟化都采用相互独立的架构，与基于X86架构的虚拟化系统(如XEN、KVM等)无法兼容，因此造成了资源浪费。[!--empirenews.page--]
对于服务器虚拟化的异构问题，可以从两个层面去解决：(1)通过资源池的分组，对不同架构的服务器和小型机进行虚拟化，不同架构的资源池归于一个独立的组，针对不同的应用，分配特定的虚拟机资源。(2)通过业务的定制和调度，将不同架构的虚拟化平台通过管理融合，实现异构虚拟机的调度。
异构资源池如图2所示。在云计算平台中，把IBM的PowerSystems小型机集群通过IBM的PowerVM系统虚拟为基于 PowerSystems架构的计算资源池，把HP的小型机集群通过HP的VSE系统虚拟为基于HP架构的计算资源池，把X86架构的计算资源通过 XENKVM系统虚拟为基于X86的ZXVE资源池。在业务部署时，不同的应用的可以根据自己的业务特点和操作系统特点，选择性地部署在不同的资源池上，从而实现虚拟化对各类小型机的异构。X86架构的计算资源池、PowerSystems架构的计算资源池和HP架构的计算资源池分别受各自的虚拟化管理软件(如VMM、IVM和gWLM)管理。在VMM、IVM和gWLM的上层，可以通过融合的虚拟化管理器(iVMM)，对3个计算资源池进行统一管理。
图3所示为虚拟资源对应用实现异构的方法。此方法的核心在于4个方面：iVMM、业务调度器、业务系统针对不同的资源池架构提供应用功能相同的不同版本、iVMM和业务调度器之间的OCCI扩充接口。
在业务应用层面，针对业务系统，本文增加业务调度器模块。业务调度器根据业务的繁忙程度，向iVMM申请增加或减少虚拟机资源，并调整负载均衡策略。业务系统针对不同的资源池架构，需要准备与之对应的功能相同的不同版本。OCCI扩充接口的工作流程为：
业务系统的业务调度器通过OCCI接口向云计算平台申请资源，同时向云计算平台提供业务系统可以支持的操作系统等信息，并提供优先级信息。
云计算平台根据业务系统的请求和云内资源的空闲情况，分配计算资源，通过OCCI接口通知业务调度器云计算平台向业务系统提供了何种架构的计算资源。
业务调度器根据申请到的资源情况，将业务处理机的操作系统、业务版本等模板信息通过OCCI接口通知云计算平台，由云计算平台进行操作系统和业务程序的部署，完成后提交给业务系统进行使用。
3 分布式技术
分布式技术最早由Google规模应用于向全球用户提供搜索服务，因此必须要解决海量数据存储和快速处理的问题。其分布式的架构，可以让多达百万台的廉价计算机协同工作。分布式文件系统完成海量数据的分布式存储，分布式计算编程模型MapReduce完成大型任务的分解和基于多台计算机的并行计算，分布式数据库完成海量结构化数据的存储。互联网运营商使用基于Key/Value的分布式存储引擎，用于数量巨大的小存储对象的快速存储和访问。
3.1 分布式文件系统
分布式文件系统的架构，不管是Google的GFS还是Hadoop的HDFS，都是针对特定的海量大文件存储应用设计的。系统中有一对主机，应用通过文件系统提供的专用应用编程接口(API)对系统访问。分布式文件系统的应用范围不广的原因主要为：主机对应用的响应速度不快，访问接口不开放。
主机是分布式文件系统的主节点。所有的元数据信息都保存在主机的内存中，主机内存的大小限制了整个系统所能支持的文件个数。一百万个文件的元数据需要近 1G的内存，而在云存储的应用中，文件数量经常以亿为单位;另外文件的读写都需要访问主机，因此主机的响应速度直接影响整个存储系统的每秒的读入输出次数 (IOPS)指标。解决此问题需要从3个方面入手：
(1)在客户端缓存访问过的元数据信息。应用对文件系统访问时，首先在客户端查找元数据，如果失败，再向主机发起访问，从而减少对主机的访问频次。
(2)元数据信息存放在主机的硬盘中，同时在主机的内存中进行缓存，以解决上亿大文件的元数据规模过大的问题。为提升硬盘可靠性和响应速度，还可使用固态硬盘(SSD)硬盘，性能可提升10倍以上。
(3)变分布式文件系统主机互为热备用的工作方式为1主多备方式(通常使用1主4备的方式)，通过锁服务器选举出主用主机，供读存储系统进行改写的元数据访问服务，如果只是读访问，应用对元数据的访问将被分布式哈希表(DHT)算法分配到备用主机上，从而解决主机的系统“瓶颈”问题
对于分布式文件系统，外部应用通过文件系统提供的专用API对其进行访问，这影响了分布式文件系统的应用范围。对于标准的POSIX接口，可以通过 FUSE的开发流程实现，但将损失10%~20%的性能。对于网络文件系统(NFS)，在实现POSIX接口的基础上，可以直接调用Linux操作系统的 NFS协议栈实现。
3.2 Key/Value存储引擎
Key/Value存储引擎最大的问题在于路由变更后，数据如何快速地实现重新分布。Key/Value存储引擎如图4所示。可以引进虚拟节点的概念，将整个Key值映射的RING空间划分成Q个大小相同的Bucket(虚拟节点，Key的映射算法推荐采用MD5)。每个物理节点根据硬件配置情况负责多个 Bucket区间的数据。同一个Bucket上的数据落在不同的N 个节点上，通常情况下N =3。我们将DCACHE的Q设定成10万，即把整个RING空间分成了10万份，如果整个DCACHE集群最大容量为50 TB，每个区间对应的数据大小仅为500 MB。对500 MB的数据进行节点间的迁移时间可以少于10 s。图4中，N =3，Bucket A中的数据存储在B、C、D 3个节点。
Key/Value存储引擎是一个扁平化的存储结构，存储内容通过Hash算法在各节点中平均分布。但是在一些应用中，业务需要对Key/Value存储引擎进行类似目录方式的批量操作(如在CDN项目中，网站向CDN节点推送内容时，需要按照网页的目录结构进行增加和删除)，Key/Value存储引擎无法支持这样的需求。可以在Key/Value存储引擎中增加一对目录服务器，存储Key值与目录之间的对应关系，用于对目录结构的操作。当应用访问 Key/Value存储引擎时，仍然按照Hash方式将访问对应到相应的节点中，当需要目录操作时，应用需要通过目录服务器对Key/Value存储引擎进行操作，目录服务器完成目录操作和Key/Value方式的转换。由于绝大多数项目中，大部分为读操作，因此目录服务器参与对Key/Value引擎访问的次数很少，不存在性能“瓶颈”。[!--empirenews.page--]
4 结束语
云平台的构建是一个具有挑战性的课题，本文详细描述了虚拟化和分布式架构两大核心技术。在基础设施即服务(IaaS)层面，着重描述了虚拟化技术，以及异构的虚拟化云计算平台的建设和应用，同时介绍了云管理平台的功能。在分布式技术方面，介绍了分布式文件系统和Key/Value存储引擎。对于分布式文件系统，本文着重介绍了主机“瓶颈”解决方案及存储接口标准化的想法;对于Key/Value存储引擎，本文提出了用于目录化存储的解决方案。
