CloudSim 云计算模拟环境使用说明

CloudSim:一个模拟与仿真云计算环境和

评估资源调度算法的工具集

Rodrigo N. Calheiros1, 3, Rajiv Ranjan2, Anton Beloglazov1, César A. F. De

Rose3,andRajkumar Buyya1

1 Cloud Computing and Distributed Systems (CLOUDS) Laboratory

Department of Computer Science and Software Engineering

The University of Melbourne, Australia 2 School of Computer Science and Engineering The University of New South Wales, Sydney, Australia

3Department of Computer Science

Pontifical Catholic University of Rio Grande do Sul

Porto Alegre, Brazil

Email:rncalheiros@ieee.org,rajiv@unsw.edu.au,cesar.derose@pucrs.br,{abe,raj}@csse.unime

lb.edu.au

摘要：近两年来，云计算技术取得很大进步，它是一种基于使用付款模式将计算机基础设施和应用作为服务提供给终端用户。云计算可以根据时间变化权衡虚拟服务即使处于多条件需求（工作负载模式和QoS）。云计算模式下的应用服务有复杂的供应、组成、配置和部署条件。当系统和用户配置和需求处于动态变化的条件下，评估云供应政策、应用工作负载模式和资源性能模式的性能是很难实现的。为了克服这一挑战，我们提出了云仿真平台cloudsim：一个可伸缩的仿真工具集可实现云计算系统和应用供应环境的模拟与仿真。Cloudsim都支持云计算系统组件的系统和行为建模，例如数据中心，虚拟机和资源调度策略等。它可以快速简易的实现一般的应用调度技术。目前，cloudsim都支持单一网络和交互网络组成的云计算环境的建模与仿真。此外，还实现了为基于交互网络云计算场景分配虚拟资源的政策和调度提供了通用接口。许多诸如来自USA的HP Lab组织的研究者都使用cloudsim用于对云资源调度和数据中心节能管理的研究。通过一个案例研究基于Cloudsim平台证明了基于混杂云环境下应用服务的动态调用的有效性。案例研究结果表明联合云计算模型大大改善了动态资源和服务需求模型下的应用QoS需求。 1介绍 云计算将可用的、可扩展的、按需付款模式的IaaS、PaaS、SaaS提供给用户。近期来自伯克利大学的报告阐述了这些服务的重要性，报告中说道：“云计算，计算作为工具的长期战略很有可能改变大多数的IT产业，使得软件作为服务更具有吸引力。” 云计算作为下一代数据中心，目的是希望实现动态、灵活的应用供应。通过作为虚拟网络服务（硬件、数据库、用户接口和应用逻辑）来提高数据中心处理能力从而使用户可以根据需求和服务质量要求在互联网的任何地方访问和部署应用。同时，一些拥有创新想法的应用服务的IT公司也不再需要在硬件和软件设施上给予大规模的资金投入。仅仅通过云中应用租用平台，他们就可以免费获得所需的基本的硬件和软件设施。从而可以将全部精力投入到他们应用服务的业务价值的创新和创造。 一些传统和基于云的新兴应用服务包括了社交网络、web租用、内容交付和实时基础数据处理。这些应用都有不同的组件、配置和部署条件。根据现有条件在异构真实的云计算环

境（比如EC2，Azure,GAE）下对不同应用模式来量化（评价）供应（调度和分配）策略的性能是非常困难的。因为⑴云计算需要满足多变需求、供应模式、系统大小、资源（软件，硬件，网络等）⑵用户处于一个复杂、动态、满足QoS要求的环境⑶应用要求多变性能，工作负载，动态可伸缩条件。而对于真实的基础设施诸如EC2和Azure的使用在多变条件下确定应用的性能则常常受到特定严格的基础设施的限制。因此，这导致试验结果难以得到保证。此外在大规模的云计算基础设施下重复配置参数运行多次测试也是乏味和耗费时间的。由于这些限制的缘故，导致了基于云环境试验的流行，它不受开发者应用服务的限制，这样使得没必要基于真实云计算环境下做重复、可信赖、可伸缩试验来评测其性能。 一个更可行、可代替的方法是使用仿真工具。这些工具展示了在异构可控制的环境下方便地重复产生结果用来评估提出的假设的可能性。基于仿真的方法为IT公司（或者任何想通过云提供应用服务的人）提供了巨大的便利，因为这样可以允许他们：⑴可在重复和可控制的环境下测试他们的服务⑵在部署到真实云中前调整系统瓶颈点⑶为开发和测试适合的应用供应技术，基于仿真基础设施在不同混合工作负载和资源性能场景下做实验。 考虑到目前没有一个分布式系统仿真平台（如Grid和Network）提供了用于直接模拟云计算环境的环境。我们提出了CloudSim：一个新的，普遍的合可扩展的仿真框架，该平台实现了无缝的对新兴云计算基础设施和应用服务的模拟、仿真、试验。通过使用CloudSim，研究者和企业开发者可以在异构可控和简单安装的环境下测试新开发出来的应用服务的性能。根据CloudSim结果的评估，可以对服务性能做进一步更好的改进。使用CloudSim为初始化性能测试的主要好处有：⑴时间效率：仅仅需要很少的经历和时间搭建基于云应用供应测试环境⑵灵活性和适用性：开发者可以用很少的编程和部署经历在负责的云环境（EC2，Azure）去模拟和测试他们应用服务的性能。 CloudSim提供了以下新的特性：⑴支持大规模的云计算环境的模拟与仿真，包括数据中心，单一物理计算节点⑵为模拟云、服务代理、供应、分配策略提供独立的平台⑶支持在模拟系统元素间仿真网络连接⑷具有在联合的云环境下仿真的功能，私有和公共领域的混合网络资源，对有关Cloud-Bursts和自动应用伸缩的关键功能的研究。CloudSim一些独特功能有：⑴使用虚拟化引擎帮助在数据中心节点的多样的、独立的、租用的虚拟服务的创建和管理⑵实现空间共享和时间共享下对处理单元分配给虚拟服务的灵活转换。CloudSim的这些新特性将促进云计算下应用调度算法的发展。 本论文的主要贡献有：⑴给出了模拟云计算环境和测试应用服务性能的整体框架⑵建立了端到端的云网络体系，利用BRITE拓扑模拟链接带宽和相关潜在因素。对应CloudSim框架，我们有如下发现：⑴支持大规模仿真环境，而在初始化和内存消耗上花费的很少或不需要考虑⑵对模拟定制化云计算环境（联合/非联合）和应用供应技术（Cloud Bursts，energy conscious/non-energy conscious）可实现轻易扩展。 论文剩余部分由以下组成：首先，对云计算进行大概描述，以及现有模式和他们的层次结构设计，该部分结尾对已存在的流行的分布式系统仿真和模拟做了简单总结。然后对CloudSim框架的体系结构做了详细描述。Section4描述了CloudSim组件的整体设计。Section5描述了一系列在成功仿真云计算环境下对CloudSim性能的检测试验。Section6对正在使用或已使用CloudSim做研究和开发的项目做一个简单描述。最后论文对未来研究发展方向做了简单的总结和讨论。 2.背景 这部分从多方面阐述了形成云计算系统体系的基础背景信息。同时也阐述了需要通过拥有一个或多个云服务提供商的多种的、跨地区分布式数据中心扩展所需的条件。CloudSim框架目的是为了简化和加快实验云计算作为应用供应环境来组成实验研究的过程。因为由于其大规模和复杂性来使用真实的云基础设施搭建实验平台是非常的耗时的。

