Scalable Fog Computing Orchestration for Reliable Cloud Task Scheduling

Abstract

As Internet of Things (IoT) and Industrial Internet of Things (IIoT) devices are becoming increasingly popular in the era of the Fourth Industrial Revolution, the orchestration and management of numerous fog devices encounter a scalability problem. In fog computing environments, to embrace various types of computation, cloud virtualization technology is widely used. With virtualization technology, IoT and IIoT tasks can be run on virtual machines or containers, which are able to migrate from one machine to another. However, efficient and scalable orchestration of migrations for mobile users and devices in fog computing environments is not an easy task. Naïve or unmanaged migrations may impinge on the reliability of cloud tasks. In this paper, we propose a scalable fog computing orchestration mechanism for reliable cloud task scheduling. The proposed scalable orchestration mechanism considers live migrations of virtual machines and containers for the edge servers to reduce both cloud task failures and suspended time when a device is disconnected due to mobility. The performance evaluation shows that our proposed fog computing orchestration is scalable while preserving the reliability of cloud tasks.

1. Introduction

Fog computing is a computing architecture that extends cloud computing by enabling data processing at the network edge instead of the central cloud computing server for small and tiny devices, also known as Internet of Things (IoT) devices [1,2]. IoT and Industrial Internet of things (IIoT) devices are increasing by 35% annually, and IoT and IIoT businesses will be worth around USD 7.1 trillion to the United States and EUR 1.2 trillion to Europe by 2030 [3].

To support the ever-increasing number of devices and amount of data generated in IoT and IIoT computing environments, cloud computing provides service offload and virtual machine migration capabilities at the network edge level (edge server) [4,5]. However, the inherited characteristics of IoT and IIoT devices hinder reliable cloud task computation [5,6,7]. In other words, devices in fog computing environments can move around a field, and when a device moves from one spot to another, the device can be disconnected from the edge server [8,9].

In this case, the device that disconnected from the edge server should try to connect to another edge server nearby. If the device cannot access another edge server, the cloud tasks of the device cannot be completed [10,11,12]. Even when the device is able to access another edge server nearby, the cloud tasks of the device can be suspended until data and virtual machine migrations are complete. This will worsen the reliability of cloud tasks when multiple mobile users perform them simultaneously in IoT and IIoT computing environments [13,14].

Figure 1 shows an IoT and IIoT computing architecture with an edge cloud. There are three layers in the architecture: the central cloud center, edge servers and containers, and IoT applications (tuple). As far as migrations of services and applications are concerned, edge servers should cooperate with the central cloud center and other nearby edge servers. When unconsidered scheduling and migration algorithms trigger migrations, tuples or related data can be lost.

To mitigate the reliability issues of cloud tasks in IoT and IIoT computing environments, in this paper, we propose a scalable fog computing orchestration mechanism for reliable cloud task scheduling. The proposed scalable orchestration mechanism considers live migrations of virtual machines and containers for the edge servers to reduce both cloud task failures and suspended time when a device is disconnected due to mobility. Furthermore, we use information about the distance between a user and nearby edge servers in order to optimize task scheduling and migration decisions.

Unlike the previous work related to IoT and IIoT cloud task scheduling [15,16], we take users’ mobility speed into account so that our scalable fog computing orchestration can select an optimal destination edge server for the migration. A performance evaluation based on realistic mobility data (simulation of urban mobility—SUMO [17,18]) shows that our proposed fog computing orchestration mechanism for a reliable cloud task scheduling algorithm outperforms previous work in terms of the reliability of cloud tasks while introducing affordable data traffic on the network. It also shows that our algorithm scales well in terms of the number of IoT and IIoT users.

The contributions of our study can be summarized as follows.

• We discuss the IoT and IIoT system architectures to show their characteristics and their limitations in supporting cloud-based mobile applications, which will help both architects of IoT and IIoT systems and cloud data center administrators.
• We implement two scalable fog computing orchestration algorithms: one is for scheduling and assigning cloud tasks to appropriate edge servers and containers with considerations of signal strength, and the other one is for cloud task migrations that improve the overall reliability of mobile applications by checking and calculating migratability.
• We validate our proposed algorithms by comparing various performance metrics and incorporating mobility pattern data obtained from SUMO.

