Queuing Model with Customer Class Movement across Server Groups for Analyzing Virtual Machine Migration in Cloud Computing

Abstract

The advancement of cloud computing technologies has positioned virtual machine (VM) migration as a critical area of research, essential for optimizing resource management, bolstering fault tolerance, and ensuring uninterrupted service delivery. This paper offers an exhaustive analysis of VM migration processes within cloud infrastructures, examining various migration types, server load assessment methods, VM selection strategies, ideal migration timing, and target server determination criteria. We introduce a queuing theory-based model to scrutinize VM migration dynamics between servers in a cloud environment. By reinterpreting resource-centric migration mechanisms into a task-processing paradigm, we accommodate the stochastic nature of resource demands, characterized by random task arrivals and variable processing times. The model is specifically tailored to scenarios with two servers and three VMs. Through numerical examples, we elucidate several performance metrics: task blocking probability, average tasks processed by VMs, and average tasks managed by servers. Additionally, we examine the influence of task arrival rates and average task duration on these performance measures.

1. Introduction

Cloud computing is a crucial element of modern infrastructure, providing accessible computing resources and power. It encompasses various service models, including on-site cloud services where owners are responsible for setting up all processes from the networking level to the application stack. Infrastructure-as-a-service (IaaS) allows for the use of actual computing resources through system-level virtualization. This model grants users control over the virtual cloud infrastructure, including virtual processors, memory (RAM), network, and storage. It allows them to manage both infrastructure and software, along with additional tools. Platform-as-a-service (PaaS) addresses the operating system, middleware, and runtime, eliminating the need for users to manage these components and allowing them to focus on managing their data and applications. Software-as-a-service (SaaS) offers fully managed cloud-based applications by service providers.

Virtual machines (VMs) emulate physical computers and can vary in power and resources, aiding in efficient resource management in cloud services. However, the dynamic nature of the cloud environment presents challenges such as load balancing and hardware maintenance. A critical issue in this regard is VM placement, which is particularly significant in data centers. It involves VM migration strategies for better energy consumption, resource allocation, load balancing, and reduced ecological impact. VM migration addresses challenges such as uneven computing power distribution, quality of service (QoS) requirements, server load, resource exhaustion, and underutilization.

The VM migration across servers in a cloud computing system is a critical aspect of managing modern cloud infrastructure. This topic has been addressed in many recent research papers. For a review of these works, please refer to Section 2. This paper focuses on a queuing model for analyzing VM migration across servers in a cloud computing system. Building upon the VM migration mechanism outlined in [1], we adapt the resource utilization approach for migration to a task processing perspective. This allows us also to consider the stochastic nature of resource utilization in the form of random arrivals of tasks and random duration for task processing.

The main contributions of our study are as follows:

• We present a comprehensive review of the nuances involved in VM migration across servers within cloud computing infrastructures. This includes an exploration of diverse VM migration types, methodologies for determining server load states, strategies for selecting VMs for migration, optimal timing for VM transfers, and criteria for choosing the target server. A synopsis of recent papers on VM migration is also provided.
• We formalize a model for VM migration that encompasses both resource utilization and task processing aspects. We introduce a queuing model for the task processing scenario, addressing the stochastic nature of task arrivals at VMs. This model applies to configurations involving two servers and three VMs.
• Through numerical analysis, we quantify several performance indicators: the probability of blocking a task, the average number of tasks processed by VMs, and the average number of tasks handled by servers. The effects of task arrival rates and the average task duration on these indicators were scrutinized.

The rest of the paper is organized as follows. Section 2 provides an overview of related work in the field of VM migration. Section 3 details the model formalization in terms of resource utilization based on [1]. Section 4 presents the queuing model in terms of task processing and some metrics of interest. In Section 5, we present illustrative numerical results for these metrics, analyzing the impact of the arrival rate of tasks on servers and their average duration. The conclusions are drawn in the final Section 6.

2. Virtual Machine Migration in Cloud Computing

In this section, we review the various aspects of VM migration, including types of migration such as live and offline, definitions of overloaded and underloaded servers, and the selection process for migrating a VM. The importance of choosing the appropriate moment and server for successful migration is also discussed, along with a brief overview of recent research in this area.

2.1. Types of VM Migration

VM migration is the process of transferring a VM from one server to another [2]. This involves moving the VM’s memory, disk storage, and network connections. There are two primary types of migration: static and dynamic. Static migration relies on prior knowledge of workload patterns and entails solving the VM placement problem for all VMs and available hosts. Conversely, dynamic migration permits the relocation of VMs after their initial allocation. This process necessitates continuous monitoring to detect resource contention and potential service disruption. Dynamic migration is facilitated by dynamic resource allocation, a sophisticated approach capable of managing unpredictable workloads [3]. Dynamic migration can be subdivided into periodic and real-time migration. Periodic migration can be scheduled manually or triggered by system state changes, such as the addition or removal of a server [4].

Furthermore, VM migration can be categorized as either offline or online (live) [5]. Offline migration requires halting or shutting down the VM before transfer to another host, potentially causing service interruptions and adversely affecting user experience and service level agreements (SLAs) [6]. In contrast, live migration allows the VM to remain operational during transfer, preserving access to its RAM, storage, and network states. Live migration strives to minimize downtime and total migration time while ensuring QoS and service availability [7]. Depending on the sequence in which memory pages are transferred from the source to the destination host, live migration can be further classified as pre-copy or post-copy [8].

Live migration offers various advantages over offline migration. One notable benefit is the ability to rapidly scale data centers without disrupting the quality of service (QoS) [9]. Pre-copy live migration is generally faster than post-copy because it continuously transfers memory pages from the source machine without interruption [10]. Alternatively, post-copy migration initially sends only a minimal set of memory pages and transfers additional pages upon request from the destination server [11].