2.1云计算 云计算可以地定义为“一类由一系列内部连接和虚拟化计算机组成的并行分布式系统，可提供动态供应和通过服务提供者和使用者的协商建立起来的基于SLA的作为一个或多个统一计算资源来阐述”[13],一些新兴的云计算基础设施/平台有Microsoft Azure [1], Amazon EC2, Google App Engine, and Aneka [2]. 云平台必需具备的一个特性是为了满足多变的需求可以动态的增加或减少对应用的资源提供，可以是可预见的、日夜可访问观察到的；也可以是不可预见的，如当某个应用服务的流行而导致要求资源供应的增长。云的这种能力对可伸缩应用（如web租用，内容传递，社交网络等）对此行为敏感的非常有用。 这些应用通常表现为瞬时行为和因为时间因素和用户交互模式而有不同的QoS条件。因此，动态供应技术的发展保证了这些应用在满足瞬时条件的前提下达到QoS。 尽管云计算被认为支持弹性应用的平台，它仍然面临相关核心问题的限制，例如所有权、规模和本地化。例如，一个云仅仅在给定的时间内提供有限的租用能力（虚拟机和计算服务）给应用服务，因此在某个时间段伸缩应用容量变得十分复杂。所以，在那些需要过高云容量的情况下，云中应用租用需对用户在QoS上进行妥协。解决这个问题的一个办法是在网络之间将多云作为一个联合组织并开发出下一代动态供应技术，这样可以从该体系结构中获得利润。这些跨地域的分布式云的联合可以基于他们中已满足条件的基础上组成，来有效应对服务需求的多样性。通过应用服务的透明整合到云联合中将进一步有效实现用户SLAs，更加接近于原始请求。 混合云是私有云和公共云的组合。私有云和公共云的主要区别在于所有权类型和他们所支持的访问权限的不同。访问私有云资源仅仅局限于属于用户云服务组织的那些用户，而公共云资源对互联网中任何感兴趣的用户都可用，根据按需付费模式使用。因此，中小企业和政府都以探索公共云需求驱动供应开始，与此同时，利用已有的计算基础设施（私有云）来解决暂时多变的服务需求。这种模式尤其适用于那些仅仅在特殊时期需要超大计算能力（如后台作业处理和事务分析）的中小企业（SMEs）和银行。然而，针对任何云部署模式（私有、公共、混合等）编写和开发应用软件是非常复杂和艰难的。基于云的应用供应还有一些相关关键挑战：服务传递、监测，虚拟机、应用和负载均衡的部署。在整个云操作过程中，每个元素的影响对运行隔离，评估和复制都不是很重要的。Cloudsim通过提供每种元素在可控制和可重复执行的行为下进行数据测试的平台，以此减轻了这些困难。所以上，诸如cloudsim这些仿真框架是很重要的，因为它们允许在不同的使用和基础设施可用场景下评估资源管理和应用调度技术的性能。 2.2层次设计（Layered design） 图1显示了云计算体系结构的层次设计。实际物理资源与核心中间件共同构成了IaaS和PaaS的基础。而用户层中间件主要提供SaaS功能。最上层则集中于应用服务SaaS，其充分利用更低层提供的服务。Paas/SaaS通常以第三方服务提供商开发和提供，与IaaS不同。

Cloud Application：该层的应用直接对终端用户可用。这里我们定义终端用户指通过网络使用SaaS应用的群体。这些应用可以是云提供商提供，终端用户通过订阅模式或按需付费形式进行访问；用户也可以在这层部署自己的应用。诸如Salesforce.com在云中提供业务流程模式（即CRM）和社交网络的应用就属于前者形式。而后者形式的有e-Science、e-Research和Content-Delivery Networks。

User-Level Middleware：该层包括了如Web2.0接口（Ajax，IBM Workplace）的软件构架用来帮助开发者创建基于浏览器模式的丰富、低成本的用户接口的应用。该层也提供了一些编程环境和组件用于减轻在云中创建、部署和执行应用的难度。最后，这层的一些框架也支持多层应用开发，如Spring和Hibernate，使能够支持应用运行在更上层。 Core Middleware：该层实现了平台等级服务，提供了租用和管理用户等级应用服务的运行环境。该层的核心服务包括动态SLA管理，Accounting、Billing、执行监督和管理、费用。运行在该层比较有名的服务有Amazon EC2、GAE和Aneka。该层的功能即可被SaaS（图1中的最高层的服务）访问，也可被IaaS（图1中最底层的服务）访问。该层关键的功能包括消息传递，服务发现和负载均衡。这些功能通常由云提供商实现和应用开发者额外提供。例如，Amazon为Amazon EC2的开发者和用户提供了一个负载均衡器和监测服务（Cloudwatch）。类似的，开发者在Azure云搭建应用时也可使用.Net服务总线用来实现消息传递机制。

