基础设施层将经过虚拟化的计算资源、存储资源和网络资源以基础设施即服务的方式通过网络提供给用户使用和管理。虽然不同云提供商的基础设施层在所提供的服务上有所差异，但是作为提供底层基础lT资源的服务，核层一般都具有以下基本功能。

　　1 资源抽象

　　当要搭建基础设施层时，首先面对的是大规模的硬件资源，比如通过网络相互连接的服务器和存储设备等。为了能够实现高层次的资源管理逻辑，必须对资源进行抽象，也就是对硬件资源进行虚拟化。

　　虚拟化的过程一方面需要屏蔽掉硬件产品上的差异，另一方面需要对每一种硬件资源提供统一的管理逻辑和接口。值得注意的是，根据基础设施层实现的逻辑不同，同一类型资源的不同虚拟化方法可能存在着非常大的差异。例如，存储虚拟化方面有IBM SAN Volume Controller、IBM Tivoli Storage Manager(TSM)、Google File System、HadoopDistributed FileSystem和VMware Virtual MachineFile System等几种主流的技术。

　　另外，根据业务逻辑和基础设施层服务接口的需要，基础设施层资源的抽象往往是具有多个层次的。例如，目前业界提出的资源模型中就出现了虚拟饥、集群(Cluster)和云(Cloud)等若干层次分明的资源抽象。资源抽象为上层资源管理逻辑定义了被操作的对象和粒度，是构建基础设施层的基础。如何对不同品牌和型号的物理资源进行抽象，以一个全局统一的资源池的方式进行管理并呈现给客户，是基础设施层必须解决的一个核心问题。

　　2 资源监控

　　资源监控是保证基础设施层高效率工作的一个关键功能。资源监控是负载管理的前提，如果不能对资源进行有效监控，也就无法进行负载管理。基础设施层对不同类型的资源监控的指标不同。对于cpu，通常监控的是cpu的使用率。对于内存和存储，除了监控使用率，还会根据需要监控读写操作频率。对于网络，则需要对网络实时的输入、输出流量、可获得带宽及路由状态进行监控。

　　基础设施层首先需要根据资源的抽象模型建立一个资源监控模型，用来描述资源监控的对象及其度量。Amazon公司的CloudWatch是一个给用户提供监控Amazon EC2实例并负责负载均衡的Web服务，该服务定义了一组监控模型，使得用户可以基于模型使用监控工具对EC2实例进行实时监测，并在此基础上进行负载均衡决策。

　　同时，资源监控还具有不同的粒度和抽象层次。一个典型的场景是对包括相互关联的多个虚拟资源的某个具体的解决方案整体进行资源监控。整体监控结果是对解决方案各个部分监控结果的整合。通过对结果进行分析，用户可以更加直观地监控到某个解决方案整体资源的使用情况及其对解决方案整体性能的影响，从而采取必要的操作对解决方案进行调整。

　　3 负载管理 

　　 在基础设施层这样大规模的集群资源环境中，任何时刻参与节点的负载都是起伏不定的。如图4.2左所示为负载管理之前某个时刻负载分布状况。

　　一般来说，节点之间的负载允许存在一定的差异和起伏，它们的负载在一定程度上不均匀也不会导致严重的后果。然而，如果太多节点资源利用率过低或者节点之间负载差异过大就会造成一系列突出洲问题。一方面，如果太多节点负载过低，会造成资源使用上的浪费，需要基础设施层提供自动化的负载平衡机制将负载进行合并，提高资源使用率并且关闭负载整合后闲置的资源。另一方面，如果有些节点的负载过高，上层服务的性能将会受到影响。一般来说，理想的处理器负载在60%-80%之间，基础设施层的自动化负载平衡机制可以将负载进行转移，即从负载过高节点转移部分负载到负载过低节点，从而使得所有的资源在整体负载和整体利用率上面趋于平衡，尽量将服务器负载控制在理想范围内。图4.2右所示即为负载平衡后的负载分布状况。

　　4 存储管理

　　在基础设施层的存储有两个主要用途:1)存储虚拟机的镜像文件;2 )保存云中虚拟机系统所保存的应用业务数据。

　　一个典型的基础设施服务上面会运行成千上万个虚拟机，每个虚拟机都有自己的镜像文件。通常一个镜像文件的大小会在l0个GB左右，随着虚拟机的运行过程中业务数据的产生，存储往往还会增加。基础设施云对镜像文件存储有着巨大的需求。

　　另外，在云中运行的虚拟机内部的应用程序通常会有存储数据的需要。如果将这些数据存储在虚拟机内部则会使得支持高可用性变得非常闲难。为了支持应用的高可用性，可以将这些数据都存储在虚拟机外的其他地方，当虚拟机不可用时直接快速启动另外一个相同的虚拟机实例井使用之前在虚拟机外存储的数据。为了保证虚拟机动态迁移的性能，通常会让不同硬件服务器上的虚拟机管理器使用共享存储。这些存储设备需要通过高速I/O网络和传输协议链接起来，比如iSCSI。因此，基础设施即服务云通常也会提供相应的存储服务来保存应用业务数据，比如AmazonS3。

　　5 资源部署