Pre-copy live migration consists of six distinct phases as delineated in [12]. The first phase involves selecting a VM for migration and choosing a new host for it. The second phase, reservation, requires confirmation from the target host that it can accommodate the migration. In the third phase, iterative pre-copy, the entire RAM of the VM is copied to the new host. The fourth phase, stop-and-copy, entails shutting down the original VM and migrating its central processing unit (CPU) state. During the fifth phase, commitment, the new host confirms successful migration and checks for any tampering. The final phase, activation, takes place if there is no tampering detected, allowing full activation of the VM on the new host. Following this, the source VM is decommissioned from the old server.

The post-copy approach follows similar steps to pre-copy but differs in the RAM transfer phase. Instead, post-copy involves handling page faults at the end of the migration process. If a page fault is identified by the source machine during this step, the migration process is paused to address the issue [11].

2.2. Overloaded and Underloaded Servers

VM migration encompasses two tasks: firstly, determining the optimal placement for a new VM within the data center, and secondly, optimizing the current allocation of VMs. This emphasizes that VM migration comprises two critical components: (i) identifying overloaded and underloaded servers in the data center, and (ii) selecting VMs for migration. Thus, the process of migrating VMs across servers is intricately linked to the servers’ state in the data center [1,13]. It is advisable to initiate migration when there are any overloaded or underloaded servers. Overloaded servers lead to higher energy consumption rates, while underloaded servers result in inefficiencies in data center utilization and energy wastage [14].

The definition of overloaded and underloaded servers typically relies on predefined workload value thresholds. These thresholds can be set statically or dynamically, with both methods being prevalent. In static threshold algorithms, the threshold values are constant throughout the migration process [15]. Reactive controllers detect any excess resource usage on a server based on these threshold values [3]. If system resource utilization surpasses the set threshold, the server is considered overutilized, triggering a migration algorithm.

Conversely, dynamic threshold algorithms adjust threshold values over time according to the overall workload [16]. Here, a server is deemed overloaded if its resource usage (e.g., CPU, RAM, network bandwidth) reaches its capacity and exceeds the upper threshold value [1,13,17]. Hosting an overloaded server can degrade QoS for applications running on it. An underloaded server, by contrast, falls below the lower threshold, indicating suboptimal utilization.

2.3. Selection of VM for Migration

To effectively manage dynamic VM migration, it is essential to identify instances of utilization imbalance for both current and future periods. This involves prioritizing servers with excessive utilization for VM offloading while considering alternative policies for underloaded servers. VM migration is triggered when a server’s state threatens resource degradation, potentially leading to service disruption. For example, an overloaded server can cause resource contention and affect service performance. In contrast, an underloaded server may lead to inefficient resource use but it poses minimal risk to service continuity. Hence, overutilization is the primary impetus for initiating rebalancing procedures [1,13].

Beyond resource utilization thresholds, other factors must be considered when selecting a VM for migration from a server. The migration time increases linearly with the VM’s RAM size, making smaller RAM sizes preferable [1]. CPU utilization can also serve as a criterion for VM selection, with lower utilization rates being more desirable [18]. This method, known as the highest potential growth policy, enables server utilization to rise without accruing future migration overhead [10,19].

A dynamic VM consolidation strategy includes information from users of services hosted in the data center. As shown in [6], incorporating user-provided information such as the release time—indicating when a VM is no longer required for its services—improves data center energy efficiency. This demonstrates the advantages of using user information in consolidation algorithms.

2.4. Timing for VM Migration

Load balancing of VMs across servers can be triggered by various factors [20]. One such factor is the violation of the system’s state, such as overutilization or underutilization of a server. Another trigger is the placement of a new VM. The process of initiating load balancing algorithms can be sender- or receiver-initiated [20]. These algorithms are based on definitions of overloaded and underloaded servers [21]. Sender-initiated algorithms transfer the load from overloaded servers to underloaded ones, whereas receiver-initiated algorithms distribute the load from all underloaded servers to reduce the overall number of active servers. However, the receiver-initiated method may cause overhead for the servers accepting the load from underloaded servers.

Load balancing methods can also be classified into static and dynamic types [20,22,23]. Static load balancing methods, initiated by the system’s state, can be implemented with round-robin (RR) or weighted round-robin (WRR) algorithms. These algorithms are triggered according to a schedule. In RR, VMs are distributed across servers based on their order of appearance in the system. WRR considers the characteristics of VMs during the distribution process by assigning weights to each VM. However, this method can be more time-consuming than simple RR. Opportunistic load balancing, a branch stemming from static load balancing methods [24], does not consider the current workload of the node and assigns VMs to all available servers in a free order. Other types include min–max and max–min algorithms, based on the completion time of tasks.

Dynamic load balancing requires continuous monitoring of the infrastructure and can be implemented with random sampling and throttled methods. During random sampling, the mapping between requests and resources occurs randomly, while the throttled method assigns resources based on their current load by using load metrics to assign VMs to servers according to their indexes [25]. In contrast, the least-connections method selects a server with the fewest number of VMs and plans a new migration to that server [26].

The most commonly used type of migration is pre-copy live migration, where the VM state is migrated while the original VM is still running [2]. However, in cases where modified memory pages are encountered, the changes are not immediately reflected and must be copied again later [12]. If there is a significant number of changes and the process of transferring modified pages exceeds a certain number of attempts, these pages will be skipped [27]. Consequently, the migration time becomes unpredictable and may even fail if there are a high number of frequently written pages on the VM [28].

