DE-RALBA: dynamic enhanced resource aware load balancing algorithm for cloud computing

DE-RALBA overview

DE-RALBA is a dynamic and enhanced technique in cloud-based computing architecture. It comprises two sub-schedulers: DE-RALBA and Update-Scheduler. Figure 1 shows the DE-RALBA based Cloud computing architecture at abstract level. The performance evaluation of DE-RALBA is conducted in a simulation environment using the CloudsimPlus. The tasks or jobs on the cloud system are referred as cloudlet in CloudSimPlus simulator. The delivery of infrastructure-as-a-service (IaaS) and platform-as-a-service (PaaS) are provided by the physical and virtual layers to the cloud users. The physical layer comprises the actual computing, memory and storage resources in the form of physical machines (PMs) presenting the overall computing power of a datacenter. These physical machines are presented as PM1, PM2, PM3,…, PMN in the Fig. 1. The computing and storage services are transparently managed by the virtualization layer to provide dynamic sharing of computing and storage in the form of VMs to cloud users (Hussain et al., 2018). Cloud resource manager operates at the top of the virtualization layer and its primary responsibility is to handle the creation, termination, and migration of VMs as needed for the computing purposes. The cloud resource manager also communicates to provide the availability and computing capabilities of VMs to the DE-RALBA scheduler. To ensure efficient utilization of VMs in load-balanced manner, the proposed DE-RALBA algorithm is implemented on top of the virtualization. This algorithm provides a balance allocation of cloudlets across the available VMs in the cloud system.

The system accessibility layer serves as an interface for the cloud users to conveniently submit their cloudlets for processing in the cloud environment.

DE-RALBA system architecture

The proposed DE-RALBA technique is an enhanced version of the RALBA mechanism (Hussain et al., 2018). DE-RALBA system architecture is presented in Fig. 2 and the Table 2 presents the terminologies and notations used in explaining the system model of DE-RALBA. The proposed approach is dynamic scheduling which updates the VM’s status and manages the arrival time of the cloudlets at runtime.

The DE-RALBA comprises two sub-schedulers, i.e., DE-RALBA and Update. The DE-RALBA maps the cloudlets to VMs based on computation share and EFT of cloudlets. The computation share of each VM is determined based on the total workload submitted and the total computation power available for executing it on the Cloud. At first, VM_j with maxVShare is selected and determines maxPCld for this VM_j. The selected cloudlet (maxCld) is assigned to VM_j and vStatusTable_vmj is updated. The vmShare of VM_j is modified and the assigned cld is removed from the cldList. This process continues until maxPCld returns NULL and cldList becomes empty. If maxPCld returns NULL, the scheduler checks the status of newly arrived cloudlets. If new cloudlets arrive, then the Update-Scheduler is called. If the maxPCld and iscldArrive returned false while cldList is non-empty, then the scheduler allocates the already arrived clds to VM using EFT on VM. The scheduler picks the maxCld from the already arrived cldList and determines the VM_j for maxClds with EFT. The selected cld is assigned to VM and vStatusTable_vmj of VM_j is modified. The process continues until cldList becomes empty. The DE-RALBA Scheduler also monitors the vStatusTable of VM when the VM_j completed all of its allocated clds and the remaining vStatusTable_vmj.remMI of VM_j is ZERO. The scheduler then tries to balance the load by shifting cld from loaded VM to emptyV (empty VM). The cldTList is getting from VM_j of lV and compares the execution time of lV and emptyV; if the emptyV execution time is less than lV execution time, then cld is moved to emptyV, and ctdSList is updated. The ctdTList is iterated, and removing the minCld from the list is after one iteration. The process continues until the ctdTlist becomes empty.

The Update-Scheduler updates the vStatusTable_vmj of VM_j with the current time of the execution. The input of the scheduler is the list of VMStatusTable and the current time of the datacenter. The vStatusTable_vmj.executedMI, vStatusTable_vmj.remMI, vStatusTable_vmj.readyTime of VM_j are updated with respect to the time clock of the datacenter and the update vStatusTable is returned to the main scheduler.

DE-RALBA system model

