CloudSim核心问题理解

1、optimizeAllocation函数中为何要先store所有虚拟机和主机映射，然后再restore进行恢复？

---

1）此函数先会执行getOverUtilizedHosts操作，得到过载主机；

2）然后执行saveAllocation操作，每次执行都会清空其对应的存储map；

3）然后从这些过载主机上选择待迁移的VMs，并对应找到合适的新的主机位置（此过程getNewVmPlacement中，在新选择的主机上对相应的VMs执行vmCreate操作）；

4）进一步在3）步执行得到的vm-host映射map中添加欠载主机vm以及对应的迁移主机ID；

5）执行restoreAllocation操作，此操作会清空所有主机上所有的vms，即3）、4）步骤中所建立的实际映射关系将全部重新清空；然后根据saveAllocation事先保存的vm-host映射进行重新部署；

6）optimizaAllocation函数返回建立带迁移的（过载和欠载分析得到的vm-host映射），回到updateCloudletProcessing函数继续执行；

7）updateCloudletProcessing函数中，对于optimizeAllocation所得到每一组迁移映射进行遍历，并执行addMigratingInVm函数，在targetHost上执行create操作，即部署映射关系上面的VMs，同时增加迁移计数；

8）给当前的Datacenter Entity发送迁移消息，到此迁移过程全部结束。

2、updateCloudletProcessing函数中通过optimizeAllocation函数得到待迁移虚拟机和host之间的映射对之后，为何还需要在targetHost上执行addMigratingInVm操作，这个跟在optimizeAllocation中寻找分配主机时以及restore里面的vm.create是否冲突？

3、Vm、cpu MIPS的分时和空间调度具体怎么体现？

---

4、updateCloudletProcessing、updateVmsProcessing、updateVmProcessing的含义或者目的是什么，怎么理解？

---

1）updateCloudletProcessing

（1）调用每个主机的updateVmsProcessing方法，得到所有主机中所有vm中最早完成的任务估计时间；

（2）对当前datacenter发送VM_DATACENTER_EVENT消息。

2）updateVmsProcessing

（1）该方法源于HostDynamicWorkload继承自Host类，其主要执行两部分类型。第一部分调用Host（即父类）的super.updateVmsProcessing(currentTime)方法，第二部分主要执行Log操作和Host分配以及VM分配的相关状态存储操作，这个状态是指的是当前的分配状态，主要用于后期的SLA统计；

（2）父类即Host类updateVmsProcessing中，遍历当前主机的每个vm，调用updateVmProcessing(currentTime, getVmScheduler().getAllocatedMipsForVm(vm))方法，返回所有vm所有任务中预计最早完成的完成时间。

（3）更新上一次mips利用率为当前的mips利用率，并设置当前的mips利用率为0；

（4）每个vm重新分配mips，vm.getCurrentRequestedMips()为每个vm当前请求的mips数量。

3）updateVmProcessing(double currentTime, List mipsShare)

（1）此方法实际执行的是CloudletSchedulerDynamicWorkload类中代码，继承自CloudletSchedulerTimeShared（并继续向上继承自CloudletScheduler），用户可同样通过实现继承该父类，实现其中的updateVmProcessing方法，来完成自定义的cloudlet mips调度机制；

（2） 此方法传入的参数包括当前时间和共享请求的mipsShare数组（表示对每个核的mips请求占用情况）；

（3）此方法首先更新其mipsShare属性；

（4）遍历当前VM中所有存在的CloudLet任务（在实际处理时，用ResCloudlet rcl来集中表示每个cloudlet任务相关数据信息）；

（5）对于每个正在执行中的任务，rcl计算当前任务实际已经完成量，执行代码rcl.updateCloudletFinishedSoFar((long) (timeSpan * getTotalCurrentAllocatedMipsForCloudlet(rcl, getPreviousTime()) * Consts.MILLION)); 其中timespan表示当前时刻距离上一时刻的时间差，并乘以当前分配给该任务的Mips大小，即表示已经执行的任务长度。其中getTotalCurrentAllocatedMipsForCloudlet函数比较的是上一时间该cloudlet请求的总mips和当前时刻

mipsShare中所提供的mips。因为是时间共享，所以对于每个核都共享核的mips使用。