Stop-and-copy is a hybrid approach where the VM is briefly suspended, and only specific memory pages, such as those frequently accessed by the VM, are transferred [12]. This approach helps reduce downtime by limiting the number of transfers. On the other hand, post-copy live migration initially transfers only the data necessary for the VM to start at the destination. The remaining memory pages are then sent in one step after the VM has started. While this approach allows for predictable migration times, it also has drawbacks such as longer migration times and a higher likelihood of network transfer errors.

2.5. Selection of Destination Server for VM Migration

The selection of the most appropriate server for a given VM is a crucial step in optimizing data center performance. This decision depends on the desired objective function, which may vary according to the optimization problem at hand. A primary objective in data center optimization is to reduce the total number of active servers and minimize energy consumption [29]. In some instances, the focus might be solely on minimizing energy consumption, with the chosen server having the lowest energy usage in the data center [30].

Heuristic algorithms are frequently used to find feasible solutions for the NP-hard VM placement problem. Many of these algorithms are based on bio-inspired, population-based meta-heuristics [31,32]. For instance, particle swarm optimization uses four key components—initial position, velocity, weight, and fitness function—to determine its effectiveness. Other approaches may aim to minimize migration time and cost, and optimize global QoS [33], or focus on resource allocation and server consolidation within the data center [15].

The threshold-free method is an alternative for determining server status. This approach eschews static threshold values and instead identifies heavily loaded servers based on current usage metrics, such as CPU and RAM parameters. Migration occurs only if predicted values exceed the threshold at both present and future times. A key advantage of threshold-free algorithms is their time efficiency [6]. However, some algorithms may also consider not only the improvement of server utilization but also its performance degradation rates post-migration [4], thereby maintaining QoS for users while optimizing resource utilization.

AI-based methods can control system performance by managing resource usage rates [34]. Another strategy involves using linear regression to predict future CPU consumption on the server and make preemptive migration decisions to avoid SLA violations [35]. These methods are highly accurate as they utilize various AI techniques or combinations thereof. Nonetheless, they may have drawbacks such as high costs and extensive computing power requirements. The Markov decision process, optimized with reinforcement learning (RL), is another technique applied in this context [36]. Additionally, deep learning can be combined with RL to explore data characteristics and learn scheduling strategies, or it can be applied directly to the VM placement problem [37]. Markov chains have also been used for this purpose [18].

2.6. Service Rate Degradation in VM Migration

In the era of cloud computing, the dynamic nature of VM migration between servers plays a crucial role in effectively managing workloads. As the number of VMs operating within a cloud increases, the contention for shared resources, such as CPU cores or memory, can lead to a degradation in the service rates of individual tasks or processes. The paper [38] aims to derive an approximation for the stationary probability distribution of the number of customers in the phases using the asymptotic analysis method under the condition of increasing service time. Subsequently, [39] provided a mathematical model and analytical framework for understanding the impact of service rate degradation in cloud nodes, with a specific focus on queuing systems with two phases of service.

Effectively managing VM migration is critical to ensuring high-speed service in server environments. By implementing intelligent resource allocation, proactive resource reservation, data pre-fetching, migration throttling, and efficient migration decision-making, one can optimize VM migration processes and improve service speed.

2.7. Summary of Recent Selected Works on VM Migration

In this overview, we consolidate findings from selected papers investigating diverse migration techniques designed to address server overload. The summarized works are presented in Table 1, focusing predominantly on virtual machine (VM) migration strategies. The primary emphasis of these strategies is the minimization of CPU utilization, particularly relevant in the context of overloaded servers characterized by elevated CPU usage.

The migration process involves transferring Virtual Machines (VMs) from overloaded servers to those with lower resource utilization. This methodology aims to achieve a reduction in energy consumption within data centers. Numerous studies employ the criterion of high power consumption to define an overloaded server [32,40,41]. The research primarily underscores the imperative of optimizing energy consumption in environments housing multiple servers that operate continuously, resulting in substantial energy consumption. Furthermore, a substantial portion of researchers characterizes overloaded servers based on elevated CPU utilization [42,43], overall resource consumption at the individual server level [44], and across an entire cluster [45].

Table 1. Summary of recent selected works on virtual machine migration.

Ref.	Overloaded Server	Selection of VM for Migration	Selection of Destination Server for VM Migration	General Objective Function
[32]	Server with high power consumption	VM placement based on resource utilization and fault probability	Server, such that total power consumption with newly migrated VMs does not exceed the threshold	Glowworm swarm optimization
[40]	Server with high power consumption	VM less suited to server’s capacity	Server with low resource usage efficiency	Optimization of resource usage and minimization of resource wastage
[42]	Server with high CPU utilization	VM with the lowest allocated RAM	Server offering minimal energy consumption and migration time	Minimization of VM migrations and energy consumption
[43]	Server with high CPU utilization	VM with the lowest CPU utilization	Server meeting VM resource requirements and optimizing energy consumption	Minimization of energy consumption and number of VM migrations
[44]	Server with high CPU, RAM, and bandwidth utilization	VM selected based on utilization and lowest migration delay	Server with the highest available capacity and lowest power consumption	Load balancing across servers, minimization of power consumption, maximization of system performance
[46]	Server with CPU utilization higher than the average absolute deviation of other CPU values	VM with the smallest RAM and lowest migration delay	Under-utilized server with CPU utilization below median absolute deviation of past CPU values	Minimization of total energy consumption, number of VM migrations, percentage of SLA violations
[47]	Overloaded server determined by a greedy algorithm	VM with the lowest migration delay and cost	Target server determined by a greedy algorithm	Minimization of average VM migration delay
[48]	Server with high CPU utilization based on historical data	VM with the highest traffic	Server with most remaining resources	Minimization of energy consumption and maximization of QoS
[45]	Cluster of servers with high CPU utilization	VM with high-energy consumption and SLA violations	Cluster with low CPU utilization	Minimization of VM migrations and energy consumption
[41]	Server with high power consumption	VM with high migration costs selected	Server with minimal power increase post-migration	Optimization of consolidation score of metrics
[49]	Server with the most imbalanced power consumption	VM with the highest power consumption	A server that will not become over-utilized post-migration	Minimization of energy consumption
Our paper	Server exceeding the task threshold upon a new task acceptance	VM responsible for server overload	Another server or without migration	Minimization of number of tasks

