Indetermsoft-Set-Based D* Extra Lite Framework for Resource Provisioning in Cloud Computing

Abstract

Cloud computing is an immensely complex, huge-scale, and highly diverse computing platform that allows the deployment of highly resource-constrained scientific and personal applications. Resource provisioning in cloud computing is difficult because of the uncertainty associated with it in terms of dynamic elasticity, rapid performance change, large-scale virtualization, loosely coupled applications, the elastic escalation of user demands, etc. Hence, there is a need to develop an intelligent framework that allows effective resource provisioning under uncertainties. The Indetermsoft set is a promising mathematical model that is an extension of the traditional soft set that is designed to handle uncertain forms of data. The D* extra lite algorithm is a dynamic heuristic algorithm that makes use of the history of knowledge from past search experience to arrive at decisions. In this paper, the D* extra lite algorithm is enabled with the Indetermsoft set to perform proficient resource provisioning under uncertainty. The experimental results show that the performance of the proposed algorithm is found to be promising in performance metrics such as power consumption, resource utilization, total execution time, and learning rate. The expected value analysis also validated the experimental results obtained.

1. Introduction

Cloud computing is a highly expansive platform that supports a broad spectrum of applications, catering to diverse needs across various domains. Its vast infrastructure allows for the scalable deployment of both resource-intensive scientific simulations and lightweight personal applications. By offering on-demand access to computing resources, cloud computing enables flexibility and efficiency, accommodating everything from large-scale data processing to everyday tasks. This adaptability makes it an invaluable tool for organizations and individuals alike, providing the necessary resources to handle complex workloads and drive innovation across different fields. Effective resource management is composed of several activities, which include the provisioning of resources, the reporting of provisioning, task scheduling, and thermal management. The resource management system must be capable of dealing with the huge size, heterogeneity, and changing workload demands of cloud users. The main aim of the resource-provisioning scheme is to achieve the maximum data transfer rate with the minimum incurred cost of transfer. For applications utilizing the cloud, their Quality of Service (QoS) must be upgraded without violating the Service-Level Agreement (SLA). While the resources are provisioned, resource availability must be ensured, deployment must be optimized, and interdependency between the user tasks must be managed very well. The improper provisioning of resources leads to an increase in the host machine downtime, compromised service, the inefficient functioning of the application, energy wastage, prolonged time to scale up/down, inability to satisfy the cost goal of users, etc. [1,2,3].

Modern cloud computing structures are utilized to serve computation-intensive applications with large datasets. Resource provisioning is an important aspect of accommodating this use. Potential sources that cause interruption to effective resource provisioning are uncertain operating conditions, performance fluctuations, the improper positioning of the cloud, and the complex infrastructure of a multi-cloud environment. Several forms of uncertainty in the cloud include dynamic elasticity, rapid performance change, large-scale virtualization, loosely coupled applications, the elastic escalation of user demands, etc. These uncertainties make resource provisioning a difficult activity. It is also impossible to determine the workload demands and to obtain the exact knowledge of system parameters like processor speed and bandwidth. Hence, there is a need to develop an intelligent framework with a self-learning ability to make resource-provisioning decisions by properly handling these uncertainties [4,5].

The classical soft set deals only with the determinate form of data, whose values are obviously certain and precise. However, in real-world scenarios, there are several sources that generate uncertainty, which include a lack of information and ignorance. The Indetermsoft set is an extension of the traditional soft set that is designed to handle the uncertain form of data. The word “indeterm” represents indeterminate, reflecting the conflicting and unique form of output. The mathematical definition of the Indetermsoft set is as follows: Let U be the universe of discourse, H be the non-empty subset of U, and P(H) be the power set of H. The Indetermsoft set function $ISSF:A\to P\left(H\right)$ satisfies three properties: the set A has indeterminacy, P(H) has some indeterminacy, and there exists an attribute value $v\in A$ such that F(v) is indeterminate [6,7,8].

D* lite is exactly the reverse of the A* algorithm and is much simpler. The trivial A* algorithm is executed in reverse order; i.e., it begins from the goal state and traverses to the start state. It first determines the current solution and goes into the waiting state until an obstacle occurs. Then, D* lite performs re-planning and incrementally repairs the path by keeping the modifications around the robot’s current pose [9,10]. D* extra lite is a novel and general-purpose algorithm that performs a shortest-path search using an incremental search approach. It performs a fast re-initialization of the search space to determine the shortest path in an unknown or highly dynamic environment. In this paper, the novel D* extra lite algorithm is enriched with the Indetermsoft set mathematical model, which performs a superior re-initialization process under cloud uncertainty to provide stable resource-provisioning decisions.

The objectives of this paper are as follows:

• Providing a brief introduction to the need for effective resource provisioning in uncertain cloud computing systems;
• The efficient handling of parameter uncertainty in the user tasks and virtual machines using the Indetermsoft set mathematical model;
• The design of a novel Indetermsoft-set-based D* extra lite framework for resource provisioning in the cloud;
• An experimental evaluation of the D* extra lite framework performance using the Google Cluster dataset and the Bitbrains dataset using the CloudSim 3.0 open-source framework;
• An expected value analysis and validation of the D* extra lite framework in a dynamic cloud scenario with respect to future time intervals.

The remaining sections of this paper are organized as follows. Section 2 discusses related work. Section 3 provides a mathematical definition of the system model, along with the performance objectives. Section 4 presents the novel Indetermsoft-set-based D* extra lite framework. Section 5 provides the mathematical modeling of the performance objectives that were considered for evaluation. Section 6 deals with the results and discussion by considering the Google Cluster dataset and the Bitbrains dataset. Finally, Section 7 presents the conclusions.

2. Related Work

This section provides a comprehensive overview of the existing literature and developments pertinent to resource provisioning in cloud computing. Through this review of previous research, methodologies, and technological advancements, we establish the foundation/scope for the proposed work.

Shreshth et al. [11] present an artificial-intelligence-based holistic approach named HUNTER for resource management in cloud computing. They view optimizing energy emission in cloud data centers as a multiple-objective-based scheduling problem. A large amount of energy is consumed by cloud data centers, and hence, there is a need to optimize energy emissions. One of the key factors to consider while optimizing energy consumption is reducing the number of thermal hotspots which lead to the degradation of system performance. Three important models are considered for resource management: cooling, thermal, and energy. A gated graph convolutional network is viewed as a surrogate model for optimizing Quality of Service (QoS) to perform optimal task scheduling. The continuous training of the model helps in quick adaption to dynamic scenarios by providing the permission to change the scheduling decisions through task migration. Power performance is used as a heuristic to efficiently balance the load among the cloud hosts. The performance of the HUNTER is evaluated through the CloudSim simulation toolkit and is good with respect to energy conservation. However, the approach exhibits poor scalability as it cannot scale up to large-scale graphs with higher node degrees.

Spyridon et al. propose an auto-scaling framework for resource provisioning in a cloud computing environment [12]. The over- and under-provisioning of resources results in a loss of revenue for the cloud brokers whose primary function is to select, manage, and provide the resources in a complex heterogeneous environment. Since the client resource requirements are uncertain, it becomes difficult for the cloud broker to predict and process the client resource demands. Here, the resource-provisioning problem is divided into two stages: resource selection and resource management. The resource selection problem deals with the process of selecting the services that meet the requirements of multiple cloud service providers. The resource management problem deals with the effective maintenance of cloud resources in terms of resource utilization and overhead maintenance. Both selection and management of resources have been considered as decision-making problems that focus on matching the resource requests with services provided. The cloud users make use of virtualized resources in order to benefit from long-term pricing strategies. For providing cost-effective solutions, a precise estimation of the upcoming workload is required. An adaptive auto-scaling framework for resource provisioning that uses historical time-series data for training a K-means-enabled CNN framework to categorize the future workload demands as low, medium, or high as per their CPU utilization rate is proposed here. From the performance evaluation, it is observed that the solution deployment cost is minimal. However, the framework exhibits higher sensitivity towards initial parameter setting and an inability to handle categorical data in large-state-space environments.