（6）如果当前的任务或者说rcl体现的任务剩余长度不为0，则预测该任务的完成时间getEstimatedFinishTime(rcl, currentTime)。预计完成时间=当前时间+任务的剩余长度/当前时刻下该任务请求的mips量和实际可获得的mips量的最小值。第5步骤中计算任务完成量时，用的是上一时刻用户请求的mips量，而不是当前时刻。而此处估计任务完成时间时同样用的当前传入的mipsShare，而非下一时刻的mipsShare。

（7）判断预测的结束时间和当前时间的时间差与最小事件间隔0.1之间的大小关系，如果小与最小事件间隔，则将该任务的预计完成事件设置为当前事件+最小事件间隔时间schedulingInterval

（8）返回所有任务中最小预计完成时间

5、当发现MIPS过载时，Vms调度器执行redistributeMipsDueToOverSubscription函数来重新分配各个VMs的Mpis资源，这个函数具体怎么理解？

---

1）VMs调度器是主机创建时用户传入的可控制程序，此代码中以VmSchedulerTimeSharedOverSubscription表示；

2）VmSchedulerTimeSharedOverSubscription继承自VmSchedulerTimeShared，进一步继承自VmScheduler；

3）用户自定义时必须重载allocatePesForVm方法，即定义如何对Vms进行MIPS的分配（源码中主要定义了时间共享和空间共享两种机制）

4）在allocatePesForVm(String vmUid, List mipsShareRequested)函数被调用时，其传入的时VM的唯一编码（用户ID+VM ID），以及该VM对每个CPU核的MIPS请求；

5）由于VmSchedulerTimeSharedOverSubscription表示的含义是VM时间共享，并且允许请求的MIPS过载。因此在allocatePesForVM函数中：

a、由于时间共享，当前处理的VM和同主机其他vms一个时间单位内共享核的使用，因此代码中率先遍历mipsShareRequested（表示该VM对每个CPU核所请求的mips），如果大于核的容量，则以核的容量为准，计算该VM总共请求的mips，并用mipsShareRequestedCapped存储该VM所实际请求的mips（超过核容量的以核容量为准）；

b、如果当前调度器发现当前处理的vm正处于迁入专改，那么对a步骤中计算得到的当前vm的总请求mips乘以0.1，表示目的host只负责提供当前vm实际请求（以mipsShareRequestedCapped为准）量的10%。其导致的结果是当前vm分配到目标主机时，实际只占用了实际请求10%的量；

c、由于上面计算得到的当前VM的总请求MIPS量，并不代表当前Host（即目标host）的实际可用mips容量能够完全满足该vm的需求；

d、如果满足需求，则进一步判断的当前的vm是否处于迁出状态，如果是，那么对VM请求的mipsShareRequestedCapped，每个核对应的请求mips量乘以0.9，表示迁出时（该VM遭受了10%的性能下降）；如果不是，进一步判断是否处于迁入，如果是，则相应的乘以0.1，表示实际只占用当前请求的10%的量；然后在mipsMap中存入vmUid和对应每个核上分配的mips量；

e、如果不满足需求，转而执行redistributeMipsDueToOverSubscription函数，对每个VM重新分配每个核的占用量；

（1）VM调度器中存储了每个VM到其各自在每个物理核上的请求映射；那么在此函数中会实现遍历这个map链表，对vm实际请求的mips进行capped处理，即超出了核的实际容量，按照核的实际容量表示该vm对此核的请求；如果当前vm是迁入（同样以0.1乘之）；

（2）然后统计出所有VM的总请求Mips数以及该主机所有核的实际总容量，并相除得到scaling系数，即redistributeMipsDueToOverSubscription函数意图通过scaling方式统一缩小每个vm的请求量；

（3）然后按照此scaling系数处理每个vm在每个核上请求的mips数量，等比例放缩。至此，VMs的Mips分配结束。

6、如何统计SLA数量？

---

1）每次updateCloudletProcessing操作，都会对应存储HostStateHistoryEntry

和VmStateHistoryEntry，其中记录了对应主机或者vm请求的mips、实际分配的mips等等；

2）Helper类中实现了对这些entry的统计方法，计算出对应的SLA，主要以实际请求的mips和实际分配的mips进行比较

7、既然过载检测完成了，然后也对一个给vm找到了合适的主机，那么Host在addMigrateIn(vm)的时候还会出现SLA问题呢，即为什么还会进一步调用redistributeMipsDueToOverSubscription函数？

---

1）isSuitableForVm的判断条件是