Table 1. Summary of recent selected works on virtual machine migration.

Ref.	Overloaded Server	Selection of VM for Migration	Selection of Destination Server for VM Migration	General Objective Function
[32]	Server with high power consumption	VM placement based on resource utilization and fault probability	Server, such that total power consumption with newly migrated VMs does not exceed the threshold	Glowworm swarm optimization
[40]	Server with high power consumption	VM less suited to server’s capacity	Server with low resource usage efficiency	Optimization of resource usage and minimization of resource wastage
[42]	Server with high CPU utilization	VM with the lowest allocated RAM	Server offering minimal energy consumption and migration time	Minimization of VM migrations and energy consumption
[43]	Server with high CPU utilization	VM with the lowest CPU utilization	Server meeting VM resource requirements and optimizing energy consumption	Minimization of energy consumption and number of VM migrations
[44]	Server with high CPU, RAM, and bandwidth utilization	VM selected based on utilization and lowest migration delay	Server with the highest available capacity and lowest power consumption	Load balancing across servers, minimization of power consumption, maximization of system performance
[46]	Server with CPU utilization higher than the average absolute deviation of other CPU values	VM with the smallest RAM and lowest migration delay	Under-utilized server with CPU utilization below median absolute deviation of past CPU values	Minimization of total energy consumption, number of VM migrations, percentage of SLA violations
[47]	Overloaded server determined by a greedy algorithm	VM with the lowest migration delay and cost	Target server determined by a greedy algorithm	Minimization of average VM migration delay
[48]	Server with high CPU utilization based on historical data	VM with the highest traffic	Server with most remaining resources	Minimization of energy consumption and maximization of QoS
[45]	Cluster of servers with high CPU utilization	VM with high-energy consumption and SLA violations	Cluster with low CPU utilization	Minimization of VM migrations and energy consumption
[41]	Server with high power consumption	VM with high migration costs selected	Server with minimal power increase post-migration	Optimization of consolidation score of metrics
[49]	Server with the most imbalanced power consumption	VM with the highest power consumption	A server that will not become over-utilized post-migration	Minimization of energy consumption
Our paper	Server exceeding the task threshold upon a new task acceptance	VM responsible for server overload	Another server or without migration	Minimization of number of tasks

The majority of the summarized papers outlined in Table 1 predominantly focus on identifying overloaded servers through high resource and energy utilization, primarily relying on large-scale data processing of consumption rates. In contrast, we propose an approach that emphasizes queuing theory and the advantages it offers to decision-making processes. It enables us to capture and model the stochastic nature of requests, considering the unpredictability of user interactions and system demands. This nuanced perspective enhances our decision-making framework, allowing for a server management strategy that accommodates the dynamic and unpredictable patterns inherent in real-world usage scenarios.

3. Model Formalization in Terms of Resource Utilization

In this section, we present the model formalization with respect to resource utilization. We describe the criteria for identifying overloaded servers and discuss the selection process for servers targeted for future VM migration.

3.1. General Assumptions

Consider a cloud computing system that delivers IT infrastructure via a range of computing resources. There are $\mathcal{S}=\{1,\dots ,S\}$ servers on which $\mathcal{V}=\{1,\dots ,V\}$ VMs are running, utilizing $\mathcal{R}=\{1,\dots ,R\}$ resources. Each s-server maintains a minimum volume $C_{rs}^0$ of an r-resource when no VMs are running. The threshold for the maximum volume of the r-resource that can be occupied by the s-server is denoted by $C_{rs}^{\max }$.

Let ${\mathcal{V}}_s\left(t\right)\subset \mathcal{V}$ represent the set of VMs running on the s-server at time t, and let $b_{rv}\left(t\right)$ denote the volume of the r-resource occupied by v-VM at time t. The total volume of the r-resource occupied by all VMs on the s-server at time t is given by

$$c_{rs}\left(t\right)=\sum _{v\in {\mathcal{V}}_s\left(t\right)}{b}_{rv}\left(t\right),r\in \mathcal{R},s\in \mathcal{S},$$

and the utilization of the r-resource on the s-server at time t can be defined as

$$u_{rs}\left(t\right)=\frac{C_{rs}^0+c_{rs}\left(t\right)}{C_{rs}^{\max }},r\in \mathcal{R},s\in \mathcal{S}.$$

These parameters, along with others for model formalization in terms of resource utilization and queuing model parameters regarding task processing, are summarized in

Table 2. Main notation.

