云计算仿真工具CloudSim Plus常见问题总结

CloudSim Plus是一个用于仿真云计算场景的工具箱（库）。它提供了基本的类用于描述数据中心、虚拟机、应用程序、用户、计算资源和系统内众多部分的管理策略（例如调度与配置）。
用户能够通过组合这些组件来评估云计算中的各种新策略，比如调度算法、映射规则、负载均衡策略等。它还能被用来从各个方面评估策略的效率，例如从性价比的角度或者从追求极致性能的角度。它同时支持关于“绿色IT”政策的评估。
上述场景是一些可以预见的通用应用场景，或是用户已经探索出来的应用场景。然而，CloudSim Plus本身并没有对更广泛的应用加以限制：所有的类都可以被继承或替换，新的策略可以被添加，新的应用场景可以通过编码实现。它是云计算仿真环境的基石。
因此，CloudSim Plus并不是一个开箱即用的、只需填写一些参数就能收集仿真结果的解决方案。CloudSim Plus作为一个类库，需要用户使用Java语言编写仿真程序，利用其相关组件构建需要的仿真场景。不过，CloudSim Plus也能为用户提供一些开箱即用的解决方案。

容器即服务CaaS层连接了PaaS与IaaS层
CloudSim实体关系图

1.CloudSim Plus 的组件、通信和事件

1.1 CloudSim Plus 提供的各组件的默认机制是什么？如何才能改变它们？

Dataenter类似于Iaas的提供者。它从各个broker那里接收来自各个VM的请求并且在host中创建VM。
CloudSim Plus中提供的最基本的Broker（DatacenterBrokerSimple）只会提交一组需要被创建的VM并且顺序地调度各个Cloudlet。通常如果你需要实现想要的调度策略或者生成VM和Cloudlet的策略，需要创建自己的Broker。你可以继承这些类或者添加想要的方法来改变默认的行为机制。

1.2 如何创建编写一个适应于各个实体的周期性的行为机制？

可以通过设定一个周期性发射的内部事件（internal event）来实现。Handler在接收到这些事件后被调用，需要的机制就在这些handler中的方法中实现。下面介绍如何通过Datacenter类来实现上述方法。同样的方式可以用来在Broker中实现。
1.继承DatacenterSimple类
2.为周期性的事件定义一个新的标签（tag）
3.重写processOtherEvent方法，用来检测周期性的事件并且为它调用handler
4.实现handler中的方法。最后，这个方法也会调度这一事件的下一次调用（责任链？）
注意：你的代码必须包含一个终止生成内部消息的判断条件，否则仿真将不会停止。

import org.cloudbus.cloudsim.core.Simulation;
import org.cloudbus.cloudsim.core.events.SimEvent;
import org.cloudbus.cloudsim.datacenters.DatacenterSimple;
import org.cloudbus.cloudsim.hosts.Host;

import java.util.List;

import lombok.extern.slf4j.Slf4j;

/**
 * Created by Trojx on 2019/12/27.
 * E-mail: raojianxun@126.com
 */
@Slf4j
class NewDatacenter extends DatacenterSimple {
    public static final int PERIODIC_EVENT = 67567;//事件的标签（tag）

    public NewDatacenter(Simulation simulation, List<? extends Host> hostList) {
        super(simulation, hostList);
    }

    @Override
    public void processEvent(SimEvent ev) {
        if (ev == null) {
            log.debug("Warning: " + getSimulation().clock() + ": " + this.getName() + ": Null˓→event ignored.");
        } else {
            int tag = ev.getTag();
            switch (tag) {
                case PERIODIC_EVENT:
                    processPeriodicEvent(ev);
                    break;
                default:
                    log.debug("Warning: " + getSimulation().clock() + ":" + this.getName() +": Unknown event ignored. Tag:" + tag);
            }
        }
    }

    private void processPeriodicEvent(SimEvent ev) {
        //todo 事件的处理逻辑
        
        float delay=0;//发射下一个事件的延迟
        boolean generatePeriodicEvent=false; // 是否会生成新的内部消息并发送
        if (generatePeriodicEvent) {
            send(this, delay, PERIODIC_EVENT, null);
        }
    }
}

1.3如何创建自定义类型的事件消息？如何让它们被其他实体接收？

流程类似于上一条。首先，需要在某处声明新消息的标签（tag）。然后，事件消息的接收者（receiver）中需要有处理该事件的handler。代码类似与上面，但是handler中需要加上
异常处理。它不会产生内部消息，相反地，它会等待某实体发送消息。

2.调度策略与算法

2.1 默认的调度策略是怎样的？我应该如何修改它们？

