Resource utilization prediction with multipath traffic routing for congestion-aware VM migration in cloud computing

[Load Balancing (LB) is the most essential challenge in cloud computing for assigning the workload equally among each node that avoids the state of nodes being overloaded when others are under-loaded. To tackle this challenge, an Osmotic Hybrid artificial Bee and Ant Colony with Future Utilization Prediction (OH-BAC-FUP) algorithm has been proposed that considers both current and future utilizations of resources for choosing the most suitable Virtual Machines (VMs) to be migrated to the most appropriate Physical Machines (PMs). On the other hand, the possibility network congestion occurrence was high when increasing the bandwidth use between VMs within the cloud data centers. Also, the resource utilization efficiency was degraded when the number of congestions was high. A less-than optimal migration of VMs can lead to high network traffic since it causes inter-VM traffic for traversing the bottleneck network routes. Therefore in this article, OH-BAC-FUP with Multipath Traffic Routing (OH-BAC-FUP-MTR) algorithm is proposed to increase the efficiency of LB and minimize the possibility of congestion occurrence in cloud data centers. Initially, OH-BAC-FUP algorithm is performed for choosing the most appropriate VMs to be migrated to the most suitable PMs. If any congestion exists due to high bandwidth use or traffic flows, then MTR algorithm is applied to partition the flows and route them through multiple link-disjoint routes. Based on this, the congestion is avoided while ensuring the bandwidth and security grade demands. Also, the maximum load on any link is applied as a measure of congestion. Moreover, the current and future network states are taken into account for MTR to select the most optimal route from multiple routes without considering the past utilization of the links. Finally, the simulation outcomes demonstrate the efficiency of OH-BAC-FUP-MTR algorithm compared to the OH-BAC-FUP. 
]


Introduction
In general, the cloud computing paradigm possesses numerous problems as its usage is increasing exponentially. The most significant problem is the balancing of loads between resources (1,2) . To solve this problem, LB mechanisms are used which improves the overall system efficiency, robustness, availability and other characteristics in the cloud data centers. The objective of LB is to handle the unbalance of the workload between the datacenter to prevent overload and under overload situations. The LB mechanisms are enhanced by providing the Service Level Agreement (SLA) and customer satisfaction (3) . The development of powerful LB systems and applications is indeed a key element of cloud-based systems. For this reason, many algorithms have been developed in the field of LB with task scheduling processes in cloud services (4)(5)(6)(7)(8) .
In recent years, overall development is looking into an innovative concept in osmotic computing followed by the substance osmotic characteristic concept. It is primarily applied for achieving the balanced utilization of resources in highly distributed systems.
In cloud-based services, it is introduced to make use of balanced VMs that are migrated in the cloud devices (9,10) . Among different LB algorithms, many optimization algorithms achieve better performance; however, most of them cannot have the ability to achieve better performance in all aspects. To tackle this issue, Gamal et al. (11) proposed an OH-BAC mechanism to minimize the power usage, the number of VM migrations and the number of shutdown hosts. Conversely, only the amount of active PMs was minimized depending on their present resource demands whereas the future resource demands were omitted. So, the undesired VM migrations were created and the percentage of SLA Violations (SLAV) was improved in the cloud storage.
As a result, OH-BAC-FUP was developed for minimizing the number of VM migrations and improving the LB efficiency. In this mechanism (12) , the upcoming use of resources was also taken into account with the current use for transferring the VMs to the minimal number of operative PMs. For predicting the future use of resources such as CPU, bandwidth, storage size and memory of both VMs and PMs, LR and OPLR-based prediction algorithms were applied. After obtaining the predicted values, these were employed in the OH-BAC's fitness factor for selecting the suitable VM to migrate to the highly appropriate PM. But, the probability of the occurrence of network congestion was high while increasing the bandwidth utilization between VMs within the data center. Less than optimal positioning of VMs can lead inter-VM communication to connect bottleneck network paths which results in huge cross-network congestion. Primary node overprovisioning and unstable assignments in cloudlets can also contribute to long-lasting traffic. If there were a large number of congestions, the resource utilization performance may degrade significantly.
Many studies have considered VM migration with its impact on network traffic; however, the primary objective of minimizing the overall energy consumption in a data center. As data centers transmit a massive amount of traffic, system failures have severe impacts (13) . If resources are reserved with adequate backup bandwidth resources, then, 100% traffic prevention can be achieved. Due to the expense of reserving the backup resources, traffic can be prevented partially wherein traffic will obtain less bandwidth in the system failures. The partial prevention can guarantee service accessibility, but with less bandwidth and efficiency which could be acceptable for many applications. From this perspective, a prevention grade is considered as a measure of partial prevention in this paper for reducing traffic congestion in data centers. Therefore, this study introduces an OH-BAC-FUP-MTR mechanism to achieve effective LB and reducing the probability of congestion occurrence in cloudlets. In this mechanism, the traffic is routed on multiple link-disjoint routes for preventing the failures and ensuring the availability of a minimum of one route for the traffic upon a link failure or congestion. At first, the OH-BAC-FUP is executed for deciding the most appropriate VMs to be migrated to the most suitable PMs. If any congestion occurs during migrating VMs to the PMs, then the MTR algorithm is performed that partitions flows or traffic into 2 and forwards them via multiple link-disjoint routes so the traffic is reduced when guaranteeing the bandwidth and security grade demands. Also, the highest traffic on the path is used as a congestion factor. Moreover, the current and future network states are accounting for MTR to select the most optimal route from multiple routes with no consideration of the past use of the paths. As a result, this OH-BAC-FUP-MTR mechanism is more suitable for intelligently migrating VMs onto the PMs with reduced traffic load on the network.
The rest of the article is prepared as follows: Section 2 studies the researches related to the VM migration in cloud computing. Section 3 describes the functioning of OH-BAC-FUP-MTR and Section 4 portrays its performance. Section 5 summarizes this research work and suggests future scope.