Parameter	Description
Model parameters in terms of resource utilization
$\mathcal{S}=\{1,\dots ,S\}$	Set of servers
${\mathcal{S}}^{★}\left(t\right)$	Set of overloaded servers at time t
$\mathcal{V}=\{1,\dots ,V\}$	Set of VMs running on $\mathcal{S}$ servers
${\mathcal{V}}_s\left(t\right)\subset \mathcal{V}$	Set of VMs running on the s-server at time t
$\mathcal{R}=\{1,\dots ,R\}$	Set of resources that VMs and servers occupy
$C_{rs}^0$	Minimum volume of the r-resource occupied by the s-server without any running VMs
$C_{rs}^{\max }$	Threshold for the maximum volume of the r-resource that can be occupied by the s-server
$b_{rv}\left(t\right)$	Volume of the r-resource occupied by v-VM running at time t
$c_{rs}\left(t\right)$	Total volume of the r-resource occupied by all VMs running on the s-server at time t
$u_{rs}\left(t\right)$	Utilization of the r-resource on the s-server at time t
$U_r^{\max }$	Threshold for the maximum utilization of the r-resource
$r_s^{★}\left(t\right)$	Resource with the maximum utilization on the s-server with maximum utilization at time t
Queuing model parameters in terms of task processing
S	Number of servers
V	Number of VMs running on S servers
${\lambda }_v$	Arrival rate of tasks to be processed by v-VM, 1/s
${\mu }_v^{-1}$	Average processing time for a task by v-VM, s
$M_s$	Threshold for the maximum number of tasks that can be processed simultaneously by all VMs running on the s-server
Continuous-Time Markov Chain (CTMC) parameters
$n_v$	Number of tasks being processed by v-VM
$s_v$	Server on which v-VM is running
$\mathbf{n}=(n_1,\dots ,n_V)$	Number of tasks being processed by all VMs
$\mathbf{s}=(s_1,\dots ,s_V)$	Server assignment for each VM
$\mathbf{x}=(\mathbf{n},\mathbf{s})$	State of the system
$m_s\left(\mathbf{x}\right)$	Number of tasks being processed by all VMs running on the s-server in state $\mathbf{x}$
$\mathcal{X}$	Set of states
$\mathit{\pi }$	Stationary probability distribution

.

3.2. Modeling the Overloaded Server

The main challenge for cloud service providers is maintaining the QoS levels defined by the SLA. Typically, servers in a data center fall into two categories of edge cases: underloaded and overloaded. Overloaded servers pose the most significant threat to the stability of services running in the data center. Overutilization of available resources can result in the immediate failure of the running services. Therefore, detecting host overutilization is necessary. However, this problem remains challenging in a dynamic consolidation environment.

We consider the s-server to be overloaded at time t if the following inequality holds for all resources $r\in \mathcal{R}$:

$$u_{rs}\left(t\right)>U_r^{\max }\forall r\in \mathcal{R}.$$

Then, the server is considered overloaded at future times $t+1,\dots ,t+n$ if for all $i=1,\dots ,n$ and for all resources, the following inequality occurs:

$$u_{rs}(t+i)>U_r^{\max }\forall r\in \mathcal{R},\forall i=1,\cdots ,n.$$

Consequently, the set of overloaded servers is defined as follows:

$${\mathcal{S}}^{★}\left(t\right)=\left\{s\in \mathcal{S}:u_{rs}(t+i)>U_r^{\max },r\in \mathcal{R},i=1,\dots ,n\right\}.$$

3.3. Criteria for Server Selection in VM Migration

The procedure for unloading a server is performed iteratively according to two main migration principles. Firstly, the most utilized resource should be prioritized. Secondly, the VM selection policy should aim to minimize the impact of the migrated VM on the “new” server. Thus, the resource with the highest utilization level is defined by the following equation:

$$r_s^{★}\left(t\right)=\underset{r\in \mathcal{R}}{argmax}{u}_{rs}\left(t\right),s\in {\mathcal{S}}^{★}\left(t\right).$$

Then, we calculate the squared deviation of its resource usage coefficient from the recommended threshold $U_{r_s^{★}\left(t\right)}^{\max }$:

$$W_s\left(t\right)=W\left({\mathcal{V}}_s\left(t\right)\right)={\left(u_{r_s^{★}\left(t\right),s}\left(t\right)-U_{r_s^{★}\left(t\right)}^{\max }\right)}^2,s\in {\mathcal{S}}^{★}\left(t\right).$$

Finally, the selected VM should satisfy the following equation:

$$v_s^{★}\left(t\right)=\underset{v\in {\mathcal{V}}_s\left(t\right)}{argmax}\frac{W({\mathcal{V}}_s\left(t\right)\setminus \left\{v\right\})}{m_v\left(t\right)},s\in {\mathcal{S}}^{★}\left(t\right),$$

where $m_v\left(t\right)$ is the memory occupied by v-VM at time t.

The “new” server for the selected VM must not be overloaded at time t, and it must not become overloaded after the migration procedure. Therefore, any of the following servers would satisfy the aforementioned requirements:

$$u_{rs}\left(t\right)+\frac{b_{r,v_s^{★}\left(t\right)}\left(t\right)}{C_{rs}^{\max }}\le U_r^{\max }\forall r\in \mathcal{R},s\notin {\mathcal{S}}^{★}\left(t\right).$$

4. Queuing Model in Terms of Task Processing

In this section, we present the queuing model in terms of task processing that represents features of the VM migration procedure described in the previous section.

4.1. General Assumptions

We shift our focus from resource occupation and utilization on servers to the number of tasks being processed by servers. We assume that tasks from users arrive according to a Poisson process with parameter ${\lambda }_v$ to be processed by a v-VM. The processing time for a task follows an exponential distribution with an average of ${\mu }_v^{-1}$. We consider only one type of resource, denoted as $R=1$. In

Table 3. Model parameters in terms of resource utilization vs. queuing model parameters in terms of task processing.