Kumar et al. present an efficient algorithm for resource provisioning for the efficient execution of workflows in cloud computing platforms [13]. The workflow considered here is composed of tasks exhibiting varying resource requirements in terms of memory storage, memory type, and computation speed. Improper mapping of the workflows to resources leads to wastage of resources and increased makespan time. Here, the workflow is divided into three categories: compute-intensive, memory-intensive, and storage-intensive. The proposed algorithm operates in two phases to provision resources precisely by distinguishing the tasks as computation-intensive and non-computation-intensive. The workflow model is composed of limited information about the task contained in it, which makes it applicable to real-time scenarios. The Amazon EC2 cloud model is considered for offering on-demand computational resources for applications using the presented algorithm. However, the approach is found to be static and applies a standard set of operations to process computation-intensive and non-computation-intensive tasks. This limits the practical applicability of the approach.

Mao et al. discuss a game approach based on mean-field theory for resource management in cloud computing [14]. Resource management is viewed as one of the prominent problems in serverless cloud computing environments. Multiple users compete for resources which usually suffer from scalability issues. Here, an actor–critic learning algorithm is developed to effectively deal with large-state-space environments. The algorithm is implemented by considering linear and neural network approximations. The mean-field approach is compatible with several forms of function approximations. Theoretically, convergence to Nash equilibrium is achieved under linear and softmax approximations. The performance of this approach is better in terms of resource utilization, but the time to converge towards better resource-provisioning policies is excessive.

Lucia et al. [15] present an adaptive reinforcement-learning-based approach for resource provisioning in serverless computing. Cloud service providers expect a resource-provisioning scheme to be flexible to meet the fluctuating demands of the customers. A request-based policy is proposed here in which the resources are scaled for the maximum number of requests processed in parallel. The performance is strongly influenced by the predetermined concurrency level. The performance evaluation indicates that with a limited number of iterations, the model formulates efficient scaling policies. But identifying the concurrency level that provides the maximum QoS is difficult because of the varying workload, complex infrastructure, and high latency.

Sangeetha et al. discuss a novel resource management framework based on deep learning [16]. Increased multimedia traffic in the cloud leads to minimum extensibility of a service portfolio and poor resource management. A gray-wolf-optimization-based resource allocation strategy that mimics the hunting behavior of grey wolves is proposed here. The deep neural network utilized here provides routing direction based on the data input rate and storage availability. The neural network operates in two phases: data pre-processing and routing, and controlling application. While the delay in processing the requests is reduced by this policy, it suffers from a poor search ability and a slow convergence rate.

Saxena et al. develop an elastic resource management framework to provide cloud services with high availability [17]. There is a very high demand for resources on the cloud, and the failure to provide on-demand services leads to load imbalance, performance degradation, and excessive power consumption. An online failure predictor that predicts the possibility of the virtual machines resulting in resource starvation due to a resource contention situation is developed. The server under operation is continuously monitored with the aid of a power analyzer, resource monitor, and thermal analyzer. The virtual machines that exhibit a high probability of failure are assigned to the fault tolerance unit that can handle all outages and performance degradation. The virtual machine failure prediction accuracy in this technique is poor, leading to poor resource management policies.

In summary, the existing works exhibit the following drawbacks:

• Inability to determine the parameter uncertainty in the user tasks and virtual machines.
• Conventional resource-provisioning approaches are static in nature, limiting their practical application.
• Rule-based approaches are time-consuming and hard to scale, and the rate of virtual machine violations in terms of cost and response time is very high.
• Most of the heuristic approaches exhibit a higher tendency for premature convergence under uncertainty.
• Predictive approaches exhibit poor prediction accuracy leading to over- or under-utilization of resources.
• The computational complexity of the soft computing approaches is high as they deal with a large number of optimization parameters.
• The learning algorithms fail to consider the highly dynamic operating conditions of a cloud system. As a result, they cannot handle the dynamic task scheduling and dynamic placement of resources efficiently.

3. System Model

This section provides the details of the structure, components, and interactions among the components of the proposed cloud resource-provisioning system. A detailed representation of its operational dynamics and a discussion of its theoretical foundations are also presented. The Indetermsoft-set-based D* extra lite framework for edge computing systems is composed of three functional modules: Indetermsoft set task manager, Indetermsoft set resource manager, and D* extra lite.

The user submits a set of tasks (UTs) to the system accessibility layer, i.e., ${UT}_1=\left\{{ut}_1,{ut}_2,{ut}_3,\dots ,{ut}_m\right\}$, ${UT}_2=\left\{{ut}_1,{ut}_2,{ut}_3,\dots ,{ut}_m\right\}, \dots ,{UT}_m=\left\{{ut}_1,{ut}_2,{ut}_3,\dots ,{ut}_m\right\}$. The system accessibility layer places these user tasks into the task queue of the task manager. The Indetermsoft set task manager applies the Indetermsoft set function (ISF) to the user tasks. That is,

$$ISF\left({UT}_1\right)=\left\{{isf(ut}_1),{isf(ut}_2),{isf(ut}_3),\dots ,{isf(ut}_m)\right\},$$

$$ISF\left({UT}_2\right)=\left\{{isf(ut}_1),isf({ut}_2),{isf(ut}_3),\dots ,isf\left({ut}_m\right)\right\},$$

$$ISF\left({UT}_m\right)=\left\{{isf(ut}_1),{isf(ut}_2),{isf(ut}_3),\dots ,{isf(ut}_m)\right\}$$

(1)

Similarly, the resource center is composed of several resource instances, each instance consists of a set of hosts, and a set of virtual machines are mounted on each host.

$${RCI}_1=\left\{H_1\left({vm}_1, {vm}_2,\dots ,{vm}_n\right),\dots ,H_n\left({vm}_1, {vm}_2,\dots ,{vm}_n\right) \right\},$$

$${RCI}_2=\left\{H_1\left({vm}_1, {vm}_2,\dots ,{vm}_n\right),...{,H}_n\left({vm}_1, {vm}_2,\dots ,{vm}_n\right) \right\},$$

$${RCI}_n=\left\{H_1\left({vm}_1, {vm}_2,\dots ,{vm}_n\right),\dots {,H}_n\left({vm}_1, {vm}_2,\dots ,{vm}_n\right) \right\}$$

(2)

The Indetermsoft set resource manager applies the Indetermsoft set function to the resource instances.

$$ISF\left({RCI}_1\right)=\left\{{isf(H}_1\left({vm}_1, {vm}_2,\dots ,{vm}_n\right))\dots isf(H_n\left({vm}_1, {vm}_2,\dots ,{vm}_n\right))\right\},$$

$$ISF\left({RCI}_2\right)=\left\{{isf(H}_1\left({vm}_1, {vm}_2,\dots ,{vm}_n\right))...isf(H_n\left({vm}_1, {Vm}_2,\dots ,{vm}_n\right))\right\},$$

$$ISF\left({RCI}_n\right)=\left\{{isf(H}_1\left({vm}_1, {vm}_2,\dots ,{vm}_n\right))...isf(H_n\left({vm}_1, {vm}_2,\dots ,{vm}_n\right)) \right\}$$

(3)

The D* extra lite functional module combines the Indetermsoft set function of user tasks and the resource. It is an incremental heuristic search algorithm which is a dynamic form of the A* algorithm that generates D* extra lite task resource-provisioning policies:

$$D^{*}\left(RPP\right)=\left\{ D^{*}\left({RPP}_1\right), D^{*}\left({RPP}_2\right),\dots ,D^{*}\left({RPP}_n\right) \right\}$$

(4)

The following performance objectives (POs) are set for the D* extra lite framework.

PO1: Power Consumption (PC(${\mathrm{D}}^{\mathrm{*}} \mathrm{e}\mathrm{x}\mathrm{t}\mathrm{r}\mathrm{a} \mathrm{l}\mathrm{i}\mathrm{t}\mathrm{e}$)): The power consumption of the D* extra lite framework is the summation of the power consumption of the resource instances $PC\left({RCI}_i\right)$.

$$PC\left(D^{*} extra lite\right)={\sum }_{i=1}^{i=n}PC\left({RCI}_i\right)$$

(5)