System Level：云环境中的计算能力是由一组数据中心提供的，这些数据中心是由成百上千的主机组合而成的。在该层，存在大量物理资源（存储服务和应用服务）为数据中心供应。这些服务由上层虚拟化服务和工具进行透明管理，使允许通过虚拟服务共享他们的容量。这些VMs相互之间也是独立的，因此使容错技术和独立文本的安全性有保障。 2.3云联合（Federation（Inter-Networking of clouds）） 目前云计算提供商在全球不同的地区都有一些数据中心，目的是为了通过互联网满足来自全世界的消费者需求。然而，已有系统在不支持在不同的数据中心之间为租用应用服务在达到可接受的QoS水平选择最优方案上实现动态协同负载平衡的机制和政策。甚至，云服务提供商业不能够预测分布在多地区的终端用户使用他们的服务，因此负载协调必须是自动

发生的，以及服务的分配必须是根据负载行为动态响应的。图2描述了一个云计算体系结构，该结构由服务消费者代理和提供者协调器组成，可以支持云在交互网络中进行效用驱动：应用供应和工作负载转移。

在交互网络中对分布云进行联合管理具有非常高的性能和财政利润，例如：（ⅰ）通过寻找最优的服务配置和规模改善SaaS提供商满足用户QoS等级的能力和服务完善（ⅱ）通过允许用户从联合网络中动态获得额外资源来增强峰值负荷处理能力和每个云用户动态系统伸展能力。这也免除了云提供商必须在每处都要建立一个新的数据中心的麻烦（ⅲ）由于云提供商可以无缝的整合他们的服务到联合网络中的其他地方，使得更能适应当自然灾害和常规的系统维护，这样可以避免违反SLA和导致赔偿。因此，联合云不仅保证了业务的连续性，也增强了参与云的提供商的可靠性。

图2描述了体系结构的一个关键组件，就是云协调器（cloud coordinator）。这个组件是当系统中每个云的职责是进行以下重要活动时才实例化的：⑴输出云服务给联合网络，包括基础设施层和平台层⑵记录云资源（VMs，计算服务）的负载和在联合云中与其他云提供商进行协调以解决在本地云对资源突然增长的需求⑶监测应用执行的生命周期和审查是否满足SLAs。云代理代表SaaS提供商来确定在云交易中是否有匹配的云服务提供商。还有，云代理也能够商议来分配资源的各云协调器是否满足租用的QoS需求或者是否被SaaS应用租用。云交易（CEx）扮演了一个市场制造商将云服务（IaaS）和SaaS提供商聚集在一起。云交易负责从云代理器聚集对基础设施的需求和通过云协调器评估当前可用供应是否满足它们的需求。

诸如社交网络Facebook、MySpace和Content Delivery Networks（CDNs）这些应用都可以从上述的联合云计算基础设施受益。社交网站服务于数百万用户，而且他们访问网站时间和交互模式都很难预测。一般而言，社交网络的网站是使用多层web应用如WebSphere和持久层如MySql关系数据库建立起来的。通常，每个组件都运行在不同的虚拟机下，这些虚拟机可以租用不同的云计算提供商。此外，每个插件开发商可以自由的选择更适合运行其插件的云计算提供商提供的服务。总而言之，一个典型的社交网络web应用可以由数百个不同的服务组成，也就是说可以租用世界上许多面向云结构的数据中心。无论何时有变化，当

工作负载暂时或本地空间收限制，每个应用组件都必须动态扩展为用户提供好的体验。 领域专家和科学家也可以充分利用这些机制，通过使用云为他们高吞吐量的e-Science应用获得资源，例如Monte-Carlo仿真和医学图像注册。在这些场景下，云能够在已有的集群和基于资源池的网格下加快研究预期进度时间。 2.4相关工作

在过去的十几年，网格一直作为为计算和数据敏感的科学应用提供高性能服务的基础设施发展而来。为支持网格组件、政策和中间件的研究、开发和测试，提出了如GridSim、SimGrid、OptorSim和GangSim等网格仿真平台。SimGrid是一类基于网格平台模拟分布式应用的框架。类似地，GangSim是一个网格仿真工具，用于提供基于网格虚拟组织和资源的建模的支持。另一方面，GridSim是一个用于复杂网格资源的事件驱动的仿真工具，它支持对网格实体、用户、设备、网络包括网络阻塞的复杂建模。

尽管以上所述的工具都能够多网格应用管理行为（执行，供应，发现，监测）进行模拟与仿真，但没有一款能够满足云计算环境条件，能够清楚地隔离多层服务抽象（SaaS，PaaS，IaaS）。尤其是，在已有的网格仿真平台很少甚至几乎没有支持对虚拟可用资源和应用管理环境的建模。而云是以按需付费模式基于订阅的形式提供服务给SaaS提供商。因此，云环境模拟与仿真工具必须提供像云代理和云交易等经济实体，以实现在消费者和提供商进行实时服务交易。在本文提及的当前可用的仿真器中，只有GridSim提供了经济取得资源管理和应用供应模拟的支持。还有，已有的仿真平台没有一个提供对虚拟设施模拟的支持，它们都没有提供模拟由成百上千的计算服务组成的数据中心环境的工具。

近两年，Yahoo和HP建立了一个叫OpenCirrus的全球云计算测试平台，支持在10个组织中的数据中心的整合。建立此实验环境即耗费大量金钱又由于其共享特性很难因为资源条件的变化进行时不时重复实验。而且它们也仅仅局限于合作成员才能访问。因此，仿真环境起了很重要的作用。

