System Model
Figure 2 illustrates two mechanisms, namely, A and B, that can be adopted in CaaS cloud systems. Mechanism A does not focus on power consumption; therefore, it distributes the VMs around two different PMs, whereas Mechanism B places the three VMs on one PM if the PM can host all the VMs. Mechanism B can help reduce the overall power consumption provided that the second PM is in a powersaving mode. However, CP mechanisms can affect the overall performance of CaaS clouds because the overhead of finding an appropriate solution for CP can delay the processing of jobs in CaaS systems [
35]. Therefore, the optimal mechanism should involve a tradeoff between reducing the energy consumption and improving the system performance.
This section presents the proposed DCP mechanism that extends the DWO mechanism [
16], which is a container placement mechanism designed to improve resource utilization and reduce power consumption in CaaSbased cloud systems. DWO adopts the WOA [
31], which is a metaheuristic optimization algorithm that imitates the social behavior of humpback whales. A group of Humpback whales (i.e., search agents) make a spiral shape around the prey and then swim up to hunt the prey (i.e., a solution) inside the circles. Three phases are used by the humpback whale: (i) encircling, (ii) spiral bubblenet feeding, and (iii) searching for prey. The position of the prey is unknown; therefore, the current best search agent can be any position near the prey in the search space. Other search agents then update their positions according to the current search agent [
16].
The algorithm employs a search process that commences with a randomly generated population of solutions (a matrix of solutions), which then evolves over successive generations. The solutions are always combined to form the next generation of solutions, allowing the matrix to be enhanced over the course of generations. However, the main difference between the current work and recently published papers in the literature (particularly the DWO mechanism [
16]) is that the proposed DCP mechanism utilizes a heuristic approach to direct (hence, the name of the mechanism) the search process in the mechanism. This approach plays a vital role in reducing the overall power consumption of CaaS cloud systems with an acceptable overhead time.
The workflow of the DCP policy is depicted in
Figure 3, which contains two phases: initialization and search. The initialization phase uses the number of PMs (
p), VMs (
v), and containers (
c) as the input parameters. The mechanism also obtains the number of possible solutions (
$NW$) and total number of iterations (
$iterN$) to search for the best solution. The mechanism sets
a as a double random number
$\in [2,0]$ that is linearly decreased from 2 to 0 [
31]. The number of iterations
t is set as zero.
t is an iteration counter from one to
$iterN$. Moreover,
$c{f}_{1}$ and
$c{f}_{2}$ are the coefficient vectors that are employed to determine how to update current solutions [
31]. Those vectors are calculated as follows:
Next, the policy initializes the solution matrix ($NWmatrix$), which is a matrix of NW possible solutions, and each solution can be implemented using the CP mechanism in a cloud system. It randomly assigns containers to the VMs and allocates VMs to the PMs. Furthermore, the policy in the next step employs a repair mechanism that repairs the solutions in the $NWmatrix$ because the random allocation of containers to VMs can overload some VMs with containers, i.e., the CPU or RAM requirements of the containers are greater than those of a VM that hosts those containers. Similarly, some PMs can be overloaded with VMs. Overloaded VMs or PMs must be repaired by migrating containers and VMs from overloaded VMs and PMs, respectively.
The repair mechanism employs a twofactor approach to identify the most suitable containers (or VMs) for migration. Next, an appropriate candidate VM (or PM) is selected as the new host for these containers (or VMs) [
16]. This approach aims to decrease the total power consumption by improving resource utilization. The first factor is the overloaded factor
$OF(he,ge)$, which is a function employed to select a guest element
$ge$. The guest element can be a container or VM to be migrated from an overloaded hosting element
$he$, which can be a VM or PM. The overloaded factor can be calculated as follows:
$ge$ is a generic term that refers to either containers or VMs, and
$he$ is a generic term that refers to either VMs or PMs. The second factor is the selection factor
$SF(he,ge)$, which is a function employed to select the VM (or PM) that is the most suitable candidate among all available choices. It can be calculated as follows:
Both Equations (
12) and (
13) are utilized to minimize the idle fragmentation of resources and help to efficiently harness the available resources to the maximum extent possible with an aim to improve resource utilization.
The repair mechanism fixes one solution at a time as shown in Algorithm 1. The mechanism input is a list of
$he$. If
$he$ is overloaded, the mechanism retrieves all
$ge$ elements to select the elements to be migrated. The mechanism selects the
$ge$ element with the minimum
$OF$. Subsequently, it removes it from the current
$he$ and adds it to the migration list as illustrated in lines 3–14 in the algorithm. Furthermore, the mechanism selects an appropriate destined host (
$desHe$) for each
$ge$ in the migration list,
$geMigrateList$. The
$desHe$ with the least
$SF$ is selected to host
$ge$ provided that
$desHe$ can host it as given in Equation (
3) or Equation (
6) if it is a VM or PM, respectively.
In the next step, DCP initializes the best solution (
$bs$) by creating a solution that allocates VMs to the PMs based on the firstfit (FF) heuristic. The best solution initialization mechanism is presented in Algorithm 2. DCP employs the FF approach with the aim of reducing power consumption by stacking more VMs, which improves resource utilization. In contrast to other mechanisms based on the WOA, such as [
36] and [
16], DCP does not choose the best solution among the NW solutions in the solution matrix. Rather, it constructs a solution that can direct the search process, resulting in a reduced search time. The next step is to select the first solution
${s}_{r}$ in the
$NWmatrix$ and compare it with
$bs$ in terms of energy consumption, according to Equation (
9). If
${s}_{r}$ consumes less energy, it is selected as the new
$bs$.
The search phase begins by updating the parameters a, $c{f}_{1}$, and $c{f}_{2}$ as mentioned in the initialization phase. Subsequently, if the current solution is not the same as the best solution, ${s}_{r}$ is updated using the aforementioned parameters and $bs$, as explained in the WOA. Otherwise, DCP chooses the next solution in the matrix and continues the search process. The feasibility of the updated solution of ${s}_{r}$ is checked to determine if it needs repair by sending it to the repair mechanism. Next, ${s}_{r}$ is evaluated if it consumes less energy than $bs$; subsequently, $bs$ becomes ${s}_{r}$ as explained in the previous stage. The search phase then selects the next solution ${s}_{r}$ in the solution matrix to repeat the same steps in this stage until the last solution in the matrix.
The entire search phase undergoes
$iterN$ iterations, and each iteration is supposed to generate better solutions with
$bs$ being updated. Finally, DCP generates the optimal solution
$bs$, which preserves the optimal energy in the CaaS cloud system under consideration.
Algorithm 1 Repair mechanism. 
 1:
input:$heList$  2:
foreach$ohe$ in $heList$ do  3:
while $ohe.isOverloaded==true$ do  4:
$geList\leftarrow ohe.getGeList\left(\right)$  5:
$OF=maximumValue$  6:
$migGe\leftarrow null$  7:
foreach $ge$ in $geList$ do  8:
$O{F}_{tmp}=OF(he,ge)$ //Equation ( 12)  9:
if $O{F}_{tmp}<OF$ then  10:
$OF=O{F}_{tmp}$  11:
$migGe\leftarrow ge$  12:
end if  13:
$ohe.removeElement\left(migGe\right)$  14:
$geMigrateList.add\left(migGe\right)$  15:
end for  16:
end while  17:
end for  18:
foreach$ge$ in $geMigrateList$ do  19:
$SF=maximumValue$  20:
$desHe\leftarrow null$  21:
foreach $he$ in $heList$ do  22:
if $he.canHost\left(ge\right)==true$ then  23:
$SFtmp=SF(he,ge)$ //Equation ( 13)  24:
if $SFtmp<SF$ then  25:
$SF=SFtmp$  26:
$desHe=he$  27:
end if  28:
end if  29:
end for  30:
$desHe.addElement\left(ge\right)$  31:
$geMigrateList.remove\left(ge\right)$  32:
$update(heList,desHe)$  33:
end for

Algorithm 2 Best solution initialization. 
 1:
input:$pmList$, $vmList$, $contList$  2:
output:$bs$  3:
foreach$continer$ in $contList$ do  4:
foreach $vm$ in $pvmList$ do  5:
if $assign(cont,vm)==true$ then  6:
$vm.assign\left(cont\right)$  7:
end if  8:
end for  9:
end for  10:
foreach$vm$ in $vmList$ do  11:
foreach $pm$ in $pmList$ do  12:
if $allocate(vm,pm)==true$ then  13:
$pm.allocate\left(vm\right)$  14:
end if  15:
end for  16:
end for  17:
$bs.setSolution(vmList,pmList)$  18:
return$bs$
