BwProvisioner：这是一个用于模拟带宽供应给VMs政策的抽象类。该组件的主要功能是分配网络带宽给部署在数据中心里的竞争VMs集合。云系统开发者和研究者可以根据他们应用的需要实现自己的策略（优先级，QoS）来扩展此类。BwProvisioningSimple类允许一个VM存储尽可能多的带宽，当然其受主机总的可用带宽的限制。 CloudCoordinator: 该抽象类用于扩展联合的基于云的数据中心。它负责周期性地监测数据中心资源的内部状态和动态load-shredding决策也在基于该类的基础上。该组件的具体实现包括了专门的传感器和load-shredding期间应该遵循的策略。监测数据中心资源是由updateDatacenter()方法通过发送需查询的传感器来执行的。服务/资源发现是由setDatacenter() 抽象方法实现的，它可扩展实现自定义协议和机制（多广播，广播，p2p）。此外，该组件也可以扩展基于云的服务的仿真，如AmazonEC2 Load-Balancer。开发者希望通过多个云实现部署他们的应用服务，可通过扩展该类来实现他们自定义内部云供应策略。
Cloudlet：这个类对基于云的应用服务进行了建模（如内容传递，社交网络，业务工作流）。Cloudsim根据它的计算要求来安排一个应用的复杂性。每一个应用服务都有一个预计的指令长度和在生命周期中应该承受的数据传送（之前和之后执行）费用。该类也支持对其他性能和应用组成矩阵的建模的扩展，如面向数据库应用的事务。 CloudletScheduler：该类扩展了在一个虚拟机下对云任务集决定共享处理能力的不同策略的实现。之前已经描述了，共提供了两类供应策略：空间共享（CloudetSchedulerSpaceShared）和时间共享（CloudletSchedulerTimeShared）。
Datacenter:该类对由云提供商（Amazon，Azure，AppEngine）提供的核心基础设施等级服务进行了建模。它根据硬件配置（内存，处理器，容量，存储）封装了计算主机，主机可以是同构或者异构的。此外，每实例化一个数据中心组件时就自动生成了应用供应组件策略集合，包括分配给主机和VMs的带宽，内存，存储设备等。
DatacenterBroker or Cloud Broker:该类模拟了一个代理器，主要负责SaaS和云提供商，以及受QoS限制的中介协商。该代理器代表了SaaS提供商，可根据查询云信息服务（CIS）和承担对要求满足应用QoS需求的资源/服务的分配的在线协商来发现合适的云服务提供商。研究者和系统开发者必须扩展该类用来评估和测试自定义代理策略。云代理器和协调器的区别是前者代表着用户消费者（组件决策是为了增加相关用户性能），而后者代表了数据中心（为了使数据中心的整体性能最大化，而不考虑特殊消费者的需求）。 DatacenterCharacteristics：该类包括了数据中心资源的配置信息。
Host：该类模拟了一个物理资源如一个计算或存储服务。它封装了诸如内存和存储器大小，处理器个数和类型，在虚拟机中贡献处理器分配策略，供应给虚拟机的内存和带宽的策略等重要信息。
NetworkTopology：该类包含了在仿真中产生网络行为（延时）的信息，它存储了用BRITE拓扑生成器的拓扑信息。
RamProvisioner：这是一个抽象类，实现了对RAM分配给VMs的供应策略。只有当
RamProvisioner组件证明主机拥有符合要求的空闲内存，该主机才能够对VM执行和部署。RamProvisionerSimple对VM请求内存大小没有任何限制，但是当请求超过了可用内存容量时就会拒绝分配。
SanStorage：该类模拟了一个存储领域网络，通常地是围绕基于云的数据中心来存储较大的数据块（AmazonS3，Azure blob storage）。SanStorage实现了一个简单接口能够用于仿真任何数据总数的存储和检索，支配网络带宽的可用性。在SAN运行时刻访问文件会导致任务单元执行时间的额外延时。额外的延时发生在数据中心内部网络传输数据文件的过程。
Sensor：这个接口必须实例化一个传感器组件来实现，可以备一个云协调器作为检测特殊性能参数（能源消耗，资源使用率）来使用。云协调器是利用动态性能信息来担当负载均衡决
策的。该接口定义的方法有：⑴设置性能的最大和最小值⑵周期性地更新测量尺寸。该类可以用于模拟由主导的云提供商诸如Amazon’s CloudWatch和Azure’s FabricController提供的真正服务。一个数据中心可以实例化一个或多个传感器，每个传感器负载检测某一特殊数据中心性能参数。
Vm：该类模拟了一个虚拟机，负责对云主机组件的管理和租用。每个VM组件都可以访问存储了以下与VM有关的特征的组件（可访问的内存，处理器，容量大小和VM内部供应策略，这些都可以由CloudletScheduler抽象类来扩展）
VmmAllocationPolicy：该抽象类描述了一个VM监听器对分配VMs给Hosts的使用情况的供应策略。VmmAllocationPolicy主要功能是在一个数据中心中选择可用的主机，以满足内存，容量和VM部署有效性要求。 VmScheduler：该抽象类由一个主机组件实现，模拟了要求分配处理器给VMs的策略（空间、时间共享）。该类功能可以轻易被根据应用调整特殊处理器共享策略所重写。 4.1 Cloudsim core simulation framework 如之前所讨论的，GridSim作为CloudSim的基础模块，GridSim使用SimJava库进行事件处理和内部实体消息传送。SimJava在创建可伸缩性仿真环境暴露出了一些不足：
a. 不允许在运行时刻通过编程来重置仿真。
b. 不支持在运行时刻创建新的仿真实体（一旦仿真被实例化后）。 c. Simjava的多线程机制导致当系统大小增长时性能超负载。性能的降低时由于线程频
繁的文本交换导致的。
d. 多线程机制为系统调试带来额外的复杂度。
为了克服这些不足和使仿真过程中包括多个实体的复杂场景，我们开发了一个新的事件管理框架。图7（a）显示了类图的核心部分。以下是相关类：
CloudSim：这是主类，主要负责管理事件队列和控制仿真事件的按步骤执行。每一个由CloudSim实体在运行时刻生成的事件都存储在称为future events队列中。这些事件按照事件参数排序和插入到队列中去。然后，仿真中每步被调度的事件从future events队列中移除并且被转移到延时队列中。接着，为每个实体激发一个事件处理过程，主要是从延时事件队列中选择事件和执行适宜的行动。这样的组织运行仿真的灵活管理和提供了以下有利优势：
a. 实体钝化
b. 不同状态之间的实体文本交换。暂停和重新开始仿真过程 c. 在运行时刻创建新实体 d. 在运行时刻放弃和重启仿真
DeferredQueue：该类实现了供CloudSim使用的延时事件队列 FutureQueue：该类实现了供CloudSim使用的未来事件队列
CloudInformationService：CIS是一个提供了注册、索引、发现资源能力的实体。CIS支持两个基本的方法：⑴publish()，允许实体通过CIS注册自身⑵search()，允许诸如
CloudCoordinator和Broker实体发现与其他实体位置和终结点。该实体也会就仿真的结束通知其他实体。
SimEntity：这是一个抽象类，负责发送消息给其他实体以及处理接收的消息如放弃或处理事件。所有的实体都必须扩展该类和重写它的三个核心方法：startEntity(),processEvent()和shutdownEntity(),用来处理实体初始化、事件处理和实体销毁等行为。SimEntity类提供了调度新事件和发送消息给其他实体的功能，其中网络延时根据BRITE模型计算。一旦创建了，实体自动地与CIS注册。
CloudSimTags：这个类包含了多个静态事件/命令标签，用来指出当接收或发送事件时需由CloudSim实体承担的行为类型。
SimEvent：该实体类描绘了两个或多个实体之间传送仿真事件的过程。SimEvents存储了一个事件的下述信息：类型，初始时间，事件发生时间，完成时间，预计到达目标实体传输时间，资源ID和目标实体，需传送到目标实体的事件和数据标签。
CloudSimShutdown：该实体类主要是等待所有终端用户和代理实体的结束，然后发送仿真结束信号给CIS。 Predicate：该类是用于从延时队列中选择事件。是一个抽象类，必须创建一个新类来扩展它。图7(b)展示了一些标准的predicates类。
PredicateAny：该类描述了在延时事件队列中匹配任意事件的predicate类。在CloudSim类中有一个叫CloudSim.SIM_ANY有一个公共可访问该实例化类，因此没必要创建任何新的实例。
PredicateFrom：该类是描述了从特殊实体中放弃的事件中选择事件的predicate类。
PredicateNone：该类是指在不在延时事件队列中匹配任何事件的predicate类。在CloudSim类中有一个CloudSim.SIM_NONE有一个公共静态可访问该实例化类，因此没必要创建任何新的实例。
PredicateNotFrom：该类描述了不是由特殊实体发送中选择事件的predicate类。 PredicateNotType：该类是指从不匹配特殊标签中选择事件的predicate类。 PredicateType：该类是指从匹配特殊标签中选择事件的predicate类。 4.2Data Center Internal Processing 各任务单元流程都是由各自VMs处理的，因此他们在每仿真步骤中的进展都必须是连续更新和监测的。为了解决此问题，构建了一个内部事件用来通知数据中心实体一个任务单元执行即将结束。因此，在每仿真步骤中，每个数据中心实体都激发一个称为
updateVMsProcessing()方法以便管理每个主机。按照此流程，相互联系的VMs可实时更新主机当前活动的任务流程。该方法的输入参数是当前仿真时间，返回类型是一个任务单元运行在某个VMs的某个主机上下次预计完成的时间。下次内部事件时间指由主机返回的所有完成时间中最短时间。 在主机层上，updateVMsProcessing()方法触发了updateClouletsProcessing()方法，用来指导每个VM更新它们在数据中心实体中的任务单元状态（结束，悬挂，执行）。该方法的原理与前述的updateVMsProcessing()方法有相似的作用，不同的是处于VM层上。一旦该方法被调用，VMs将返回当前由VMs管理的任务单元下次预计完成时间。它们中最短完成时间值被传送到数据中心实体。因此，完成时间存储在执行完每步事件处理的数据中心队列中。在结束队列中等候完成的任务中直接由CloudBroker或CloudCoordinator返回。图8以顺序图形式描述了该过程。
4.3Communication among Entities 图9描述了核心Cloudsim实体通信流量。在仿真开始时，每个数据中心实体在CIS注册表中注册。然后CIS提供信息注册类型功能，如为用户/代理器请求合适的云提供商匹配合适的服务。下一步，数据中心代理器扮演着用户角色咨询CIS服务来获得可提供基础设施服务并满足应用QoS，硬件和软件要求的云提供商列表。在匹配过程中，数据中心代理器使用CIS建议的云来部署应用。通信流量描述了在仿真实验中相关的基本流。在这些通信流中一些变化可能依赖于政策的不同。例如，代理器与数据中心的消息传递需要其他数据中心的确认，一个用户可以对行为的执行或VMs最大数进行创建。
