Security prioritized multiple workflow allocation model under precedence constraints in cloud computing environment

Abstract

In the last decade, cloud computing has become an effective and efficient service delivery platform to offer resources, innovation, and economies of scale on telecommunication networks. An allocation scheme without security constraints consideration may assign the high security-sensitive tasks onto the lower trustworthy machines. This would lead the performance deterioration. To address this issue, in this paper, a security-prioritized multiple workflow allocation (SPMWA) model is proposed by integrating the security-prioritized mapping scheme for Infrastructure-as-a-Service cloud computing environment. It is expected that incorporating a security-prioritized allocation scheme under precedence constraints will enhance the performance of workflow processing in risk-prone environments. In this model, more priority is given to tasks with high-security demand to get allocated onto the more trustworthy virtual machines during allocation to minimize the failure probability of the cloud system. The failure probability can be minimized by assigning the tasks on to the trustable virtual machines exhibiting sufficient trust level to minimize the number of task failures. The number of task failure, failure probability, and makespan have been computed for the comparative evaluation of the SPMWA. For performance comparison, the SPMWA model has been compared with state-of-the-art models from the literature having the same environment and objective. The experimental evaluation confirms the superior performance of the proposed model on account of the considered objective among its peers.

1 Introduction

Cloud computing is an internet-based service infrastructure that facilitates on-demand access on a pay-as-you-go basis for users of configuration resources such as stockpiling, server, network, administrations, and other applications to allow them pervasive services which can be rapidly discharged and provisioned with insignificant administrative effort [1, 2]. Day-by-day, cloud computing is growing in heterogeneous distributed processing, automatic computing, utility, and matrix computing. The heterogeneous distributed computing facilitates any type of administration for worldview like social networking, registering applications of computational assets, broadcast communication, and web administration. From these benefits of cloud computing, cloud users can make use of processing assets, and an apparition of IT resources used on-demand. These assets can be used for managing the different types of services such as Workflow as a Service (WaaS), Infrastructure as a Service (IaaS), Network as a Service (NaaS), Platform as a Service (PaaS), Storage as a Service (StaaS) Software as a Service (SaaS), and Data as a Service (DaaS) [3,4,5,6]. Cloud computing also allows anyone to provision services, virtual hardware, and runtime environments with a credit card. However, with newly developed technology, several issues have to be addressed in cloud computing such as dynamic resources provisioning, virtualization technologies and large computing infrastructure for cloud service providers (CSPs), availability and storage for large data processing, protection, and confidentiality of resources, legal issues arise in different countries and losing of data [2, 6, 7]. Some researchers and scientists utilize the CSP for computation-intensive applications and running large-scale data by workflow applications.

Workflow is a specific model used for scientific application in various domains having dependent and communicating components [8]. Generally, a workflow application is modeled by using Directed Acyclic Graph (DAG), having a node-set representing tasks and an edge set with the dependencies among the tasks using the directed edges between them. Workflow allocation faces several challenges due to its dynamic nature and heterogeneity as well as searching for suitable resources of geographical distribution to construct the allocation decision while meeting optimization of the Quality of Service (QoS) parameters in a cloud computing environment. The workflows are used in several applications from different domains like genomics, earthquake analysis, gravitational waves detection, astronomy, healthcare, project planning, chemical reaction, and supply chain management. Since a huge amount of data is processed in cloud computing daily so the task allocation mechanism is more important and should be computed efficiently. Workflow’s task allocation is one of the most common application models, particularly in designing, business plans, and logical fields which has been directed towards workflow task allocation. Therefore, many researchers address the workflow tasks allocation problem for many aspects such as computational time minimization [9,10,11,12,13,14,15], minimum budget assurance [16, 17], least energy consumption [18, 19], improving the throughput and server performance [20, 21] and employing security measures [22,23,24,25,26,27,28,29,30,31,32] in heterogeneous and other efficient computing [33, 34] for single workflow. Further, the work has been also reported for multiple workflows allocation to improve the turnaround time, response time and flowtime [35,36,37,38,39,40,41,42,43], budget [43, 44], and energy [45, 46], by aggregating the batch of workflows prior to allocation. In workflow allocation, precedence constraints (execution order) management is one of the challenging issues. Precedence constraints in workflow tasks are preserved by various methods such as ranking methods [11], and level attribute methods [10, 38, 39]. In recent times, we can see that many researchers have been working to ensure the security constraints in the IaaS cloud and the trust of cloud users so that their information and applications are protected and managed effectively. However, the creation of ad-hoc security solutions, targeting a very small part of the whole problem makes a fair and sound evaluation of the state of the art. At this point, we start from the view that the cloud computing paradigm can be fully exploited only if the contributions of cloud users and CSPs for security constraints are made wider by improving their trust. As a result, software security assurance mechanisms improve the confidence level of cloud users and cloud transparency so that the CSPs behave as expected [47]. The standard software security assurance is defined with the line and the assurance of cloud security is defined to gain reasonable confidence that applications and/or infrastructure will reliably demonstrate more than one security constraint, and process performs as expected despite attacks and failures [48]. Since assurance is an extensive notion in a cloud environment than security for any type of workflow applications, it consists of methodologies for collecting and validating proof supporting security constraints. Moreover, various challenging works have been proposed for secure workflow allocation only for a single workflow [22,23,24,25,26,27,28,29,30,31,32] but lagging for multiple workflows. So, emergent work requires exploiting the process of security services for multiple workflow applications to defend security-critical applications from threats in the IaaS cloud where batch mode processing is necessary. In addition to security constraints in the cloud user request will increase the security overhead (in terms of time), which turns the turnaround time, flowtime, and operational cost of use increments [49] but reduces the risk or failure probability [24, 28].

In this paper, a security-prioritized multiple workflow allocation (SPMWA) model is proposed by integrating the security-prioritized mapping scheme for Infrastructure-as-a-Service cloud computing environment. It is expected that incorporating a security-prioritized allocation scheme under precedence constraints will enhance the performance of workflow processing in risk-prone environments. SPMWA gives more priority to the tasks having high-security demands to get allocated onto the more trustworthy virtual machines during allocation to minimize the failure probability of the system. The contributions of the proposed model are given below as follows:

• A Security Prioritized Multiple Workflows Allocation (SPMWA) model is proposed by incorporating a security prioritization scheme in workflow task allocation to minimize the failure probability of the system for the cloud computing environment.

• A security model is introduced to estimate the failure probability of the system. This model also calculates the total number of task failure to assess how often tasks with a given security requirement end up being allocated on the VMs exhibiting insufficient trust.

• Workflows are partitioned in accordance to depth level to maintain precedence constraints. Communication requirements among the workflow tasks are estimated by considering the edge weights and machine distances.

• An idle gap reduction policy is employed to the utilization of the idle gaps generated during the allocation process by accommodating the successor tasks from the next partitions.

• We expect that integrating such security measures would aid in designing a more robust workflow task allocation model for networked and high security-sensitive applications.

• The experimental results of SPMWA are compared with state-of-the-art workflow models from the literature. For this, we have taken two multiple workflow allocation strategies namely sequential-based strategy and merge-based strategy [35]. These strategies and security prioritized allocation are incorporated in HEFT [11] to develop two versions of Security Prioritized Multiple workflow allocation (SPM) models, namely SPM1 (Merge-Based) and SPM2 (Sequential-Based) respectively. For performance comparison, LBSIR [39] and HEFT [11] have also been included.

• The performance evaluation of the proposed model has been carried out on random multiple workflows and real-world scientific application graphs namely Montage [50], CyberShake [50], and LIGO [51].

• The proposed model can be used in many emerging security-sensitive domains such as batch mode transaction processing, chemical reaction, supply chain management, project management, and Pegasus project for some other scientific workflow applications.

The basic structure of the paper is as follows: Sect. 2 presents the standard and current literature review related to the work. Section 3 describes the system model for the proposed methodology. Section 4 describes the proposed model design with an algorithmic template, a simple illustration, and a time complexity analysis. The performance evaluation for the proposed work with experimental results is discussed in Sect. 5. The conclusion and future work are presented in Sect. 6.

2 Related work

Workflow allocations have been a common research topic in the recent computing environment for decades and have been built together with changes in technology. In the last few years, most of the research has been engrossed in workflow allocation problems using DAG heuristics [8, 11]. The mapping of workflow allocation problems is well-established NP-complete [52]. Consequently, various heuristic algorithms have been developed to achieve sub-optimal solutions for resource allocation in the cloud environment. Here, some reported works deal with independent task allocation considering VM placement [53], cost-effective task allocation [54], security-aware task allocation [55,56,57], etc. On other hand, many other models have presented the mechanism for addressing the allocation of dependent communication workflow tasks. In this section, the various models are further categorized into single workflow allocation [9,10,11,12,13,14,15,16,17,18,19], security-aware workflow allocation [22,23,24,25,26,27,28,29,30,31,32], and multiple workflow allocation models [35,36,37,38,39,40,41,42,43,44,45,46].

2.1 Single workflow allocation

In single workflow allocation, only one DAG is represented by task mapping onto parallel resources. The most common DAG-based scheduling is designed for a single workflow on heterogeneous distributed systems such as [9,10,11,12,13,14,15,16,17,18,19]. Dynamic-Level Scheduling (DLS) [9] is one of the first algorithms that find the availability of resources and thus allow the task to be scheduled onto the current busy resource. DLS does not guarantee the minimum processing time for a task. Furthermore, it also does not attempt to idle time gaps between two tasks on the same resource in contrast to other more current algorithms. Levelized Minimum Time (LMT) algorithm [10] is very simple and based on the precedence level of tasks onto the resource having the lowest processing time for a heterogeneous distributed system. The CPOP [11] algorithm attains better allocations than LMT and is similar to DLS with lower time complexity. The main characteristic of CPOP is the workflow of all the tasks that belong to the critical path assigned to a single resource. The HEFT [11] is one of the best DAG list scheduling algorithms, as it has quadratic time complexity. This algorithm aims to reduce the time complexity and schedule length. The modified HEFT has also been proposed to reduce processing time in a cloud computing environment [12]. Other versions of HEFT have also been proposed, such as Predict Earliest Finish Time (PEFT) [13], Communication aware Earliest Finish Time (CEFT) [14], and Dependency-ratio Bundling Earliest Finish Time (DBEFT) [15] to reduce the schedule length. PEFT algorithm defines the task priority based on the optimistic cost table. PEFT takes the assurance of task execution in minimum processing time. CEFT algorithm is based on the task duplication heuristic using communication ratio having task execution order as according to upward rank. DBEFT is also list-based task duplication scheduling to reduce communication costs. DBEFT improves the scheduling length ratio over the PEFT, CEFT, and HEFT. Some of the work has been proposed for multi-objective workflow allocation reducing the makespan and economic cost, [16, 17], and optimizing time and energy [18, 19].