Resource Utilization		Task Processing
Parameter	Description	Parameter	Description
S	Number of servers	S	Number of servers
V	Number of VMs running on S servers	V	Number of VMs running on S servers
R	Number of resources that VMs and servers occupy	$R=1$	Only one type of resource is considered
$C_{rs}^0$	Minimum volume of the r-resource occupied by the s-server without any running VMs	–	Not considered
$C_{rs}^{\max }$	Threshold for the maximum volume of the r-resource that can be occupied by the s-server	$M_s$	Threshold for the maximum number of tasks that can be processed simultaneously by all VMs running on the s-server
$b_{rv}\left(t\right)$	Volume of the r-resource occupied by v-VM running at time t	$n_v$	Number of tasks being processed by v-VM
$c_{rs}\left(t\right)$	Total volume of the r-resource occupied by all VMs running on the s-server at time t	$m_s\left(\mathbf{x}\right)$	Number of tasks being processed by all VMs running on the s-server in state $\mathbf{x}$
$u_{rs}\left(t\right)>U_r^{\max }$	Overloaded s-server	$m_s\left(\mathbf{x}\right)>M_s$	Overloaded s-server

, we present the mapping between the parameters used in the two models, some of which will be described in the subsequent subsection. Figure 1 illustrates a schematic of the corresponding queuing system.

4.2. Continuous-Time Markov Chain

We describe the system dynamics using a continuous-time Markov chain (CTMC) $\mathbf{X}\left(t\right)$ with states $\mathbf{x}=(n_1,\dots ,n_k,s_1,\dots ,s_v)$, where $\mathbf{n}=(n_1,\dots ,n_V)$ represents the number of tasks being processed by all VMs, and $\mathbf{s}=(s_1,\dots ,s_V)$ indicates the server assignment for each VM. The set of CTMC states is defined as follows:

$$\begin{array}{cc}\hfill \mathcal{X}=\{\mathbf{x}=(\mathbf{n},\mathbf{s})=& (n_1,\dots ,n_V,s_1,\dots ,s_V):\hfill \\ \hfill & n_v\ge 0,v=1,\dots ,V,\hfill \\ \hfill & m_s\left(\mathbf{x}\right)=\sum _{v=1}^V{n}_v·\mathbf{1}(s_v=s)\le M_s,s=1,\dots ,S\}.\hfill \end{array}$$

For the scenario with two servers and three VMs, the set of states is:

$$\begin{array}{cc}\hfill \mathcal{X}=\{\mathbf{x}=(\mathbf{n},\mathbf{s})=& (n_1,n_2,n_3,s_1,s_2,s_3):\hfill \\ \hfill & n_v\ge 0,v=1,2,3,\hfill \\ \hfill & m_s\left(\mathbf{x}\right)=n_1·\mathbf{1}(s_1=s)+n_2·\mathbf{1}(s_2=s)+n_3·\mathbf{1}(s_3=s)\le M_s,s=1,2\}.\hfill \end{array}$$

The possible distributions of VMs across servers are as follows: $⌀\cup \{1,2,3\}$; $\left\{1\right\}\cup \{2,3\}$; $\left\{2\right\}\cup \{1,3\}$; $\left\{3\right\}\cup \{1,2\}$; $\{1,2\}\cup \left\{3\right\}$; $\{1,3\}\cup \left\{2\right\}$; $\{2,3\}\cup \left\{1\right\}$; $\{1,2,3\}\cup ⌀$.

The principle of VM migration from one server to another upon task arrival is illustrated in Figure 2. As depicted, the system must first have sufficient space; that is, available resources on a server. If at least one server has available resources and is not overloaded, then the task will be processed.

4.3. Transition Rates between CTMC States

In

Table 4. Transition rates.

Description	Transition Rate	Condition on x	State ${\mathbf{x}}^{\prime }$
A task has arrived at v-VM running on the 1-server and will not migrate to another server	${\lambda }_v$	$s_v=1$, $m_1\left(\mathbf{x}\right)+1\le M_1$	$(\mathbf{n}+{\mathbf{e}}_v,\mathbf{s})$
A task has arrived at v-VM running on the 1-server and will migrate to another server	${\lambda }_v$	$s_v=1$, $m_1\left(\mathbf{x}\right)+1>M_1$, $m_2\left(\mathbf{x}\right)+1\le M_2$	$(\mathbf{n}+{\mathbf{e}}_v,\mathbf{s}+{\mathbf{e}}_v)$
A task has arrived at v-VM running on the 2-server and will not migrate to another server	${\lambda }_v$	$s_v=2$, $m_2\left(\mathbf{x}\right)+1\le M_2$	$(\mathbf{n}+{\mathbf{e}}_v,\mathbf{s})$
A task has arrived at v-VM running on the 2-server and will migrate to another server	${\lambda }_v$	$s_v=2$, $m_2\left(\mathbf{x}\right)+1>M_2$, $m_1\left(\mathbf{x}\right)+1\le M_1$	$(\mathbf{n}+{\mathbf{e}}_v,\mathbf{s}-{\mathbf{e}}_v)$
A task has been processed by v-VM	$n_v{\mu }_v$	$n_v>0$	$(\mathbf{n}-{\mathbf{e}}_v,\mathbf{s})$

, the transition rates of the CTMC are presented along with their descriptions. The stationary probability distribution $\pi \left(\mathbf{x}\right)$ is computed using balance equations. Vector ${\mathbf{e}}_v$ is the unit vector with a 1 in the $v^{th}$ place.

4.4. Metrics of Interest

We are interested in the following metrics:

• The blocking probability of a task:

  $$\begin{array}{cc}\hfill & B=B_1=B_2=\sum _{\mathbf{x}\in \mathcal{B}}\pi \left(\mathbf{x}\right),\hfill \\ \hfill & \mathcal{B}=\left\{\mathbf{x}\in \mathcal{X}:m_1\left(\mathbf{x}\right)+1>M_1,m_2\left(\mathbf{x}\right)+1>M_2\right\}.\hfill \end{array}$$