由于云计算R&D仍处于不成熟阶段，根据云计算分层体系结构还有一系列重要的问题仍需进行详细的调查研究。比较关注的方面包括根据终端用户请求、云合作商和联合云对虚拟资源供应提出经济、节能策略。为支持和加快对相关云计算系统、应用和服务的研究，设计和开发一些必须的软件工具来帮助研究者和企业开发者是很重要的。 3.CloudSim Architecture

图3显示了CloudSim软件框架的多层设计以及其体系结构组件。Cloudsim初始版本使用SimJava作为离散时间仿真引擎，可支持一些核心函数如事件队列和处理，云系统实体的创建（服务、主机、数据中心、代理器、虚拟机），组件间消息传递、仿真时钟的管理。然而目前版本中，SimJava层已经被去除，因为为了允许更高级的操作但它不支持。我们将在下一部分对这些高级操作进行深入讨论。

Cloudsim仿真层提供了对基于云的虚拟数据中心环境的建模与仿真的支持，包括对虚拟机、内存、容量、带宽的专用接口管理。这层要处理的基本问题包括虚拟机租用主机的供应，管理应用执行和监测动态系统状态。一个云提供商如果想要研究在分配其主机到虚拟机上不同策略的有效性，就必须在这层来实现他们的策略。这些实现策略可以通过扩展编写核心VM供应函数来实现。在这层对相关主机分配到虚拟机有明显的差别。一个云主机可以同时分配给多个虚拟机用来执行基于SaaS提供商定义的QoS级别的应用。这层也提供了对云应用开发商对执行复杂工作负载和应用性能研究的扩展的函数。在Cloudsim结构中最上层是用户代码层，该层提供了基本的主机实体类（机器数量、特性等）、应用（任务数和条件） 、VMs、用户数和应用类型、代理调度策略。在此次通过扩展给定的基本实体，一个云应用开发商可以执行以下功能：⑴生成一个混合的工作负载请求分配和应用配置⑵建立基于云的可用场景和根据自定义配置执行鲁棒性测试⑶为云和联合云实现自定义应用供应技术。

因为云计算仍然是一个新兴的分布式计算模式，在有效处理基础设施和应用水平复杂性上还是缺乏给定的标准、工具和方法。因此，在未来几年无论是学术界还是企业界都将进行努力研究，基于执行环境给出核心算法、政策和应用标准。通过扩展cloudsim已有的基本函数，研究者将能够基于特殊场景和配置环境下进行测试，允许对相关云计算的所有关键因素做最好的实践开发。 3.1Modeling the Cloud

IaaS可以通过扩展cloudsim的数据中心实体进行模拟。而数据中心实体又管理许多主机实体。这些主机根据由云服务提供商定义的虚拟分配策略分配给一个或多个虚拟机。这里，虚拟策略代表了相关VM生命周期对操作控制的策略，如将一个主机host供应给一个VM，VM的创建，VM的销毁和VM转移。类似的，根据云计算环境的应用供应条件，一个或多个应用服务可以在单一VM中供应。对于cloudsim，一个实体就是一个组件的实例化。一个Cloudsim组件可以是一个类，也可以是多个类来代表一个Cloudsim模型（数据中心，主机）。

一个数据中心能够管理多个主机，即在他们的生命周期内管理虚拟机VMs。主机在一个Cloudsim组件中代表了在云环境中的一个实际物理计算机。它分配好了预计处理能力（按MIPS计算）、内存、容量和分配给虚拟机的处理器的供应政策。主机组件实现了支持对单一节点和多节点的支持的接口。

虚拟机分配策略是在已有主机上创建VM实例的过程，主要是匹配重要特性（容量，内存）、配置（软件环境）和SaaS提供商的请求（实用区域）。Cloudsim支持自定义应用服务建模的开发，可以在一个VM实例和要求扩展核心任务集的用户的部署以此来实现他们的应用服务。此外，cloudsim对服务模型或供应技术没有过度的限制，并不是说开发者必须用此来实现和执行测试。一旦一个应用服务定义好合建立好模型后，将根据一个服务特殊分配策略将服务分配到一个或多个预先实例化的VMs上。在基于云的数据中心中，为主机host分配特殊应用的VMs由VmAllocationPolicy类服装。这个组件为研究者和开发者提供了自定义方法，用于帮助实现新的政策来达到最优目标（用户为中心，系统为中心或两者都是）。 默认情况下，VmAllocationPolicy直接使用了FCFS策略实现为主机分配虚拟机。硬件条件

