2
C h a p t e r
Background and Literature Survey
I
n this chapter, we present some background material relevant to the problems addressed in the thesis and also discuss the literature surveyed on these topics. First, we present the general architecture of federated cloud data centers considered in the work and also discuss vehicular cloud computing briefly. Next, we discuss two important concepts, virtualization, and migration. We give an overview of various migration techniques and explain the pre-copy live migration technique used in our work. Finally, we present a comprehensive taxonomy of resource management problems and then discuss the state-of-art literature related to the problems addressed in the thesis.Organization of the Chapter: The rest of the chapter is organized as follows. Section 2.1 discusses the architecture of federated cloud data center considered in the thesis. In Section 2.2, we discuss the salient features of vehicular cloud computing, relevant to the work in Chapter 4. The basic concepts of virtualization and migration are discussed in Section 2.3. Section 2.4 details the taxonomy of the resource management problems in cloud networks. We discuss the literature relevant to the problems addressed in the thesis and the limitations therein in Section 2.5. The chapter is summarized in Section 2.6.
2.1. Federated Cloud Data Center Architecture
Figure 2.1: Cloud service model
typically over Internet [62]. This encouraged most of the big companies and organizations to shift their businesses to the cloud [3]. Cloud computing services can be delivered in three different models based on pay-as-you-use, as depicted in Figure. 2.1. They are (i) Infrastructure as a Service (IaaS) which offers physical resources like processing power, memory, storage, and network bandwidth to customers, (ii) Platform as a Service (PaaS), where a cloud service provider delivers the computing environment which is required for building cloud applications, and (iii) Software as a Service (SaaS) which provides applications hosted on cloud and the end-user access the application through internet [63]. In this thesis, we focus on IaaS where customers can share physical resources that are hosted in data centers.
The massive demand for cloud resources has led to the emergence of the geo-distributed cloud data center, which is a collection of many small data centers located in different geographical areas. A data center may contain just a few servers in a single private cloud or may have several thousands of interconnected servers across a public geo-distributed cloud.
It has been reported that the number of hyper-scale data centers worldwide increased by 226% during the last five years, going up from 259 in 2015 to 597 data centers at the end of 2020 [64]. For example, Amazon operates 81 availability zones; each has one or more data centers across 25 regions in 4 continents [65].
2. Background and Literature Survey
However, the problem is that the big cloud users cannot get all the required resources from a single cloud provider, no matter how large it is. Most of the main cloud providers also have a limited geographic presence, and they usually establish their data centers in places profitable for their businesses [30]. If we look at the majority of applications that are deployed in the cloud, such as social media, e-commerce, big data analysis, and online games, they all require humongous resources and global coverage. Furthermore, some customers may have specific requirements. For example, a customer may have already stored data in Amazon S3 but wants to deploy a computing service using Google compute engine without moving the data.
The federated cloud data center has emerged as a promising solution for hosting such applications in a scalable and cost-efficient manner. Federated cloud systems aggregate the resources provided by the data centers of collaborating cloud providers into a single platform [7, 6]. The architecture of a federated cloud system is illustrated in Figure. 2.2.
Actors or stakeholders usually participating in the federated cloud system are [8]:
Figure 2.2: Federated cloud system architecture
2.1. Federated Cloud Data Center Architecture
• Cloud Infrastructure Provider (CIP): It owns and manages data centers which in- clude physical resources. Every CIP represents an anonymous subsystem within the federation with one or more data centers.
• Cloud Service Provider (CSP): It offers various cloud services to customers using resources provided by the CIPs participating in the federation. It may use resources from different CIPs.
• End User: This is the cloud consumer that requests services from the CSP; it may be a mobile user in some cases, such as a vehicle moving on a highway.
• Cloud Broker (CB): It acts as a proxy between the end users and the CSPs and between the CSP and CIP to find the best CSP (or CIP) according to pre-specified criteria.
• Network Service Provider (NSP): It provides network access or bandwidth and provides connectivity between end users and data centers of the cloud, as well as across the data centers of various CIPs.
Figure. 2.2 presents the general architecture of the federated cloud system. The CSP may not have any data center where it offers services by leasing resources from CIPs. A CIP may offer infrastructure services (and other services) directly to end users acting as a CSP, such as Google and Amazon cloud providers. In this case, end users may request the service from the CIP directly without any broker. In traditional geo-distributed data centers, CSP connects to one CIP that has multiple data centers in different geographical locations where the CIP can use the resources of its data centers only. On the other hand, CSP can connect to several CIPs simultaneously in a multi-cloud scenario. However, in a federated cloud, a CSP connects to only one CIP, and this CIP may communicate with other providers and rent resources from them. This is transparent to the CSP, which interacts only with one CIP. Federation minimizes the resource management effort for the CSP and also minimizes the communication between the CSP and CIPs as well. The problem of resource management in a federated cloud is restricted within the boundary of the federation. Each CIP represents an individual entity within the federation where the privacy of the CIPs should be maintained, and each CIP can decide its own strategy regarding resource sharing.
2. Background and Literature Survey
In traditional geo-distributed data centers, the CIP usually has its own inter-data center WAN network. But, in a federated system, a CIP needs to engage with an NSP to connect to another CIP. There may be various NSPs that offer different types of network connectivity services at different prices. Hence, the data centers of a federation are connected through links with diverse bandwidths and pricing. The price of network bandwidth (typically measured in $/GB) also varies based on the geographical distance [51]. Since we focus on resource management in a federated cloud system, we assume CIP to also act as a CSP, which we term ascloud provider (CP)in the thesis. The problem here is that the CP has to choose the best resource allocation for hosting applications according to their requirements and the cost of various resources across the federation, considering the possibility of resource sharing and workload outsourcing.