The system model of cloud design delineates the performance of DE-RALBA-based job scheduling. A cloud is comprised of various VMs represented as VMS = { $V{M}_1$, $V{M}_2$, …, $V{M}_m$}, where m is the number of VMs, and a single VM can be presented as $V{M}_j$ $(1\le j\le m)$. The cloudlets are presented as CLS = { $Cloudle{t}_1$, $Cloudle{t}_2$, …, $Cloudle{t}_n$}, where n is the number of cloudlets and a single cloudlet can be shown as $Cloudle{t}_i$ $(1\le i\le n)$. A cloud resource manager provides the computation ratios (vmCrMap) of all VMs to DE-RALBA, where $vmCrMa{p}_j$ can compute as:

(1) $$vmCrMa{p}_j=\frac{V{M}_j.MIPS}{{\sum }_{k=1}^{m}V{M}_k.MIPS}.$$

$vmCrMap$ is used to ensure a balanced load distribution among VMs and to calculate the compute share of all VMs (VMShare). The $VMShar{e}_j$ of $V{M}_j$ is expressed as:

(2) $$VMShar{e}_j=\sum _{i=1}^{n}Cloudle{t}_i.MI\times vmCrMa{p}_j.$$

The scheduler assigns a cloudlet to a VM depending on the $VMShare$. The $RPCloudle{t}_j$ of a given $V{M}_j$ may be calculated as follows:

(3) $$RPCloudle{t}_j=\{Cloudlet|Cloudlet\in CLS,Cloudlet\le VMShar{e}_j\}$$where, $maxPCld$ in each scheduling decision can be computed as:

(4) $$maxPCld=\underset{\mathrm{\forall }p\in RPCloudle{t}_j}{max}Size(p).$$

In addition, each time the scheduler makes a scheduling choice; the candidate cloudlet is deleted from the list of cloudlets. While, minCld and maxCld are computed:

(5) $$\mathrm{m}\mathrm{i}\mathrm{n}\mathrm{C}\mathrm{l}\mathrm{d}=\underset{\mathrm{\forall }c\in CLS}{min}\mathrm{S}\mathrm{i}\mathrm{z}\mathrm{e}(c)$$

(6) $$\mathrm{m}\mathrm{a}\mathrm{x}\mathrm{C}\mathrm{l}\mathrm{d}=\underset{\mathrm{\forall }c\in CLS}{max}\mathrm{S}\mathrm{i}\mathrm{z}\mathrm{e}(c).$$

On cloudlet— $V{M}_j$ allocation, the computation share of $V{M}_j$ is modified by subtracting the cloudlet size from the current $VMShar{e}_j$. The VM with the biggest $VMShar{e}_j$ is chosen by calculating the $maxVShare$ as follows:

(7) $$\mathrm{m}\mathrm{a}\mathrm{x}\mathrm{V}\mathrm{S}\mathrm{h}\mathrm{a}\mathrm{r}\mathrm{e}=\underset{\mathrm{\forall }j\in \{1,2,3,\dots ,m\}}{max}(\mathrm{V}\mathrm{M}\mathrm{S}\mathrm{h}\mathrm{a}\mathrm{r}{\mathrm{e}}_j).$$

The scheduler utilizes $Cld\mathrm{\_}EF{T}_i$ to assign leftover cloudlets to VMs. The $Cld\mathrm{\_}EF{T}_i$ of a given $Cloudle{t}_i$ is determined using the formula:

(8) $$Cld\mathrm{\_}EF{T}_i=\underset{\mathrm{\forall }j\in \{1,2,3,\dots ,m\}}{max}(\mathrm{C}\mathrm{l}\mathrm{o}\mathrm{u}\mathrm{d}\mathrm{l}\mathrm{e}\mathrm{t}\mathrm{\_}{\mathrm{C}\mathrm{T}}_{{\mathrm{i}}_{\mathrm{j}}}).$$where $Cloudlet\mathrm{\_}C{T}_{i_j}$ is $Cloudle{t}_i$ estimated completion time on $V{M}_j$: The definition of the $Cloudlet\mathrm{\_}C{T}_{i_j}$ is:

(9) $$\mathrm{C}\mathrm{l}\mathrm{o}\mathrm{u}\mathrm{d}\mathrm{l}\mathrm{e}\mathrm{t}\mathrm{\_}\mathrm{C}{\mathrm{T}}_{{\mathrm{i}}_{\mathrm{j}}}=\left(\frac{\mathrm{C}\mathrm{l}\mathrm{o}\mathrm{u}\mathrm{d}\mathrm{l}\mathrm{e}{\mathrm{t}}_{\mathrm{i}}.\mathrm{M}\mathrm{I}}{\mathrm{V}{\mathrm{M}}_{\mathrm{j}}.\mathrm{M}\mathrm{I}\mathrm{P}\mathrm{S}}\right)+\mathrm{V}\mathrm{M}\mathrm{\_}\mathrm{C}{\mathrm{T}}_{\mathrm{j}}.$$