Literature Survey
Vu and Hwang (14) proposed a flow and energy-aware method for VM localization in the cloud storage systems intending to reduce the communication cost and energy consumption. In this method, a novel algorithm was proposed for finding the target PM to host selected VMs. If VMs were consolidated on PMs with higher CPU use per energy consumption, the overall energy https://www.indjst.org/ consumption was reduced. Also, if two VMs running network-aware applications were hosted on a PM, the traffic cost for that connection was reduced. However, the number of VM migrations was very high. Reguri et al. (15) proposed a power-efficient flow-aware VM migration based on dynamic VM migration techniques. It was performed via clustering the VMs depending on the transmission or flow. But, the SLAV created by over-loaded hosts was not reduced and also it does not consider the memory factor in the VM migration model.
Deshpande & Keahey (16) proposed a flow-sensitive real-time VM migration algorithm by using a mixture of pre-copy and post-copy methods for transferring the co-situated VMs. The choice of migration algorithms was depending on VM's network traffic profiles. The network traffic on each host was monitored for generating the per-VM system flow summary. After that, each combination of pre-copy and post-copy was weighed and selected for all the VMs. But, the issue of migrating VMs from an identical origin host to an identical target host was not addressed.
Liu et al. (17) proposed an accurate Failure Detection based on Weibull distribution called WD-FD for preventing any congestion or failures in the cloud network. In WD-FD, a sliding window was considered for maintaining more fresh data to estimate the Weibull distribution factors. By using these data, the suspicion level was computed for matching the recent network condition. But, it needs to further reduce the mistake rate for improving the detection accuracy. Cui et al. (18) proposed a novel method for migrating VM via dynamically creating adaptive topologies depending on VM requirements. First, a flowaware VM migration dilemma was formulated. After that, a new progressive-decompose-rounding algorithm was proposed for periodic traffic to plan VM migration in a polynomial period with a verified estimate rate. Also, an Online Decision-Maker (ODM) strategy was proposed with a verified efficiency limits for highly dynamic flows. However, the computational complexity of this method was high and it does not improve resource utilization.
Fu et al. (19) proposed a layered VM migration scheme for reducing resource use and network congestion. Initially, the cloud data center was split into many regions using the inter-and intra-area VM migration algorithm. These were performed based on the ratio of bandwidth used by the hosts. After that, the resources of all areas were balanced by VM migrations. But, the number of VM migrations was not reduced efficiently and the cost of this algorithm was high since the VMs were migrated several times in intra-regions.
Vakilina (20) proposed a hybrid optimization of energy use of system, transmission and migration costs including traffic and system heterogeneity concerning the resource and bandwidth limits. The optimization problem was devised as an Integer Quadratic Program (IQP) using quadratic limits for small-scale systems. Also, this can be developed as an Integer Linear Programming (ILP) resolved by the column creation in large-scale systems. Also, network bandwidth constraints were considered for preventing traffic congestion. However, the computational complexity and runtime were high (Afzal & Kavitha) (21) . This algorithm IMDLB takes consideration of the proficiency-related entity Vms and complicity of each requested task to assign relevant virtual machines. This work consider as migration cost of quality of service Qos parameter and validates its efficiency by providing the most minimal optimized solution in term of migration cost.
Hejja & Hesselbach (22) presented a novel energy-aware resource allocation method that supports PM consolidations integrated with the VMs consolidation for reducing the data centers overall costs for an offline scenario. Also, this method was combined with an elective standalone traffic migration scheme which was triggered based on certain criteria. But, its efficiency was less since it does not consider LB and traffic predictions. Hsieh et al. (23) suggested the VM consolidation method which considers the current and future use of resources by the host overload and host under-load identification. The future use of resources was precisely identified by the gray-Markov-based scheme. But, it does not consider the traffic flow during migration to solve any conflicts. Afzal & Kavitha (24) developed a hybrid multiple parallel queuing methods for improving the Quality-of-Service (QoS) in cloud computing. But, it assumes the traffic arrival rate and service rate were constant.

