CloudSim5.0学习笔记

2009年4月8日，澳大利亚墨尔本大学的网格实验室和Gridbus项目宣布推出CloudSim云计算仿真软件。CloudSim是在离散事件模拟包SimJava上开发的函数库，可以创建多种云计算环境中的实体，包括云数据中心、主机、服务、代理器和虚拟机，支持事件队列的处理、组件中消息传递和仿真时钟的管理。CloudSim可在Windows和Linuxh系统上跨平台运行，拥有以下特点：(1)支持大型云计算的基础设施的建模与仿真；(2)一个自足的支持数据中心、服务代理人、调度和分配策略的平台。其中CloudSim 独特功能有：一是提供虚拟化引擎，旨在数据中心节点上帮助建立和管理多重的、独立的、协同的的虚拟化服务；二是在对虚拟化服务分配处理核心时能够在时间共享和空间共享之间灵活切换。

CloudSim的仿真主要针对组件、行为、资源分配策略这三大类型。组件包括云数据中心、物理机、虚拟机、服务代理商、任务单元、云信息服务等；行为创建VM，删除VM的数据、迁移VM，任务提交、任务取消等；资源分配策略包括VM主机分配、带宽分配、内存资源分配、总线时间分配等。

参考：https://www.cnblogs.com/sddai/p/6036893.html

2.CloudSim版本的变化

2.1 从CloudSim beta1.0到CloudSim2.0的变化：

(1)建立新的仿真核心。由于SimJava不支持更高级的操作和版权问题，CloudSim 2.0不再依赖SimJava来处理模拟，此后，CloudSim能可控的对线程进行创建；在CloudSim beta测试中发现的竞争条件也被删除，CloudSim的可伸缩性和性能得到改善。此外，还支持仿真实体的动态创建和销毁。(2)改进了调度器，提高了仿真结果的准确性。(3)增加了新特性，包括能耗感知模拟、联合模拟和网络模拟。(4)对项目进行更改，包括类名的更改、类的删除和接口的更改。

2.2 从CloudSim2.0到CloudSim2.1的变化：