（例如处理器个数，内存，容量）构成了这些供应的基础。关于其他政策（很可能由云提供商提出的）均可以在cloudsim下轻易地仿真与建模。但是，由公共云提供商（如AmazonEC2，Azure）提出的策略为被公开，因此这些算法在CloudSim未提供。 对每个主机host主件，分配多少处理器个数给VMs是根据主机分配策略来实现的。这些策略在实例化VM需考虑一些硬件特性，如CPU数，CPU共享和内存数。因此，CloudSim支持多个仿真场景，可以分配特殊的CPU核给特殊的VMs（空间共享）或者在VMs间（时间共享）动态分配CPU核数目。 每个主机组件都实例化了一个VM调度器组件，这样在为VMs分配CPU核数时或者实现空间共享或者实现时间共享。云系统/应用开发者和研究者可以根据自定义的分配政策通过实验进一步扩展VM调度器组件。在下一部分，将详细描述时间共享和空间共享。与VMs有关的基本的硬件和软件配置均在VM类中定义了。目前支持对如AmazonEC2类似的云提供商提供多个VM配置的建模。 3.2Modeling the VM Allocation 区分云计算基础设施与网格计算基础设施的一个关键因素是大规模虚拟工具和技术的部署。因此，与网格计算不同的是，云计算包括了额外层（虚拟层）来对应用服务的执行、管理和租用环境。所以说，传统的应用供应模式是独立的应用元素并不是精确地代表计算提取被分配用来计算节点的，而通常是与云资源有一定联系的。例如，假设一个云主机由一个单一处理器，然而在该主机上同时有两个VMs要求实例化。尽管实际上VMs是独立的，但他们仍然需要共享同一个处理器和系统总线。因此，对每个VM可用的硬件资源数目因为总的处理能力和云主机范围内可用系统带宽而受到限制。其中在VM供应过程中一个关键因素必须考虑的是，尽量避免当创建一个VM时在主机可用范围内需要更多的处理能力。在变化的性能隔离层次基础下允许对不同供应政策的仿真，Cloudsim支持两层VM供应：第一，在主机层和第二，在VM层。在主机层，对每个处理器多少处理能力应该分配给每个VM；在VM层，VM在租用执行范围内，分配固定的、可用的处理能力给单独的应用服务。未达到这个目标，我们假设一个抽象的应用服务作为任务单元被VM租用。 在每层中，Cloudsim实现了时间共享和空间共享供应政策。为了清楚的阐述两者的策略和在应用服务性能效果上的区别，图4我们显示了一个简单的VM供应场景。图中，拥有2个处理器的主机接收2个VMs租用请求，每个VM请求两个处理器并计划完成4个任务单元。将其具体化，任务t1，t2，t3，t4租用VM1，而任务t5，t6，t7，t8租用VM2。

图4(a)描述了一个基于空间共享策略均应用在VMs和任务单元的供应场景。因为每个VM请求了两个处理器，在空间共享模式中，在实例化的时间内只有一个VM能够运行，VM2只有当VM1执行完其所有的任务后才能够被分配。对VM1而言，其任务单元分配模

式也是一样的：因为一个任务单元只需要一个处理器，因此同时可以运行两个任务单元。而在运行期间，剩余的任务单元在执行队列中等候。通过使用空间共享策略，VM i完成p个任务的估计完成时间是：

其中est(p)是云任务集的估计开始时间，rl是任务集执行在一个处理器上的总的指令数。est依赖于云任务集在执行队列中的位置，因为任务集是唯一（空间共享模式）使用了处理单元。当有可用的空闲处理器时，云任务集被分配到VM的队列中。这种模式下，有n个处理单元的主机总的容量可表示为：

其中cap(i)是单个元素的处理强度。

图4(b),空间共享策略应用到主机分配VMs上，而时间共享策略则应用到在VM内任务单元分配处理器上。因此，在一个VM生命周期内，所有的任务单元同时被动态分配。通过使用时间共享策略，一个VM完成所有任务的估计完成时间是：

其中eft(p)是估计完成时间，ct是当前仿真时间。cores(p)是云任务集需要处理器数目。在时间共享模式下，云任务集在同一个VM下可同时运行多个任务。这种模式下，计算云主机总的处理器容量为：

其中cap(i)是单个元素的处理强度。

图4(c),时间共享策略应用在主机分配VMs，而空间共享策略则应用在任务单元对处理器的需求。这样的话，每个VM接收每个处理器的空闲时间片，而对每个时间片以空间共享基础来分配任务单元。因为处理器是共享的，每个VM的可用处理能力的数目也是变化的。所以这就取决于实际运行VMs的活动主机。因为任务单元是基于空间共享策略分配的，意味着任意实例化时刻，只有一个任务使用处理器。 最后，图4中，时间共享策略同时应用在VMs和任务单元上。因此，VMs的可以同时共享处理能力，并且每个VM上可以同时运行其所有的任务单元。这种情况，任务单元就不存在队列等候延时情况。 3.3Modeling the Cloud Market 在云计算生态系统中，市场是一个重要的组成部分，因此在公共云计算模式根据按需支付方式调整云资源交易和在线协商是很有必要的，所以在研究过程中需要对新兴云计算平台的成本与效益比率进行精确评估。SaaS提供商在发现大量云提供服务（IaaS，PaaS，SaaS）中实现透明机制。因此在设计一个云仿真器时成本与经济型策略的建模是需要考虑的重要方面。云市场是基于多层（2层）设计来建立模型的。第一层包含了与IaaS有关的经济型特征，如每一单位内存费用，每一单位硬盘费用和使用每一单位带宽费用。当云消费者（SaaS提供商）创建和实例化VMs时必须支付使用内存和硬盘的费用，而网络使用费用仅仅是数据传送时才需支付。第二层是对相关SaaS模型的成本度量建立模型。该层中成本费用直接应用于为应用服务的任务单元（应用服务请求）上。因此，如果云消费未对应用服务（任务单

元）供应VM，他们将仅需支付第一层的费用（如内存和容量的费用）。Cloudsim用户可以依据情况修改和扩展该行为。 3.4Modeling the Network Behavior 对连接仿真的云计算实体的复杂网络拓扑结构的建模必须给予高度重视，因为消息延迟将直接影响整体服务满意度。对QoS不满意的终端用户或SaaS消费者很可能因此而更换他们的云提供商，因此云系统仿真框架提供模拟真实网络拓扑结构和模型的工具是非常重要的。Cloudsim中的云实体（数据中心，主机，SaaS提供商，终端用户）的交互网络是基于概念上的网络抽象。在这种模型中，没有真正的实体对仿真网络实体可用，例如路由器或交换机。取而代之的是，网络延迟影响因素是基于潜伏因素矩阵（Table1）存储的信息来仿真从一个实体（主机）到另一个实体（cloud broker）的路径。例如Table1中的潜伏因素矩阵包括了5个实体。在任意时刻，对所有cloudsim实体都由m*n大小的矩阵来表示。矩阵中元素eij代表了实体ei通过网络传送消息至ej将预计的延时。让我们回想起cloudsim是一个基于事件的仿真器，不同的系统模型/实体通过发送事件实现信息传递。Cloudsim的的事件管理引擎使用了交互实体网络延时信息来表示实体传送消息时产生的延时。时间延时用诸如miliseconds单位表示。