Proposed Methodology
This part explains the OH-BAC-FUP-MTR mechanism in detail. Initially, the OH-BAC-FUP is performed to choose the highly appropriate VMs to be transferred to the highly appropriate PMs based on the current and future resource utilization demands. During migration, the MTR algorithm is applied if any congestion occurs due to high traffic. The overview processing and flow diagram of the OH-BAC-FUP-MTR mechanism are portrayed in Figures 1 and 2, respectively.
In Figure 1, the VM migration through switches is shown which reduces the probability of congestion in the network. The use of switches can regulate the traffic on a link during VM migration. If V M 1 in PM 1 needs to transmit a flow to V M 2 in PM 5 , the possible route between PM 1 and PM 5 is S 1 − S 2 − S 3 − S 4 with different traffic loads. It may split the traffic loads to avoid congestion based on the following processes: https://www.indjst.org/

Problem formation
Let a set of x PMs P = (p 1 , p 2 , . . . , p x } and a set of y VMs V = (v 1 , v 2 , . . . , v y } . A PM host p i has a specific amount of resources represented as where p c i is the CPU usage, p m i is the capacity of memory, p b i is the bandwidth and p ss i is the capacity of storage size. A VM flow is initiated at a VM and terminated at another VM. A task's resource demand is specified as a vector J = (r 1 , r 2 , . . . , r y } where r k is the amount of VMs of type v k . The resource necessity of v i is denoted where v c i is the necessary CPU usage, v m i is the necessary memory, v b i is the necessary bandwidth and v ss i is the necessary storage size. Consider that there is a mixture of traffic flows in a data center requiring a different amount of bandwidth. So, it is essential to consider different types of VMs. Though it is complex to compute an accurate bandwidth requirement of traffic between VMs, consider that occupiers encompass a better estimation of bandwidth demands according to the types of purposes and their efficiency demands.
https://www.indjst.org/ In this mechanism, the difficulty is to discover a mapping between VMs and PMs that fulfills the VM's resource necessities when aiming to reduce the overcrowding and offering prevention assurance of rank ϒ, i.e., the ratio of bandwidth assured to be accessible for traffic upon a path collapse.
The highest traffic on a path is used as a congestion factor. A cloud storage system is modeled by a directed graph G = (V, E) wherein v ∈ V is a system controller, PM or the outside user and (u, v) ∈ E is a substantial path connecting the controllers or/and the PMs. Every path (u, v) contain a nonnegative ability ct (u, v) ≥ 0. Each path transmits single or multiple traffics. On (u, v) ∈ E, bandwidth b i,u,v is reserved for flow i. For each task, the PMs are selected for supporting its substantial resource demands and a group of routes in G to forward flows between VMs.
Every route has a group of connections that intersect controllers and PMs. In this mechanism, MTR is considered in which the flow is mapped to multiple routes having a specific flow rate to reduce the overcrowding when offering a certain ϒ. When traffic requirement (i) including the bandwidth demand (b) are divided and transmitted across n link-disjoint routes at the ratio of b max (maximum bandwidth), the least ϒ is given by (b − b max ] / (b] that occurs if a connection on the route having b max is unsuccessful.
The goal is to reduce the highest flow on a path when offering ϒ as a minimum of Γ for every requirement. The fitness factor and the restraints associated with VM migration and MTR are as follows: Restraints: • The overall bandwidth or traffic used on (u, v) is computed as the total of traffic i passing through the path.
• Ability restraints: The overall resource demand of the VMs situated on the host must not surpass its ability. For PM j, the total of the resource demands of each VM situated on it must be lower than or similar to the host's overall accessible ability.
• Migration restraint: Each VM is migrated to one PM and all VMs are migrated.
• Bandwidth restraint: The total bandwidth utilized on (u, v) must not surpass its ct (u, v).
https://www.indjst.org/ • No failure restraint: For each controller u which is not the origin controller s i or the target controller t i of i, the received bandwidth should be similar to the transmitted bandwidth.
• Traffic partitioning restraint: Traffic i is partitioned into n having bandwidth b to be migrated onto multiple routes.
• Traffic routing on link-disjoint routes: (u, v) is passed through by no one or only one of the n routes of i. Also, it guarantees that n routes utilize disjoint groups of paths.
• Traffic partitioning at the origin: The overall flow ratio of s i is similar to b.
• Traffic combining at the target controller: The overall flow ratio of t i is similar to b.
• Prevention restraint: The rate of bandwidth accessible for i upon a path collapse is not less than ϒ.