CloudSim Plus在两个层面上调度CPU资源：Host和VM。
在Host层面，host将处理单元（Processor Element,PE）分片划分给运行于host上的各个VM。由于资源被各个VM共享，所以这个调度器称为VmScheduler。在一个host实例化后，必须设置一个VmScheduler调度器。
在VM层面，每个虚拟机将从host那里分配到的资源划分给在虚拟机中运行的各个Cloudlet。由于资源被各个Cloudlets共享，所以这个调度器成称为CloudletScheduler。在一个VM创建后，必须设置一个CloudletScheduler调度器。
在上述两个层面，有两个默认的调度策略可用：一，xSpaceShared（x代表VmScheduler或者CloudletScheduler），Cloudlet或VM所需的PE将被独有地安排。这意味着如果Cloudlet或VM数量大于可用的PE数量，后面到达的Cloudlet或VM将在队列中等待，直到有足够的空闲资源。二，xTimeShared，运行中的Cloudlet或VM分时享有可用的PE，所有Cloudlet或VM同时运行。
上述Cloudlet和VM有关策略可以以任何组合形式搭配使用。例如，你可以使用VmSchedulerTimeShared 和 CloudletSchedulerSpaceShared，或者VmSchedulerTimeShared和CloudletSchedulerTimeShared。甚至一个运行了多个虚拟机的Host有多种CloudletScheduler或者是一个运行了多个Host的Datacenter有多种VmScheduler也是可能的。
如果要自定义调度策略，可以通过继承一个VmScheduler 或者CloudletScheduler类来实现。

2.2 VM层面和Broker层面分别适合实现哪些调度策略？

VmScheduler定义了在虚拟机层面的调度策略。因此，如果你想定义在同一个Host中的各个虚拟机之间的资源调度策略，就应该在这里面实现你自己的策略。
类似的，CloudletScheduler定义了在虚拟机的客户操作系统（Guest Operation System）层面上的调度策略：给定一组正在运行于虚拟机中的应用程序，可用的CPU资源将如何分配给他它们？如果你想自定义这一策略，需要继承CloudletScheduler类。
以上两个层面上的调度器都没有涉及到一点：对于给定的一组Cloudlet，哪一个应该先被执行？这一种策略应该在Broker层面上定义，因为Broker负责将各个Cloudlet依照指定的顺序调度到各个虚拟机上，同时，也可以通过指定的策略将部分Cloudlet延迟提交。例如，如果当前Broker负责调度的各个虚拟机全部过载，新提交的Cloudlet将被延迟提交给各个虚拟机执行。

2.3 默认的资源提供策略是怎样的，我如何能够改变它？

Host向虚拟机提供资源的策略遵循简单的策略：运行了最少数量的虚拟机的Host接收下一个新建的虚拟机。这一策略在VMAllocationPolicySimple类中被定义。要改变这一策略，可以继承VMAllocationPolicyAbstract类并定义新的策略，并且在初始化Datacenter时将它作为参数传递进去。

2.4 我应该修改哪些类来实现我自己的算法？

根据你想实现的算法的不同，CloudSim Plus中有几个地方可以供你实现自己的算法。通常来说，你可以通过继承一个抽象类或者一个具体类来做到。下面就是几个可以继承的类：

1. DatacenterBrokerAbstract——用来定义虚拟机的资源提供请求以何种方式提交给Datacenter，还用来定义cloudlet是如何提交并且指派给虚拟机的。
2. VmAllocatonPolicyAbstract——继承这个类，通过算法来来确定新创建的虚拟机将在存在于哪个Host中。你也可以实现动态的虚拟机重分配算法（虚拟机迁移），方法是重写optimizeAllocation方法。该方法会在每个时间帧内调用，并且在调用时获得Datacenter中全部虚拟机的结合。
3. PowerVmAllocationPolicyMigrationAbstract——通过实现能量感知的虚拟机整合算法，在每个时间帧内动态地迁移虚拟机。需要重写的主要函数是optimizeAllocation。
4. VmSchedulerAbstract——继承这个类，通过算法实现来确定单个Host中对各个虚拟机的资源分配策略。
5. CloudletSchedulerAbstract——继承这个类，通过算法实现来规划单个虚拟机中各个Cloudlet的资源分配。

3.高级特性

3.1 如何编写虚拟机迁移的代码？

虚拟机迁移是在Datacenter内部通过其内部事件触发的。因此，触发一个迁移意味着收到并处理一个VM_MIGRATION事件。这类事件是由Datacenter根据VmAllocationPolicy在收到一组待迁移的虚拟机列表后自行发出的。Datacenter发出一个迁移请求消息的调用方式如下：

send(this.getId(), delay, CloudSimTags.VM_MIGRATE, vm);

其中delay这个参数包含了迁移完成所需的时间。因此，在使用这个函数时，启动迁移过程的函数需要提供预计完成迁移的时间。在这个延迟时间过后，Datacenter接收到该事件，通过中断的方式获知迁移完成。因此，这段时间过后，迁移完成的虚拟机将在目标Host中可用。

原文地址：http://www.trojx.me/2019/12/30/cloudsim-plus-faq/