意思是通过事件管理引擎实现实体i到实体j的传递总共的仿真时间是t+d，其中t表示消息传送最初的仿真时间，d代表实体i与j之间的网络延时。图5描述了各实体之间的状态转移图。这种模拟网络延时的方法为我们在仿真环境中对实际网络体系建模提供了一个实用简单的方式。而且这种方法相对于模拟复杂网络组件（路由器，交换机）来讲实现、管理、模拟方面更轻易和更清楚。 对网络拓扑的描述以BRITE格式存储，包含了许多网络节点比仿真节点的数量更好。这些节点包括了各类CloudSim实体如主机、数据中心、云代理器等。BRITE装载了每次CloudSim初始化的信息和用来生成网络延时矩阵。数据中心和代理器也被映射为网络节点。另外，任何两个CloudSim实体不能映射到同一个网络节点。由CloudSim传送的消息（事件）首先由网络拓扑信息存储的网络拓扑对象处理。这个对象（矩阵）装载了事件延时信息和为后期的处理在事件管理引擎来传递。我们假设一个场景，设一个数据中心映射在第一个节点，云代理器映射到第五个节点，当消息从代理器发送到数据中心，其通信延时信息存储在矩阵中e（1,5）。因此在传输事件到目标实体之前事件管理引擎必须考虑这些延时。通过使用外部网络描述文件，我们允许不同实验重复使用同样的拓扑结构。而且配置文件中逻辑节点数量比实际仿真实体数量更多，因此网络建模方法并未违背实验的可扩展性。例如，每次在仿真时需要添加额外的实体时，仅仅需要添加映射到BRITE节点而不需要映射到任何活动的CloudSim实体。所以基于应用服务和云计算环境场景下发展总的网络大小还存在一定空间。

4.3Communication among Entities 图9描述了核心Cloudsim实体通信流量。在仿真开始时，每个数据中心实体在CIS注册表中注册。然后CIS提供信息注册类型功能，如为用户/代理器请求合适的云提供商匹配合适的服务。下一步，数据中心代理器扮演着用户角色咨询CIS服务来获得可提供基础设施服务并满足应用QoS，硬件和软件要求的云提供商列表。在匹配过程中，数据中心代理器使用CIS建议的云来部署应用。通信流量描述了在仿真实验中相关的基本流。在这些通信流中一些变化可能依赖于政策的不同。例如，代理器与数据中心的消息传递需要其他数据中心的确认，一个用户可以对行为的执行或VMs最大数进行创建。

5.Experiments and Evaluation

在这部分，为了验证cloudsim在模拟和仿真云计算环境的有效性，我们将叙述我们所做的一些实验和评估。

5.1cloudsim：可扩展性和费用(overhead)评估

第一个实验是我们分析了cloudsim在内存使用率和整体效率上的花费和可扩展性。这个实验是基于处理器有2个Intel Xeon Quad-core 2.27 GHz and 16 GB of RAM memory。为运行该实验，所有硬件资源都运行在虚拟机上的Ubuntu8.04上。 用来衡量cloudsim消耗的费用和内存使用率，实验仿真环境配置包括

DataCenterBroker和DataCenter（负责租用machines）实体。在第一个实验中，所有的处理器都是基于单独的数据中心被租用的。而在下一个实验中，将均匀地分布到两个数据中心中去租用。在两实验中主机数在1000到1000000之间。每个实验重复30次。在内存测试中，我们描述了因实例化和加载cloudsim环境的总的物理内存使用率。在花费（overhead）测试中，我们计算了因实例仿真环境导致的总延时，而时间差异是由以下事件导致：(1)java虚拟机加载cloudsim框架造成的时间差异(2)实例化cloudsim实体和处理事件时造成的时间差异。

图10(a)描述了在实验中需考虑安装模拟主机需要的平均时间。图10(b)绘制了成功执行实验所需的内存大小。结果显示总的花费没有随系统大小成线性增长。反而，我们观察到当数量级主机被使用于实验中时才按步增长。根据得到的结果显示实例化1000000个主机大概需12s。这些数据证明了cloudsim能支持大规模的模拟环境而在实例化时间和内存消耗不需或仅需少量花费。因此，相比真实的云服务，cloudsim作为性能测试平台方面有很大优势。它几乎不需计算时间和经济花费，而真实的云平台(Amazon EC2,Azure)在配置大规模测试环境时却耗费很高成本。结果还显示在不同的系统大小环境下反映出几乎相同的行为。不管是实例化一个还是两个data center都显示了相同的行为。尽管后面的总体平均值比之前稍微小了点。这个差异是微不足道的()，并且它也可以由在java虚拟机下多核处理器的使用效率来解释。

而内存消耗方面，我们观察到随着主机数的增加而呈线性增长，但总的内存使用从未超过320MB来增长，尽管当超大系统大小时。这个结果暗示了在最新版本的cloudsim(2.0)的性能得到了改善，相比于之前那些基于simJava仿真内核建立起来的版本。早期的版本进行相似配置时内存使用率会发生指数级增长。

下一个测试是验证由cloudsim提供的功能函数的有效性。仿真环境由一个数据中心拥有10000个主机组成，其中每个主机有单独的CPU内核(1200MIPS),4GB