Multipath traffic routing
In this step, routes and their flow rates are computed. The accessibility of multiple routes between origin VM s j and target VM t j is leveraged to share the flow across the routes and partly prevent the flow from a particular path collapse. For all couples of interacting VMs, multiple link-disjoint minimum-congested routes are determined. The minimum-congested route is the route having the minimum traffic. The route traffic is referred to as the highest traffic on a connection passed through the route. The traffic is partitioned only at the edge and it pursues the pre-assigned routes with no necessity of additional partitioning.

Design of Routing and Route Load
Two different cases of routing are considered for selecting routes for a flow such as intra-and inter-pod routing. Intra-pod routing occurs while a couple of interacting hosts is inside a similar pod whereas inter-pod routing occurs while the hosts are in dissimilar pods.
For instance, assume the scenario of intra-pod routing as illustrated in Figure 3 in which the components which are not involved in the transmission route are neglected and the connections are noticeable including the present flow rate. If VM 1 requests to transmit traffic to VM 2 , both are inside a similar pod. Figure 3(a) depicts 2 promising link-disjoint routes between PM 1 and PM 2 . When the route S 1 -S 2 -S 4 contains a flow rate of 12, the route S 1 -S 3 -S 4 contains a flow rate of 17.
https://www.indjst.org/ Inter-pod routing explores routes between dissimilar pods. For instance, assume a scenario of inter-pod routing as illustrated in Figure 3(b). In pod 1, VM 1 is included which requests to transmit traffic to VM 2 in pod 4. In this case, 2 promising routes are available between PM 1 and PM 2 : S 1 -S 2 -S 4 -S 8 -S 10 and S 1 -S 3 -S 6 -S 9 -S 10 containing the flow rate of 12 and 17, accordingly .   Fig 3(b). Example for inter-pod routing scenario https://www.indjst.org/ Traffic portioning policy Assume the congestion and prevention constraint for selecting the traffic partitioning rate. Also, γ is used as a measure of the ratio of bandwidth assured to be accessible for the traffic on a path collapse. The highest γ is 0.5, while the flow is partitioned uniformly. If there is no traffic/flow partitioning, then γ is 0. Through this, it is observed that reducing the overcrowding is not essential leading to the highest γ.
The effect of partitioning on congestion and γ is shown in Figure 4. The routes R 1 , R 2 and R 3 having different traffics are illustrated in Figure 4(a). If traffic having a flow ratio of 200 units requests to be transmitted. Assume 3 scenarios of partitioning such as 50:50, 60:40 and 55:45. While the flow is partitioned in the fraction of 50:50, the congestion is 120 with γ of 0.5 as illustrated in Figure 4(b).  Figure 4(d). If the aim is to maximize γ without reporting congestion, then the flow is partitioned into 50:50.
If the goal is to reduce the congestion without reporting γ, then the flow is partitioned into 60:40. If the aim is to reduce the congestion related to a specific constraint, e.g., at least 45% γ, then the flow is partitioned into 55:45. If the minimum γ required is 30%. Partitioning the flow 30:70 results in traffic of 140 and 50 on P 2 and P 3 , accordingly with the congestion being 140. Here, partitioning flow 40:60 as in scenario 2 will result in congestion of 110 only. Initiate with partitioning the flow in the fraction γ : (200 − γ) and the resulting congestion is computed. After that, the congestion for various ranges of γ is computed until γ = 50 and the partitioning ratio has been selected that results in less congestion.
where x and w are the number of PMs and switches (S) in the system.

