in control message exchange are not considered. To study the performance of dynamic service placement in a more practical setting, we propose an emulation framework in Chapter 6, in which physical nodes are encapsulated into virtual containers that are connected via emulated physical links. A real computer pro- gram with some basic packet exchange functionalities runs in each node in the emulation. Emulation results of different service placement policies are shown and their insights are discussed.
1.4
Organization of the Thesis
This thesis is organized as follows. Chapter 2 introduces the general problem and re- lated techniques that are used in this thesis. Chapter 3 presents the optimal algorithm for line-to-tree placement and online approximation algorithms for the placement of an incoming stream of tree application graphs. The MDP-based approach for dy- namic service migration is presented in Chapter 4. Chapter 5 presents algorithms for dynamic service placement with predicted future costs. An emulation framework is presented in Chapter 6. Chapter 7 draws conclusions and discusses some future directions.
CHAPTER
2
Background of Dynamic Service
Placement
2.1
Definitions
We can abstract the service placement problem as a graph (or, as a special case, node) placement problem, as illustrated in Fig. 2.1. In the following, we introduce some concepts that will be used in this thesis.
Application/Service Graph: A service or a service instance1can be abstracted as
a graph (referred to as the application/service graph2) in which the nodes represent
processing/computational modules in the service, and the edges represent commu- nication demand between the nodes. Each node v ∈ V in the application graph
R = (V, E) is associated with parameters that represent the computational resource
1For simplicity, we exchangeably use the terms “service” and “service instance” in this thesis. 2We exchangeably use the notions application graph and service graph in this thesis.
1 2 3 4 5 6 A C D E F G H
CPU, storage, I/O requirements Communication bandwidth requirement B Map
Application graph (cloud environment)Physical graph
Current utilization and total amount of resources
2.1. Definitions 12 (of K different types) demands of node v. Similarly, each edge e ∈ E is associated with a communication bandwidth demand. The notation e = (v1, v2) denotes that
application edge e connects application nodes v1 and v2. The application graph R can be either a directed or an undirected graph. If it is a directed graph, the direction of edges specify the direction of data communication; if it is an undirected graph, data communication can occur in either direction along application edges.
Physical Graph: The physical computing system can also be abstracted as a graph (referred to as the physical graph) with nodes denoting network elements such as data-centers3, servers, routers, etc. and edges denoting communication links be-
tween the nodes. Each node n ∈ N in the physical graph Y = (N , L) has K different types of computational resources, and each edge l ∈ L has a communi- cation capability. For nodes in the physical network that do not have capability of hosting computational modules (such as routers), we can regard their computational capacity as zero. We use the notation l = (n1, n2) to denote that physical link l con-
nects physical nodes n1 and n2. Similar to the application graph, the physical graph can be either directed or undirected, depending on whether the physical links are bidirectional (i.e., communication in both directions share the same link) or single- directional (i.e., communication in each direction has a separate link).
Policy: A policy specifies how to place the application graphR onto the physical graphY. In a dynamic setting, the policy can also depend on the current state of the system (defined below), so that a new placement decision can be made based on the current placement. It can also be dependent on the time of performing the placement. 3A physical node can either represent a data-center (which is a collection of network elements) or
2.1. Definitions 13 State: The state of the cloud system specifies where each application node and link is placed, and the current status (including topology, resource demand/availability, etc.) of the application and physical graphs.
Cost: Each possible way of service placement incurs some costs. Generally, there are two types of costs. The first type is the cost of running services on the cloud system when the placement of these services remain unchanged. The second type is the migration cost, which is incurred when we change the placement of the ser- vice during its operation. We consider the migration cost because when the service placement is altered, we may need to restart the service or transfer some state infor- mation to the new physical machine that runs the service, which incurs some cost. The explicit cost definition will be discussed in details for each specific problem in the remainder of this thesis.
Constraints: There can be constraints such as the resource capacity of each phys- ical node and link, the location that each application node and link can be placed at, as well as other constraints including those that are related to access or security restrictions.
Offline and Online Service Placement: Throughout this thesis, we say that a ser- vice placement is offline when our goal is to place a single or a set of application graphs “in one shot”. In contrast, an online service placement is the case where we have an incoming stream of application graphs, which have to be sequentially placed onto the physical graph as each application graph arrives. There may or may not exist some application graphs that depart while others are arriving.
A Note on Graphs: For the problems discussed Chapters 4, 5, and 6, the notion of graphs is not important for explaining the problems. In those chapters, we will