　　资源部署指的是通过自动化部署流程将资源分配给上层应用的过程，即使基础设施服务变得可用的过程。在应用程序环境构建初期，当所有虚拟化的硬件资源环境都已经准备就绪时，就需要进行初始化过程的资源部署。另外，在应用运行过程中，往往会进行二次甚至多次资源部署，从而满足上层应用对于基础设施层中资源的需求，也就是运行过程中的动态部署。

　　在云计算基础设施层，动态部署有多种应用场景。一个典型的场景就是实现基础设施层的动态可伸缩性，也就是说云的应用可以在极短的时间内根据用户需求和服务状况的变化而调整。当用户应用的工作负载过高时，用户可以非常容易地将自己的服务实例从数个扩展到数千个，并自动获得所需要的资源。通常这种伸缩操作不但要在极短的时间内完成，还要保证操作复杂度不会随着规模的增加而增大。另外一个典型场景是故障恢复和硬件维护。在云计算这样由成千上万服务器组成的大规模分布式系统中，硬件出现故障在所难免，在硬件维护时也需要将应用暂时移走。基础设施层需要能够复制该服务器的数据和运行环境并通过动态资源部署在另外一个节点上建立起相同的环境，从而保证服务从故障中快速恢复过来。

　　资源部署的方法也会随构建基础设施层所采用技术的不同而有着巨大的差异。使用服务器虚拟化技术构建的基础设施层和未使用这些技术的传统物理环境有很大的差别，前者的资源部署更多是虚拟机的部署和配置过程，而后者的资源部署则涉及了从操作系统到上层应用整个软件堆栈的自动化安装相配置。相比之下，采用虚拟化技术的基础设施层资源部署更容易实现。

　　6 安全和风险管理

　　在基础实施层，安全管理的目标是保证基础设施资源被合法地访问和使用。在个人电脑上，为了防止恶意程序通过网络访问计算机中的数据或者破坏计算机，一般都会安装防火墙来阻止潜在的威胁。数据中心也设有专用防火墙，甚至通过规划出隔离区来防止恶意访问入侵。云计算需要提供可靠的安全防护机制来保证云中的数据和操作安全，并提供安全审查机制保证对云中数据的操作都是经过授权的并且是可被追踪的。

　　另外，云计算环境对于用户来讲，也存在着一些其它风险，Gartner发布了一份名为《云计算安全风险评估》的报告，其中列出了云计算技术存在的七大风险。即特权用户的接人、可审查性、数据位置、数据隔离、数据恢复、凋查支持和长期生存性。

　　Gartner报告中所提到的云计算环境中存在的这些风险，并不是说在传统环境中就不存在，而是说有些风险在云计算中更为明显或更有挑战性;也不是说这些风险仅存在于基础设施展中，而是可能存在于云计算的各个服务层次。在这里我们以长期生存性举例，介绍在基础设施层进行风险管理的必要性。传统方式中，当客户买了某个软件提供商的产品时，并不是说将来这个软件提供商就一定不会倒闭或者被兼并，只不过由于软件产品市场相对成熟，通常可以比较容易地找到替代产品，从而相应的风险是可控的。由于目前云计算还处于初级发展阶段，很多服务都没有标准化，因此市场上能够相互兼容相互替代的产品还不是很多。在这种情况下，云计算服务长期生存性的风险就相对更大了。对于用户前言，在选择云计算服务的时候，只要对可能的风险有充分的认识并制定好应对措施，风险是可以很好控制的。再比如数据恢复风险，客户需要认识到灾难会给自己的数据和服务带来怎样的影响，了解云计算提供商是否能够应对数据损失风险并采取相应的恢复措施，也需要知道在风险发生时自身应采取何种数据恢复措施从而避免损失。　

　　7 计费管理

　　云计算作为一种信息技术与传统的信息技术相比，云计算只有让用户以更低的成本获得更高的价值才能够得到用户的认可，从而蓬勃发展起来。因此，合理的计费模式非常重要。云计算倡导”按使用虽计费”的模式。

　　目前，面向公众提供服务的基础设施云主要的计费模式是依据某个时间段内应用所消耗的存储、网络、内存等资源向用户收费。实现这种计费模式有两种方式:1)实时计费，真正用多少资源就收多少费;2为用户预设几种固定资源配置类型，每种类型都有单位时间内的计费标准，用户选择一种类型使用并根据使用时间长短进行付费。第一种方式对各种资源使用的监控准确度要求很高，因此很少被真正采用;而第二种是一个相对折中的办法，使用时间长短和所选择的资源配置类型是计费变量，实施起来比较容易，因此被广泛采用。

　　实际上，计费管理不仅仅是基础设施层所需要的，而且是云计算不同的层次稠服务类型都需要的。当然，在不同的层次和服务类型上，计费所选择的变量是不同的，而相同之处在于都需要依据对相应服务的使用时间进行费用计算。例如，在平台层，计费是以对平台的使用为核心的。一种计费方式是基于应用程序对资源的使用状况进行计费，比如Google App Engine，计费方式与基础设施层类似;另一种计费方式是基于软件的许可证的。与传统的许可证计费方式略有不同的是，新的许可证计费模式会结合基础设施层资源的使用状况采制定计费标准。比如表4.1列出了IBM软件在AmazonEC2上面的计费标准。表4.1表明，IBM软件在EC2上的计费标准是与EC2实例类型相关的。