2.2 Security-aware workflow allocation

Security plays an essential role in e-commerce and digital transaction processing systems. In the field of distributed information-sharing networks, significant work considering security constraints [22,23,24,25,26,27,28,29,30,31,32] has been reported in the heterogeneous distributed environment like grid/cloud computing to share and process the resources with trustworthy contributing peers. The authors presented a task allocation strategy with security constraints and the deadline for parallel applications [22] with the objectives of optimizing security parameters and processing time. However, it is implemented on homogeneous clusters. In [23], the authors present the trust-based allocation model for the scientific workflow to improve the stability of the schedule. In [24], authors have developed the security-driven scheduling (SDS) model for heterogeneous distributed systems to optimize the makespan, speedup, and risk probability. SDS introduces task priority allocation on the suitable processor using estimated security overhead. The strategy presented in [25] namely Cloud-DLS incorporates dynamic trust-based task allocation in the DLS algorithm in the cloud environment. The objective of Cloud-DLS is to assure the execution of the task and minimize the processing time. In [26], the authors have proposed a trust service-oriented workflow allocation (TMOWS) model to minimize the execution time and cost simultaneously in a cloud environment using fuzzy member functions. TMOWS meets the security demands of the users or other constraints with balance factors. In [27], the authors model maintains the reliability of services. It avoids discrete events, and workflow application failure between the direct and recommended trust. It also found the best solution and concurrently satisfied deadline conditions. The work in [28] presents a novel security-sensitive workflow allocation with a task duplication (SOLID) scheme. SOLID has been developed having three features, firstly, the selection of duplicated predecessor tasks which is useful to avoid the data encryption and transmission time by delaying the start time of the task, further, defines the latest finish time of workflow’s task, and lastly, it also assures these tasks should be finished on the cheapest resources with aim of minimizes the makespan and monetary cost. In [29], trust-based stochastic workflow scheduling (TSS) is proposed to minimize the makespan with increased speedup using the TSS trust model for security estimation including both direct trust and reputation relationships. The strategy presented in [30] for security-aware workflow allocation (SAWA) is to reduce the number of failed tasks. SAWA selects the task allocation as per depth level. In [32], the authors are presenting a security-prioritized HEFT (SPHEFT) algorithm in the cloud computing environment to optimize the guarantee ratio. SPHEFT is integrated by the security requirements into the HEFT [11] algorithm by giving more priority to the tasks having a high degree of security constraints. SPHEFT creates the clusters for distinct upward rank values and then again sorts each cluster as per the security demand of the tasks. Thus, the tasks with higher security demand will get more chances to execute at first. Therefore, it will improve the guarantee ratio over the HEFT algorithm.

2.3 Multiple workflow allocation

In the multiple workflow allocation, more than one workflow task is grouped to form a batch for processing on suitable machines to achieve the desired QoS parameters. To tackle the multiple workflow allocation problems, Bittencourt and Madeira [35] have first introduced four strategies to schedule multiple workflows namely sequential-based strategy, gap search strategy, interleave strategy, and merge-based strategy. The sequential-based strategy, schedules the workflows sequentially, one after another on the available resources. The gap search strategy works the same as the first strategy but it finds the gaps between tasks already executed, and then accommodatable tasks from the workflow at hand are being scheduled into the found gaps without interfering with their starting time. Interleave strategy uses both the first and second strategies, however, the strategy schedules tasks of each workflow in turns, interleaving their tasks in the schedule of the available resources. The merge-based multiple workflow strategy merges all workflows into a single one and then schedules this resulting workflow as a single workflow. Here, a significant number of works have been proposed for multiple workflow allocation to reduce turnaround time [38, 39]. The strategy proposed in [36] aggregates multiple workflows to achieve near-optimal throughput for heterogeneous cloud computing. In [37], the authors analyze the allocation strategy for multiple workflows including two and four stages like labeling, adaptive information, prioritization, and parallel machines in the grid environment. In [38], the authors have proposed a novel approach (SLBBS) for the multiple workflow allocation problem in a computational grid environment to optimize the turnaround time. SLBBS divides the multiple workflows as per depth level and allocation of tasks is assigned on best-fit resource levelwise. Level-based Batch scheduling Strategy with Idle slot Reduction (LBSIR) [39] strategy reduces the drawbacks of SLBBS by incorporating an idle slot reduction policy. The work reported in [40], concurrently executes multiple workflows using a rescheduling algorithm and dynamic task rearrangement to exploit task allocation flexibility under precedence constraints. In [41], the authors present the cluster-based allocation strategy for multiple workflow applications with soft deadlines to achieve the quality of schedule in terms of fairness and execution time. In [42], the authors present deadline budget workflow allocation to optimize the time and cost in the cloud environment. Some of the work has been proposed for multi-objective of multiple workflow allocation reducing the makespan and economic cost [43, 44] and to optimizing time and energy [45, 46].

In the literature, various approaches have been proposed for solving single workflow [9,10,11,12,13,14,15,16,17,18,19] and multiple workflows [35,36,37,38,39,40,41,42,43] allocation problems in heterogenous distributed systems. However, many cloud-based workflow applications need to be processed in batch mode to enhance the systems performance. Therefore, to develop superior multiple workflow allocation models is a requirement in various domains. Further, as we see in Table 1, a significant number of approaches [22,23,24,25,26,27,28,29,30,31,32] have also been proposed for security-aware workflow allocation problems for considering only a single workflow. In the majority of the work, the task execution order is computed by the ranking method, and then the allocation of the resources is done as per the task execution order. In this scenario, high-security demand tasks with low rank may be allocated to untrustworthy machines leading to more failure in the system. But in the proposed work, workflow tasks are grouped into partitions as per depth level. In each partition, the task execution order is computed by using the security demand levels. In this way, high-security demand tasks always get allocated first and have a chance of getting higher trustable machines leading to lower failures in the system.

Table 1 A comparison of related works for workflow allocation models

Finally, in multiple workflow scenario, the models [35,36,37,38,39,40,41,42,43,44,45,46] have also been reported for cloud environments to optimize the makespan, schedule length, speedup, energy, total budget, and utilization. However, as per our knowledge, we have not found any work on multiple workflow allocation considering security constraints in the cloud environment. Therefore, this paper is the first attempt toward the allocation of the batch of workflow applications satisfying the security requirements of the workflow tasks.

3 System model

This section presents an insight into the SPMWA developed for multiple workflow allocation, representing each workflow by using DAGs. e.g., the notation used, workflows descriptions, virtual machine descriptions, security model, parameter estimation, and problem statement. The proposed model aims to produce an efficient schedule for the workflow tasks and optimizes considered parameters from the quality of service of the cloud.

3.1 Symbols used

To describe the various models, symobls, and parameters involved in the process have been listed in Table 2 as follows:

Table 2 Definition of symbols

3.2 Multiple workflow model

In this work, we consider a set of multiple workflows, $\mathcal{W}f=\left\{{\mathcal{W}f}_{i}:i=\mathrm{1,2},3,\dots \dots {N}_{\mathcal{W}f}\right\}$ and each ${\mathcal{W}f}_{i}$ has tasks set, ${\tau }_{i}=\left\{{T}_{ij}:1\le j\le {N}_{{\mathcal{W}f}_{i}}\right\}\text{.}$ Each workflow consists of tasks with parent (predecessor) and child (successor) relationships. Here, j^th task of i^th workflow (T_ij) has a set of successor tasks (Succ(T_ij)) and predecessor tasks (Pred(T_ij)). The successor tasks depend on the predecessor tasks with a communication requirement termed edge weight (e_ixy) between all possible pair of tasks. The following characteristics of multiple workflows in this work are given below:

• The batch of ${N}_{\mathcal{W}f}$ the number of compute-intensive workflows, represented by DAG.

• The number of tasks in each ${\mathcal{W}f}_{i}$ is ${N}_{{wf}_{i}}$.

• Each ${T}_{ij}{\in \mathcal{W}f}_{i}$ has an associated level attribute (l_ij).

• Precedence and dependency constraints have been handled through level attributes.

• The number of depth levels (${l}_{ {\mathcal{W}f}_{i}}$) in an i^th workflow is defined as ${l}_{ {\mathcal{W}f}_{i}}=\underset{\forall j}{\mathrm{max}} \{{l}_{ij}:\forall {T}_{ij}\in {\mathcal{W}f}_{i}\}$.

• The depth level of a batch of workflows ($\mathcal{W}f$) is defined as, $L=\underset{\forall i}{\mathit{max}}\left({l}_{ {\mathcal{W}f}_{i}}\right)$.

• The multiple workflows are divided into L partitions (d^l) as per the depth levels such that ${d}^{l}=\{{T}_{ij}:\forall {T}_{ij} \& {l}_{ij}=l\}$.

• The e_ixy is for communication between T_ix and T_iy, and it is considered in MIs.