where $PC\left({RCI}_i\right)$ is determined by the summation of the power consumption of the host $PC\left(H_i\right)$, i.e., $PC\left({RCI}_i\right)=\sum _{i=1}^{i=n}PC\left(H_i\right)$. Here, $PC\left(H_i\right)$ is determined by considering the maximum power consumption state $PC\left({vm}_i^{max}\right)$, minimum power consumption state $PC\left({vm}_i^{min}\right)$, and idle state power consumption $PC\left({vm}_i^{idle}\right)$ of the virtual machine:

$$PC\left(H_i\right)=\left[ PC\left({vm}_i^{max}\right)-PC\left({vm}_i^{min}\right)\right]\ast RU\left({vm}_i\right)+PC\left({vm}_i^{idle}\right)]$$

(5a)

PO2: Resource Utilization (RU(${\mathrm{D}}^{\mathrm{*}} \mathrm{e}\mathrm{x}\mathrm{t}\mathrm{r}\mathrm{a} \mathrm{l}\mathrm{i}\mathrm{t}\mathrm{e}$)): The resource utilization of the D* extra lite framework is computed by the summation of the resources utilized by the resource instances $RU\left({RCI}_i\right)$.

$$RU\left(D^{*}extra lite\right)={\sum }_{i=1}^{i=n}RU\left({RCI}_i\right)$$

(6)

where $RU\left({RCI}_i\right)$ is determined by the summation of the resources consumed by the host $RU\left(H_i\right)$, i.e., $RU\left({RCI}_i\right)=\sum _{i=1}^{i=n}RU\left(H_i\right)$. Here, $RU\left(H_i\right)$ is the measure of the utilities of the virtual machines that are used by the user tasks. It is determined by computing the over-utilized resource center instances ${RCI}_i^{over}$ and under-utilized resource center instances ${RCI}_i^{under}$ among the set of available resource center instances $N_{RCI}$.

$$RU\left(D^{*} extra lite\right)={\sum }_{i=1}^{i=n}({RCI}_i^{over}-{RCI}_i^{under})/N_{RCI}$$

(6a)

PO3: Total Execution Time (TET(${\mathrm{D}}^{\mathrm{*}} \mathrm{e}\mathrm{x}\mathrm{t}\mathrm{r}\mathrm{a} \mathrm{l}\mathrm{i}\mathrm{t}\mathrm{e}$)): The total execution time of the D* extra lite framework is the time taken to assign the user tasks to virtual machines. It is the summation of total execution time of the Indetermsoft set function of user tasks ISF(${UT}_i)$, Indetermsoft set function of resource instances $ISF\left({RCI}_i\right)$, and D* policy $D^{*}\left({RPP}_i\right)$.

$$\begin{array}{c}TET\left(D^{*} extra lite\right)=\\ {\sum }_{i=1}^{i=m}TET\left(ISF\left({UT}_i\right)\right)+{\sum }_{i=1}^{i=n}TET\left(ISF\left({RCI}_i\right)\right)+{\sum }_{i=1}^{i=n}TET\left(D^{*}\left({RPP}_i\right)\right)\end{array}$$

(7)

PO4: Learning Rate ($\mathrm{L}\mathrm{R}({\mathrm{D}}^{\mathrm{*}} \mathrm{e}\mathrm{x}\mathrm{t}\mathrm{r}\mathrm{a} \mathrm{l}\mathrm{i}\mathrm{t}\mathrm{e}$)): The learning rate of the D* extra lite framework is the speed at which the Indetermsoft set function of user tasks ISF(${UT}_i)$ is mapped to the Indetermsoft set function of resource instances $ISF\left({RCI}_i\right)$. It is computed by considering the total execution time for the formulation of the first resource-provisioning policy ${ET(D}^{*}\left({RPP}_1\right))$ and the number of resource-provisioning policies formulated ${N(D}^{*}\left(RPPP\right)$).

$$LR\left(D^{*} extra lite\right)={TET(D}^{*}\left({RPP}_1\right))\ast N(D^{*}\left(RPP\right))$$

(8)

4. Proposed Work

This section outlines the innovative contributions and research directions that form the core of this research study and presents the novel ideas, methodologies, and proposed solutions, emphasizing their significance and potential impact on the resource-provisioning field.

As shown in Figure 1, the Indetermsoft-set-based D* extra lite framework is composed of three distinct modules. The users submit requests to the system accessibility layer. The task manager is responsible for monitoring the resources and tasks. The resource center is composed of a set of virtual machines that are hosted on several physical machines. The uncertainty in the incoming tasks is managed by the Indetermsoft set task manager. Similarly, the uncertainty in the resources is managed by the Indetermsoft set resource manager. The D* extra lite algorithm is executed on the Indetermsoft set of tasks and resources. D* extra lite is also referred to as dynamic A*, which determines an ideal path between the starting point and goal of an application. The obstacles that occur are handled efficiently when they are encountered on the path towards the destination.

4.1. Indetermsoft Set Task Manager (ISSTM)

The ISSTM component of the D* extra lite framework accepts a set of user tasks UT as inputs; ${\mathrm{U}\mathrm{T}=\{\mathrm{U}\mathrm{T}}_1,{\mathrm{U}\mathrm{T}}_2,{\mathrm{U}\mathrm{T}}_3,\dots ,{\mathrm{U}\mathrm{T}}_{\mathrm{m}}\}$. It applies the Indetermsoft set function to generate the Indetermsoft set function ISF of the user task set. $ISF\left(UT\right)=\{ISF\left({UT}_1\right),ISF\left({UT}_2\right),ISF\left({UT}_1\right),\dots ,ISF\left({UT}_m\right)\}$. The Indetermsoft set function handles the indeterminate and conflicting parameters of the user tasks by mapping the attributes of user tasks to the power set of the user task set. The working of the ISSTM module is depicted in Algorithm 1, which consists of a training phase and a testing phase. During the training phase, for each set of user tasks, the Indetermsoft set function is applied to generate the Indetermsoft set function of the user task set. Likewise, during the testing phase, the cumulative aggregation of the Indetermsoft set function of the user task set is computed.

Algorithm 1: Working of ISSTM

1: Start

2: Input user task set

${\mathrm{U}\mathrm{T}=\{\mathrm{U}\mathrm{T}}_1,{\mathrm{U}\mathrm{T}}_2,{\mathrm{U}\mathrm{T}}_3,\dots ,{\mathrm{U}\mathrm{T}}_{\mathrm{m}}\}$

3: Output ISF of user task set

$ISF\left(UT\right)=\{ISF\left({UT}_1\right),ISF\left({UT}_2\right),ISF\left({UT}_1\right),...,ISF\left({UT}_m\right)\}$

4: Training phase of ISSTM

$5: \mathrm{For} \mathrm{each} \mathrm{training} \mathrm{user} \mathrm{task} \mathrm{set} {UT}_{\mathrm{i}}\in UT$ do

6:      $\mathrm{For} \mathrm{each} \mathrm{training} \mathrm{user} \mathrm{task} \mathrm{set} \mathrm{attributes} {UT}_i^{at}=\{{ut}_1^{at},{ut}_2^{at},\dots ,{ut}_m^{at}\}$ in UT do

7:                 $\mathrm{Train} {{\forall isf}_{\mathrm{i}}\left({ut}_k\right)}^{\mathrm{a}\mathrm{t}}\in {\mathrm{u}\mathrm{t}}^{\mathrm{a}\mathrm{t}} \mathrm{i}\mathrm{n}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{a}\mathrm{l}\mathrm{i}\mathrm{z}\mathrm{e} \sigma \left({{isf}_{\mathrm{i}}\left({ut}_k\right)}^{\mathrm{a}\mathrm{t}}\right)=\mathrm{N}\mathrm{U}\mathrm{L}\mathrm{L}$

8:         Calculate training ISF of user tasks

9:                        ${ISF(UT}_{\mathrm{i}}):{ut}_k^{at}\to P\left(H\left({UT}_i^{at}\right)\right),H\subseteq UT$

10:     End For

11: End For

12: Testing phase of ISSTM

$13: \mathrm{For} \mathrm{each} \mathrm{testing} \mathrm{user} \mathrm{task} \mathrm{set} {UT}_{\mathrm{i}}\in UT$ do