的RAM和2TB的容量。而VMs的供应策略是空间共享，允许vm在实例化时间内被一个主机使用。我们配置了终端用户（通过DatacenterBroker实例化）来请求创建和实例化50个VMs，要求有以下限制：1024MB物理内存，1个CPU内核和1GB的容量。应用粒度建模由300个任务单元组成，其中每个任务单元需要在主机中执行1440000million指令（即在仿真主机中允许20 minutes）。因为网络因素在此次研究中暂时还未考虑，因此假设任务单元以300KB最小限度来进行数据传输。 VMs创建后，任务单元在50个VMs小组中以间隔10minutes延时被提交。VMs配置成空间共享和时间共享策略让处理内核来执行任务单元。图11(a)和图11(b)显示了应用多供应策略(时间共享和空间共享)随着仿真时间的增长任务单元的过程状态。与预期的一样，在空间共享模式下，每个任务单元花费20minutes来完成对处理内核的访问。在空间共享模式下，新任务的到来对当前执行的任务没有任何影响。每个新的任务仅仅是排队等待未来的调度。然而，在时间共享模式下，每个任务单元的执行时间随着任务单元提交数量而变化。时间共享策略对分配任务单元给VMs时在执行时间上有很大影响，因为处理内核被正调度的任务间平凡进行数据传输。与后面的任务单元相比，开始的50个任务单元拥有更好的响应时间。导致这个的主要原因是后面的任务单元需要处理复杂的负载情况。然而，在仿真的最后随着系统有更少的负载，响应时间又得到改善（图11）。两种策略的预期行为都考虑了实验的input。因此，cloudsim的策略和组件的实现是完全正确的。

5.2Evaluating Federated Cloud Computing Components

下一个实验是测试cloudsim组件，那些构成了模拟和仿真云联合网络的基本组件。最后，创建了一个模拟由3个云提供商和1个终端用户(DataCenterBroker创建)的组合的测试环境。每个提供商同时实例化一个传感器组件，用于负责动态获取相关数据中心主机的可用信息。接下来，静态传感器将信息提交给

CloudCoordinator，利用这些信息来进行负载转移决策。我们根据联合云提供商使用一个简单的负载转移政策来评估在线VMs转移性能，以免初始的提供商不能请求到可用空闲的VM节点。总之，负载转移过程包括以下步骤：(1)创建一个与初始VM相同配置的VM实例并且该实例也服从目标提供商配置(2)迁移原始的虚拟机上云任务集到新的实例化虚拟机。云提供商联合网络是基于图12的拓扑结构而创建的。

每个在联合网络中基于云的数据中心都有50个计算主机，10GB内存，2TB容量，1个1000MIPS处理器和一个时间共享VM调度器。DataCenterBroker代表终端用户，用于请求实例化需要256MB内存，1GB容量，1个CPU和时间共享任务集调度器的VM。Broker请求实例化25个VMs并分配每个任务集到一个即将被租用的VM上。这些请求初始位于Datacenter0上。每个任务集长度设置为1800000MIS。进一步，仿真实验是由以下系统配置和负载转移场景组成的：(1)第一步，一个云联合网络中数据中心能够应付转移超载节点到最小负载节点产生的高响应需求(2)第二步，数据中心是作为单独实体来建模的(不属于联合网络中)。所有提交给数据中心的工作负载都必须在本地处理和执行。

表2显示了在两种情况下每个任务集的平均turn-around和终端用户应用整体的makespan。一个终端用户应用由一个或多个连续依赖的任务集组成。仿真结果表明了使用云联合网络体系可以减少超过50%的平均turn-around时间，并且提高了20%的makespan。由此可以看出，尽管是一个简单的负载转移政策，联合运资源池在应用性能上多终端用户都有巨大益处。 5.3Case study:Hybrid Cloud Provisioning Strategy

在这部分，将展示一个更加完整的实验，该实验还考虑了云之间网络延时因素。实验显示采用混合云计算环境能够提高公司的生产力。通过使用这种模式，

公司能够以合理成本租用公共运资源来动态扩展他们系统容量。

仿真场景模拟来一个私有和公共云的网络。该公共云和私有云建立来两个不同的数据中心模型。在私有云数据中心中，CloudCoordinator接收用户应用并以FCFS模式处理它们。为了评估混合云在加速执行任务上的有效性，我们仿真了两个测试场景：第一个场景-所有的工作负载都在本地的私有云中处理，第二个场景-当本地私有云资源(主机，VMs)忙或不可用时，工作负载可以转移到公共云中。也就是说，第二个场景模拟来一个CloudBurst，当服务需求处于高峰期时，我们将工作负载从本地私有云转移到公共云上。在任务提交到公共云之前，第一个请求会在目标对象上加载和实例化VM镜像。在公共云实例化镜像数目是私有云可用主机数目的10%到100%之间。任务单元以空间共享模式被分配到VMs上。每当任务被执行完，空闲VM又被分配给后面等候排队的任务。只有当等候任务全部被处理，公共云中所有VMs通过CloudCoordinator销毁。

私有云租用来大约100个虚拟处理器，每个有2GB的RAM，10TB的容量，1个1000MIPS的CPU。而公共云中的虚拟机则按照Amazon小型配置，拥有1.7GB内存，1个虚拟内核和160GB容量。在此次仿真实验中，我们假设虚拟内核与本地处理器有相同的处理能力。

发送给私有云的工作负载是由10000个任务组成的。每个任务请求处理时间在20-22minutes之间。处理时间的分配是根据标准分配模式随机生成的。10000个任务是同时提交给私有云的。

表3显示了不同私有云和公共云资源组合方式得到的所有任务完成时间makespan。在表的第三栏中，我们定义来服务的总成本。费用政策是基于Amazon的小型业务模式来设计的。意思是成本实例化是按小时计费。因此，如果一个实例运行来一小时一分钟，费用将按2小时计算。

与预期的一样，随着提供给任务的可用资源池容量的增加，所有任务执行完成时间不断减少。但是，相关处理成本也增加来，以公共云资源成本的1%增加。不过我们发现提高成本为改善makespan起到很大作用。因为整体而言，与因为要处理突发需求高峰期而不得不购买或安装私有设施相比，从公共云中租用相应资源成本更低。

5.4Case study：Energy-Conscious Management of Data Center

为了测试CloudSim在VM供应技术的模拟和仿真节能意识的能力，我们设计了以下实验配置。仿真环境包括来一个基于云的数据中心拥有100个主机(host).