The $VM\mathrm{\_}C{T}_j$ is the completion time of $V{M}_j$ for workloads already assigned before the allocation of $Cloudle{t}_i$ and is calculated as follows:

(10) $$VM\mathrm{\_}C{T}_j=\sum _{i=1}^n\frac{Cloudle{t}_i.MI\times F[i,j]}{V{M}_j.MIPS}.$$where F[i,j] is a Boolean variable that decides the assignment of $Cloudle{t}_i$ to $V{M}_j$, as shown:

(11) $$F[i,j]=\{\begin{array}{cc}1,\hfill & Cloudle{t}_i\mathrm{i}\mathrm{s}\mathrm{a}\mathrm{s}\mathrm{s}\mathrm{i}\mathrm{g}\mathrm{n}\mathrm{e}\mathrm{d}\mathrm{t}\mathrm{o}\mathrm{V}\mathrm{M}\mathrm{j}\hfill \\ 0,\hfill & \mathrm{O}\mathrm{t}\mathrm{h}\mathrm{e}\mathrm{r}\mathrm{w}\mathrm{i}\mathrm{s}\mathrm{e}\hfill \end{array}.$$

DE-RALBA performance model

Makespan is represented as Panda & Jana (2017), Hussain et al. (2018):

(12) $$Makespan=\underset{\mathrm{\forall }j=1,2,3,\dots ,m}{max}(VM\mathrm{\_}C{T}_j).$$

ARUR is a metric for presenting the total cloud usage (Panda & Jana, 2017; Hussain et al., 2018) as presented in following equation. ARUR’s value stays between 0 and 1. The higher the ARUR number, the greater the resource consumption in the cloud.

(13) $$ARUR=\frac{\frac{{\sum }_{j=1}^{m}VM\mathrm{\_}C{T}_j}{m}}{Makespan}.$$

DE-RALBA algorithm

The DE-RALBA algorithm is elaborated with its two primary sub-schedulers i.e., DE-RALBA Scheduler (in Algorithm 1) and Update Scheduler (in Algorithm 2).

DE-RALBA-scheduler algorithm

The DE-RALBA is a scheduling mechanism designed to optimize cloudlet allocation across heterogeneous VMs in cloud computing environments. The algorithm addresses the critical challenges of efficient resource utilization, balanced load distribution, and reduced execution times. By leveraging the computational capacities of VMs and dynamically adapting to workload changes, DE-RALBA ensures that cloudlets are allocated in a manner that minimizes execution overhead while preventing resource underutilization or bottlenecks. The algorithm begins by analyzing the system’s computational capacity, represented in the VM Status Table (vStatusTable) and Cloudlet Status Table (cldStatusTable). The vStatusTable provides essential details about each VM, including its processing power, readiness status, and currently assigned workloads. The cldStatusTable contains information about cloudlets, such as their lengths (in terms of million instructions) and scheduling statuses. Using this data, DE-RALBA calculates the total computational workload and determines each VM’s share (vShare) based on its processing capacity ratio (vCRatio). This preliminary step ensures that each VM is assigned a workload proportional to its capabilities, promoting equitable resource distribution.

The core of the algorithm revolves around iteratively assigning cloudlets to VMs in a manner that prioritizes efficiency. VMs with the highest remaining share (maxVShare) are given precedence, and the most suitable cloudlet (maxPCld) is identified and assigned to these VMs. The algorithm dynamically updates the VMs’ remaining share to reflect the newly assigned workload and removes the cloudlet from the scheduling queue. In cases where no immediate cloudlet is suitable for the VM with the highest share, the scheduler invokes an update mechanism that incorporates newly arrived cloudlets into the system. Furthermore, if no VMs with high remaining shares are available, DE-RALBA employs an earliest finish time (EFT) heuristic. This heuristic identifies the VM that minimizes the execution time for the given cloudlet, ensuring cloudlets are completed as quickly as possible. To address imbalances caused by idle or underutilized VMs, the algorithm incorporates a robust load-balancing mechanism. If any VM remains idle while others are heavily loaded, DE-RALBA redistributes cloudlets from loaded VMs to idle ones. This redistribution is guided by a reassessment of execution times, ensuring that the overall system throughput is optimized without introducing unnecessary delays. Additionally, the algorithm handles interruptions by dynamically reevaluating the status of empty or partially loaded VMs and reallocating cloudlets to ensure consistent resource utilization.

The iterative process continues until all cloudlets have been assigned and processed. Through its dynamic, priority-based cloudlets allocation and load-balancing strategies, DE-RALBA ensures an efficient and balanced use of resources. Its ability to adapt to real-time system changes and workload variations makes it a powerful solution for modern cloud computing environments, where efficiency and scalability are paramount.

Update-scheduler algorithm

The algorithm begins by initializing a variable executedMI to 0. This variable tracks the amount of work completed by each VM. It then iterates over each entry in the vStatusTable, which contains the status of all VMs in the system. For each VM, the algorithm calculates the executedMI as the product of the VM’s computation power and the current simulation time (currentTime). This computation determines how much work the VM has processed since the last update. Following the calculation of executedMI, the algorithm updates the remMI (remaining Million Instructions) for each VM by subtracting the executedMI from the total MI of the VM (getTotalMI). This step is crucial for tracking the remaining workload that needs to be completed. The algorithm also updates the readyTime for each VM, which is the difference between the currentTime and the VM’s last update time (getLastUpdateTime). The readyTime indicates how long it has been since the last time the VM was scheduled or executed, helping to track its readiness for the next cloudlet. Finally, the lastUpdateTime of each VM is set to the current simulation time to ensure that the next update reflects the latest time point. Once all the VMs in the system have been updated, the algorithm returns the modified vStatusTable, providing the most current status of each VM, including the executed MI, remaining MI, and ready time. This updated information is essential for efficient resource allocation and cloudlet scheduling in the system.

Experimental setup

The experiments are conducted on a computing machine equipped with Intel Core™ i5-4030U CPU @ 1.90 GHz 2.49 GHz and 12 GB of RAM. Table 3 describes the configuration of the computing simulation environment. The experiments are evaluated by using computing resources ranging from 16 to 50 VMs hosted on 30 host machines within a Cloud. The statistics of the VMs with its power in MIPS (Millions of instructions per second) used for the execution of various instances of the GoCJ and HCSP datasets are shown in Figs. 3 and 4.

Dataset used

Two scientific benchmark datasets are used in this study. The first benchmark dataset is the expected time to compute (ETC) model of Braun (2000) in the form of HCSP instances and the second dataset is the Google-like realistic workload proposed in the form of GoCJ benchmark dataset. The GoCJ and HCSP datasets are publicly available for use on the given URLs provided in Hussain & Aleem (2018a, 2018b) and Tracy (2000), respectively.

The GoCJ dataset comprises various types of jobs, including small, medium, big, extra-large, and massive tasks. These tasks are classified and categorized within the GoCJ dataset based on their respective sizes and complexities (Hussain & Aleem, 2018b). In the HCSP dataset, a range of tasks, including small, medium, big, extra-large, and massive are included. These tasks are classified based on their size. HCSP instances are labeled using a name with pattern C-THMH, where c indicates the consistency type (c for consistent, s for semi-consistent, and i for inconsistent), TH and MH indicate the job and machine level heterogeneity, respectively (lo and hi for low and high heterogeneity, respectively). This shows that HCSP instances provide different variants of possible heterogeneity at machine’s power and job’s sizes level. Additionally, the HCSP dataset provides information about the specifications of the host machine and VMs used for computation of different instances of HCSP dataset. Figures 3 and 4 show the composition of VMs and its computation power used for GoCJ and HCSP datasets, respectively.

CloudSimPlus simulator

The CloudSimPlus simulator is used for the experimental evaluation of this work. The CloudSimPlus is an up-to-date and full-featured cloud simulation framework. It is easy to use and extend, enabling modeling and simulation of cloud computing services. Figures 5 and 6 show a few simulations of experimentation conducted using CloudSimPlus simulator.

Performance results: GoCJ dataset

In Fig. 7, the ARUR results of DE-RALBA, DRALBA, PSSELB, PSSLB, and Dynamic Max-Min algorithms are presented. ARUR values are depicted on a scale ranging from 0.0 to 1.0. These results are obtained by evaluating the algorithms across different numbers of GoCJ workload instances as presented.

To provide a clearer representation, Fig. 8 displays the mean ARUR-based results of DE-RALBA, DRALBA, PSSELB, PSSLB, and Dynamic Max-Min algorithms in terms of percentage resource utilization. DE-RALBA achieves significantly higher resource utilization compared to the other algorithms, with values reaching 162.13%, 98.22%, 100.77%, and 534.49% higher than DRALBA, PSSELB, PSSLB, and Dynamic Max-Min, respectively. These results demonstrate the superior performance of DE-RALBA in efficiently utilizing available resources in the cloud-based environment.

The results shows that Dynamic-MaxMin provides the poor resource utilization because this technique favors large-sized jobs that may cause starvation for the allocation of small-sized jobs (as mentioned in the literature). DRALBA, PSSELB, and PSSLB techniques are claimed to be load-balancing algorithms in literature and provide better resource utilization as compared to Dynamic-MaxMin algorithm. The proposed DE-RALBA is a resource-ware load-balancing technique; therefore, it provides a more balanced distribution of jobs among the resources by considering their computing powers. The resources with higher power are allocated with more number of or large-sized jobs, while relatively slower resources are allocated with less number of or small-sized jobs. The ARUR-based results in Figs. 7 and 8 prove that DE-RALBA outperforms the these scheduling algorithms with significant improvements in resource utilization by ensuring the optimal balanced distribution of workload among resources.

Figure 9 illustrates the makespan-based results of DE-RALBA, DRALBA, PSSELB, PSSLB, and Dynamic Max-Min algorithms in terms of seconds, using different numbers of GoCJ instances workload.

For more clarity of representations, Fig. 10 presents the average makespan in seconds achieved by DE-RALBA, DRALBA, PSSELB, PSSLB, and Dynamic Max-Min algorithms. In terms of average makespan, DE-RALBA demonstrates significant improvements compared to the other algorithms. Specifically, DE-RALBA achieves a decrease of 81.96%, 50.45%, 50.45%, and 83.02% in makespan compared to DRALBA, PSSELB, PSSLB, and Dynamic Max-Min algorithms, respectively. These results highlight the superior performance of DE-RALBA in minimizing the total execution time and improving the overall efficiency of task scheduling in the cloud environment by providing load-balanced schedule of workload.

Performance results: HCSP dataset

Figure 11 presents the ARUR-based results (on a scale of 0.0–1.0) of DE-RALBA, DRALBA, PSSELB, PSSLB, and Dynamic Max-Min algorithms for the different number of HCSP instances workload.

For more clarity of representations, Fig. 12 presents the mean ARUR-based results of DE-RALBA, DRALBA, PSSELB, PSSLB, and Dynamic Max-Min algorithms in terms of percentage resource utilization. DE-RALBA achieves 50.82%, 8.64%, 8.19%, and 52.35% higher resource utilization than DRALBA, PSSELB, PSSLB, and Dynamic Max-Min, respectively. HCSP instances provide different possible variants of heterogeneity in the composition of machines and jobs (discussed in the dataset section), the results in Figs. 11 and 12 prove that DE-RALBA provides significant improvements in resource utilization against these scheduling algorithms. The proposed DE-RALBA is termed as resource-aware technique because it provides consistently improved results in resource utilization for various dataset instances possessing different types of heterogeneity in the composition of machines and jobs.

Figure 13 showcases the makespan-based results in seconds of DE-RALBA, DRALBA, PSSELB, PSSLB, and Dynamic Max-Min algorithms across different numbers of GoCJ instances workload.

To enhance clarity, Fig. 14 presents the average makespan in seconds derived from the results of DE-RALBA, DRALBA, PSSELB, PSSLB, and Dynamic Max-Min algorithms. Remarkably, DE-RALBA demonstrates substantial reductions in makespan compared to the other algorithms. Specifically, DE-RALBA achieves a significant decrease of 345.75%, 25.61%, 26.03%, and 227.89% in makespan compared to DRALBA, PSSELB, PSSLB, and Dynamic Max-Min algorithms, respectively. These results underscore the exceptional performance of DE-RALBA in effectively minimizing the total execution time and enhancing job scheduling efficiency within the GoCJ and HCSP instances workload scenario.