getVmScheduler().getPeCapacity() >= vm.getCurrentRequestedMaxMips()

每一个Pe的容量要大于虚拟机针对每个Pe（逻辑核）所请求的最大的mips

getVmScheduler().getAvailableMips() >= vm.getCurrentRequestedTotalMips()

总的可获得mips大于请求的总的mips

getRamProvisioner().isSuitableForVm(vm, vm.getCurrentRequestedRam())

总的可获得ram大于请求的总的ram

getBwProvisioner().isSuitableForVm(vm, vm.getCurrentRequestedBw()));

带宽如上

2）Host类的addMigratingInVm中allocatePesForVm函数

（1）如果当前主机中正在迁入的vms中已经包含了此vm，那么所有的请求的mips即vm请求的mips性能下降至10%，即只能请求10%的mips；

（2）进一步的，如果请求的mips小于可获得的mips，那么对于每个核上请求的mips，执行：

a、如果迁出的vms列表中已经包含了此vm，那么请求的mips下降至90%，即性能下降90%；

b、如果是迁入的vms列表中已经包含了额此vm，那么性能下降至10%；

c、否则，请求的mips量不发生变化。

（3）如果请求的mips大于可获得的mips，那么调用redistributeMipsDueToOverSubscription进行重分配。

8、函数调用的执行顺序，为何会出现违反SLA的现象？

---

Datacenter|processEvent

PowerDatacenter|updateCloudletProcessing

PowerDatacenter|updateCloudetProcessingWithoutSchedulingFutureEventsForce

此函数会以上一个时间点的状态为依据，以此更新每个主机，每个vm中每个cloudlet的进度，即以上一个时间点的cpu利用率和总的mips计算上一个时刻到现在该cloudlet执行了多少长度，返回所有任务中最早的一个预测完成时间。如果该时长小于最小的事件周期时间0.1s，则以0.1为依据，时间轴往前推0.1s；否则，时间轴往前推至：当前时刻+所有任务的最小预测完成时长。

-->updateCloudletProcessing先执行

-->updateCloudetProcessingWithoutSchedulingFutureEventsForce，再完成

-->getVmAllocationPolicy().optimizeAllocation的操作。因为此时利用的是上一时刻的分配的CPU数据和请求数据进行SLA检测的。为此，才会出现违反SLA的情况。

HostDynamicWorkload|updateVmsProcessing

VmSchedulerTimeShared|allocatePesForVm

此时可获得mips小于请求的mips，违反SLA

9、CloudSim的时间更新机制？

---

1）初始的系统模拟时间是0.0，系统的clock更新是以当前执行的事件事件为依据的；

2）模拟开始后，系统会轮询执行future队列里面的事件；

3）事件执行过程中，事件执行时又可能触发新的事件。新的事件时间一般设置成当前系统时间clock+delay时间。其中delay时间根据新事件执行的对象和事件类型进行设置。比如“最短的事件周期0.1”，或者在处理cloudlet提交事件时，delay设置成该任务长度/共享的mips大小，即预期完成时间。

当然有些时间的delay被设置成getSchedulingInterval()即事先定义好的300s（5分钟）。

10、如何理解迁移导致的SLA violation和过载导致的SLA violation？

---

迁移导致的SLA violation：实际CloudSim的结果统计里面的做法是统计所有当前正处于迁移状态的虚拟机的请求资源大小和实际分配资源大小，然后计算SLA violation比例；整体的SLA比例统计只是并未单纯的统计处于迁移状态的虚拟机，而是全部的虚拟机分配和需求状态。

11、CloudSim中欠载主机的检测办法：getMigrationMapFromUnderUtilizedHosts

---

1、欠载主机的检测首先需要剔除掉三种类型的主机：过载主机、正在发生迁移操作的主机、以及处于关闭状态的主机；

2、找到所有符合1条件主机中，资源占用最少的一个主机，以此作为欠载主机。

12、何时调用updateCloudletProcessing()函数来更新任务状态？

---

1、processCloudletSubmit(SimEvent ev, boolean ack)当DC处理提交过来的任务时

2、当Power DC处理VM_DATACENTER_EVENT事件时，这个时间指的是所有Power数据中心内产生的事件，比如：VM 通过设定的 CloudletScheduler 调度 cloudlet，估计完成执行的时间并延迟发送 VM_DATACENTER_EVENT

3、processCloudletMove，即当任务发生迁移操作时。