$14: \mathrm{For} \mathrm{each} \mathrm{testing} \mathrm{user} \mathrm{task} \mathrm{set} \mathrm{attributes} {UT}_i^{at}=\{{ut}_1^{at},{ut}_2^{at},...,{ut}_m^{at}\}$ in UT do

$15: \mathrm{Test} {{\forall isf}_{\mathrm{i}}\left({ut}_k\right)}^{\mathrm{a}\mathrm{t}}\in {\mathrm{u}\mathrm{t}}^{\mathrm{a}\mathrm{t}} \mathrm{i}\mathrm{n}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{a}\mathrm{l}\mathrm{i}\mathrm{z}\mathrm{e} \sigma \left({{isf}_{\mathrm{i}}\left({ut}_k\right)}^{\mathrm{a}\mathrm{t}}\right)=\mathrm{N}\mathrm{U}\mathrm{L}\mathrm{L}$

16:               Compute aggregation of Indetermsoft set function

$ISF\left(UT\right)\colon\colon =ISF\left({UT}_i\right)\cup {{({UT}_i^{at},isf}_{\mathrm{i}}\left({ut}_k\right)}^{\mathrm{a}\mathrm{t}})$

17:     End For

18: End For

$19: \mathrm{Output} ISF\left(UT\right)=\{ISF\left({UT}_1\right),ISF\left({UT}_2\right),ISF\left({UT}_1\right),...,ISF\left({UT}_m\right)\}$

20: Stop

4.2. Indetermsoft Set Resource Manager (ISSRM)

The ISSRM component of the D* extra lite framework receives the set of resource center instances RCI as inputs. ${RCI=\{RCI}_1, {RCI}_2,{RCI}_3$,…,${RCI}_m\}$. It applies the Indetermsoft set function to generate the Indetermsoft set function ISF of the resource center instance set. ${ISF\left(RCI\right)=\left\{ISF\right(RCI}_1), ISF({RCI}_2),{ISF(RCI}_3)$,…,$ISF\left({RCI}_m\right)\}$. The Indetermsoft set function handles the indeterminate, conflicting parameters of the resource center instances by mapping the attributes of resource center instances to the power set of the resource center instance set. The working of the ISSRM module is shown in Algorithm 2, which consists of training and testing phases. During the training phase, for every set of resource center instances, the Indetermsoft set function is applied to generate the Indetermsoft set function of resource center instances. Likewise, during the testing phase, the cumulative aggregation of the Indetermsoft set function of the resource center instance set is computed.

Algorithm 2: Working of ISSRM

1: Start

2: Input user task set

${\mathrm{R}\mathrm{C}\mathrm{I}=\{\mathrm{R}\mathrm{C}\mathrm{I}}_1,{\mathrm{R}\mathrm{C}\mathrm{I}}_2,{\mathrm{R}\mathrm{C}\mathrm{I}}_3,\dots ,{\mathrm{R}\mathrm{C}\mathrm{I}}_{\mathrm{m}}\}$

3: Output ISF of user task set

$ISF\left(RCI\right)=\{ISF\left({RCI}_1\right),ISF\left({RCI}_2\right),ISF\left({RCI}_3\right),...,ISF\left({RCI}_n\right)\}$

4: Training phase of ISSRM

$5: \mathrm{For} \mathrm{each} \mathrm{training} \mathrm{resource} \mathrm{center} \mathrm{instance} {RCI}_{\mathrm{i}}\in RCI$ do

6:          For each training resource center instance attributes do

${RCI}_i^{at}=\left\{H_i\right({vm}_1^{at}),\dots ,H_i({vm}_i^{at}\left)\right\}$  $\mathrm{in} RCI$

7:              $\mathrm{Train} {\forall isf}_{\mathrm{i}}\left(H_i\right({vm}_1^{at})$  $\in {H_i\left(vm\right)}^{\mathrm{a}\mathrm{t}}) \mathrm{i}\mathrm{n}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{a}\mathrm{l}\mathrm{i}\mathrm{z}\mathrm{e} \sigma ({isf}_i\left(H_i\right({vm}_k^{at}\left)\right))=\mathrm{N}\mathrm{U}\mathrm{L}\mathrm{L}$

8:        Calculate training ISF of resource center instances

9:                          ${ISF(RCI}_{\mathrm{i}}):H_i({vm}_k^{at})\to P\left(H\left(H_i\right({vm}_k^{at}\left)\right)\right),H\subseteq RCI$

10:     End For

11: End For

12: Testing phase of ISSRM

$13: \mathrm{For} \mathrm{each} \mathrm{testing} \mathrm{user} \mathrm{task} \mathrm{set} {RCI}_{\mathrm{i}}\in RCI$ do

14:               For each testing user task set attributes do

${RCI}_i^{at}=\left\{H_i\right({vm}_1^{at}),H_i({vm}_i^{at}\left)\right\}$  $\mathrm{in} RCI$

15:          $\mathrm{Test} {\forall isf}_{\mathrm{i}}\left(H_i\right({vm}_1^{at})\in {H_i\left(vm\right)}^{\mathrm{a}\mathrm{t}}) \mathrm{i}\mathrm{n}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{a}\mathrm{l}\mathrm{i}\mathrm{z}\mathrm{e} \sigma \left({isf}_i\right(H_i\left({vm}_k^{at}\right)\left)\right)=\mathrm{N}\mathrm{U}\mathrm{L}\mathrm{L}$

16:              Compute aggregation of Indetermsoft set function

$ISF\left(RCI\right)\colon\colon =ISF\left({RCI}_i\right)\cup ({RCI}_i^{at},\forall {\forall isf}_{\mathrm{i}}\left(H_i\left({vm}_k^{at}\right))\right)$

17:     End For

18: End For

$19: \mathrm{Output} ISF\left(RCI\right)=\{ISF\left({RCI}_1\right),ISF\left({RCI}_2\right),ISF\left({RCI}_3\right),...,ISF\left({RCI}_n\right)\}$

20: Stop

4.3. D* Extra Lite (D*EL)

The D*EL component of the D* extra lite framework accepts the Indetermsoft set function of the user task set $ISF\left(UT\right)=\{ISF\left({UT}_1\right),ISF\left({UT}_2\right),...,ISF\left({UT}_m\right)\}$ and Indetermsoft set function of resource center instances to generate D* extra lite resource-provisioning policies $D^{*}\left(RPP\right)=\left\{ D^{*}\left({RPP}_1\right),\dots ,D^{*}\left({RPP}_n\right) \right\}.$ The working of the D*EL component is shown in Algorithm 3, which is composed of training and testing phases. The user tasks and resource center instances are represented in terms of an acyclic tree composed of nodes and edges. During training, D*EL uses an incremental heuristic search technique for the robust navigation of user tasks to ideal resource center instances. During testing, for the incoming user tasks, an ideal path is determined by using a priority queue data structure. The time incurred in training and testing is less as the user tasks are aligned in a priority queue which prevents frequent reordering and fast re-planning during user task navigation. The efficiency lies in re-expanding the parts of the search space that are registered for changes. The CALCULATE KEY function uses the key value for assigning priority to the list elements, and this value is determined through the sum of heuristic values. The REINITIALIZE function performs fast re-initialization of the affected search space using a search tree. Quick re-computation of the optimal path is performed by keeping track of visited and unvisited states of the resource center instances using the CUT BRANCHES function.

Algorithm 3: Working of D*EL

1: Start

2: Input

$ISF\left(UT\right)=\{ISF\left({UT}_1\right),ISF\left({UT}_2\right),ISF\left({UT}_1\right),...,ISF\left({UT}_m\right)\}$

$ISF\left(RCI\right)=\{ISF\left({RCI}_1\right),ISF\left({RCI}_2\right),ISF\left({RCI}_3\right),...,ISF\left({RCI}_n\right)\}$

$3: \mathrm{Output} D^{\mathrm{*}}\left(RPP\right)=\left\{D^{\mathrm{*}}\left({RPP}_1\right),D^{\mathrm{*}}\left({RPP}_2\right),\dots ,D^{\mathrm{*}}\left({RPP}_n\right)\right\}$