这些主机配置有1个1000MIPS的CPU内核，2GB的RAM和1TB的容量。该试验的工作负载包括对400VMs进行任务请求，每个请求要求有1个250MIPS的CPU内核，256MB的内存和1GB的容量。每个VM租用一个web-hosting应用服务，其CPU使用率分配原则按统一的分配原则进行分配。每个实例化的web-hosting服务需要150000MIPS或者大概需10minutes完成全部请求。节能模式的实现是在假设能源消费是指一些静态资源的总和，这对于主机host而已是固定的。而动态组件的能源消耗是一个线性函数。起始时，VMs根据请求参数(4VMs on each host)进行分配。我们用于研究节能意识资源管理技术的云计算体系结构包括一个data center，CloudCoordinator和一个Sensor组件。CloudCoordinator和Sensor组件的功能与前述的相同。通过附加的Sensor（连接每一个host），CloudCoordinator可以周期得监测活动的VMs的性能状态，如负载情况和过程共享。然后将实际的信息传递给VMM，它根据这些信息进行合适地调整VMs，DVFS应用和软件规模。

CloudCoordinator则根据发出的VM转移指令以及改变的节点能源状态来对VMs的重新分配。

在该试验中，我们比较来两种节能意识资源管理技术的性能忽略来一些琐碎因素，该实验没有考虑当VMs分配给主机时的节能优化。在基准技术中，处理器允许最大频率运行，也就是说，他们尽可能的100%来执行。第一种节能意识技术是DVFS，即VMs大小的重新分配是根据在仿真过程中基于主机的CPU使用率的动态变化。这里还假设CPU的电压和频率按线性调整。第二种技术其实是DVFS策略的改进；它每5秒就对VMs进行实时转移来满足分配策略。这里的基本思想是在最少节点上整合VMs，以及关闭空闲节点已尽可能的减少能源消耗。为了将VMs映射到主机上，我们采用来一个贪心算法，其算法是按降序对VM的CPU使用率进行排序，然后将它们最优(a first-fit manner)分配给主机。如果发现更优的能源消耗，则将VMs转移到其他主机上。为了不违反SLA，将VMs分配给主机时，该主机的使用率必须低于事先定义的阈值(threshold).阈值会因所要仿真的系统行为分配而不同。当仿真要求重复10次，我们得到的结果平均值在图14中显示： 结果显示节能意识技术能够大大减少数据中心主机总共的能源消耗。但是，这也仅仅是测试数据，实际的节能意识技术的性能直接依赖于云中被租用的应用服务的类型。在改善专门应用能源优化技术领域还有很大空间。随着使用率阈值的增长，能源消耗逐渐减少，这是因为VMs能够更有效地被整合。这也导致了VM转移数目的减少和违背SLA标准数目的增长。这个简单的实验研究显示了CloudSim是如何适用于不同节能意识资源管理技术/政策。

6.Additional CloudSim Use Cases

随着云计算变得越来越流行和重要，国内外一些研究者都开始使用

CloudSim。如，HP labs研究者正使用CloudSim用来研究HP云数据中心的资源调度算法的评估。Duke University 研究者使用它来研究数据中心的能源有效性管理。华东交大研究院使用CloudSim来研究云调度和应用。国家研究中心的智能计算系统研究员用它来进行对云计算环境的面向SLA管理和优化。Kookmin University研究员使用其工具集来调研工作流在云中的调度。

云分析器是由墨尔本大学开发的一款工具，它的目的是对跨区域用户和数据中心的社交网络应用的评估，例如FaceBook。在这个工具中，支持社交网络应用的用户和数据中心的社区是基于他们的地理位置和其他参数（用户使用这些社交网络应用的体验值）来特征化使之数字化。数据中心上的负载将已日志的形式持续记录下来。CloudSim的另一用处，它能够成功地部署执行数据中心中将虚拟机映射到主机上的相关实验，CloudSim实现对HMN评估——一种实现虚拟机间带宽预定的启发式算法。

这些研究表明来CloudSim在相关领域的云计算及其应用实验上起到重要支持作用。

7.Conclusion and Future work

近来在设计和开发云计算技术上，我们集中在为有效管理云基础设施定义新颖方法、政策和机制上。为了测试这些新开发方法和政策，研究员需要新的工具来支持他们将先前的假设应用到实验的实际部署上，这样以实现重复测试。基于仿真的方法在评估云计算系统和应用行为上提供来众多好处，因为他们允许云开发者：(1)以无成本方式在一个可重复和可控制的环境下测试他们的供应和服务传递策略的性能；(2)在部署到真实的商业云环境之前调整性能瓶颈。

为了满足这些条件，我们开发来CloudSim工具用于模拟和仿真可扩展的云。作为一个完整自定义工具，它允许在软件所有组件策略的扩展和定义，这使它成为一款更适合研究的工具用来处理仿真环境中的复杂性。在未来的工作进展中，

为了更好仿真当前可用的公共云，我们计划将新的费用和供应策略考虑进去。至于未来其他研究方向还包括：(1)工作负载模式(2)数据库服务建模，如blob，SQL等(3)在VM和云等级上对QoS监测(4)公共云费用模式对面向经济资源供应研究的支持。

此外，近期研究发现数据中心耗费了巨大电力消耗，因此它们在日操作和管理上产生巨大花费。例如，一个Google数据中心消耗的电力相当于一个如

SanFrancisco城市的电力消耗。社会学经济因素和跨地域的环境条件直接影响了被租用的数据中心总共电力花费的产生。例如，一个数据中心租用在费用成本低并且天气情况不是很恶劣的地方，将相对减少电力费用。为了实现前述云计算环境的仿真，未来的研究中我们将进一步为依赖能源效率和服务提供商花费的应用服务的分配上，研究新的模型和技术。 Software Availability

CloudSim软件的源代码的下载可以从：http://www.cloudbus.org/cloudsim/。还附加来许多CloudSim如何使用的实例。

本文来源：https://www.bwwdw.com/article/3dcf.html