Service Traffic Shaping for Resource Protection in Enterprise Data Centers 

Get Complete Project Material File(s) Now! »

Resource Protection in Single-Site Enterprise Data Centers

DOWSS. In most EDC deployments communication delay is not an issue as the infrastructure usually shares the same rack or is located in the same geographical site. In this kind of deployments, IT managers define service access requirements, which is the rate at which a service should be accessed, and limits it to no more than a number of service requests during an observation period. In this thesis, we first propose and validate DOWSS, a doubly-weighted algorithm for service traffic shaping from multiple access points towards a single service instance. We show via simulation that DOWSS possesses several advantages: it eliminates the approximation issues, prevents starvation and contains the rapid credit consumption issue in existing credit-based approaches. MUST. Next, we argue that current off-the-shelf SON appliances present architectural limitations that prevent them from being used to efficiently perform traffic shaping in the presence of multiple service hosts. In this thesis, we introduce MUST, a SON appliance architecture fit for multi-service traffic shaping. We show via simulation that our approach solves the multipoint-to-multipoint service traffic shaping problem while pushing the system to its maximum capacity.

Resource Protection in Geographically Distributed EDC Deployments

GEODS. Current trends point to having applications located in geographically distributed EDCs. This type of systems often induce new constraints, in addition to the ones already found in single-site systems, such as non-negligible communications delays. To tackle these new constraints, we propose and validate GEODS, an algorithm for service traffic shaping in geographically distributed setups. We show via simulation that our approach prevents issues inherent to the presence of network latencies, and efficiently solves the service traffic shaping problem.

Service Level Agreements and Service Access Requirements

Access to services is governed by a Service-Level Agreement (SLA), which specifies the rules for sharing EDC resources, aswell as for offering service quality guarantees to customers[4]. To better meet the service guarantees fixed by SLAs and in order to protect shared EDC resources, in the SON environment resource utilization metrics mostly fall into the following types:
CPU is the general CPU utilization of a hosted application. Memory defines the main memory (RAM) utilization by a particular hosted service.
Storage is the amount of disk storage that is allocated to a particular service. Throughput specifies the number of requests a service should receive during a given period of time.
Bandwidth is the amount of bandwidth that a service uses in the EDC internal network.
Unlike their counter-partners from the “classic” networking, SLAs in SON environments are not standardized by industrial bodies. Examples taken from two major providers of Data Center colocation and hosting services further corroborate this. Even though both providers offer similar services, Verizon’s SLA definitions are pointed towards specific goals in bandwidth and throughput, while Amazon’s definitions dwell more on overall service availability.[31;36].
However, even in this heterogeneous environment, IT managers establish Service Access Requirements (SAR) as part of an SLA, aimed at protecting system resources. For illustration purposes, we present several examples of SAR definitions in terms of the above mentioned types. Let us first consider a government agency, say, the Internal Revenue Service (IRS), which has deployed an EDC in order to offer electronic processing of tax returns. In order to protect the IRS’ EDC resources, the IT administrator defines a SAR as follows: “Limit the number of tax returns to process to no more than 1,000 over a period of 10 s”. As a second example, a cloud service provider (e.g., Google) with a Software as a Service (SaaS) offering maywant to protect their internal EDC network from saturation by limiting the amount of bandwidth customers use to access their applications. For this case, a SAR could be defined as: “Limit the amount of bandwidth for customer A to a maximum of 4 GB per 24-hour period”. Finally, Infrastructure-as-a-Service (IaaS) providers, such as Amazon EC2, define instances for billing purposes, and for protecting their EDC infrastructure. For example, Amazon would want to limit the resources consumed by a customer’s Virtual Machine (VM) by establishing the following SAR: “Client B is allowed to use a maximum of 1.7 GB of RAM, 25% of CPU power, and 160 GB of storage for its VMs”.

Existing Solutions for Service Traffic Shaping

We have so far identified in the literature two different strategies for performing service traffic shaping in service-oriented EDCs. The simplest strategy is to use a Manual and Static Allocation (MSA), in which the allowed rate is equally divided among all the SON appliances: xi = X × T B , ∀i ∈ [1, . . . , B], (2.1).
where xi is the number of credits allocated to appliance i, X is the maximum rate allowed per enforcement period, T is the duration of the enforcement period, and B is the number of appliances. This solution, although simple, is quite inefficient as it only provides satisfactory performance when the incoming traffic rates at the appliances are identical. Therefore, a number of appliances may hold queued requests while others remain idle.

Instantiation of the SystemArchitecture to theMultipointto- Point Case

The general architecture of the considered system is depicted in Fig. 3.1. There are four main elements composing this architecture:
Clients: The clients are nodes that generate service requests. They can be located anywhere in the Internet. In Fig. 3.1, Yin denotes the input rate of requests into the system.
Gateways: These are border routers. They are responsible of forwarding service requests to the SONappliances and of distributing the service load among the appliances without any deep-content inspection.
SON Appliances: These are middleware devices responsible for translating XML requests into the system’s local language. They are also responsible for controlling the rate at which the service requests are forwarded to the service host. In the figure, xi denotes the number of processed requests appliance Bi sends to the service host within some time interval.
Service host: This node handles processing of the requests. It also specifies the rate at which the services may be accessed or SAR. In the figure, the service may not receive more than C requests during an time interval of duration T, where C = X × T.

Related Work Specific to the Multipoint-to-Point Case