4: Function CALCULATE KEY (State S)

$5: \mathrm{Return} [g\left(s\right)+h\left(S_{start},S\right)+K_m;g(s\left)\right]$, where h is the heuristic value,

$g\left(s\right)$$\mathrm{is} \mathrm{the} \cos \mathrm{t} \mathrm{from} \mathrm{goal} \mathrm{state}, \mathrm{and} K_m$ is the bias value.

6: Function SOLUTION FOUND ()

$7: \mathrm{Return} \mathrm{TOP} \mathrm{OPEN}=S_{start}$$\mathrm{or} \mathrm{Visited} (S_{start}$$) \mathrm{AND} \mathrm{NOT} \mathrm{OPEN} (S_{start}$)

8: Function INITIALIZE ()

$9: K_m=0,$  $\mathrm{Visited} \left(S_{goal}\right)$  $=\mathrm{True}, \mathrm{Parent} \left(S_{goal}\right)$  $=\mathrm{NULL}, \mathrm{g} \left(S_{goal}\right)=0$

$10: \mathrm{PUSH} \mathrm{OPEN} (S_{goal},$$\mathrm{CALCULATE} \mathrm{KEY} (S_{goal}$))

11: Function SEARCH STEP ()

12:      s = TOP OPEN ()

13:      POP OPEN ()

$14: k_{old}=key\left(s\right)$

$15: k_{new}=$$\mathrm{CALCULATE} \mathrm{KEY} (S_{goal}$)

$16: \mathrm{if} k_{old}<k_{new}$ then

17:               PUSH OPEN(s, CALCULATE KEY(s))

18:               else

$19: \mathrm{for} \mathrm{all} s^{\prime }\in Pred\left(s\right) do$

$20: \mathrm{if} \mathrm{NOT} \mathrm{VISITED} \left(s^{\prime }\right)$$\mathrm{OR} g\left(s^{\prime }\right)>cost\left(s^{\prime },s\right)+g\left(s\right)$then

$21: Parent\left(s^{\prime }\right)=s$

$22: g\left(s^{\prime }\right)=cost\left(s^{\prime },s\right)+g\left(s\right)$

$23: \mathrm{if} \mathrm{NOT} \mathrm{VISTED} \left(s^{\prime }\right)$ then

$24: \mathrm{VISITED} \left(s^{\prime }\right)$ = true

$25: \mathrm{PUSH} \mathrm{OPEN} (s^{\prime },$$\mathrm{CALCULATE} \mathrm{KEY} (s^{\prime }$))

26:                    End for

27:    Function REINITIALIZE ()

28:        if any edge cost changed then

29:                 CUT BRANCHES

$30: \mathrm{if} seeds\ne \varnothing$ then

$31: K_m=K_m+h(S_{last},S_{start})$

$32: S_{last}=S_{start}$

$33: \mathrm{for} \mathrm{all} \mathrm{s}\in Seeds do$

$34: \mathrm{if} visited\left(s\right) \mathrm{A}\mathrm{N}\mathrm{D} \mathrm{N}\mathrm{O}\mathrm{T} \mathrm{O}\mathrm{P}\mathrm{E}\mathrm{N}\left(S\right)$ THEN

35:                          PUSH OPEN (s, CALCULATE KEY(s))

$36: \mathrm{seed}=\varnothing$

37:          Function CUT BRANCHES ()

38:                          Reopen_start = false

39:                          For all directed edges (u, v) with changed cost do

40:              if visited (u) AND visited (v) then

41:                          cold = cost (u, v)

42:                          Update edge cost (u, v)

43:                          if cold > cost (u, v) then

$44: \mathrm{if} g\left(start\right)>g\left(v\right)+cost\left(u,v\right)+h(S_{start},u)$ then

45:                                    reopen_start = true

$46: \mathrm{seeds}=\mathrm{seeds} \cup v$

47:                                          else if cold < cost (u, v) then

$48: \mathrm{if} parent \left(u\right)=v$ then

49:                          CUT BRANCHES (u)

$50: \mathrm{if} reope{n}_{start}=true AND visited\left(S_{start}\right)then$

$51: \mathrm{seeds}=\mathrm{seeds} \cup S_{start}$

52:              End for

53:        Function CUT BRANCHES(s)

54:        Visited(s) = false

55:                   Parent(s) = NULL

56:        REMOVE OPEN(s)

$57: \mathrm{for} \mathrm{all} s^{\prime }\in Succ\left(s\right) do$

$58: \mathrm{if} \mathrm{visited} (s^{\prime }$$) \mathrm{AND} \mathrm{NOT} \mathrm{parent} (s^{\prime }$) = s then

$59: \mathrm{seeds}=\mathrm{seeds} \cup s^{\prime }$

60:     End for

$61: \mathrm{for} \mathrm{all} s^{\prime }\in Pred\left(s\right) do$

$62: \mathrm{if} \mathrm{visited} (s^{\prime }$$) \mathrm{AND} \mathrm{parent} (s^{\prime }$) = s then

$63: \mathrm{CUT} \mathrm{BRANCHES} (s^{\prime }$)

64:        End for

$65: \mathrm{Output} D^{\mathrm{*}}\left(RPP\right)=\left\{D^{\mathrm{*}}\left({RPP}_1\right),D^{\mathrm{*}}\left({RPP}_2\right),\dots ,D^{\mathrm{*}}\left({RPP}_n\right)\right\}$

5. Mathematical Modeling

This section presents the mathematical structures, equations, and algorithms that are central to this resource-provisioning study, providing a rigorous basis for our theoretical and empirical investigations. The performance of the D* extra lite framework is analyzed through mathematical modeling. For modeling purposes, a limited cloud setup that is composed of a predefined set of user tasks and resource center instances is considered. The performance objectives considered for evaluation purposes are power consumption (PC(${\mathrm{D}}^{\mathrm{*}} \mathrm{e}\mathrm{x}\mathrm{t}\mathrm{r}\mathrm{a} \mathrm{l}\mathrm{i}\mathrm{t}\mathrm{e}$)), resource utilization (RU(${\mathrm{D}}^{\mathrm{*}} \mathrm{e}\mathrm{x}\mathrm{t}\mathrm{r}\mathrm{a} \mathrm{l}\mathrm{i}\mathrm{t}\mathrm{e}$)), total execution time (TET(${\mathrm{D}}^{\mathrm{*}} \mathrm{e}\mathrm{x}\mathrm{t}\mathrm{r}\mathrm{a} \mathrm{l}\mathrm{i}\mathrm{t}\mathrm{e}$)), and learning rate ($\mathrm{L}\mathrm{R}({\mathrm{D}}^{\mathrm{*}} \mathrm{e}\mathrm{x}\mathrm{t}\mathrm{r}\mathrm{a} \mathrm{l}\mathrm{i}\mathrm{t}\mathrm{e}$)). The expected value analysis is performed to determine the performance metrics for the future time FT. Finally, the performance of the proposed D* extra lite framework is compared with three existing works: EW1-TP [13], EW2-AC [14], and EW3-GC [16].

PO1: Power Consumption (PC(${\mathrm{D}}^{\mathrm{*}} \mathrm{e}\mathrm{x}\mathrm{t}\mathrm{r}\mathrm{a} \mathrm{l}\mathrm{i}\mathrm{t}\mathrm{e}$)): The power consumption of D* extra lite is mainly influenced by the power consumed by the virtual machines during the maximum power consumption state $PC\left({vm}_i^{max}\right)$ and minimum power consumption state $PC\left({vm}_i^{min}\right)$. The PC(D* extra lite) is low as D* extra lite performs smooth matching of tasks and resource instances by finding safer paths, whereas the power consumption of EW1 is comparatively higher as it performs static classification of tasks as computation-intensive, memory-intensive, and storage-intensive by considering the present traffic scenario and ignoring the history. The power consumption of EW2 and EW3 is higher than that of EW1 due to loose function approximation, poor scalability, and inappropriate selection of resources.