The rest of the paper can be summarized as follows. Section 2 discusses our research background and related work. Section 3 proposes our scalable fog computing orchestration algorithm in IoT and IIoT computing environments. Section 4 provides comparative performance evaluation results to show the efficiency and scalability of the proposed mechanism. Finally, Section 5 concludes the paper.

2. Related Work

In this section, we provide a literature review to support the background and motivation of this research. Our scalable fog computing orchestration mechanism is aimed at optimizing the overall IoT and IIoT task performance by improving the reliability of cloud scheduling. The proposed method adopts a live migration scheme [19,20] for mobile users, which generates more network traffic than cold migration [21,22].

For this reason, a few studies have used the live migration scheme in fog computing environments. Despite the network traffic, our fog computing orchestration mechanism is able to improve the reliability of cloud tasks by considering users’ mobility and signal strength.

Martins et al. [23] explored virtual network function [24,25] overheads in fog computing environments. Specifically, to predict the container migration cost, they used a linear regression model that is widely used in machine learning and artificial intelligence.

In a container virtualization platform using LXD [26,27], they identified several variables that affected the performance of container migrations. Then, they provided a mathematical analysis in terms of the processing time and network traffic associated with virtual network function migrations.

Since that study was focused on virtual network functions from the perspective of predicting overheads and validating the predictor model, it lacked an overall performance evaluation in fog computing environments, such as realistic scenarios with multiple mobile users.

To support a stateful container migration in a geometrically distributed fog computing environment, another work [28] used an open-source file system (OverlayFS [27]) and took snapshots of containers to reduce network transfer time when migrating.

It achieved a reduced downtime during the container migration when compared to the baseline (no volume checkpoint). Although it proposed enhanced checkpoint and migration techniques, no high-level orchestrations, such as task allocation or scheduling for fog devices, were provided.

Rosário et al. [29] proposed multi-tier (central cloud node, regional fog node, neighborhood fog node, and local fog node) computing node environments in fog computing. Specifically, they supported the quality of experience for multimedia-based mobile applications.

To enhance the quality of experience, the authors designed a service migration from the central cloud server to multi-tier fog computing nodes based on software-defined networking for video distribution.

The potential downside of the method was weak generality. In other words, it was specialized for mobile applications that used multimedia, while our proposed method can be used in general-purpose mobile applications, including multimedia-related functionalities.

Based on the OpenStack platform [30,31], Puliafito et al. [32] proposed a fog computing service. It uses a container-based implementation for service migrations to support the mobility of mobile devices. By implementing a monitoring server for the decision-making mechanism, it calculates the score of the distance and decides on a migration scheduling policy.

Although this was closely related to our study, it differed in that our research uses signal strength instead of distances. In addition, they did not consider multi-user environments for scalability, unlike the proposed evaluation setup.

To employ a load-balancing feature in fog computing environments, Singh et al. [33] analyzed a load-balancing algorithm by considering energy consumption. For the energy-efficient load-balancing mechanism, they considered two main components in fog computing environments: resource (virtual machines) allocation and scheduling.

While the authors analyzed the state-of-the-art load-balancing techniques in fog computing environments, they did not incorporate a container-based resource allocation or scheduling, which is a common acceptance in resource virtualization environments.

Gonçalves et al. [34] proposed a network slicing technique to satisfy the quality of service requirements and improve network utilization in fog computing environments. Two aspects of the proposed techniques were container migration and network slicing.

Among the two, network slicing was the major contribution of the study. In other words, the physical infrastructure of the fog computing network was logically divided into several slices based on the number of users. With the divided slices, it achieved the requirements of a specific group or application. However, the number of mobile users was stationary, and no scalability settings were provided, unlike in the proposed research method.

3. The Proposed Fog Computing Orchestration Mechanism

In this section, we provide our scalable fog computing orchestration algorithms that enhance the reliability of cloud tasks. The proposed algorithms are composed of two parts: a task scheduling algorithm that schedules a new task for IoT and IIoT devices and a task migration algorithm that transfers existing tasks to another edge server and container.