The set of multiple workflows is presented in Fig. 1 with all associated attributes. We can see that each partition tasks are shown by using the same color e.g. (T₁₁, T₁₂, T₂₁,…,${T}_{{N}_{\mathcal{W}f}3}$), (T₁₃, T₁₄, T₂₂,….,${T}_{{N}_{\mathcal{W}f}4}$), (${T}_{1{{N}_{\mathcal{W}f}}_{1}}$, T₂₃, T₂₄,….,${T}_{{N}_{\mathcal{W}f}7}$) and (${T}_{2{{N}_{\mathcal{W}f}}_{2}}$,…,${T}_{{N}_{\mathcal{W}f}{{N}_{\mathcal{W}f}}_{{N}_{\mathcal{W}f}}}$) are at depth levels 1, 2, 3, and L depicted by using sky blue, magenta, canary, and green color respectively. Further, we can see in Fig. 1, T₁₃ is dependent on T₁₁ and T₁₂ to start its execution with edge weights, whereas the tasks are at the same precedence level within the batch of tasks. For example, T₁₁, T₁₂, T₂₁,…,${T}_{{N}_{\mathcal{W}f}3}$ can be executed in parallel.

Fig. 1

A sample multiple workflows application

3.3 Machine model

In this work, we consider a cloud computing environment having a set of n heterogeneous VMs, V = {V_k | 1 ≤ k ≤ n} interconnected via a fully connected network. The computational VM under this work with following characteristics are:

• We consider n, number of heterogeneous VMs.

• Each VM has $\mathcal{R}{\fancyscript{t}}_{k}^{l}$ due to previously assigned tasks.

• VM distances (V_kr) among the heterogeneous VMs. V_kr actually calculates the distance between V_k and V_r by finding the number of hop counts between them.

• The processing capacity (PC_k) of VMs is in MIPS.

• Once a VM has started task execution, it continues without interruptions, and after completing the execution it immediately sends the output data to all the children tasks in parallel.

• The expected time to compute matrix E_ijk is the estimated execution time of task T_ij on V_k.

The measure of communication cost depends on two parameters e_ixy between the tasks (i.e., T_ix and T_iy) and V_kr between the VMs (i.e., V_k and V_r). Suppose two tasks’ T_ix ∈ d^l and T_iy ∈ d^l−s of the workflow ${\mathcal{W}f}_{i}$ assigned on V_k and V_r respectively, is represented by ${CC}_{ixykr}^{l-s, l}$. It can be computed as [38, 39]:

$${CC}_{ixykr}^{l-s, l}=\pi \left({e}_{ixy}\times {V}_{kr}\right)$$

(1)

where π is considered as one for liner behaviour, ${CC}_{k}^{l}$ gives the total communication cost of tasks assigned on V_k at depth level l and needs communication to their predecessor tasks allocated to other VMs. This value is zero for tasks with predecessors being assigned on the same VM. In this model, this is taken as the maximum of all ${CC}_{ixykr}^{l-s, l}$ among tasks assigned on V_k due to having the possibility of parallel communication and written as

$${CC}_{k}^{l}=\underset{\forall k}{\mathit{max}}({CC}_{ixykr}^{l-s, l})$$

(2)

3.4 Security model

Security in cloud computing can be perceived as the protection mechanism against unauthorized access, use, and modification of cloud resources. To safeguard infrastructure of the cloud-based systems from security risk, a variety of rules, processes, controls, and technologies are used. The security risk is related to vulnerabilities, failure probability, and attacks or threats. The cloud environment is risk prone due to challenging security threats. Therefore, it is very crucial to provide the best-in-class security by vendors tailored for the cloud infrastructure. Thus, the cloud vendors use their own unique security standards, methods, and models to satisfy the client’s requirements. Further, cloud system security offers many benefits, including centralized security, reduced cost and administration, and reliability. In workflow execution in the IaaS cloud, a workflow management system (WMS) allocates the workflow tasks onto the secure cloud resources so that they could be executed without failures. A secure workflow system requires taking into account a variety of security services for modeling any security-sensitive applications, such as authentication, integrity, and confidentiality as discussed follows:

• Authentication: It refers to trustworthily confirming the task execution agents’ identities. Authentication, authorization, and accounting (AAA) is a security organizing module for authentication, authorization, and accounting. When a user tries to access cloud resources from CSP, then AAA verifies the user's authentication information. If the user is authenticated, then AAA verifies the user's access into the system. The authentication methods are available to fulfill the authenticated users, such as HMAC-MD5, HMAC-SHA-1, and CBC-MAC-AES [22, 24, 55].

• Integrity: Integrity services guarantee that no one can tamper or modify the data and applications while executing on the IaaS cloud. When the attacker modifies the data, the integrity of the data is compromised. Integrity can be achieved using various hash functions such as Tiger, RIPEMD-160, SHA-1, etc. [28, 55, 57].

• Confidentiality: Confidentiality is important for users to store their confidential resources in the cloud. Confidentiality is the defense against eavesdropping and other passive attacks on cloud resources. A passive attacker could disclose that sensitive information is being transferred insecurely or without encryption. Confidentiality can be achieved by using various encryption algorithms like IDEA, DES, etc. [22, 55, 57].

In authentication service, the machines are authenticated and allowed for the workflow task to process them in workflow execution. A workflow authorization model is capable of authorization in such a way that machines have access to necessary objects and synchronize the authorization flow with the workflow during execution. After this, the associated information of workflow tasks needs to be transferred among machines during processing due to communicating and dependent tasks. Hence, it is the service provider's responsibility to make these transfers confidential and unaltered to maintain confidentiality and integrity, respectively. The task failure could result from the security threat or inaccessibility from the security-imposed barricade in the cloud system. In the proposed SPMWA model, authentication service is considered during secure workflow task allocation. Authentication is the initial process which allows entering the authorized machines to satisfy the security requirement for execution of the workflow tasks from the various users. In this way, the cloud system can prevent the tasks failure during the workflow task’s executions. The authentication must be validated to protect the data transfer from security attacks to a certain extent according to its service level requirement. For task T_ij having a security level $({SL}_{ij}^{a})$ in the aspect of authentication of m_i^th method used, an authentication method providing a higher security level must be applied if the task is outsourced to the cloud such as ${SL}_{ij}^{a}\le {Sl}_{{m}_{i}}^{a}$ where ${Sl}_{{m}_{i}}^{a}$ represents the security level provided by the m_i^th authentication method (m_i ∈ {0, 1, 2, 3}). We also assume that, ${{\mu }_{{m}_{i}-1}^{a}<\mu }_{{m}_{i}}^{a}, \forall {m}_{i}\in \{0, 1, 2, 3\}$ without loss of generality as shown in Table 3, where ${\mu }_{{m}_{i}}^{a}$ is the authentication time overhead of m_i. For task T_ij, the optimal authentication method that satisfies the security level requirement with the least amount of time overhead is that which meets the following criteria ${{Sl}_{{m}_{i}-1}^{a}<SL}_{ij}^{a}{\le Sl}_{{m}_{i}}^{a}$. These authentication methods are shown in Table 3.

Table 3 Authentication methods for authentication services [55, 58]

Each authentication method is assigned a security level (${SL}_{mi}^{a})$, in agreement with the concert. If it is assigned to 1 then CBC-MAC-AES method will be used. SLs for the other two methods can be computed as per Eq. (3) where ${\mu }_{{m}_{i}}^{a}$ is the performance of the m_i^th authentication method i.e., 0 ≤ m_i ≤ 3.

$${\text{SL}}_{{m_{i} }}^{a} = \mu_{{m_{i} }}^{a} /163;\,0 \le m_{i} \le 3$$

(3)

Assume that SO_ijk is the security overhead to fulfill authentication service for workflow tasks and T_ij is a function security level. The following characteristics related to the security of multiple workflows and VMs are given below:

• Each T_ij has a SD_ij that needs to be satisfied on VMs.

• SD_ij varies in the range from very high to very low, representing their priority, such that SD_ij ∈ {0.0, 0.1, 0.2,……,1.0}. For example, SD_ij = 1.0, SD_ij = 0.5, and SD_ij = 0.1 are very high, average, and low-security demands respectively.

• Each virtual machine (VM_k) has a trust level (TL_k) normalized in the range [0, 1].

• Trust level of a cloud system (TL_CS) is defined as the trust level of the highest trustable VM such as ${TL}_{ CS}= \underset{\forall k}{\mathit{max}}\{{ TL}_{k}\}$.

• The range of failure coefficient, λ_k ∈ (0.1–5.5).

Now, in the allocation process, each task from the cloud users requiring SD_ij has been mapped onto fit VMs. The security overhead of T_ij on V_k (SO_ijk) with security demands can be estimated as per Eq. (4).