$$\begin{array}{c}E\left({\displaystyle \frac{PC\left(D^{*} extra lite\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)={\int }_x^y{\displaystyle \frac{\sum _{aϵ\pi }PC\left(D^{*} extra lite\right)\left(a\right)}{\left|D^{*}\right(\mathrm{T}\mathrm{S}\mathrm{P}\left)\right|}}\\ E\left({\displaystyle \frac{PC\left(D^{*} extra lite\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)={\displaystyle \sum _{d\in D}}d{\int }_x^y{\displaystyle \frac{\sum _{aϵ\pi }PC\left(D^{*} extra lite\right)\left(a\right)}{\left|D^{*}\right(\mathrm{T}\mathrm{S}\mathrm{P}\left)\right|}}\\ E\left({\displaystyle \frac{PC\left(D^{*} extra lite\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)={\displaystyle \frac{E\left(1\ast \pi \ast \sum _{i=1}^{i=n}PC\left({RCI}_i\right)\right)}{P\left(D^{*}\right(\mathrm{T}\mathrm{S}\mathrm{P}\left)\right)}}\\ ={\displaystyle \sum _{d\in D}}d{\int }_q^Q\left[ PC\left({vm}_i^{max}\right)-PC\left({vm}_i^{min}\right)\right]\ast RU\left({vm}_i\right)+PC\left({vm}_i^{idle}\right)]\\ ={\int }_q^{Q}Q\ast dP{\displaystyle \frac{\left[ PC\left({vm}_i^{max}\right)-PC\left({vm}_i^{min}\right)\right]\ast RU\left({vm}_i\right)+PC\left({vm}_i^{idle}\right)]}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}\\ \mathrm{PC}(\mathrm{D}* \mathrm{extra} \mathrm{lite}): E\left({\displaystyle \frac{PC\left(D^{*} extra lite\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)\approx Low\\ \mathrm{PC}(\mathrm{EW}1): E\left({\displaystyle \frac{PC\left(EW1\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)\approx Medium\\ \mathrm{PC}(\mathrm{EW}2): E\left({\displaystyle \frac{PC\left(EW2\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)\approx High\\ \mathrm{PC}(\mathrm{EW}3): E\left({\displaystyle \frac{PC\left(EW3\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)\approx High\end{array}$$

PO2: Resource Utilization (RU(${\mathrm{D}}^{\mathrm{*}} \mathrm{l}\mathrm{i}\mathrm{t}\mathrm{e}$)): The resource utilization of D* extra lite is mainly influenced by the over-utilization of resources of resource center instance ${RCI}_i^{over}$ and under-utilization of resources of resource center instance ${RCI}_i^{under}$. The RU(${\mathrm{D}}^{\mathrm{*}} \mathrm{l}\mathrm{i}\mathrm{t}\mathrm{e}$) is high as it combines an incremental search and a heuristic search strategy for task mapping. The resource utilization of EW1 is low due to improper formulation of the workflow model which leads to more resource wastage. The resource utilization of EW2 is moderate as the model is not capable of dealing with a large-state-space environment and takes a longer time to converge to Nash equilibrium. The RU(EW3) is low due to convergence to suboptimal solutions and poor task-routing capability.

$$\begin{array}{c}\left({\displaystyle \frac{RU\left(D^{*} extra lite\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}},FT\right)={\int }_x^y{\displaystyle \frac{\sum _{aϵ\pi }RU\left(D^{*} extra lite\right)\left(a\right)}{\left|D^{*}\right(\mathrm{T}\mathrm{S}\mathrm{P}\left)\right|}}\\ E\left({\displaystyle \frac{RU\left(D^{*} extra lite\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}},FT\right)={\displaystyle \sum _{d\in D}}d{\int }_x^y{\displaystyle \frac{\sum _{aϵ\pi }RU\left(D^{*} extra lite\right)\left(a\right)}{\left|D^{*}\right(\mathrm{T}\mathrm{S}\mathrm{P}\left)\right|}}\\ E\left({\displaystyle \frac{RU\left(D^{*} extra lite\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)={\displaystyle \frac{E\left(1\ast \pi \ast \sum _{i=1}^{i=n}RU\left({RCI}_i\right)\right)}{P\left(D^{*}\right(\mathrm{T}\mathrm{S}\mathrm{P}\left)\right)}}\\ E\left({\displaystyle \frac{RU\left(D^{*} extra lite\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}},FT\right)={\displaystyle \sum _{d\in D}}d{\int }_q^Q{\displaystyle \sum _{i=1}^{i=n}}({RCI}_i^{over}-{RCI}_i^{under})/N_{RCI}\\ E\left({\displaystyle \frac{RU\left(D^{*} extra lite\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)={\int }_q^{Q}Q\ast dP{\displaystyle \frac{\sum _{i=1}^{i=n}({RCI}_i^{over}-{RCI}_i^{under})/N_{RCI}}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}\\ \mathrm{RU}(\mathrm{D}* \mathrm{extra} \mathrm{lite}): E\left({\displaystyle \frac{RU\left(D^{*} extra lite\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)\approx High\\ \mathrm{RU}(\mathrm{EW}1): E\left({\displaystyle \frac{RU\left(EW1\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)\approx Low\\ \mathrm{RU}(\mathrm{EW}2): E\left({\displaystyle \frac{RU\left(EW2\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)\approx Medium\\ \mathrm{RU}(\mathrm{EW}3): E\left({\displaystyle \frac{RU\left(EW3\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)\approx Low\end{array}$$

PO3: Total Execution Time (TET(${\mathrm{D}}^{\mathrm{*}} \mathrm{l}\mathrm{i}\mathrm{t}\mathrm{e}$)): The total execution time of D* extra lite is mainly influenced by the total execution time of the Indetermsoft set function of user tasks ISF(${UT}_i)$, Indetermsoft set function of resource instances $ISF\left({RCI}_i\right)$, and D* policy $D^{*}\left({Tsp}_i\right)$. The TET(${\mathrm{D}}^{\mathrm{*}} \mathrm{l}\mathrm{i}\mathrm{t}\mathrm{e}$) is low as it is capable of handling dynamic obstacles in cloud scenarios using an incremental search strategy. The TET(EW1) is moderate due to inappropriate mapping of resources. The TET(EW2) is very high because of poor workflow classification and softmax parametrization taking an infinite period of time for convergence. The TET(EW3) is low due to bad local search capability and a poor convergence rate.

$$\begin{array}{c}E\left({\displaystyle \frac{TET\left(D^{*} extra lite\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)={\int }_x^y{\displaystyle \frac{\sum _{aϵ\pi }TET\left(D^{*} extra lite\right)\left(a\right)}{\left|D^{*}\right(\mathrm{T}\mathrm{S}\mathrm{P}\left)\right|}}\\ E\left({\displaystyle \frac{TET\left(D^{*} extra lite\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)={\displaystyle \sum _{d\in D}}d{\int }_x^y{\displaystyle \frac{\sum _{aϵ\pi }TET\left(D^{*} extra lite\right)\left(a\right)}{\left|D^{*}\right(\mathrm{T}\mathrm{S}\mathrm{P}\left)\right|}}\\ ={\displaystyle \frac{E\left(1\ast \pi \ast \sum _{i=1}^{i=m}TET\left(ISF\left({UT}_i\right)\right)+\sum _{i=1}^{i=n}TET\left(ISF\left({RCI}_i\right)\right)+\sum _{i=1}^{i=n}TET\left(D^{*}\left({Tsp}_i\right)\right)\right)}{P\left(D^{*}\right(\mathrm{T}\mathrm{S}\mathrm{P}\left)\right)}}\\ ={\displaystyle \sum _{d\in D}}d{\int }_q^Q{\displaystyle \sum _{i=1}^{i=m}}TET\left(ISF\left({UT}_i\right)\right)+{\displaystyle \sum _{i=1}^{i=n}}TET\left(ISF\left({RCI}_i\right)\right)+{\displaystyle \sum _{i=1}^{i=n}}TET\left(D^{*}\left({Tsp}_i\right)\right)\\ ={\int }_q^{Q}Qdp{\displaystyle \frac{\sum _{i=1}^{i=m}TET\left(ISF\left({UT}_i\right)\right)+\sum _{i=1}^{i=n}TET\left(ISF\left({RCI}_i\right)\right)+\sum _{i=1}^{i=n}TET\left(D^{*}\left({Tsp}_i\right)\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}\\ \mathrm{TET}(\mathrm{D}* \mathrm{extra} \mathrm{lite}): E\left({\displaystyle \frac{TET\left(D^{*} extra lite\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)\approx Low\\ \mathrm{TET}(\mathrm{EW}1): E\left({\displaystyle \frac{TET\left(EW1\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)\approx Medium\\ \mathrm{TET}(\mathrm{EW}2): E\left({\displaystyle \frac{TET\left(EW2\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)\approx High\\ \mathrm{TET}(\mathrm{EW}3): E\left({\displaystyle \frac{TET\left(EW3\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)\approx Low\end{array}$$

PO4: Learning Rate ($\mathrm{L}\mathrm{R}({\mathrm{D}}^{\mathrm{*}} \mathrm{e}\mathrm{x}\mathrm{t}\mathrm{r}\mathrm{a} \mathrm{l}\mathrm{i}\mathrm{t}\mathrm{e}$)): The learning rate of D* extra lite is mainly influenced by the total execution time for the formulation of the first task-scheduling policy ${TET(D}^{*}\left({TSP}_1\right))$ and the number of task-scheduling policies formulated $D^{*}\left(TSP\right)$. The $\mathrm{L}\mathrm{R}({\mathrm{D}}^{\mathrm{*}} \mathrm{e}\mathrm{x}\mathrm{t}\mathrm{r}\mathrm{a} \mathrm{l}\mathrm{i}\mathrm{t}\mathrm{e}$) is very high due to high planning efficiency and provides a fast reliable path from user tasks to resource center instances. The LR(EW1) is medium as it makes poor task-scheduling decisions considering limited information about user tasks. The LR(EW2) is low as it does not consider the computation-sensitive and storage-sensitive features of the tasks. The LR(EW3) is low due to low learning accuracy and converging to a low-optimality solution as it is easily affected by external factors.

$$\begin{array}{c}E\left({\displaystyle \frac{LR\left(D^{*} extra lite\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)={\int }_x^y{\displaystyle \frac{\sum _{aϵ\pi }LR\left(D^{*} extra lite\right)\left(a\right)}{\left|D^{*}\right(\mathrm{T}\mathrm{S}\mathrm{P}\left)\right|}}\\ E\left({\displaystyle \frac{LR\left(D^{*} extra lite\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)={\displaystyle \sum _{d\in D}}d{\int }_x^y{\displaystyle \frac{\sum _{aϵ\pi }LR\left(D^{*} extra lite\right)\left(a\right)}{\left|D^{*}\right(\mathrm{T}\mathrm{S}\mathrm{P}\left)\right|}}\\ E\left({\displaystyle \frac{LR\left(D^{*} extra lite\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)={\displaystyle \frac{E\left(1\ast \pi \ast {TET(D}^{*}\left({TSP}_1\right))\ast N(D^{*}\left(TSP\right))\right)}{P\left(D^{*}\right(\mathrm{T}\mathrm{S}\mathrm{P}\left)\right)}}\\ E\left({\displaystyle \frac{LR\left(D^{*} extra lite\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)={\displaystyle \sum _{d\in D}}d{\int }_q^Q{TET(D}^{*}\left({TSP}_1\right))\ast N(D^{*}\left(TSP\right))\\ E\left({\displaystyle \frac{LR\left(D^{*} extra lite\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)={\int }_q^{Q}Q\ast dP{\displaystyle \frac{{TET(D}^{*}\left({TSP}_1\right))\ast N(D^{*}\left(TSP\right))}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}\\ \mathrm{LR}(\mathrm{D}* \mathrm{extra} \mathrm{lite}): E\left({\displaystyle \frac{LR\left(D^{*} extra lite\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)\approx High\\ \mathrm{LR}(\mathrm{EW}1): E\left({\displaystyle \frac{LR\left(EW1\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)\approx Medium\\ \mathrm{LR}(\mathrm{EW}2): E\left({\displaystyle \frac{LR\left(EW2\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)\approx Low\\ \mathrm{LR}(\mathrm{EW}3): E\left({\displaystyle \frac{LR\left(EW3\right)}{D^{*}\left(\mathrm{T}\mathrm{S}\mathrm{P}\right)}}, FT\right)\approx Low\end{array}$$

6. Results and Discussion

This section presents our findings and interprets their significance in the context of resource-provisioning studies. As the key outcome of our research, a summary of the data and insights that have emerged from the analyses is presented. Also, a stage is set for a comprehensive comparison of our work with three recent existing works.

6.1. Experimental Setup

The CloudSim 3.0.3 framework is used for the modeling and simulation of the proposed Indetermsoft-set-based D* extra lite framework [18,19]. The experimental setup for execution is as follows: The resource center consists of three systems: Intel 5150 CPU containing 40 core processors with 3.0 GHz clock speed, Xeon 4150 CPU containing 45 core processors with 4.0 GHz clock speed, and Silver 6150 CPU containing 50 core processors with 2.0 GHz clock speed. Four host machine configurations are used: Host Machine 1 = {PE = 2 (small), MIPS = 2660, RAM = 4 GB, Storage = 160 GB, $PC\left({vm}_i^{max}\right)$ = 135, $PC\left({vm}_i^{min}\right)$/$PC\left({vm}_i^{idle}\right)$ = 93.7}, Host Machine 2 = {PE = 4 (medium), MIPS = 3067, RAM = 8 GB, Storage = 250 GB, $PC\left({vm}_i^{max}\right)$ = 113, $PC\left({vm}_i^{min}\right)$/$PC\left({vm}_i^{idle}\right)$ = 42.3}, Host Machine 3 = {PE = 12 (large), MIPS = 3067, RAM = 16 GB, Storage = 500 GB, $PC\left({vm}_i^{max}\right)$ = 222, $PC\left({vm}_i^{min}\right)$/$PC\left({vm}_i^{idle}\right)$ = 58.4}, and Host Machine 4 = {PE = 24 (Extra-large), MIPS = 4067, RAM = 18 GB, Storage = 600 GB, $PC\left({vm}_i^{max}\right)$ = 322, $PC\left({vm}_i^{min}\right)$/$PC\left({vm}_i^{idle}\right)$ = 68.4}. Four virtual machine configurations are used: Virtual Machine 1 = {Host Machine 1, VM type = small, PE = 1, MIPS = 500, RAM (GB) = 0.5, Storage (GB) = 40}, Virtual Machine 2 = {Host Machine 2, VM type = medium, PE = 2, MIPS = 1000, RAM (GB) = 1.0, Storage (GB) = 60}, Virtual Machine 3 = {Host Machine 3, VM type = large, PE = 3, MIPS = 1500, RAM (GB) = 2.0, Storage (GB) = 80}, and Virtual Machine 4 = {Host Machine 4, VM type = Extra-large, PE = 4, MIPS = 2000, RAM (GB) = 3.0, Storage (GB) = 100}. Two real-time datasets are used for implementation: the Google Cluster dataset and the Bitbrains dataset [20].

6.2. Google Cluster Dataset

The Google Cluster dataset is composed of physical resources such as memory, CPU, and disk storage. The user task set is composed of 672,300 tasks that are executed over 12,500 host machines for a period of 30 days. The experiments are conducted with varying sizes of resource center instances considering 100 (Tiny), 300 (Small), 700 (Large), 900 (Extra Large), and 1000 (Huge) host machines. The ratio of virtual machines to host machines is 2:1. As per the user task set resource demands, the virtual machines are allocated for every 5 min randomly. The user task set is created with a virtual machine ratio of 60 percent. The number of virtual machines varies over time, and each user task set can keep 0 to 20 virtual machines. The user task set exhibits varying resource requirements. There will be user task set demand of workload burst conditions in terms of massive failure of virtual machines, and at peak service hours, situations of overloads and resource contention will occur. Each experiment is conducted for a time period of 100 min to analyze the performance of the proposed D* extra lite framework dynamically with respect to the performance objectives mentioned.

PO1: Power Consumption (PC(${\mathrm{D}}^{\mathrm{*}} \mathrm{e}\mathrm{x}\mathrm{t}\mathrm{r}\mathrm{a} \mathrm{l}\mathrm{i}\mathrm{t}\mathrm{e}$))

A graph of varying resource center instances versus power consumption is shown in Figure 2. It is observed from the graph that the power consumption of D* extra lite is minimal over varying sizes of resource center instances. The framework is focused and performs smooth matching between tasks and resource instances by finding safer paths. The power consumption of EW1-TP is very high as it performs static classification of tasks as computation-intensive, memory-intensive, and storage-intensive by considering the present traffic scenario and ignoring the history. The power consumptions of EW2-AC and EW3-GW are moderate due to loose function approximation, poor scalability, and inappropriate selection of resources. The workflow model considered in EW2-AC and EW3-GW has limited information about the task parameters which makes it not suitable for real-world situations.

PO2: Resource Utilization (RU(${\mathrm{D}}^{\mathrm{*}} \mathrm{l}\mathrm{i}\mathrm{t}\mathrm{e}$))

A graph of varying sizes of user task sets versus resource utilization is shown in Figure 3. The resource utilization of D* extra lite is optimal over all sizes of user tasks as it combines incremental and heuristic search strategies for task mapping. The resource utilization of EW1-TP is poor due to improper formulation of the workflow model which does not suit the real-time scenario of cloud systems. The structural features extracted from the tasks are poor, which leads to resource wastage. The resource utilization of EW2-AC and EW3-GW is moderate due to convergence to suboptimal solutions and poor task-routing capability. They are not capable of dealing with a large-state-space environment, and the resource allocation models take longer time to converge to Nash equilibrium.

PO3: Total Execution Time (TET(${\mathrm{D}}^{\mathrm{*}} \mathrm{l}\mathrm{i}\mathrm{t}\mathrm{e}$))

A graph of varying sizes of user tasks set versus total execution time (ms) is shown in Figure 4. The total execution time of D* extra lite is considerably less for all sizes of user task sets due to effective task scheduling despite dynamic obstacles in cloud scenarios. The total execution time of EW1-TP and EW2-AC is very high due to the poor classification of workflow and inappropriate mapping of resources, which cause the execution time to spike. The softmax parametrization also takes an infinite period of time for convergence to promising solutions. The total execution time of EW3-GW is moderate due to poor local search capability and poor convergence rate. Also, the resource management model provides minimal extensibility of a service portfolio.

PO4: Learning Rate ($\mathrm{L}\mathrm{R}({\mathrm{D}}^{\mathrm{*}} \mathrm{l}\mathrm{i}\mathrm{t}\mathrm{e}$))

A graph of varying sizes of user task sets versus learning rate is shown in Figure 5. The learning rate of D* extra lite is very high due to high planning efficiency and provides a fast reliable path from user tasks to resource center instances. The learning rate of EW1-TP is very low as it makes poor task-scheduling decisions considering limited information on user tasks. It does not consider the computation-sensitive and storage-sensitive features of the tasks. The learning rates of EW2-AC and EW3-GW are moderate due to low learning accuracy and convergence to low-optimality solutions. They also fail to capture the complexity of real-world situations, and the outcomes of the approach are easily affected by external factors.

6.3. Bitbrains Dataset

The Bitbrains dataset is composed of performance metrics related to rapid data storage of 2830 virtual machines over distributed resource center instances for a period of one month. It mainly constitutes information related to the percentage of CPU usage, memory consumed (kilobytes), memory sanctioned (kilobytes), network capacity, throughput, etc. The ratio of virtual machines to host machines is 4:2, and per the user task set resource demand, the virtual machines are allocated for every minute randomly. The user task sets are created with a virtual machine ratio of 40 percent. The number of virtual machines varies over time, and each user task set can keep 0 to 10 virtual machines. The experiments are conducted for different resource center instances for 24 h over a period of 60 days. Resource center instances are composed of 200 (Tiny), 400 (Small), 600 (Large), 800 (Extra-large), and 1000 (Huge) host machines. The user task sets exhibit varying resource requirements and often lead to burst conditions at peak service hours. Each experiment is executed for a time period of 600 min to analyze the performance of the proposed D* extra lite framework dynamically with respect to the performance objectives mentioned.

PO1: Power Consumption (PC(${\mathrm{D}}^{\mathrm{*}} \mathrm{l}\mathrm{i}\mathrm{t}\mathrm{e}$))

A graph of varying sizes of resource center instances versus power consumption is shown in Figure 6. It is observed from the graph that the power consumption of D* extra lite is considerably less over varying sizes of resource center instances from small to huge. It easily navigates the tasks to the resource center instances in a highly dynamic environment by using a priority queue to minimize the effect of reordering. The power consumption of EW3-GW is moderate because of poor exploration capability when exposed to a large state space. The convergence speed is never satisfied due to insufficient handling of task diversities. The power consumption of EW1-TP and EW2-AC is very high since it takes a long time (infinite time) to converge to Nash equilibrium under linear function approximation. Also, the tendency towards the selection of inappropriate solutions is high, and the ability to handle enormous computational resources for larger task sets is poor.

PO2: Resource Utilization (RU(${\mathrm{D}}^{\mathrm{*}} \mathrm{l}\mathrm{i}\mathrm{t}\mathrm{e}$))

A graph of varying sizes of user task sets versus resource utilization is shown in Figure 7. The resource utilization rate of D* extra lite is very high for varying sizes of user task sets. It simplifies the maintenance of user task set priority by efficiently analyzing the program workflow. The resource utilization of RE3-GW is average as the algorithm converges to a suboptimal solution due to an imbalance in grey wolf behavior. The resource utilization of EW1-TP and EW2-AC is very low as the task-scheduling policy gradient quality is low due to a mismatch between the critical value function and actor policy. Also, the softmax parametrization of the user task set leads to an infinite time required for convergence to a promising solution. It is also not able to handle a spike in user requests which causes resource contention in the multi-tenancy nature of a serverless platform.

PO3: Total Execution Time (TET(${\mathbf{D}}^{\mathbf{*}} \mathbf{l}\mathbf{i}\mathbf{t}\mathbf{e}$))

A graph of varying sizes of resource center instances versus total execution time is shown in Figure 8. The total execution time of D* extra lite is low for all sizes of user tasks as it is able to find the optimal path between the starting point (user test set) and ending point (resource instances) in a dynamic cloud environment. The total execution time of EW3-GW is moderate as it generates an approximate solution whose correctness of operation is not guaranteed. Service management and operating system deployment are improper due to poor approximation towards a promising solution. The total execution time of EW1-TP and EW2-AC is very high due to their limited capability to perform global search operations and susceptibility to convergence towards local suboptimal solutions. Also, the task-scheduling decisions suffer from severe scalability issues and inappropriate convergence towards promising solutions.

PO4: Learning Rate ($\mathbf{L}\mathbf{R}({\mathbf{D}}^{\mathbf{*}} \mathbf{l}\mathbf{i}\mathbf{t}\mathbf{e}$))

A graph of varying sizes of resource center instances versus learning rate is shown in Figure 9. The learning rate of D* extra lite is very high for all varying sizes of user task sets since it efficiently handles uncertainty in the environment by precisely taking actions using the knowledge gained from previous searches. The learning rate of EW2-AC is very low due to neural network function approximation. Even the asymptotic behavior of the differential game approach decreases its learning rate towards promising solutions. The learning rates of EW1-TP and EW3-GW are moderate due to an imbalanced relationship between exploration and exploitation. They also fail to handle larger user requests, and the task data cannot be handled effectively with increasing user demands.

7. Conclusions

This paper presented a novel Indetermsoft-set-based D* Extra Lite framework for resource provisioning in the cloud. The experimental evaluation was carried out using the CloudSim simulator, with the Google Cluster dataset and Bitbrains dataset. The results obtained were found to outperform three of the existing works with respect to the performance objectives of power consumption, resource utilization, total execution time, and learning rate. However, the proposed framework also suffered from limitations in terms of limited handling of highly dynamic obstacles, extensive memory usage, and increased computational overhead. As future work, complete analytical modeling and exhaustive testing of the framework are planned to address higher-end performance objectives such as fault tolerance, correctness, confidentiality, reliability, and transparency.