Figure 2 shows the process and flow of the proposed algorithms. There are eight stages in the performance of our proposed orchestration schemes. First, task scheduling is initiated when a new task for IoT and IIoT devices has arrived. Second, when a task is assigned an edge server and its container, the user’s mobile application is associated with the edge server. Third, the central cloud center periodically monitors the edge servers and containers in the cloud computing environment.

Fourth, based on monitoring information, the system may trigger task migration in a reliable fashion. Fifth, the central cloud center collects data and has the target edge server prepare for migrations. Sixth, the source edge server and destination edge server are synchronized for migrations. Seventh, the migration data are transferred from the source edge server to the destination edge server. Finally, the eighth stage is the re-registration of the user’s mobile application to the destination edge server, which is transparent to the user.

Algorithm 1 Task Scheduling Algorithm.
	Input:Tuple_i
	Output:Map_i = (Tuple_i, Edge_j, Container_k)
	Initialization: location ← get_location (Tuple_i);
	requirement ← get_requirement (Tuple_i);
1:	call assign_tuple (Tuple_i);
2:	function assign_tuple (Tuple_i)
3:	signal_strength ← 0;
4:	target_edge ← null;
5:	target_container ← null;
6:	found ← false;
7:	for allEdge_i ∊ Set_Edge (location) do
8:	current_signal_strength ← get_edge_info (Edge_i, signal);
9:	if (current_signal_strength > signal_strength) then
10:	signal_strength ← current_signal_strength;
11:	target_edge ← Edge_i;
12:	end if
13:	end for
14:	for allContainer_i ∊ target_edge do
15:	if (Container_i meets requirement) then
16:	target_container ← Container_i;
17:	assign_info ← assign_tuple (Tuple_i, target_edge, target_container);
18:	found ← true;
19:	end if
20:	end for
21:	if (found == false) then
22:	target_container ← provision_container (target_edge);
23:	assign_info ← assign_tuple (Tuple_i, target_edge, target_container);
24:	end if
25:	return assign_info;
26:	end function

Algorithm 2 Task Migration Algorithm.
	Input:Map_i = (Tuple_i, Edge_j, Container_k)
	Output:New_Map_i = (Tuple_i, Edge_j, Container_k)
	Initialization: location ← get_location (Tuple_i);
	signal_strength ← get_signal_info (Map_i);
	mobility_speed ← get_mobility_speed (Map_i);
	mobility_property ← get_mobility_property (Map_i);
	target_edge ← null;
	bool_migration ← false;
1:	call check_condition (Map_i);
2:	if (bool_migration) then
3:	call perform_migration (Map_i, target_edge);
4:	end if
5:	function check_condition (Map_i)
6:	signal_target ← 0;
7:	for all Edge_i ∊ Near_Edge (Map_i) do
8:	signal_target ← get_edge_info (Edge_i, signal);
9:	val_threshold ← threshold(signal_strength, location, mobility_speed);
10:	if (signal_target > val_threshold) then
11:	target_edge ← Edge_i;
12:	end if
13:	end for
14:	if (migratability (target_edge, mobility_property)) then
15:	bool_migration ← true;
16:	end if
17:	end function
18:	function perform_migration (Map_i, target_edge)
19:	handoff (Map_i, target_edge);
20:	for all Container_i ∊ target_edge do
21:	if (Container_i meets requirement) then
22:	target_container ← Container_i;
23:	assign_info ← assign_tuple (Tuple_i, target_container);
24:	found ← true;
25:	end if
26:	end for
27:	if (found == false) then
28:	target_container ← provision_container (Edge_i);
29:	assign_info ← assign_tuple (Tuple_i, target_container);
30:	end if
31:	migrate_tuple (Map_i, target_container);
32:	migrate_data (Map_i, target_container);
33:	sync (Map_i, target_container);
34:	return New_Map_i = (Tuple_i, target_edge, target_container)
35:	end function

Algorithm 1 shows the task scheduling algorithm. This algorithm is triggered when a new task for IoT and IIoT devices has arrived. The input is Tuple_i, and the output is mapping information for the tuple (Map_i), that is, Tuple_i, Edge_j, and Container_k. The algorithm uses location and requirement information based on Tuple_i. To compose the assign_tuple function, several variables are used: signal_strength, target_edge, target_container, and found.