Many research efforts in the literature are oriented specifically towards QoS control in Web server farms. Nevertheless, these efforts center around enforcing SLAs defined in terms of maximum response times of a service. To this end, most of the methods are based on either service differentiation and prioritization[30;44], or admission control of new service requests[8;9], or both[3;20].
In particular, the work that is the closest to ours is the one of Garcia et al.[14]. The authors analyze the deficiencies in existing methods, define a number of requirements that any QoS control mechanism working in an enterprise environment should address, and establish their basic design principles. Along these lines, the authors propose a QoS control mechanism which determines themaximum number of concurrent sessions that a service host can process, and calculates the maximum admissible sessions in order to maintain the values specified by the SLA.
It is worth noting that, most of these research works involve the use of a centralized server and measurement/processing at the service hosts. Since the idea behind using a multi-tier architecture is to offload some tasks to be done from the servers, these methods are not applicable in our particular context. In contrast, our work aims at a decentralizedmethod for enforcing the SAR. Furthermore, we do not center our work on service response times or client differentiation and scheduling. Instead, our objective is to prevent service hosts from being overwhelmed.

Table of contents :

Remerciements
R´esum´e
Abstract
Acronyms
Contents
1. Introduction 
1.1. A Service-Oriented Internet
1.2. Problem Formulation: Resource Protection in Enterprise Data Centers
1.3. Contributions of This Thesis
1.3.1. Resource Protection in Single-Site Enterprise Data Centers .
1.3.2. Resource Protection in Geographically Distributed EDC Deployments
1.4. Outline
2. Service Traffic Shaping for Resource Protection in Enterprise Data Centers 
2.1. Service-Oriented Enterprise Data Centers
2.2. Service Level Agreements and Service Access Requirements
2.2.1. SAR Enforcement in Two-tier EDCs
2.3. System Architecture
2.4. The Service Traffic Shaping Problem
2.4.1. Scheduling vs. Shaping
2.5. RelatedWork
2.5.1. General Problem
2.5.2. Existing Solutions for Service Traffic Shaping
2.5.3. Rationale for contributions
2.6. Conclusion
3. DOWSS: Multipoint-to-Point Resource Protection 
3.1. Instantiation of the System Architecture to theMultipoint-to-Point Case
3.2. RelatedWork Specific to the Multipoint-to-Point Case
3.3. Issues with Existing Multipoint-to-Point Solutions
3.3.1. Flooring Effect
3.3.2. Starvation
3.3.3. Fast Start
3.3.4. Discussion
3.4. DoWSS: Doubly-Weighted algorithm for Service Traffic Shaping
3.4.1. Preliminaries
3.4.2. Case I: Empty Queues
3.4.3. Case II: Non-empty Queues
3.4.4. Conflict Resolution
3.4.5. Addressing the fast start issue
3.5. Evaluation
3.5.1. Experimental Setup
3.5.2. Performance Metrics
3.5.3. Performance under Uniform Traffic
3.5.4. Performance Under Bursty Traffic
3.6. Discussion
3.6.1. Optimality of Results
3.6.2. Communication Overhead
3.7. Conclusions
4. MUST: Multipoint-to-Multipoint Resource Protection 
4.1. Off-the-shelf SON Appliances and Traffic Shaping
4.1.1. From Multipoint-to-Point to Multipoint-to-Multipoint Shaping
4.1.2. Architectural Shortcomings of Off-the-Shelf SON Appliances
4.1.3. Arguments Towards New Algorithms
4.2. MUST: Multipoint-to-Multipoint Service Traffic Shaping
4.2.1. A Novel SON Appliance Architecture
4.2.2. A Multipoint-to-Multipoint Service Traffic Shaping Algorithm
4.3. Evaluation
4.4. Related work specific to the Multipoint-to-multipoint Case .
4.5. Conclusion
5. GEODS: Beyond Single-Site Enterprise Data Centers 
5.1. The Service Traffic Shaping Problem in Geographically Distributed EDCs
5.1.1. System Architecture
5.1.2. Issues in Geographically Distributed EDCs Inherent to the Presence of Network Latencies
5.1.3. Discussion
5.2. GEODS: Geographically Distributed Service Traffic Shaping
5.2.1. Assumptions
5.2.2. Choosing the Maximum Sending Deadline
5.2.3. Adapting to Changes in Incoming Traffic
5.2.4. Performing credit allocation
5.3. Evaluation
5.4. Conclusion
6. Conclusions and Perspectives 
6.1. Contributions
6.1.1. DOWSS: Multipoint-to-Point Service Traffic Shaping .
6.1.2. MUST: Multipoint-to-Multipoint Service Traffic Shaping
6.1.3. GEODS: Geographically Distributed Service Traffic Shaping .
6.1.4. Conclusion
6.2. Perspectives
6.2.1. Lack of Standardized SAR
6.2.2. Different Protection Metrics
6.2.3. ApplianceWeights vs. User History
6.2.4. Scalability
6.2.5. Distributed Shaping
6.2.6. Real-World Testbed and Datasets
Appendices 
A. R´esum´e de la th`ese en fran¸cais
A.1. Une Internet Orient´ee Service
A.2. Formulation du Probl`eme : La Protection de Ressources dans des Centres de Traitement d’Entreprise
A.3. Contributions de Cette Th`ese
A.3.1. Protection de Ressources dans des Centres de Donn´ees sur un Seul Site
A.3.2. Protection de Ressources dans des Centres de Donn´ees G´eographiquement Distribu´es
B. Two Architectures for Resource Protection
B.1. A System Architecture According to the Resource to Protect .
B.2. The Impact of the Architecture on the Performance of the System .
C. List of publications
C.1. Journals
C.2. Conferences
C.3. Posters
C.4. Under review
Bibliography 

GET THE COMPLETE PROJECT