式也是一样的：因为一个任务单元只需要一个处理器，因此同时可以运行两个任务单元。而在运行期间，剩余的任务单元在执行队列中等候。通过使用空间共享策略，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实体。所以基于应用服务和云计算环境场景下发展总的网络大小还存在一定空间。
3.5Modeling a Federation of Clouds
为了建立联合或交互网络的多样云，需要对云协调器实体进行建模。这个实体不仅负责其他数据中心与终端用户在仿真环境中的建模，也负责监测和管理数据中心实体的内部状态。接收信息作为监测过程的一部分（它在仿真过程中是动态的），它用于对相关交互云供应的决策。我们可以发现已有的提供商（Amazon，Azure，GAE）没有一个提供了类似的云协调器函数。因此，如果一个真实世界的云系统开发商要从多个云中联合服务，他们需要开发自己的云协调器组件。通过使用这样的实体来管理基于云的数据中心的整合，与外部实体的交流和协商相对于核心数据中心是孤立的。所以，在它的核心对象中提供这样的一个实体，CloudSim可帮助云开发商加快对他们应用服务性能的测试。
对云联合的仿真必须解决的两个基本方面是：通信与监测。第一方面是由数据中心对标准的基于事件的消息进行处理；第二方面是由云协调器执行。为了使CloudSim中的每个数据中心作为云联合的一个部分必须对其entry进行实例化。云协调器触发了基于数据中心状态的交互云负载协调过程。通过特殊的传感器实体实现的事件的特殊集影响了调整。每个传感器实体都实现了一个与数据中心相关的特殊参数。为使数据中心主机的在线监测有效，传感器实体必须时刻跟踪云协调器的主机状态。每步监测过程，云协调器都需对传感器进行查询。如果某个预先配置的阈值达到了。云协调器就开始于其他协调器进行尽可能小的load-shredding的通信。协商协议、load-shredding策略和赔偿机制都可进行轻易扩展实现专门研究学习。
3.6Modeling Dynamic Workloads 软件开发者和第三方服务提供者经常可以根据工作负载模式、可用性、可伸缩性条件部署表现为动态行为的应用。一般地，云计算要求实现多样性和可伸缩性服务和基础设施需求。主流的云销售商包括Amazon和Azure，提出了虚拟机容器/插件，可用于租用多种SaaS和根据需求配置在无限制的资源池内提供租用。受上述因素的约束，任意仿真环境通过应用或SaaS模式支持对动态工作负载模型驱动的建模是一个非常重要的条件。为了在CloudSim中允许动态行为的仿真，我们必须在已有框架下实现一系列扩展，尤其是云计算任务实体的扩展。我们在cloudsim中设计了一个附加的仿真实体，被称为效用模型包含了可以在部署实例化条件下定义SaaS应用的资源和VM-等级条件的方法和变量。在Cloudsim框架中，效用模型是一个抽象类，是一个要求模拟应用资源需求来实现工作负载模型的扩展类。Cloudsim用户需要重新getUtilization()方法，它的输入参数是离散时间值，返回类型是云任务集中资源需要的计算百分比。 云计算环境的另一个重要条件是在QoS参数下如可用性，可靠性，应用传送的吞吐量等保证满足SLA。尽管现代虚拟化技术在不同的VMs下运行应用能够保证性能独立，但在VM供应等级下改进方法来进一步完善资源使用效率仍有很大空间。VM供应中智能算法的性能不足仍是一个挑战，当所有的VMs部署在单一主机上可能无法充分共享处理器数目，而这对于满足SLAs非常关键。这将导致响应时间、时间超时、失败等最坏情况的发生。
资源提供者必须将这些行为和初始化条件考虑进去尽可能减少对应用性能的影响。为了仿真这些行为，SLA模型可以定义为对请求资源进行完全分配或者允许资源分配达到某一比例要求就满足了SLA（如在请求的数量基础下允许CPU共享比例为10%）。Cloudsim支持上述SLA违背场景的建模。此外，也可以定义专门的SLA-aware 政策，用来描述如何在资源缺乏的VMs竞争中分配可用的容量。被请求了但为分配的SLA违背事件数和资源总数可以由Cloudsim指定。
3.7Modeling Data Center Power Consumption 云计算环境是基于大量的计算和存储主机构成的交互连接的网络，用来提高按需支付服务。这种设施与水力系统（Cooling system）类似，可以消耗大量电力和导致高操作成本。缺乏节能意识的供应技术将导致当高负载时云资源（计算和存储服务）的过热。从而导致系统可靠性和设备生命周期的缩短。另一个问题是导致CO2的排放因其温室效应导致对自然环境的破坏。所有这些问题要求我们对资源，VM和应用水平的节能意识供应的开发。 Cloudsim框架提供了基本的模型和实体，是用于验证和评估节能意识供应的技术和算法。我们为了推进上述功能对Cloudsim进行了一系列的扩展，如对PE对象的扩展（包括了一个额外的电力对象用于管理在一个云主机的电力消耗）。为了支持对不同电力消耗模型和电力管理技术（Dynamic Voltage and Frequency Scaling (DVFS)）的建模与仿真，我们提供了一个抽象类PowerModel，该类扩展了对一个PE自定义电力消耗模型的仿真。Cloudsim用户需要重写该类的getPower（）方法，其输入参数是云主机的当前使用率矩阵，返回参数是当前电力消耗值。该类促进了在云系统组件中要求计算实时电力消耗的节能意识供应的创建，此外，也有利于在仿真过程中对系统总的能源消耗的统计。 3.8Modeling Dynamic Entities Creation 云计算提供了一个史无前例的软件服务和硬件服务池，通过云企业可以通过动态供应或取消供应来处理需求短期变化的能力。许多企业服务的使用模式常常因时间而发生变化，且大多数时间都是无法预测的。这就要求云提供商能够处理用户在任意时刻进入或离开的能力。Cloudsim通过支持动态创建不同种类的实体来模拟这样的场景。除了动态创建用户和代理器实体外，也可以在运行时刻增加或移除数据中心实体。这个功能对仿真动态环境，如系统组件随机地连接、失败、离开系统情况下是很有用的。实体创建后，新实体自动地在云信息服务中注册以被动态资源发现。 4 Design and Implementation of Cloudsim 这部分我们将详细介绍Cloudsim相关的基础类，这些类共同组成了仿真器。图6展示了Cloudsim整体类的设计图。