(1)将项目迁移到Apache Maven (http://maven.apache.org/)。(2)更改目录结构，符合Maven规范。(3)从Vm类中移除VmSchedulerTimeSharedWithPriority。(4)修改项目中的bug，重构和删除过时的代码。

2.3 从CloudSim2.1到CloudSim3.0的变化：

(1)新的VM调度策略。在无需考虑大量MIPS要求的前提下，VmSchedulerTimeSharedOverSubscription模型策略允许无限制数量的虚拟机被部署在一台虚拟机上。(2)新的数据中心网络模型。添加了一个内部网络模型，它支持定义在任意网络拓扑中连接主机的交换机。(3)新的VM分配和选择策略。项目Power包中添加了6个新的VM分配策略和4个新的VM选择策略。(4)新的能耗模型。项目Power包中加入了7个使用SPECpower数据的真实服务器的能耗模型。(5)支持外部工作负载。(6)支持用户自定义仿真结束。(7)移除一些类，修改了API，修正和改进bug。

2.4 从CloudSim3.0 到CLoudSim3.0.3的变化

修改项目中的bug，重构和删除过时的代码。

2.5 从CloudSim3.0.3到CloudSim4.0到的变化

增加了对容器虚拟化的支持。(2)修正项目中的bug。

2.6 CloudSim5.0

Cloudsim5.0工具包结合了各种版本，包括容器、VM扩展、性能监控特性和多云上Web应用程序建模。它也将与其他模拟模型一起工作，如软件定义网络(SDN) /服务功能链接(SFC)。

参考：https://github.com/Cloudslab/cloudsim/releases

3. CloudSim的体系结构

3.1 CloudSim

CloudSim自1.0版本开始，已经确定了CloudSim的整体体系结构，如图1 CloudSim体系结构图所示。

CloudSim5.0学习笔记

图1 CloudSim体系结构图

用户代码层负责提供基本的云实体，包括与主机（多台机器、多规格）、应用（任务及其需求）、虚拟机、大量用户及其应用类型和代理的调度策略的配置相关功能的用户代码。云应用开发人员可在本层开发各种用户需求分布、应用的配置请求和云可用场景，进行可靠性测试，从而实现自定义的云应用调度算法。
CloudSim仿真层提供了对基于云的虚拟数据中心环境的建模与仿真的支持，包括对虚拟机、内存、容量、带宽的专用管理接口管理。这层要处理的基本问题包括：虚拟机分配到主机的调度，管理应用程序的执行和监测系统的动态状态。一个云提供商如果想要研究在分配其主机到虚拟机上的不同策略的有效性，就必须在这层来实现他们的策略。这些实现策略可以通过扩展编写核心 VM 分配函数（VM provisioning）来实现。
针对于基于SimJava库研发的GridSim，CloudSim核心模拟引擎是一套全新的离散事件管理框架，克服了SimJava在创建可伸缩仿真环境时的限制，满足更复杂的仿真环境。类图的核心部分如图2 CloudSim核心模拟引擎类图所示。

图2 CloudSim核心模拟引擎类图

CloudSim：主类，负责管理事件队列和控制仿真事件的顺序执行。

DeferredQueue：实现CloudSim使用的延时事件队列。

FutureQueue：实现CloudSim使用的未来事件队列。

CloudInformationService：提供资源注册、索引和发现能力的实体。

SimEntity：代表一个仿真实体，能向其他实体发送消息，也能处理接受到的消息。

CloudSimTags：包含多个静态的事件或命令标签，CloudSim实体在接收和发送事件时使用这些标签决定要采用的操作类型。

SimEvent：给出了在两个或多个实体间传递仿真事件的过程，存储了关于事件的信息。

CloudSimShutdown：用于结束所有终端用户和代理实体。

Predicate：抽象类，用于从延时队列中选择事件。如图3标准 predicates类图所示。

图3标准 predicates类图

3.2 引入ContainerCloudSim

CloudSim项目自4.0版本加入容器特性后，项目迎来了新成员ContainerCloudSim仿真器。ContainerCloudSim基于CloudSim仿真器的核心进行开发，但它也拥有自己的核心，如图4 ContainerCloudSim与CloudSim生态系统的关系图所示。在加入ContainerCloudSim仿真器后，CloudSim项目整体的体系结构基本没有发生变化。为了凸显出容器这一新特性，我对CloudSim的体系结构进行了一些修改（不完全正确），如图5 CloudSim结构修改图所示。容器是一种新型的云服务模型，在某种意义上，容器可被称为“轻量级虚拟机”，但是容器并不是虚拟机（我会在后面展开描述），所以容器属于CloudSim仿真层。

图4. ContainerCloudSim与CloudSim生态系统的关系

图5 CloudSim结构修改图

参考：

https://wenku.baidu.com/view/88b2307718e8b8f67c1cfad6195f312b3169eb80.html

https://max.book118.com/html/2018/0107/147809363.shtm

4. ContainerCloudSim仿真器

4.1 ContainerCloudSim的体系结构

ContainerCloudSim仿真器结构如图6：

图6. ContainerCloudSim仿真器架构图

工作负载管理服务：负责客户的应用程序注册，部署，调度，应用程序级性能和运行状况监视。

容器生命周期管理服务：负责容器生命周期管理。包括容器的创建、注册、启动、停止、重启、迁移和销毁，管理容器内运行的任务并监视其资源利用率。

VM生命周期管理服务：负责虚拟机生命周期管理，包括VM创建，启动，停止，销毁，迁移和资源利用率监视。

资源管理服务——包含三个主要服务：

容器放置服务：根据定义的容器分配策略将容器分配给虚拟机。
虚拟机放置服务：根据定义的虚拟机分配策略，将虚拟机分配给主机。

整合服务：通过将容器整合到最少数量的主机来最大程度地减少资源碎片。

资源分配服务：管理对VM和容器的资源分配——包含以下服务：

容器分配服务：配备有确定如何将VM资源分配（计划）到容器的策略。
VM分配服务：配备有确定如何将主机的资源分配（计划）到VM的策略。

功耗和能耗监视服务：负责测量数据中心中主机的功耗，并配备了必要的功耗模型。

数据中心管理服务：负责管理数据中心资源，打开和关闭主机电源以及监视资源利用率。

4.2 ContainerCloudSim的主要类

ContainerCloudSim的主要类如图7所示：

图7. ContainerCloudSim类图

ContainerCloudSim实现由两个主要部分组成：模拟元素和模拟服务。

模拟元素类包括以下内容：

DataCenter类：云服务的硬件层通过Datacenter类建模。

Host类：主机类代表物理计算资源（服务器）。

VM类：此类对VM进行建模。虚拟机由主机管理和托管。 VM的属性是内存，处理器及其存储大小。思考两个问题，容器的产生是为了“减少虚拟机启动时间”，那为什么这里的容器还要用虚拟机技术？容器作为“虚拟化2.0”技术，它会取代虚拟机吗？

Container类：此类模拟由VM托管的容器。容器的属性是内存，处理器和存储大小。

Cloudlet类：Cloudlet类对托管在云数据中心的容器中的应用程序进行建模。Cloudlet继承了CloudSim软件包中的功能，包括StartTime和执行状态（CANCEL，PAUSED和RESUMED）。

模拟服务类主要包括以下内容：

ContainerRamProvisioner：抽象类，表示用于将虚拟机的内存分配给容器的配置策略。仅当ContainerRamProvisioner组件确保VM具有所需的可用内存量时，才能将容器托管在VM上。如果容器请求的内存超出了VM的可用内存，那么ContainerRamProvisioner会拒绝该请求。

ContainerBwProvisioner：抽象类，设置容器的带宽策略，处理对一组竞争容器的网络带宽分配。此类可以扩展。

ContainerScheduler：抽象类，包含容器调度策略，由VM组件实现。通过扩展此类，可以实现更多特定于应用程序的处理器共享策略。

CloudletScheduler：cloudlet调度策略，包含两种类型的供应策略：

时间共享（ContainerCloudletSchedulerTimeShared）策略和

空间共享（ContainerCloudetSchedulerSpaceShared）策略。

CloudInformationService：CloudInformationService（CIS）类提供资源注册，索引和发现功能。

ContainerAllocationPolicy：抽象类,表示将容器分配给VM的放置策略。可以通过扩展此类来创建不同的容器分配策略。

VmAllocationPolicy：抽象类，将VM分配给主机，此类还实现了optimizeAllocation()方法，该方法定义了容器和VM级别中的合并策略。

工作负载管理：利用CloudSim中的现有利用率模型来确定容器级别的资源需求。利用率模型是一个抽象类，用户可以覆盖其getUtilization()方法以获得各种工作负载模式。getUtilization()方法的输入是仿真时间，其输出是每个Cloudlet所需计算资源的百分比。

数据中心功耗：管理每个主机的功耗，包含了PowerModel类。可以扩展它（通过重写getPower()方法）来模拟主机的自定义功耗模型。 getPower()输入参数是主机的当前利用率指标，而其输出是功耗值。

5.物理机、虚拟机、容器

5.1 物理机、虚拟机、容器的类比

关于物理机、虚拟机、容器的类比。如图8、图9、图10所示。

图8物理机类比图

图9虚拟机类比图

图10容器类比图

由图8、图9、图10展开联想，物理机可以理解为一间别墅，一栋楼只供一户人住，这户人可以使用独立的地基（硬件基础）、房型（OS）、卫生间（回收站）、厨房（第三方应用程序）、宽带（网络）等；虚拟机可以理解为一套房，一栋楼包含多套房，一套房只供一户人住，这户人与同一栋楼的居民共享地基（硬件基础），有独立的房型（OS）、卫生间（回收站）、厨房（第三方应用程序）、宽带（网络）等；容器可以理解为一套房被隔成的多个小单间（胶囊式公寓），每个单间都有一位用户使用，这位用户与其他用户共享地基（硬件基础）、房型（OS）、卫生间（回收站）、厨房（第三方应用程序）、宽带（网络）。

5.2 为什么会有虚拟机技术？

在没有云平台之前，服务器采用“独立部署”方式，这种部署方式的弊端在于资源的浪费。虚拟机是针对“独立部署”的不足，为了提高服务器资源使用率而提出的方法。

相比于物理机，虚拟机的优势：

更高的资源利用率；(2)降低管理成本；(3)提高使用灵活性；(4)提高安全性；(5)更高的可用性；(6)更高的扩招性；(7)互操作性和投资保护。

通常，数据中心的一台主机的资源可以根据用户的需求映射到多台虚拟机上，因此，虚拟机之间存在对主机资源的竞争关系，而且虚拟机的启动时间长。

5.3 为什么会有容器技术？

针对于虚拟机的缺陷，容器技术沿着“怎样减少启动时间”这个思路而产生。容器技术的本质是在一个服务器上只运行一个操作系统，每次部署一个新的软件不用重新启动操作系统，只剩下软件本身的启动时间。虚拟机与容器的对比如图11所示。

图11虚拟机与容器的架构对比

从架构的对比可以分析，每一台虚拟机都有自己的操作系统，因此虚拟机都有自己的内核（Kernel），而容器采用镜像技术，只有一个操作系统，也只有一个内核（Kernel）。在一台服务器上，只需安装一个本地操作系统，能启动多个容器。相比于虚拟机，容器的优势如图12所示。（1）降低了硬件成本；（2）更快速和便捷的开发、测试、生产环境；（3）与微服务架构更为契合。

图12 容器的优势

容器被称为“虚拟化2.0”技术，自概念的兴起以来，一直备受关注，很多人认为容器会取代虚拟机。但实际上，在容器处于高度成熟的这个阶段，虚拟机依然存在，容器可以直接部署在虚拟机上，也可以直接部署在物理机上。容器运行在虚拟机上，虚拟机运行在物理机上，这种策略相当于一栋楼（物理机）的一套房（虚拟机）被分成多个单间（容器）出租，这样做的好处是便捷性与安全性，当然也有缺陷，那就是延时。将容器直接部署在物理机上，这种策略相当于一栋楼的一层楼分成多个单间出租，这样做延迟低，但是安全性不高，而且不方便。所以可以得出结论，容器技术和虚拟机并不是简单的取舍关系，容器并没有完全取代虚拟机，而是对虚拟技术进行了改进。

参考：

https://www.cnblogs.com/yuxiaoba/p/9260633.html

http://www.loongson.cn/m/view.php?aid=836

https://blog.csdn.net/yibuchen/article/details/80426680

https://blog.csdn.net/dt763C/article/details/82321296

CloudSim怎么用？

6. CloudSim的事件驱动机制

CloudSim以事件驱动的机制进行仿真，无论初始条件和调度策略是否有变化，CloudSim的仿真流程都不会变。事件处理机制主要由事件队列、处理事件的实体组成，简单的说，事件处理机制是：在相关的实体资源被注册之后，事件根据其状态存放在队列中，然后各个实体不断的检查队列，取出队列中的事件进行处理。

CloudSim仿真流程可分为三个阶段：初始化仿真环境，执行仿真，结束仿真。

在第一阶段初始化仿真环境时，先初始化CloudSim核心仿真引擎，这标志着仿真已经开始，然后创建数据中心，再创建数据中心代理，这是上一级的实体资源，接下来创建虚拟机，虚拟机是下一级的实体资源，所以要将虚拟机列表提交给数据中心代理，然后创建云任务，将云任务列表要提交给数据中心代理。

初始化完成后，正式启动仿真，在这一阶段，主要是按照相应的调度策略处理仿真运转过程中产生的各个事件，在软件源码中，调度策略有时间共享策略和空间共享策略，研究人员还可以根据具体应用进行扩展，开发出其它调度策略，因所有事件都要经过future队列，所以若此队列中没有任何事件，则可停止仿真，如有事件，则加入到deferred队列中，等待下一步处理。在执行仿真阶段，可以暂停仿真，需要继续运行时，可唤醒仿真，继续运行。

如果所有事件处理完毕，则预示着仿真运行阶段的结束，如此，则可以结束仿真，在仿真结束阶段，主要是设置实体为不可运行状态，标识实体关闭，结束仿真。如图13所示，每一个方框代表一个事件，每一个菱形代表事件执行的条件。

图13 CloudSim仿真流程图

仿真流程的大致逻辑是：DC和Broker之间往来事件以确认DataCenterCharacteristic创建完成 -> Broker产生事件VM_CREATE_ACK要求DC创建VM -> DC完成VM创建并产生ACK事件 -> Broker收到后接着产生CLOUDLET_SUBMIT事件要求DC处理分配执行云任务 -> DC调用相关函数更新集群状态（相当于执行任务）、产生相关事件（发给自己，事件clock已推进）、产生任务完成事件（事件的clock已推进）等 -> Broker处理CLOUDLET_RETURN等事件，仿真过程基本结束。如图14所示。