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

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


CloudSim实体关系图

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

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

Dataenter类似于Iaas的提供者。它从各个broker那里接收来自各个VM的请求并且在host中创建VM
CloudSim Plus中提供的最基本的BrokerDatacenterBrokerSimple)只会提交一组需要被创建的VM并且顺序地调度各个Cloudlet。通常如果你需要实现想要的调度策略或者生成VMCloudlet的策略,需要创建自己的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资源:HostVM
在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有关策略可以以任何组合形式搭配使用。例如,你可以使用VmSchedulerTimeSharedCloudletSchedulerSpaceShared,或者VmSchedulerTimeSharedCloudletSchedulerTimeShared。甚至一个运行了多个虚拟机的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/