It first finds connectable edge servers based on the location. Then, it retrieves the signal strength (current_signal_strength) of each edge server by iterating the loop. When current_signal_strength is greater than signal_strength, the signal_strength variable is updated with current_signal_strength, and that edge server is assigned to target_edge.

After selecting a target edge server, it traverses each container of the target edge server to check whether Tuple_i can be assigned to an existing container. When one of the existing containers meets the requirement, it assigns Tuple_i to the container. If it cannot find a container that meets the requirement, it triggers a new container provision for the target_edge.

Algorithm 2 shows the task migration algorithm. The input of the algorithm is Map_i, and the output is New_Map_i. Both Map_i and New_Map_i contain tuple, edge server, and container information. For the task migration, several variables are initialized (location, signal_strength, mobility_speed, mobility_property, target_edge, and bool_migration).

Before it schedules the task migration, the check_condition function is called. Note that the check_condition function is called at a regular interval. The check_condition function traverses neighbor edge servers of Edge_i. After retrieving signal_target for Edge_i, it calculates the threshold value for the condition. The threshold value is a result of the threshold function with three parameters (signal_strength, location, and mobility_speed). If signal_target is greater than the threshold value (val_threshold), Edge_i is assigned to target_edge.

With target_edge and mobility_property, bool_migration can be true if the migratability function returns true. When bool_migration is true after calling the check_condition function, the perform_migration function is called. The perform_migration function does handoff, container selection, and task migration (tuples and data). Note that the container selection phase is similar to that of the task scheduling algorithm. The task migration phase calls three additional functions: migrate_tuple, migrate_data, and sync. Then, it returns New_Map_i.

4. Evaluation

In this section, we provide the performance results of our proposed scalable orchestration mechanism for improving migration downtime and task reliability. To evaluate the proposed mechanism in a simulated environment and to measure the network traffic, average downtime, total migration time, and tuples lost, we use SUMO mobility data, which can be used to simulate mobility patterns and network traffics based on realistic scenarios.

4.1. Performance Results

Figure 3 shows the numbers of migrations of the previous and proposed methods. When the number of users is small (one or two users), the difference between the previous and proposed methods is relatively small. However, as the number of users increases, the difference between the previous and proposed methods becomes greater.

Specifically, when the number of users is 5, the numbers of migrations of the previous and proposed methods are 14 and 19, respectively, with a difference of 5. If the number of users is 10, the numbers of migrations of the previous and proposed methods are 19 and 31, respectively, with a difference of 12. This signifies that the proposed method optimizes the performance of tasks by migrating them appropriately.

Figure 4 shows the network usage of the previous and proposed methods. Note that the total network usage is the sum of that of the devices and migration, and the baseline data in the figure indicate when the number of users is 1. The network usage of migrations accounts for most of the total network usage, which is affordable in recent high-bandwidth network environments.

Since the proposed method introduces more live migrations than the previous method, the network usage of the proposed method generates more network traffic than the previous method.

In a multi-user environment (when the number of users is 5), the difference in network usage between the previous and the proposed methods is about 1 GB. Although the proposed method incurs more network traffic, it improves the overall performance in terms of downtime and the reliability of tasks.

To figure out the performance of time-related metrics, we measure the average downtime and the total time of migration (c.f., Figure 5). As in Figure 4, we refer to the baseline performance in Figure 5 for comparison purposes. In terms of the average downtime, the proposed method outperforms the previous method. Specifically, the proposed method has only about 19% of the downtime seen in the previous method.

This means that our method is more than five times better than the previous method in terms of downtime. When we compare the total time of migration, our method takes longer than the previous method, since our method incurs more live migrations than the previous one. Note that the proposed method does not generate meaningful overhead as the number of users increases.