$$SO_{{ijk}} = \left\{ {\begin{array}{*{20}c} {\mu _{{m_{i} }}^{a} (SD_{{ij}} - TL_{k} )/PC_{k} ;} & {\left. {SD_{{ij}} > TL_{k} } \right.} \\ {0;} & {\left. {SD_{{ij}} \le TL_{k} } \right.} \\ \end{array} } \right.$$

(4)

SD_ij is a security demand of T_ij that can be specified security levels by the workflow tasks. TL_k is the trust level of V_k for fulfilling the security demand of the tasks. ${\mu }_{{m}_{i}}^{a}$ is a time overhead considered by the authentication methods [24, 55, 58] to fulfill the security levels of authentication methods. In this workflow risk analysis model, we have to consider failure probability as a function of SLs and the distribution of failure rate for any fixed time interval following the Poisson probability distribution. Accordingly, the workflow’s task failure probability for combined security services onto a particular VM can be signified by an exponential distribution as follows [24, 28,29,30].

$$F{\fancyscript{p}}_{{ijk}} = \left\{ {\begin{array}{*{20}c} {1 - e^{{ - \lambda _{k} \left( {SD_{{ij}} - TL_{k} } \right)}} ;}\, {\left. {SD_{{ij}} > TL_{k} } \right.} \\ {0;} {\left. {SD_{{ij}} \le TL_{k} } \right.} \\ \end{array} } \right.$$

(5)

In cloud computing, ${\lambda }_{k}$ is taken as a failure coefficient, and it varies over VMs. The negative exponent shows the failure probability raised by the difference SD_ij − TL_k.

3.5 Problem statement and parameter estimation

In this section, the workflow allocation problem and parameter estimation of performance metrics for the proposed model have been discussed in detail. In multiple workflows allocation problem, a set of workflows (Wf) needs to map on a set of n heterogeneous virtual machines (V) in an IaaS cloud computing environment to optimize the number of task failure and failure probability of workflow systems satisfying various constraints. A pictorial representation of the same problem is presented in Fig. 2. Here, multiple workflows are submitted to the cloud from different users. Security prioritized workflow allocator is responsible for capturing all required information and performs high security prioritized workflow tasks allocation effectively. VM manager manages and offers the set of VMs having required objects, i.e., trust level, computing capacity, etc. The physical machine comprises clusters, servers, supercomputers, and the fundamental physical computing resources that make up a cloud infrastructure. Through virtualization, users can use a virtualized version of machines of the physical machine without any management overhead.

Fig. 2

Multiple workflow allocation problem

The problem statement can be represented by the mapping function, f: $\mathcal{W}f$ × V → {1, 0}, producing an allocation schedule such that.

Minimize $F{\fancyscript{p}}$, NTF subject to constraints:

• 1.
  $$\sum_{j=1}^{{N}_{{wf}_{i}}}Allocation [i][j][k]=P;\mathrm{ where, } 0\le P\le {N}_{{wf}_{i}}$$
• 2.
  $$\sum_{k=1}^{n}Allocation [i][j][k]=1$$
• 3.
  $$\sum_{i=1}^{{N}_{wf}}\sum_{j=1}^{{N}_{{wf}_{i}}}\sum_{k=1}^{n}Allocation [i][j][k]=\sum_{i=1}^{{N}_{\mathcal{W}f}}{N}_{{wf}_{i}}$$
• 4.
  $${ST}_{ijk}\ge max\left\{FT\left[pred\left({T}_{ij}\right)\right]\right\}$$

The SPMWA model aims to optimize the failure probability and number of task failure as per the requirements of the cloud users. Some of the main parameters considered in the study that is given as follows:

The Expected Time to execution (E_ijk) can be written by using Eq. (6) as follows:

$${E}_{ijk}=\frac{{Wl}_{ij}}{{PC}_{k}}$$

(6)

Now, the allocation of tasks from various depth levels are assigned on the fit virtual machine using the proposed SPMWA model explained in Sect. 4. The Finish Time (FT_ijk) of T_ij on each V_k is computed by using Eq. (7) as follows:

$${FT}_{ijk}={ST}_{ijk}+ {E}_{ijk}+{SO}_{ijk}$$

(7)

where ST_ijk is the Start Time of T_ij on V_k to be assigned task and can be taken as the FT_ijk of the last task assigned on that virtual machine. After the allocation of all tasks from the specified partition, i.e., ${\forall T}_{ij}\in {d}^{l}$, the processing time $\left({\mathcal{P}\fancyscript{t}}_{k}^{l}\right)$ on V_k at lth level has been estimated. It is the summation of the difference between the finish time and start time of the tasks of specified partition on VMs and can be written as

$${\mathcal{P}\fancyscript{t}}_{k}^{l}= \sum_{{V}_{k }\leftarrow \forall {T}_{ij}\in {d}^{l}}\left({FT}_{ijk}-{ST}_{ijk}\right)$$

(8)

${\mathcal{R}\fancyscript{t}}_{k}^{l}$ is the initial ready time of each VM. It is the previous workloads assigned on them and affects only task allocation for the first level only. Total processing time on V_k $\left({T\mathcal{P}\fancyscript{t}}_{k}^{l}\right)$ are the sum of initial ready time, total communication cost, and processing time on the V_k as presented by using Eq. (9)

$${T\mathcal{P}\fancyscript{t}}_{k}^{l}=\left\{\begin{array}{c}R{\fancyscript{t}}_{k}^{l}+ {\mathcal{P}\fancyscript{t}}_{k}^{l} ;\, if\, {T}_{ij}\in {d}^{1}\\ {CC}_{k}^{l} + {\mathcal{P}\fancyscript{t}}_{k}^{l};\, otherwise\end{array}\right.$$

(9)

After allotment of $\forall {T}_{ij}\in {d}^{l}$, few idle gaps are left on some VMs. The idle gap list $I\fancyscript{g}^l= \left\{ {I\fancyscript{g}_{k}^{l} {\text{:}}\fancyscript{g}_{k}, \forall {\text{~k}}} \right\}$ is maintained on the respective VM in various depth levels. The idle gap size (${I\fancyscript{g}}_{k}^{l}$) at depth level l on V_k can be computed as

$${I\fancyscript{g}}_{k}^{l}=\underset{\forall k}{\mathit{max}}\left({T\mathcal{P}\fancyscript{t}}_{k}^{l}\right)-{T\mathcal{P}\fancyscript{t}}_{k}^{l}$$

(10)

After this, succ(T_ij) from the next depth level partition (d^l+1) are selected and suitable tasks are accommodated within the idle gaps generated as per idle gap reduction method presented in Algorithm #3. Further, ${T\mathcal{P}\fancyscript{t}}_{k}^{l}$ is updated due to some additional assignments on VMs. The updated total processing time ${({T\mathcal{P}\fancyscript{t}}_{k}^{l})}^{u}$ on VM can be written as

$${({T\mathcal{P}\fancyscript{t}}_{k}^{l})}^{u}={T\mathcal{P}\fancyscript{t}}_{k}^{l}+ \sum_{\forall {T}_{ij}\in {d}^{l+1}}^{L}{E}_{ijk}^{net}$$

(11)

where ${E}_{142}^{net}$ is the net processing time of successor task which is inserted into idle gaps i.e., ${E}_{ijk}^{net}= {E}_{ijk}+{SO}_{ijk}+{CC}_{ixykr}^{l-s, l}$. Now, Makespan is the total processing time taken for the submitted batch of workflows. It is estimated as the addition of queuing time and summation of ${\mathrm{max}({T\mathcal{P}\fancyscript{t}}_{k}^{l})}^{u}$ for all depth levels and written as

$$Ms=Qt+\sum_{l=1}^{L}\underset{\forall k}{\mathit{max}}{\left({T\mathcal{P}\fancyscript{t}}_{k}^{l}\right)}^{u}$$

(12)

where Qt is the Queuing Time which is estimated as the average waiting time of the multiple workflows in the global queue as

$$Qt=\left\{\begin{array}{c}\frac{1}{\mu -\Gamma };\, if\, \beta \le {Q}_{u}\\ \frac{1}{\mu -\Gamma }\left(\frac{\beta }{{Q}_{u}}\right);\, if\, \beta \ge {Q}_{u}\end{array}\right.$$

(13)

where β is the sum of the workloads of all workflow tasks. The virtual machines may not be available to the system when being infected by malicious attacks or intrusions. Many parallel workflows are executed in the risk-prone environment of the cloud computing system. Therefore, it is essential to have some guaranteed security services to execute the workflow tasks with negligible failures. If task failures happen, then it is desired that the number of task failure should be insignificant to prove the security of the system. Thus, the number of task failure (NTF) is an important QoS parameter to assess how often tasks with a given security requirement being allocated on the VMs exhibit insufficient trust. Also, the failure probability of the workflow system needs to be estimated as one of the main targets. Hence, we do evaluate the proposed SPMWA on security metrics such as the number of task failure and failure probability of the entire batch of workflows in the cloud system. Here, the aim is to ensure that all the tasks must be satisfied on trustable VMs. Yet, in some cases, it is also a possibility to assign some tasks on untrustworthy VMs. So, we defined a task failure set, T_failure = {T_ij: V_k ← T_ij such that SD_ij > TL_k, i.e.,$T_{failure} \subset \cup \tau_{i}$, i = 1, 2,…N_wf}, where on allocation T_ij assigned on insufficient trustworthy VMs. Thus, total tasks failures can be determined as the size of the set of failure tasks, o(T_failure) by using Eq. (14) as follows:

$$NTF= o({T}_{failure})$$

(14)

The failure probability is the performance metric to assess the rate of failure tasks assigned on a specified virtual machine that could result from the inaccessibility of a security-imposed barricade or severe attack. Thus, the task failure probability of T_ij assigned on V_k can be computed as:

$$F{\fancyscript{p}}_{\left({T}_{ij}\right)}=\sum_{k=1}^{n}{z}_{ijk}* F{\fancyscript{p}}_{ijk}$$

(15)

where z_ijk is the assignment vector, indicating whether T_ij is assigned on V_k or not, such as

$${z}_{ijk}=\left\{\begin{array}{c}1,\, {T}_{ij}\, is\, assigned\, to\, {V}_{k} \\ 0, \, otherwise\end{array}\right.$$

(16)

The failure probability of the cloud system ($F\fancyscript{p})$ for a considered batch of the workflow ($\mathcal{W}f$) executed in a risk-prone environment (attack or failure). $F\fancyscript{p}$ can be computed as:

$$F{\fancyscript{p}} = 1 - \prod\limits_{{T_{{ij}} \in \tau }} {\left( {1 - F{\fancyscript{p}}_{{\left( {T_{{ij}} } \right)}} } \right)}$$

(17)

NTF, $F{\fancyscript{p}}$, and Ms are used as performance metrics to evaluate our proposed security prioritized multiple workflow allocation model presented in Sect. 4.

4 Security prioritized multiple workflow allocation model

In this section, a security prioritized multiple workflow allocation (SPMWA) model with precedence constraints is presented for a cloud computing environment. In this model, more priority is given to high-security demand workflow tasks at allocation, and the main target is to minimize the failure probability of the IaaS cloud system during processing. Workflow tasks are allocated in accordance to a level attribute. After the allocation of each partition, idle gaps are eliminated by inserting suitable tasks from the next partition. An algorithmic template for SPMWA is presented in Algorithm #1.

Firstly, the batch of multiple workflows is divided into depth levels before the allocation as mentioned already in Sect. 3.2. In this phase, the allocation of workflow tasks from each partition is assigned in sequential mode onto the set of virtual machines. In each partition, the allocation preference is given to the higher security demand tasks followed by lower ones and assigned to the fit VMs. The fit VM for a specified task is the VM which satisfies its security demand against the trust level offered and also takes the least finish time to execute it. The allocation of task selection from each partition is accomplished as follows:

• Divide the batch of multiple workflows into partitions (d^l) as per depth level. In d^l list, tasks have the same level attribute and can be executed in parallel.

• In each partition, clusters are created by grouping the tasks having the same security demand (SD) ${C}_{SD}^{l}=\{{T}_{ij} : \forall {SD}_{ij}=SD\}$ where SD ∈ {0.0, 0.1, 0.2…1.0}. In this way, at most, eleven clusters can be formed in each partition by grouping the tasks of the same security demands. For allocation, the clusters are selected in higher to lower order of security demand.

• Then, sort each cluster tasks as per the workloads in descending order as shown in Algorithm #1 in step 4. Workflow’s tasks are selected one by one from the cluster. In this way, largest tasks are allocated first.

• Select ${T}_{ij}\in \boldsymbol{ }{C}_{SD}^{l}$ form the sorted cluster, then find V_Fit by Call VM Selection () as per step 10 in Algorithm #1. Algorithm #2 selects the best fit machine, V_Fit, and returns the status of tasks, Fail equals to 0 or 1. After this NTF is updated as per step 13. Further, the set of failed tasks (T_failure) is updated as steps 14–17.

• After assignment of $\forall {T}_{ij}\in {d}^{l}$, Compute the value of ${CC}_{k}^{l}$ and ${\mathcal{P}\fancyscript{t}}_{k}^{l}$ as per Eq. (2) and Eq. (8) respectively. Consequently, the communication cost will be zero for the first level of workflow task because it has no parent task.

• After completion of all tasks in each d^l, find the idle gap list and reduce the idle gap by inserting suitable tasks into them by Call Idle Gap Reduction () in Algorithm #1. The procedure of idle gap reduction is explained in Algorithm #3.

• Finally, ${CC}_{k}^{l}$ and ${({T\mathcal{P}\fancyscript{t}}_{k}^{l})}^{u}$ are computed after the allocation of tasks in the idle gap list as per Eq. (2) and Eq. (11) respectively. Finally, a schedule will be generated and QoS parameters are computed.

4.1 VM selection

In this part, the VM selection procedure is presented for the task at hand for mapping. The VM selection aims to find a fit VM for each task assignment that satisfies the security demands of tasks against the trust levels of VMs. Initially, the security requirement of the task to be assigned (SD_ij) is compared to the trust level of the cloud system, i.e., TL_CS = max (TL_k, k = 1,2,…,n). The VM selection procedure works into two cases as follows:

Case 1 (If SD_ij ≤ TL_CS): It implies that the cloud system has a set of VMs having trust levels greater than or equal to the security demand of the task. These trustable VMs can fully satisfy the security demand of the task and can execute it without any risk of failure. Further, the best fit virtual machine (V_Fit) is the VM which is a fully trustworthy machine offering the least finish time for the task among all fit VMs (step 4, Algorithm #2). The VM selection procedure returns V_Fit and that can execute the task without any risk or zero failure probability as the requirement is satisfied fully. Hence, the variable Fail returns 0 indicating the task is not failed. Thus, in this case, all the task is assigned onto a fully trustworthy machine as shown in Algorithm #2 as per steps 2–5.

Case 2 (If SD_ij > TL_CS): The cloud system is capable enough of providing the services on demand with elasticity. It implies that the cloud is able to supply the required trustable resources for processing irrespective of the place, time, and amount demanded. Yet there may be some cases, often not happen, when the task’s security demand is not fully satisfied against the trust level of the VM available. It means that the cloud system has a set of VMs having a trust level lesser than the security demand of the task. In this scenario, our SPMWA model finds the highest trustworthy machine from the cloud system (max TL_CS). In such a special case, this is rarely happen at the cloud platform as cloud systems are committed to supply the needed resources on demand. Then, the SPMWA model finds the highest trustworthy VM in the system (steps 6–13, Algorithm #2). For this, the procedure tries to find the VM against the security demand of the tasks by decrementing it by one level. This process is continued till the updated SD_ij reaches TL_CS so that, the task could be assigned on the highest trustworthy available VM (steps 9–11, Algorithm #2). In this way, the failure probability can be minimized to a possible minimum value. The task is considered partially failed (Fail is set to 1) and counted as task failure.

Thus, the SPMWA model tries to assign each task to the highest trustworthy machine in the cloud system so that the failure probability is either zero or minimal. All the number of task failure (NTF) are partially failures, not fully failures. The same stepwise VM selection procedure is presented in Algorithm #2.

4.2 Idle gap reduction

The idle gap reduction begins after the allocation of all workflow tasks on fit VMs at each partition. The idle gaps on VM at any given depth level are reduced by inserting the suitable tasks from the next level succ(T_ij). For better visualization, we have shown in the illustration Sect. 4.1 with Fig. 4. At first, after allocation of all workflow tasks at each level computes $max\left({T\mathcal{P}\fancyscript{t}}_{k}^{l}\right)\in {d}^{l}$. Now, determine the idle gap list, ${I\fancyscript{g}}^l = \left\{ {I\fancyscript{g}_{k}^{l} {\text{:}}\fancyscript{g}_{k} ,\forall {\text{~k}}} \right\}$ at each level as per Eq. (10). For insertion of tasks from next levels/partitions, i.e., ${T}_{ij}\in {d}^{l+1}$, we need to find out the start time of to be inserted tasks, the finish time of their predecessor, and the communication cost between them. To find out the best fitted idle gap for the tasks at hand are being allocated, two conditions must satisfy, (i) The start time of inserted tasks should be greater than or equal to the finish time of their predecessors i.e., ST_ijk ≥ FT_ixk (ii) The gap size must be greater than or equal to the expected time to complete the inserted task such that ${g}_{k} \ge {E}_{ijk}+{SO}_{ijk}+{CC}_{ijxkr}^{l, l+1}$ as per steps 5–8 in Algorithm #3. Idle gaps (${I\fancyscript{g}}^l_k$) has been reduced by allocating the task with fulfilling the security demand and size of the task from the successor level so that these tasks may be adjusted in the gaps onto V_Fit. The workflow tasks have been inserted to preserve the precedence constraints of the multiple workflows. For any ${Ig}_{k}^{l}$, the neighboring tasks in the workflow tasks assigned to that VM are considered so that communication overhead can be minimized by the insertion. This phase avoids VMs idle gaps as much as probable, resulting in optimizing the makespan of the system. The idle gap reduction phase algorithm is presented in Algorithm #3.

4.3 An illustrative example

An illustration has been demonstrated for a better understanding of the SPMWA model. We have considered a virtual machine set with three instances, V = {V₁, V₂, V₃} for illustration purposes. The various characteristics namely, processing capacities, ready time, trust levels, failure coefficients, and machine distances associated to the cloud VMs are presented in Table 4. Now, the trust level of a cloud system, TL_CS = max(TL₁, TL₂, TL₃) = max(0.4, 0.6, 0.7) = 0.7.

Table 4 The heterogeneous VMs parameters

Further, we consider two workflows, ${\mathcal{W}f}_{1}$ and ${\mathcal{W}f}_{2},$ consisting of 8 and 7 tasks, respectively. And depth levels are 4 and 3 respectively, as shown in Fig. 3. The corresponding edge weights (inter-task communication) between tasks have been shown by edge labels in Fig. 3. For example, 3.4 is the edge weight (e₁₁₃) between the tasks T₁₁ and T₁₃ of ${\mathcal{W}f}_{1}$. Now, the workflow tasks attributes, such as level attribute (l_ij), workload (Wl_ij), and security demand (SD_ij) of each task are presented in Table 5. The information regarding the workflow’s tasks have been shown for the three VMs in Table 5. Let ${\mu }_{{m}_{i}}^{a}$= 90 ms, service rate ($\mu$) = 0.05, arrival rate (Γ) = 0.03, and queue unit (Q_u) = 10,000 MIs. The queuing time (Qt) = 50 for the batch of workflows which is computed by using Eq. (13).

Fig. 3

A sample of two multiple workflows application

Table 5 The workflow tasks information

The expected time to compute (E_ijk), security overhead (SO_ijk), and failure probability ${(F{\fancyscript{p}}}_{ijk})$ of each task are computed onto all VMs as per Eqs. (6), (4), and (5), respectively. And the same values are presented in Table 6.

Table 6 Computed values of E_ijk, SO_ijk, and ${F\fancyscript{p}}_{ijk}$ for the tasks on respective VMs

At first, the SPMWA divides the workflows shown in Fig. 3, into the four partitions (d^l) as (T₁₁, T₁₂, T₂₁, T₂₂, T₂₃), (T₁₃, T₁₄, T₁₅, T₂₄), (T₁₆, T₂₅, T₂₆, T₂₇) and (T₁₇, T₁₈), according to depth levels 1, 2, 3, and 4 respectively. Afterward, in each partition, the various clusters with distinct security demands of the workflow tasks are created. Then, each cluster is sorted as per Wl_ij of the tasks in descending order. For example, the first partition’s tasks have three distinct security demands i.e., 0.8, 0.7, and 0.4. So, three clusters are created from the first partition (d¹), namely,${C}_{0.8}^{1}, {C}_{0.7}^{1},$ and ${C}_{0.4}^{1}$ and sorted according to their workloads. Thus, the remaining partitions are also treated in a similar manner. In allocation, SPMWA gives higher priority to the clusters consisting of high-security demand tasks. It implies that the higher-level clusters are allocated prior to the lower ones. In any cluster, the tasks allocation order is maintained as per the workload by sorting them in descending order. So, the larger task gets assigned before the smaller tasks in the specified cluster. As we know that SPMWA follows the level/partition-wise tasks allocation policy. Hence, the complete allocation order of clusters in the partitions and their associated tasks within the specified clusters are presented as follows:

$$d^{1} = \{ C_{0.8}^{1} = \{ T_{11} \} ,\,C_{0.7}^{1} = \{ T_{21} ,T_{23} \} ,\,C_{0.4}^{1} = \{ T_{22} ,\,T_{12} \} \}$$

$$d^{2} = \{ C_{0.9}^{2} = \{ T_{13} \} ,\,C_{0.6}^{2} = \{ T_{24} ,\,T_{14} \} ,\,C_{0.5}^{2} = \{ T_{15} \} \} ,$$

$$d^{3} = \{ C_{0.7}^{3} = \{ T_{27} ,\,T_{16} \} ,\,C_{0.6}^{3} = \{ T_{26} \} ,\,C_{0.4}^{3} = \{ T_{25} \} \} \,{\text{and}}$$

$$d^{4} = \{ C_{0.7}^{4} = \{ T_{18} \} ,\,C_{0.4}^{4} = \{ T_{17} \} \}$$

At first, the ready time $({\mathcal{R}\fancyscript{t}}_{k})$, i.e. (24, 10, 20) acts as the start time (ST_ijk) of T_ij on respective VMs as shown in Table 7. Now, the cluster from the first partition (d¹) with the highest security demand i.e., ${C}_{0.8}^{1}$={T₁₁}, is selected for allocation having only one task. As we can see in Table 7, the finish times of T₁₁ on VMs are computed by using Eq. (7). Now, T₁₁ has security demand, (SD₁₁) = 0.8 and the cloud system can offer maximum trust level, TL_CS = max (0.4, 0.6, 0.7) = 0.7. As, SD₁₁ > TL_CS, it means the cloud system has no VM which can completely satisfy SD₁₁ and can execute it risk-free. Therefore, T₁₁ decrements its security demand by one level to approach its value to the highest trustable VM in the system i.e., TL₃ = 0.7 (steps 7–9, Algorithm #2). Algorithm #2 returns V_Fit = V₃ and Fail = 1 for T₁₁. While we see that V₂ offered the least finish time, FT₁₁₂ = 16. Yet, SPMWA determines V₃ as the fit machine for T₁₁ by giving priority to the security requirement over completion time, (i.e., TL₃ = 0.7 is higher than TL₂ = 0.6). Thus, T₁₁ is assigned on V₃ starting from ST₁₁₃ = 20 and finishing at FT₁₁₃ = 22.60. The task failure set is updated by including T₁₁, T_failure = {T₁₁} (step 15, Algorithm #1). Here, T₁₁ assignment is considered as the allocation with task failure (F) having failure probability 0.1393 computed as per Eq. (5). The start time and finish time of T₁₁ are presented without a rectangle box. In Table 7, the numerical values of the start and finish time of V_Fit (best fit VM for allocation) for respective tasks are shown in bold. And, the values shown in rectangle boxes represent that corresponding VMs can fully satisfy the security demand of the specified task and vice versa.

Table 7 Illustration of allocation of tasks at depth level = 1

Table 8 Illustration of idle gap reduction for depth level = 1

Table 9 Illustration of allocation of tasks at depth level = 2

Table 10 Illustration of idle gap reduction for depth level = 2

Table 11 Illustration of allocation of tasks at depth level = 3

Table 12 Illustration of idle gap reduction for depth level = 3

Again, the next cluster is taken for allocation, ${C}_{0.7}^{1}=$ {T₂₁, T₂₃} having two tasks. For, T₂₁, the finish time is computed again by using Eq. (7) and presented in Table 7. Here, SD₂₁ = TL_CS. It means T₂₁ can be executed without any failure on the cloud system. As per the allocation process mentioned earlier, V_Fit = V₃ with TL₃ = 0.7 against SD₂₁ = 0.7. So, T₂₁ is assigned and executed on V₃ without any risk of failure (i.e., ${F\fancyscript{p}}_{213}$= 0). The status of T₂₁ on allocation is Non-failure (NF). Finally, the start and finish times are made bold in a rectangle box. T₂₃ is also assigned on V₃ similar to T₂₁ with status NF. For cluster, ${C}_{0.4}^{1}$ = {T₂₂, T₁₂}, both tasks have a security demand is 0.4. The trust levels of all VMs are greater than or equal to 0.4. Therefore, these tasks can be allocated and executed on any VM without risk. However, as per SPMWA for both tasks (T₂₂ and T₁₂) fit machine is V_Fit = V₂ as V₂ offers the least finish time among all as shown in Table 7. Hence, T₂₂ and T₁₂ are assigned on V₂ with status as NF. In this way, the first-level tasks are assigned. At this level, only the T₁₁ task is executed with risk due to the unavailability of VM, and the rest of the tasks are executed risk-free with zero failure probability.

As shown in Table 8, the processing time and total processing time on V_k at the first depth level are computed as per Eqs. (8) and (9) respectively. The communication cost values are zero for first-level tasks on all VMs. After this, the idle gap reduction (Algorithm #3) procedure finds the idle gaps $({I\fancyscript{g}}_{k}^{1})$ on V_k by using Eq. (10) and presented in Table 8. The successor tasks of d¹ from the next partition (d²) (T₁₃, T_24, T₁₄, and T₁₅) are taken and tried to accommodate into the suitable idle gaps in accordance to Algorithm #3. Consequently, only T₁₄ ∈ d² is fitted in the idle gap (${I\fancyscript{g}}_{2}^{1}:9.97$) on V₂ because the net processing time of T₁₄ is less than the size of the idle gap $({I\fancyscript{g}}_{2}^{1})$ on V₂ i.e., ${E}_{142}^{net}={E}_{142}+{SO}_{142}+max({CC}_{14222}^{12})$ = 6.25 + 0 + 0 = 6.25 < 9.97. Here, ${CC}_{14222}^{12}$ is computed by using Eq. (1). After that, SPMWA computes ${({T\mathcal{P}\fancyscript{t}}_{k}^{1})}^{u}$ as per Eq. (11) and given in Table 8.

The level-wise tasks allocation and idle gap reduction along with ready time, communication cost, processing time, and maximum updated processing time on virtual machines are also presented in Fig. 4 for better clarity. The illustration of allocation of tasks and respective idle gap reduction for remaining partitions have been presented in Tables 9, 10, 11, 12 presenting various intermediary computations following the similar procedure as discussed earlier for the first partition tasks. In the second partition, only one task T₁₃ is allocated to fit VM with risk of failure, and the other remaining tasks across the partitions are assigned to their corresponding fit machine without risk or zero failure probability.

Fig. 4

Allocation Schedule by using the SPMWA model

Fig. 5

Boxplots of NTF on varying number of workflows

On allocation of all workflows, the set of failed tasks is T_failure = {T₁₁, T₁₃} with the total NTF = 2 as per Eq. (14). The failure probability of the set of workflows on cloud system is computed as $F\fancyscript{p}$ = 0.3623 by using Eq. (17). As it is observed from the above illustration that the number of task failure is only two and happened only due to the unavailability of the demanded VM in the cloud system. As per Eq. (12), makespan (Ms) of the set of workflows can be computed as sum of maximum ${({T\mathcal{P}\fancyscript{t}}_{k}^{l})}^{u}$ on each depth level presented in Tables 8, 10, 12, and Fig. 4. Ms = 50 + (24.60 + 15.30 + 21.70) = 50 + 61.60 = 111.60 units. Therefore, it is expected that on larger workflow sets and VMs the proposed model would exhibit better performance behavior.

4.4 Time complexity analysis

The computational time of the proposed model for parallel multiple workflows is defined in terms of the number of workflows (${N}_{\mathcal{W}f}$), depth level (L), number of tasks $({N}_{{wf}_{i}})$ and edges weight between (e_ixy) in a single workflow, and the number of VMs (n). The time complexity of the SPMWA model is the computational time taken for complete execution, as a function input parameter which is discussed in various steps as follows:

• Partitioning: The $\mathcal{W}f$ of depth level is divided into L partitions. As per the algorithmic template of SPMWA, the time complexity for this process can be computed as $O\left(L\times {N}_{\mathcal{W}f}\times {N}_{{wf}_{i}}\right)$.

• Sorting: Partitions are sorted as per security demand in descending order with time complexity $O\left({N}_{l}\mathit{log}{N}_{l}\right)$,

• Allocation: The computational time of task allocation for each partition and adjusting the idle gaps by checking the fit VM created during the allocation phase is in the same order. The allocation of each task checks the fit VM using IF-Else condition can be done in time O(1). In the same way, each task allocation assigned onto the set of VMs can be done in $O\left(L\times {N}_{l}\times n\right)$.

Hence, the total time complexity for SPMWA model is $O\left(L\times {N}_{\mathcal{W}f}\times {N}_{{wf}_{i}}\right)+O\left({N}_{l}\mathit{log}{N}_{l}\right)+O\left(L\times {N}_{l}\times n\right)\cong O\left({N}_{\mathcal{W}f}\times {N}_{l}\mathit{log}{N}_{l}\right)$ where ${N}_{l}$ is the number of tasks in l^th partition, ${N}_{l}\approx {N}_{{wf}_{i}}, {N}_{\mathcal{W}f}>n$ and $L=\mathit{log}{N}_{l}$.

5 Performance evaluation

In this section, to evaluate the performance of SPMWA, simulation experiments have been conducted on a system having the configuration, Intel (R) i7-8700 CPU@3.20 GHz, 64 GB RAM on a single physical machine by implementing a workflow allocator prototype in MATLAB 8.5. We compare the performance of the SPMWA model with four standard workflow allocation models such as HEFT, LBSIR, SPM1, and SPM2. HEFT [11] and LBSIR [39] are designed to generate time effective schedule without considering the security requirements of the workflow tasks. In the literature section, we have seen that HEFT is rank based list scheduling heuristic that is still competitive for workflow allocation problems. HEFT works in two phases as follows: in the priority phase, it determines the upward rank for maintaining the precedence of the tasks, and in the resource selection phase, it selects the resources which have the earliest finish time.

Moreover, LBSIR is a level-based heuristic for multiple workflow allocation problem to optimize total completion time. After partitioning of workflow tasks in accordance to level attribute, LBSIR also works in two phases viz. allocation and idle slot reduction. In the allocation phase, the mapping of the task is done on the machine that offers the least execution time. In the second phase, best-fitted successor tasks will be accommodated into the idle slots left during the allocation phase between two tasks at the same machines getting a better quality of the schedule. In each partition, the selection of workflow tasks is accomplished in two ways, largest module selection (LMS) and smallest module selection (SMS), resulting in two variants of LBSIR namely LBSIR with largest module selection (L-LMS) and LBSIR with smallest module selection (L-SMS) respectively. Therefore, we are considering them for performance evaluation in our work.

As mentioned earlier in Sect. 2.3 in detail, the work presented by Bittencourt and Madeira [35] suggested four strategies to manage the multiple workflow allocation. For performance evaluation, we have taken two strategies namely sequential-based and merge-based multiple workflows strategies proposed in [35]. The security upward ranks are computed following the method presented in [24]. Further, the security prioritized VM selection and allocation has been done in accordance to SPHEFT [32]. This way, two versions of Security Prioritized Multiple workflow allocation (SPM) models namely SPM1 (Merge-Based) and SPM2 (Sequential-Based) respectively have been designed for comparison purposes.

5.1 Parameter setting

In this section, an experimental study has been carried out for random DAGs and real application DAGs such as Montage, CyberShake, and LIGO, and the results are presented in Sect. 5.2 and Sect. 5.3 respectively. The parameters/variables associated to workflow applications and heterogeneous VMs in IaaS cloud environments are randomly generated in the specified range using a uniform distribution. The security demand of the task and the trust level of the virtual machine are in the normalized range [0, 1]. For reproduction of the results, the common parameter setting is given in Table 13 for Sect. 5.2 and Sect. 5.3. And, the other remaining parameters used in the various experiments are given in separate cases clearly.

Table 13 Common input parameters for the experiments

Table 14 Computed NTF of LBSIR, HEFT, SPM1, SPM2, and SPMWA for varying workflows

• (i) Parameter setting for random workflows

  Case 1: Experiments on varying number of workflows

  In this case, the number of workflows is varied from 16 to 512, and the results are shown in Figs 5, 6, 7 and Tables 14, 15, 16 in Sect. 5.2. The fixed input parameters used in these experiments are as follows:

  Number of VMs (n) = 64, Number of depth level (d_max) = 8, Number of tasks in each depth level $({N}_{{wf}_{i}}^{l})$ = 16, Number of tasks (${N}_{{wf}_{i}}$) in a workflow = 128.

  Case 2: Experiments on varying number of VMs

  In this case, the number of VMs is varied from 16 to 512, and the results are shown in Figures 8, 9, 10 and Tables 17, 18, 19 in Sect. 5.2. The fixed input parameters used in these experiments are as follows:

  Number of workflows (${N}_{\mathcal{W}f}$) = 64, Number of depth level (d_max) = 16, Number of tasks in each depth level $({N}_{{wf}_{i}}^{l})$ = 32, Number of tasks (${N}_{{wf}_{i}}$) in a workflow = 512.

• (ii) Parameter setting for real application workflows

  In this case, the number of real application workflows is varied from 16 to 512, and the results are shown in Figs. 12, 13, 14 and in Sect. 5.3. Due to fixed structure, the number of tasks in Montage, LIGO, and Cybershake in the study is 25, 30, and 40, and the depth levels are 9, 5, and 6 respectively. The fixed input parameters in these experiments are as follows: Number of VMs (n) = 32, Number of depth level (d_max) = 9(montage)/5(CyberShake)/6(LIGO).

All the experiments are repeated 20 times to find out the representative values of the objective parameters to handle the randomness during experiments. Tables 14, 15, 16, 17, 18, 19 have been presenting the minimum (Min), maximum (Max), average (Avg), and standard deviation (Std) for all the cases. The superior values are also shown in bold in all the tables.

5.2 Experimental results for random workflows

In this section, the experiments have been conducted discussing the results for randomly generated workflows for the first two cases such that a varying number of workflows and VMs. For this, the E_ijk for the VM and workflow tasks has been generated by using the standard ETC simulation benchmark model [59] with high machine and workflow tasks heterogeneity for an inconsistent environment. So, the range of E_ijk becomes 1–300,000. As per Eq. (2), ${CC}_{k}^{l}$ is becomes in the range 1–300,000 which is equal to the range of E_ijk.

Case 1: Varying Number of Workflows

For the first case, the experimental results presenting a varying number of workflows for L-LMS, L-SMS, HEFT, SPM1, SPM2, and SPMWA are shown in Figs. 5, 6, 7 using boxplot for better representation and graphical self-interpretation and Tables 14, 15, 16. For performance comparison, simulation results of each algorithm viz. L-LMS, L-SMS, HEFT, SPM1, SPM2, and SPMWA have been done.

As expected, the number of task failure (NTF) is increasing as the number of workflows is increased for fixed VMs for all considered models, as shown in Fig. 5(a–f) and Table 14. The performance of the SPMWA model is observed to be superior among all the models for all batch of workflows. The reason behind this is strictly satisfying the security demand of the tasks on allocation if any VM with sufficient trust is available. It reduces the number of tasks failure (NTF) on the allocated VMs. As shown in Fig. 5(a–f) and Table 14, SPMWA clearly exhibits its superior performance in terms of best, average, worst, and standard deviation values of NTF in comparison to LBSIR variants, HEFT, SPM1, and SPM2 for varying number of workflows from $16$ to 512. In this case, the average performance gain of SPMWA over LBSIR, HEFT, SPM1, and SPM2 on account of NTF is approximately 43%. As expected, the performance order on NTF is SPMWA, SPM1, SPM2, LBSIR, and HEFT.

As shown in Fig. 6(a–f) and Table 15, SPMWA outperforms to all considered models on account of the failure probability. This is due to the allocation of high-security demand tasks in each partition to higher trustworthy VMs satisfying requirements fully. In this case, the failure probability of tasks becomes zero. Moreover, if the security demand of a task is not satisfied against the trust level of the VM, then it is assigned onto the VMs which offer the least risk of failure. Hence, the Min and Max failure probability of SPMWA is below 7–20% in all cases while other models give a minimum (Min) failure probability of 18% and maximum (Max) failure probability of 99% as shown in Table 15. In Fig. 6(a–f), SPMWA clearly exhibits it is superior performance in terms of best, average, standard deviation, and worst values of failure probability in comparison to LBSIR variants, HEFT, SPM1, SPM2 for all batch sizes from 16 to $512$. So, it is evident that SPMWA outperforms among all algorithms on failure probability. In this case, the average performance gain on the failure probability of SPMWA over SPM1, SPM2, LBSIR, and HEFT has been improved by approximately 73%. The performance order on the failure probability is the same as earlier.

Fig. 6

Boxplots of failure probability on varying number of workflows

Table 15 Computed failure probability of LBSIR, HEFT, SPM1, SPM2, and SPMWA for varying workflows

In Fig. 7(a–f) and Table 16, the trend of the makespan (Min, Avg, Max) values are increased when the number of workflows increases as expected. Both variants of the LBSIR clearly show superior performance on makespan for all varying batch sizes. However, SPMWA is showing better results in terms of makespan other models excluding the LBSIR variants. The reason for the superior results of LBSIR variants on makespan is that LBSIR variants target makespan to minimize without considering the security demand of the task. The average improvement of LBSIR variants over the SPMWA is approximately 21% in terms of makespan. However, SPMWA has better performance than HEFT, and SPM variants. The performance improvement against them is approximately 89%, 90%, and 97% respectively, with performance order such as LBSIR, SPMWA, HEFT, SPM1, and SPM2.

Fig. 7

Boxplots of Makespan on varying number of workflows

Table 16 Computed makespan of LBSIR, HEFT, SPM1, SPM2, and SPMWA for varying workflows

Case 2: Varying number of VMs

For the second case, the experimental results presenting varying the number of VMs for L-LMS, L-SMS, HEFT, SPM1, SPM2, and SPMWA are shown in Figs 8, 9, 10 and Tables 17, 18, 19 for n = 16 to n = 512. For the performance comparison, simulation results of each algorithm viz. L-LMS, L-SMS, HEFT, SPM1, SPM2, and SPMWA have been done. The best, worst and average values of the number of task failure, failure probability, and makespan of obtained solutions are reported in Tables 17, 18, 19, respectively.

Fig. 8

Boxplots of NTF on varying number of VMs

Fig. 9

Boxplots of failure probability on varying number of VMs

Fig. 10

Boxplots of Makespan on varying number of varying VMs

Table 17 Computed NTF of LBSIR, HEFT, SPM1, SPM2, and SPMWA for varying VMs

Table 18 Computed failure probability of LBSIR, HEFT, SPM1, SPM2, and SPMWA for varying VMs

Table 19 Computed makespan of LBSIR, HEFT, SPM1, SPM2, and SPMWA for varying VMs

As presented in Fig. 8(a–f) and Table 17, the number of task failure is in a decreasing trend when the number of VMs is increased on keeping the fixed batch of workflows for all considered models. This is because of the better exploitation of parallelism available in the workflows. In various runs, Min and Max NTF for SPMWA are 9975 and 13,231 in all cases, while for other models these values are 12,129 and 24,608, respectively. As we see in Fig. 8(e–f), when the number of VMs increases from 16 to 512, the average number of task failure for SPMWA is decreasing. It is due to the fact that when the number of VMs is increased, the chances of getting more trustworthy machines increase. For this metric, SPMWA outperforms on all other models in the study. In this case, the average performance gains of SPMWA on NTF over SPM1, SPM2, and LBSIR, HEFT are approximately in the range of 37%-40%. The performance order is SPMWA, SPM1, SPM2, LBSIR, and HEFT.

As can be seen in Fig. 9(a–f) and Table 18, the failure probability is slightly decreasing when the number of VMs is increased. The average failure probability of SPMWA is below 18% in all cases while other algorithms attain the Min failure probability 44%. As shown in Fig. 9(d–f), when we test the SPMWA model on a large number of VMs, then the average failure probability of the proposed model becomes lower e.g., $F\fancyscript{p}$ = 15 − 12% for a number of VMs from 256 to 512. Because when the number of machines is increased, the chances of more trustworthy machines to assign the task increase. So, it is evident that SPMWA outperforms all algorithms on failure probability. In this case, the average performance gain on failure probability for SPMWA over SPM1, SPM2, and LBSIR, HEFT has been improved by approximately 77%. The performance order is SPMWA, SPM1, SPM2, LBSIR, and HEFT.

When the number of VMs increased, best, worst, and average values of the makespan have the same trend as number of task failure as shown in Fig. 10(a–f) and Table 19. In this case, LBSIR variants clearly show superior performance on makespan among all from 16 to 256 VMs. The reason behind the superior results of LBSIR variants on makespan is the same as mentioned earlier. The SPMWA is showing better results in terms of makespan among all strategies except LBSIR variants. However, on a large number of VMs, the makespan of LBSIR gets closer to the makespan of SPMWA as can be seen in Fig. 10(d–e). SPMWA also tries to fill the idle gaps produced due to the size difference between tasks at the depth level by accommodating the best-fitted task which in turn, ensures a better makespan. Based on the outcomes of Table 19 and Fig. 10a, it is observed that HEFT and SPM1 algorithm performs better than SPMWA on makespan for a very small number of machines (e.g., n = 16). However, when the number of VMs is increased, the proposed model clearly shows better performance on makespan against HEFT and SPM1. The performance gain on the makespan of the proposed model over HEFT, SPM1, and SPM2 is approximately 48%, 49%, and 98% but lagging to LBSIR variants by 27%.

5.3 Experimental results for real application workflows

In this section, the experiments have been conducted for real application workflows (Montage_25, Cybershake_30, and LIGO_40) on a varying number of workflows. The parameters taken in this study are as mentioned earlier in Sect. 5.1.

The Montage_25, Cybershake_30, and LIGO_40 having 25, 30, and 40 tasks respectively, are taken for the experiments from the Pegasus website [60] as shown in Fig. 11a, b, and c. The Montage workflow has scope in astronomy. It creates unique sky mosaics from a set of input images in the “Flexible Image Transport System (FITS)” format. The majority of its tasks are simple. I/O intensives are used to describe processing capacity. The CyberShake is employed in synthetic seismograms to determine characteristics. The Laser Interferometer Gravitational Wave Observatory (LIGO) is a spacecraft that detects gravitational waves. It developed a scientific methodology to identify gravitational waves produced by various cosmic events [50, 51]. These real workflows are frequently used to examine the quality of schedules generated by various models proposed in the literature Here, SPMWA, L-LMS, L-SMS, HEFT, SPM1, and SPM2 models are evaluated to see how failure probability affects schedule quality.

Fig. 11

Real Workflow Applications a Montage b CyberShake c LIGO

Figures 12, 13, 14 present the number of task failure, failure probability, and makespan for Montage, CyberShake, and LIGO when varying the number of real workflows from 16 to 512. SPMWA outperforms to all other models from all batch sizes of real workflows on account of the NTF as presented in Fig. 12. The number of task failures increases on increasing the number of workflows (Montage_25, Cybershake_30, and LIGO_40) for all considered models keeping all the other input parameters fixed. Again, the performance order is SPMWA, SPM1, SPM1, LBSIR, and HEFT. The performance gain of SPMWA has been enhanced over SPM1, SPM2, LBSIR, and HEFT (taking the average of all three sets of workflows), in the range of 30–36% approximately.

Fig. 12

NTF on varying Montage, CyberShake, and LIGO workflows

Fig. 13

Failure probability on varying Montage, CyberShake, and LIGO workflows

Fig. 14

Makespan on varying Montage, CyberShake, and LIGO workflows

As shown in Fig. 13, SPMWA outperforms all other models for every batch size from small to larger real workflows on account of the failure probability. The trend of SPMWA on failure probability keeps slightly increasing on increasing the number of real workflows for Montage_25, Cybershake_30, and LIGO_40 keeping all the other input parameters fixed. The performance order is SPMWA, SPM1, SPM1, LBSIR, and HEFT as expected. The performance gain of SPMWA has been enhanced over SPM1, SPM1, LBSIR, and HEFT, as observed in the average of all three workflows, is in the range of 47–55% approximately.

Makespan is an increasing trend when the batch size is increased for this case as shown in Fig. 14. Both variants of LBSIR clearly show superior in terms of makespan on all scientific workflows from smaller to larger batch sizes. However, on a large number of every real workflow, the makespan of SPMWA gets closer to the makespan of LBSIR as can be seen in Fig. 14. The overall performance gain of LBSIR has been enhanced over SPMWA as observed is 19%, 20%, and 38% approximately on Montage, CyberShake, and LIGO workflows. However, SPMWA is showing better than HEFT, SPM1, and SPM2, in terms of makespan, and the performance gain is 18%, 20%, and 33% on Montage, CyberShake, and LIGO scientific workflows with 16 to 512 workflows sets. The performance order on makespan is LBSIR, SPMWA, HEFT, SPM1, and SPM2. The worst performance is observed by SPM2 because workflows are assigned one after another in sequential exploiting only task-level parallelism in the workflow.

In summary of experimental results of Sects. 5.2 and 5.3, SPMWA performs remarkably best among all considered models in terms of the failure probability, henceforth, number of task failure by achieving the higher optimal values on the objective for both cases. The performance order is SPMWA, SPM1, SPM2, LBSIR, and HEFT. It is due to the fact that SPMWA is a security-adaptive workflow allocation method. Therefore, it ensures the allocation of high-security demand tasks in each partition to higher trustworthy VMs satisfying requirements fully. As successful task execution with the least failure probability is an inevitable need in the IaaS cloud. On makespan LBSIR variants are better, however, for a large number of VMs SPMWA becomes closer to them. For real application workflows such as Montage, CyberShake, and LIGO, the proposed SPMWA model is also exhibiting the best performance on failure probability and number of task failure for all considered real workflow sets. The performance trend is the same as in the case of random workflows. Thus, SPMWA is very flexible from a programming point of view, which is also an important concern of designers of workflow allocation with security prioritization applications. Thus, we can argue that the SPMWA may greatly contribute to a secure and robust system transaction with satisfied desired constraints.

6 Conclusion and future work

Nowadays, cloud computing is adopted in many emerging application areas such as e-commerce services, medical services, transaction processing systems, scientific workflow processing, and many more. Workflow allocation satisfying the security requirements in the cloud system is also one of the core issues. In this paper, Security Prioritized Multiple Workflow Allocation (SPMWA) model is proposed that integrates the security constraints into allocation to minimize the failure probability of the workflow execution in the cloud computing environment. SPMWA gives more chance to high-security demanded tasks to get allocated onto the higher trustworthy VMs during allocation. The performance of SPMWA has been compared with standard algorithms, namely HEFT, LBSIR, SPM1, and SPM2. Our experimental results reveal that SPMWA outperforms to LBSIR, HEFT, SPM1, and SPM2, on account of the number of task failure, and failure probability. For makespan, SPMWA is better than HEFT, SPM1, and SPM2, and lagging to LBSIR.

There are still some limitations of the proposed SPMWA model for security-sensitive workflow applications which need to be addressed as potential future work as follows:

• To be extended for a more robust and efficient model considering all three security services namely, authentication, integrity, and confidentiality.

• To include some more cloud system’s constraints in the model such as deadline, budget, etc.

• To extend the model for a multi-objective model considering QoS parameters like time, energy, and economic cost.

Appendix

The overall security overhead (SO) of the system for considered workflows can be estimated as per Eq. (18):

$${\text{SO}} = \sum\limits_{i = 1}^{{N_{wf} }} {\sum\limits_{j = 1}^{{N_{wfi} }} {\sum\limits_{k = 1}^{n} {z_{ijk} } } } \times {\text{SO}}_{ijk}$$

(18)

where z_ijk is the assignment vector, SO_ijk is the security overhead of T_ij on V_k and it is computed as per Eq. (4).

As shown in Table 20, the best, worst, and average values of the security overhead are increased when the number of workflows increases as expected. However, SPMWA outperforms among all cases in terms of security overhead. It is obvious that security overhead is directly proportional to failure probability. Therefore, it follows the same performance order as expected among all models with the same reason explained above in the case of failure probability. Here, also the majority of the tasks are executed without risk or at least possible risk resulting in less security overhead. The performance gain of SPMWA over LBSIR, HEFT, SPM1, and SPM2 on account of security overhead is 45%, 45%, 41%, and 46% respectively. The performance order for the security overhead is SPMWA, SPM1, LBSIR, HEFT, and SPM2 for all batch sizes of the workflows which is almost the same for failure probability. (see Tables 20, 21, 22)

Table 20 Computed overall security overhead of LBSIR, HEFT, SPM1, SPM2, and SPMWA for varying workflows

Again, the best, worst and average values of the security overhead are decreasing when the number of the VMs is increased as expected presented in Table 21. Thus, SPMWA outperforms all cases in terms of security overhead. The average performance gain on security overhead has been improved in the range of 40% to 50% over SPM1, SPM2, LBSIR, and HEFT. The performance order is SPMWA, SPM1, LBSIR, HEFT, and SPM2 for all sets of virtual machines.

Table 21 Computed overall security overhead of LBSIR, HEFT, SPM1, SPM2, and SPMWA for varying VMs

The trend of average security overhead is increasing for all batch sizes of Montage, CyberShake, and LIGO keeping other parameters fixed as shown in Table 22. SPMWA performs best among all other models on each real workflow for every batch size in terms of security overhead. Even when the security demand for a task is not fulfilled, the proposed model assigns that task where its failure risk is least. Further, the Also, the performance of SPMWA has been improved on all real workflows for every batch size over SPM1, SPM2, LBSIR, and HEFT as observed in the range of 32–43%, 19–36%, and 25–40% approximately on Montage, CyberShake, and LIGO respectively. The performance order on security overhead is SPMWA, SPM2, SPM1, LBSIR, and HEFT.

Table 22 The overall security overhead on varying Montage, CyberShake, and LIGO workflows