Simulation Results
This section simulates the OH-BAC-FUP-MTR mechanism and compares its efficiency with the OH-BAC-FUP by LR and OPLR mechanisms. The analysis is carried out based on energy consumption, the number of VM migrations and the number of SLAV, SLATAH, PDM and the number of host's shutdowns. In this experiment, both mechanisms are implemented by using CloudSim API 3.0.3. Table 1 shows the simulation environment and the parameters used in OH-BAC-FUP.

Energy consumption
It is the overall energy consumption by PMs at a given period.
In Eq. (13), k is the % of idle PM's energy consumption, P f ull is the energy consumption of PM at full load and u i is the CPU usage of the PM. From this analysis, it is observed that the OH-BAC-FUP-MTR minimizes energy consumption than the OH-BAC-FUP during VM migration. For example, energy consumption by PMs during 500 tasks for OH-BAC-FUP-MTR is 6.75% less than the OH-BAC-FUP-LR and 2.56% less than the OH-BAC-FUP-OPLR mechanisms.

SLATAH
It refers to the proportion of time in which the operative host uses 100% CPU.
In Eq. (14), n denotes the number of PMs, T s j is the period in which j th PM uses 100% CPU and T as j is the total number of j th PM that is in the active state. Figure 6 shows the SLATAH (in %) for OH-BAC-FUP-MTR and OH-BAC-FUP mechanisms under the different number of tasks. This scrutiny notices that the OH-BAC-FUP-MTR attains the least SLATAH than the OH-BAC-FUP. For example, the SLATAH of OH-BAC-FUP-MTR for 500 tasks is 6.15% less than the OH-BAC-FUP-LR and 3.17% less than the OH-BAC-FUP-OPLR mechanisms.

PDM
It is the overall performance degradation due to VM migrations and computed as: In Eq. (15)

SLAV
It is considered for evaluating the SLA delivered by a VM in the IaaS cloud.

Number of VM migrations
It is the number of migrations created in the remapping phase. Figure 9 shows the number of VM migrations for OH-BAC-FUP-MTR and OH-BAC-FUP mechanisms under the varying number of tasks. This scrutiny indicates that the OH-BAC-FUP-MTR attains less number of VM migrations compared to the OH-BAC-FUP. For example, the number of VM migration for OH-BAC-FUP-MTR during 500 tasks is 2 whereas OH-BAC-FUP-LR and OH-BAC-FUP-OPLR mechanisms have 4 and 3 VM migrations, respectively.

Number of host's shutdowns
It decides which hosts are operating, then shutdown. The host is shutdown after VM migration. If all VMs in a certain host is moved, then the host is shut down to reduce energy use. But, the host is becoming operative when a VM has moved to it again.

Conclusion and future work
This study presents an OH-BAC-FUP-MTR mechanism for enhancing the performance of LB and reducing the chance of congestion occurrence in the cloud data centers. At first, an OH-BAC-FUP is applied to select the most suitable VMs to be migrated to the most appropriate PMs. During migration, if any congestion occurs because of using high bandwidth or traffic flows, then the MTR algorithm is performed to partition the flows and route them via multiple link-disjoint routes. By partitioning the traffic flows, the congestion is prevented when guaranteeing the bandwidth and security demands. As well, the highest traffic on a path is applied as a congestion factor. Moreover, the current and future network states are taken into account for MTR to select the most optimal route from multiple routes with no consideration of the past use of the paths. Finally, the simulation outcomes exhibited that the OH-BAC-FUP-MTR enhances the efficacy of VM migration than the OH-BAC-FUP. Scope of the OH-BAC-MTR enhances the performance of VM migration, the trade-off between load fairness and energy-saving in heterogeneous cloud computing was not effective. So, the future extension of this work could be focused on introducing workload-aware VM consolidation to measure the trade-off between load fairness and energy-saving in heterogeneous cloud scenarios.