As for the task reliability, we measure the percentages and the numbers of Tuples lost for the previous and proposed methods (c.f., Figure 6). Figure 6a shows the percentages of tuples lost. For the previous method, the percentages of tuples lost are 3.580%, 3.769%, 7.399%, 8.002%, 7.919%, and 6.194% when the numbers of users are 1, 2, 3, 4, 5, and 10, respectively. For the proposed method, the percentages of tuples lost are 0.027%, 0.033%, 0.038%, 0.041%, 0.041%, and 0.041% when the numbers of users are 1, 2, 3, 4, 5, and 10, respectively.

Figure 6b shows the numbers of tuples lost. For the previous method, the numbers of tuples lost are 87,078, 136,802, 376,588, 547,976, 666,795, and 979,050 when the numbers of users are 1, 2, 3, 4, 5, and 10, respectively. For the proposed method, the numbers of tuples lost are 762, 1416, 2637, 4029, 4875, and 13,661 when the numbers of users are 1, 2, 3, 4, 5, and 10, respectively.

Compared to the previous and proposed methods, the proposed method generates 0.875%, 1.035%, 0.700%, 0.735%, 0.731%, and 1.395% of the tuples lost compared with the previous method when the numbers of users are 1, 2, 3, 4, 5, and 10.

On the whole, the proposed method improves the overall performance for cloud tasks of IoT and IIoT devices in fog computing environments by optimizing the average downtime and the reliability of cloud tasks while generating affordable network traffic for live migrations.

4.2. Discussion

The proposed task scheduling and task migration algorithms are designed to carefully assign and migrate users’ tuples in terms of reliability. To this end, we considered various criteria (location, signal strength, mobility speed, and mobility properties) for tuple migrations.

Table 1. Comparison of cloud task management schemes. (○: considered, △: partially considered, and ×: not considered).

Study	Scalability	Mobility Support	Live Migration	Migration Criteria	Optimized for Task Reliability
[23]	×	×	○	Migration time Data transferred	×
[28]	○	○	△	Geo-distribution Migration downtime Disk usage	×
[29]	×	○	Service migration	Quality of experience Video distribution	×
[32]	△	○	○	Round-trip latency Migration downtime	×
[34]	△	○	○	User speed	△
Proposed	○	○	○	Location Signal strength Mobility speed and properties	○

shows the comparison of cloud task management schemes. Recent studies have shown that the live migration feature in IoT and IIoT computing environments is encouraging, since it helps increase the task throughput and reduces the overall downtime.

However, a few studies thoroughly analyzed and evaluated IoT and IIoT resource management schemes, including live migrations, in terms of scalability and task reliability. For this matter, we developed task scheduling and migration algorithms to improve the scalability and task reliability. Even when the number of users increases, the tuples lost are below 1% on average compared to the previous method.

The downside of the proposed orchestration technique is that it generates more network traffic for live migration data. The network traffic and other performance metrics (downtime and tuples lost) are in a trade-off relationship. To improve the task reliability, we went for the overall performance metrics rather than the network traffic. The performance results show that our scheme introduces more network traffic than the previous method.

To mitigate network overheads, one can use state-of-the-art network chipsets (e.g., WiFi 6 [802.11 ax]). Since WiFi 6 is capable of a maximum throughput speed of 9.6 Gbps, the network transmission time for live migration data can be reduced. We conjecture that as network technology evolves, the network overheads can be drastically reduced.

5. Conclusions

When IoT and IIoT devices’ tasks are provisioned to a cloud computing environment, fog computing orchestration may encounter bottleneck problems and cause the unreliability of cloud tasks. In this paper, we proposed a scalable fog computing orchestration mechanism for reliable cloud task scheduling. The proposed scalable orchestration is designed to reduce both cloud task failures and suspended time when a device is disconnected due to mobility. Even when the number of users increases, the tuples lost are below 1% on average compared to the previous method. Specifically, we take various migration criteria (location, signal strength, mobility speed, and mobility properties) into account in our algorithms for task reliability. Although our method introduces more network traffic than the traditional orchestration mechanism, the overall performance, including the downtime and tuples lost, is satisfactory. Since current network environments support high bandwidths (e.g., the fifth-generation mobile network and WiFi 6 [802.11 ax]), the overhead of additional network traffic is negligible. Future work will include the adoption of artificial intelligence techniques to manage and schedule virtualized resources in IoT and IIoT computing environments.