• The average number of tasks being processed by v-VM:

  $$N_v=\sum _{\mathbf{x}=(n_1,n_2,n_3,s_1,s_2,s_3)\in \mathcal{X}}{n}_v\pi \left(\mathbf{x}\right),v=1,2,3.$$
• The average number of tasks being processed on the s-server:

  $$M_s=\sum _{\mathbf{x}=(n_1,n_2,n_3,s_1,s_2,s_3)\in \mathcal{X}}{m}_s\left(\mathbf{x}\right)\pi \left(\mathbf{x}\right),s=1,2.$$

5. Numerical Results

In this section, we turn our attention to SaaS and present a numerical example to evaluate the system under two distinct scenarios.

5.1. Considered Scenarios

The domain of cloud gaming is experiencing a surge in popularity, offering users the ability to stream and engage in video games from remote servers, eliminating the need for advanced gaming hardware. This innovation grants gamers seamless access to a diverse portfolio of games on various devices, potentially diminishing hardware expenses and enhancing overall accessibility. Our investigation delves into the realm of game streaming services.

In our paper, we examined the case of SaaS, which allows users to access and use software over the Internet without the need to install, configure, and run the application on physical media. We considered streaming services in the gaming segment due to the growing trend towards cloud gaming. The same principle applies here: SaaS enables players to access a wide range of online games across devices. There are many examples of model applications, such as all Google services: users just need to create a Google account to gain full access to services; applications for designers like “Figma”, which allows multiple people to work together on one project in real-time with all files stored in the cloud; and CRM systems (customer relationship management), for example, “Insightly”—an online CRM and project management software for small and medium businesses, or “Salesforce”, a platform that performs broad CRM functions, such as lead management, opportunity management, and customer support.

We examine the effects of task arrival rates and average task duration on performance metrics such as blocking probability, the mean number of tasks in the process by v-VM, and the average task count on the s-server. For our system analysis, we define $V=3$ and $S=2$. The numerical analysis concentrates on exploring the relationships between task arrival rates at servers and their processing rates ($\lambda$ and $\mu$, respectively).

Two scenarios are contemplated. The first scenario illustrates the consequences of varying task arrival rates, with parameter adjustments made to demonstrate their influence on system performance. The second scenario evaluates the impact of changes in the average task duration by altering the parameter ratios.

5.2. Impact of Task Arrival Rate

In the initial case, scenario 1A, the $\lambda$ parameter is highly variable, reflecting the potential for rapid fluctuations in the number of active users within gaming services. We assume a uniform arrival rate for tasks across all VMs, setting $\lambda ={\lambda }_1={\lambda }_2={\lambda }_3=0.001,\dots ,10$, with an average task processing time of 1 h.

Our first point of analysis is the blocking probability. We consider a scenario where the maximum number of concurrent tasks across all VMs on both servers ranges from 25–30. As depicted in Figure 3a, the probability of blocking requests escalates with an increasing influx of tasks. Initially, there is negligible growth along the X-axis, but subsequently, the probability peaks at $M=25$. Regarding the average number of tasks per VM and server (Figure 3b,c), we observe a linear increase in both cases.

Scenario 1B examines variations in incoming task rates by introducing a k-parameter as a multiplier. The resulting rates are defined as ${\lambda }_1=\frac{k^2}{k^2+k+1}·\lambda$, ${\lambda }_2=\frac{k}{k^2+k+1}·\lambda$, and ${\lambda }_3=\frac{1}{k^2+k+1}·\lambda$, with k ranging from $0.1,0.2,\dots ,0.9,1,2,\dots ,10$. In this case, we fix $\lambda =10$ and $\mu =0.5$, corresponding to a processing time of 30 min.

Figure 4a reveals an intriguing outcome: despite an uptick in incoming traffic, the blocking probability remains constant across different capacities M. We commence with an examination of the average number of tasks per VM (Figure 4b), noting disparities among the VMs. Moreover, 1-VM and 2-VM exhibit similar trends, likely due to the operation of the migration algorithm. Initially, 3-VM accommodates most tasks before redistribution occurs. At $k=1$, all three lines intersect, showing the same average number of tasks. The average number of tasks on 1 and 2 servers is the same due to the equal number of maximum allowed number of tasks processed on the servers (Figure 4c).

5.3. Impact of Task’s Average Duration

In the second scenario, labeled 2A, we maintain a constant task arrival rate at $\lambda =30$ tasks per hour to assess the influence of the variation of the average task duration on system performance metrics. The service rates, denoted by ${\mu }_1={\mu }_2={\mu }_3$, are uniformly adjusted across all VMs and span from 1/6 to 4, indicative of the rate at which tasks are processed.

Figure 5a illustrates the blocking probability as a function of the service rates $\mu$. The graph exhibits a distinct inverse correlation: an increase in service rate corresponds to a reduction in blocking probability for all system capacities (M values between 25 and 30). Notably, the lines representing various M values cluster tightly, suggesting that the influence of service rate on blocking probability is consistent regardless of system capacity.

In Figure 5b, the average number of tasks managed by each VM is depicted. As anticipated, there is a downward trend, indicating that a higher service rate results in a lower average number of concurrent tasks. Similarly, Figure 5c displays the average task count per server. Echoing the trend observed for VMs, the graph demonstrates that servers process fewer tasks on average as service rates improve. This outcome confirms the expected impact of increased service rates, where tasks are completed more expeditiously, leading to a reduced average number of tasks within the system.

Collectively, these results emphasize the critical role of service rates in optimizing the performance of virtualized server environments. Enhanced task processing speeds (higher $\mu$ values) contribute to lower blocking probabilities and reduced numbers of tasks in both VMs and servers, underscoring the advantages of refining task processing times within such infrastructures.

In scenario 2B, we investigate how the system responds when the average task duration is modulated by a scaling factor k, resulting in variable service rates among VMs. We establish a baseline service rate $\mu =\frac{5}{60}$ h, equivalent to 5 min per task, with VM-specific service rates defined as ${\mu }_1={\mu }_2·2k$, ${\mu }_2={\mu }_3·k$, and ${\mu }_3=\mu$. The scaling factor k is varied from 0.1 to 10, providing a comprehensive range of service rate differentials for analysis.

Figure 6a depicts a marked decrease in the blocking probability as the scaling factor k is incremented. This trend persists irrespective of the VM capacity, ranging M from 25 to 30, indicating that a faster processing rate enhances the system’s capacity to manage incoming tasks, thereby diminishing the potential for task blocking.

In Figure 6b, the average task count per VM is presented. Moreover, 1-VM, benefiting from the fastest service rate due to the $2k$ coefficient, exhibits a pronounced reduction in task numbers. Conversely, 2-VM and 3-VM experience a more gradual decline, reflecting their lower service rates. With the increase of k, the average task counts across all VMs tend to equalize, signifying a transition toward uniform load distribution as discrepancies in task processing times across VMs decrease.

Figure 6c portrays the average task count across both servers. In alignment with the VM data, a significant drop in task numbers is observed as k is elevated. The server connected to 1-VM, which boasts the highest service rate, initially presents a more rapid decline that eventually levels off. The 2-server exhibits a similar, albeit less pronounced, downward trajectory, mirroring the influence of the scaling factor on task processing duration and the associated service rate.

This analysis underscores the pivotal influence of task processing duration on resource allocation and overall system throughput. By manipulating service rates via the k parameter, we can emulate the outcomes of implementing task prioritization and resource optimization strategies within a virtual setting. The study reveals that dynamically modulating service rates in response to fluctuating workload conditions can lead to substantial enhancements in system performance.

5.4. Discussion

The management of cloud computing resources involves working with system and user-defined parameters. The cloud focuses on adjusting the system-defined parameters to meet user requests. In our analysis, parameters $M_1$ and $M_2$ represent the parameters that can be modified by the cloud provider. Conversely, $\lambda$ and $\mu$ reflect user behavior and cannot be managed. One immediate effect of changing the values of $M_1$ and $M_2$ is on the energy efficiency of the data center. A higher number of $M_1$ and $M_2$ would result in increased energy costs; therefore, we aim to optimize the maximum number of tasks allowed to be processed on the VMs. To analyze the proposed model, we considered various service schemes, varying the maximum allowed number of tasks, arrival rate, and processing rate. We examined four cases: (i) there is an equal arrival rate from all users, (ii) the arrival rate changes proportionally among users while the total arrival rate remains constant, (iii) there is an equal processing rate at a constant arrival rate, (iv) the processing rate scales proportionally at a constant arrival rate.

By introducing different limits on the blocking probability, we can determine the optimal number of M. From Figure 3a, we can maintain a blocking probability of ${10}^{-2}$ and $M=25$ for values of $\lambda =0...7$. Increasing M to 30 would allow us to provide services at an arrival rate of $\lambda =0...9$. In Figure 5a, the lines for different M values are located closely enough. Additionally, the average number of tasks on the server for $\mu =2$ is 10. This suggests that the number of active servers can be reduced in this case.

Another critical factor for service providers is the server load. In Figure 3a, when $\lambda =8$ and $M=25$, the average number of tasks for both servers is 4, and the blocking probability is 0.015. To increase the average number of tasks for the servers, we would need to raise $\lambda =10$, which leads to a spike in the blocking probability value almost doubling to 0.03.

Case 2B, as shown in Figure 6c, provides insight into the behavior of tasks across three VMs at different values of the scaling factor k, revealing two distinct patterns. There are several points of interest concerning the average number of tasks. We observe 15 tasks on both VM1 and VM3 once and 25 tasks on VM1 and VM2 twice. Furthermore, the slope of the blocking probability curves changes rapidly at the exact k-values. Additionally, the average number of tasks on both servers exhibits similar behavior within the same range of k. From this analysis, we can predict how different processing rates affect the system’s performance at the beginning of the migration procedure.

6. Conclusions

The rapid evolution of cloud computing technologies has underscored the importance of VM migration as a critical area of research. It plays a pivotal role in optimizing resource management, enhancing fault tolerance, and ensuring service continuity. Motivated by this reality, our paper provides a thorough examination of VM migration complexities within cloud computing frameworks. We explore various VM migration approaches, methods for assessing server load conditions, protocols for VM selection during migration, strategies for identifying optimal times for VM relocation, and criteria for selecting target servers.

At the heart of our discussion is the introduction of a queuing theory model designed to analyze the dynamics of VM migration between servers in cloud systems. By shifting from a traditional resource utilization perspective to one focused on task processing, we capture the stochastic nature of resource demands characterized by randomly timed task arrivals and variable processing duration. Our model is specifically designed for scenarios involving two servers and three VMs. Through numerical examples, we articulate several key performance metrics: the probability of task blocking, the average number of tasks processed by each VM, and the average number of tasks handled by servers. Furthermore, we highlight the impact of task arrival rates and mean task duration on these performance metrics.

Future research will broaden the scope of our model to include a variable number of servers and VMs and will not only consider Poisson arrival processes for tasks but also correlated arrival processes. Additionally, we will consider service rate degradation to develop a more comprehensive understanding of the dynamics within cloud environments. The frequency of migrations is another topic for future research, which would enable exploration beyond quality metrics such as blocking probability.