+ All Categories
Home > Documents > Cloud Bursting Transcoder Nodes

Cloud Bursting Transcoder Nodes

Date post: 10-Feb-2022
Category:
Upload: others
View: 10 times
Download: 0 times
Share this document with a friend
55
Cloud Bursting Transcoder Nodes Thomas Rondahl April 21, 2013 Master’s Thesis in Computing Science, 15 credits Supervisor at CS-UmU: Lars Larsson & Daniel Espling Examiner: Jerry Eriksson Ume ˚ a University Department of Computing Science SE-901 87 UME ˚ A SWEDEN
Transcript

Cloud Bursting TranscoderNodes

Thomas Rondahl

April 21, 2013

Master’s Thesis in Computing Science, 15 credits

Supervisor at CS-UmU: Lars Larsson & Daniel EsplingExaminer: Jerry Eriksson

Umea UniversityDepartment of Computing Science

SE-901 87 UMEASWEDEN

Abstract

Within each web service there is a bottleneck which limits the maximum throughput. Inthis thesis the bottleneck of the media web service is in the task of transcoding. We explorethe option of creating new transcoding nodes on-demand to deal with the computationallyexpensive task of video transcoding.

The thesis presents a prototype for controlling the expansion of a transcoding service intothe cloud. Using cloud infrastructure-as-a-service allows for creation of new nodes, withoutany modification to the software and via a prototype RESTful API using a simple syntax.The prototype also includes a systems integration framework (Chef) to configure new nodesto run any specified service. Due to licensing issues, we could not install the transcodingsoftware itself while performing system testing. A substitute configuration of software ofsimilar complexity was installed instead, and a large suite of tests shows that a single newnode can be fully configured and a host notified about the node’s existence within approxi-mately 7 minutes. Updates/configurations can then be pushed out to all existing nodes, ora subset of nodes thereof. The destruction of nodes takes less than a minute and implicitlydisassociate the nodes with all related resources, allowing for resource management.

The thesis also explores the theoretical possibility of using MapReduce as a distributedmodel for a video transcoding service. Concepts in cloud computing, virtualization, videocompression and transcoding are discussed as a part of an in-depth-study.

ii

Contents

1 Introduction 1

2 Problem Description 3

2.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Purposes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Theory 5

3.1 Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2 Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.3 Cloud Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.3.1 OpenStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.3.2 AWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.4 Video Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.4.1 Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.5 Video Transcoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.6 MapReduce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.6.1 MapReduce Example: Word Counting . . . . . . . . . . . . . . . . . . 13

3.6.2 MapReduce for Transcoding . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Experiment 17

4.1 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2 Systems Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2.1 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2.2 Setup Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3.1 Client to RESTful Server . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.4 Protocol/RESTful API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

iii

iv CONTENTS

4.5 Production System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 Results 25

6 Conclusions 33

6.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

7 Acknowledgments 35

References 37

A Sample usage 41

List of Figures

3.1 Compression flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 Prediction between frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3 General transcoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.4 Map-function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.5 Reduce-function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.6 Distribution of transcoder load . . . . . . . . . . . . . . . . . . . . . . . . . 15

(a) Normal load on single process . . . . . . . . . . . . . . . . . . . . . . . . 15

(b) Distribution of load on multiple processes . . . . . . . . . . . . . . . . . 15

4.1 System design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.3 Production system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2 Initial Controller draft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1 One node statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.2 One node load variance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.3 Box plot one node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.4 Three nodes statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.5 Box plot three nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.6 Five nodes statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.7 Box plot for five nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.8 Seven nodes statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.9 Box plot for seven nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.10 Box plot for all creation times . . . . . . . . . . . . . . . . . . . . . . . . . . 32

A.1 POST xml body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

A.2 Create request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

A.3 Destruction request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

A.4 Status request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

A.5 Status request contains error . . . . . . . . . . . . . . . . . . . . . . . . . . 45

v

vi LIST OF FIGURES

List of Tables

3-1 Cloud computing service models . . . . . . . . . . . . . . . . . . . . . . . . 7

4-1 Creation syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4-2 Destruction syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4-3 Status syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5-1 Creation times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5-2 Destruction times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

vii

viii LIST OF TABLES

Chapter 1

Introduction

Video has been an important media for communication and entertainment for decades.Digital video is comprised of a series of bitmap digital images displayed in rapid successionat a constant rate, creating the appearance of a moving picture. An uncompressed videowould consume massive amounts of data space at higher frame sizes. To mitigate this issuedata compression, or encodings, is extensively applied on video formats.

Transcoding is used to convert digital data encoded in one format to another, where a transi-tion between a MPEG2 video stream to a H.264 stream is an example usage of transcoding.For video, this means that the video stream is decoded to an intermediate uncompressedformat for re-encoding and compression into the target format. This can also be used tofurther lower the bit rate when streaming media over the Internet, allowing for a smootherplayback at the client end.

This thesis suggests a way of expanding available computational capacity for a video transcoderservice, without requiring any modifications to the transcoding software and allowing foreasy integration via a Representational State Transfer (REST) style architecture [11]. Transcod-ing is a computationally expensive process and may be the bottleneck in a media web service.A traditional way of dealing with usage peaks is to purchase new (and costly) hardware,that may stay idle to a large degree (over-provisioning). This approach may not be optimalas virtual hardware can be rented on-demand using the cloud. As we are not aware whenthe increase in demand may occur we can utilize the flexibility of cloud computing to onlyallocate additional virtual hardware when it is necessary.

The cloud offers us new way of utilizing computational resources and easy access to virtualhardware. This way of managing resources on-demand is utilized by the created prototypefor creation of new nodes without the need to modify the existing transcoding software.

In addition to presenting and evaluating the prototype, this thesis also explores the theo-retical possibility of using the well know concept of MapReduce for distributed transcoding.This option was explored as a possibility for future work.

The remainder of this thesis is structured as follows: Chapter 2 describes the problems andgoals which were the basis for this thesis work. Chapter 3 explains some of the concepts

1

2 Chapter 1. Introduction

surrounding the area of cloud computing and virtualization. The composition of digitalvideo, transcoding and its internal structure is discussed, and a brief explanation of the pro-cessing model MapReduce and its possible applications in distributed transcoding. Chapter4 discusses preliminaries of the thesis project and elaborates on the prototyped system,components, and their functions. It explains the system protocol and syntax, Chapter 5presents the experiments concerning the time consumption of new service nodes creationand destruction. Finally the thesis report ends with Chapter 6 that concludes with a sum-mary of the collected results and the conclusions drawn from these and a section on futurework and comments on further development of the system.

Chapter 2

Problem Description

As long as there is no peak in the number of requests a media web server can deal respondto all requests without any issues. This depends on over-provisioning too, as idle resourcesalso is an issue. The web server has no problem serving the normal (average) flow of data,but when a peak in demand (unexpected or predicted) happens the overall performance ofthe service is dropped. Response time is increased and some requests may consume largeamounts of computational resources, causing requests to pile up.

The aim of this thesis project is to mitigate peaks in demand for a service without having toincrease local hardware properties. This is done via an expansion of the number of availablenodes into the cloud.

2.1 Goals

The project consists of several goals.

– Creating RESTful architecture, using a simple request format for creation of newnodes, allowing for easy integration in an existing system.

– Create new instances in the cloud, via a simple interface.

– Configuration of the newly created instances.

2.2 Purposes

– Creating a prototype framework for extending the number of available nodes to thecloud using a simple RESTful interface.

– Designing a prototype which will work as proof-of-concept for the idea.

3

4 Chapter 2. Problem Description

– Establishing future development of the project may help companies that experiencethe described issues and wishes to mitigate them using the suggested solution.

Chapter 3

Theory

In this chapter the overall theory for the thesis work is covered. It starts with a basicintroduction to virtualization as a part of cloud computing and various concepts utilized by,and of importance to, the service. Two of the major cloud Operating Systems providers areelaborated on and compared, Amazon Web Services a pay-per-use service, and OpenStack,a free system which can be installed and maintained by the users themselves. A sectioncovering the digital video structure and some related concepts is explained and followed bya section explaining the concept of video transcoding and its purpose. The chapter concludeswith a section concerning MapReduce and the utilization of this technique as a basis fordistributed transcoding.

3.1 Virtualization

The goal of system virtualization is to pool the resources of physical hardware so they can beutilized on-demand by multiple processes isolated from each other. In cloud computing theconcept of system virtualization is important as it allows providers to house multiple logicalcompute instances on same physical hardware, sharing computational resources. The systemvirtualization is implemented by a thin layer of software, called hypervisor, on top of theunderlying physical machine architecture. The software running on the physical hardwareis known as the host and the virtual software is known as the guest.

There exists several types of virtualization, mainly three; Container virtualization, Fullvirtualization and Para-virtualization.

Container virtualization runs the guests in user-space, where all guests share the samefilesystem tree and hardware. Using isolation of the guest rather than virtualization of thehardware can achieve native execution speeds. For a container-based solution a modifiedkernel is needed to run the virtual environments. The process isolation and resource man-agement is provided by the kernel. All of the virtual machines use the same kernel buteach machine appears to each have their own filesystem, processes, etc., this is due to theresource isolation enforced by the kernel. All guests are processes running in parallel using

5

6 Chapter 3. Theory

process isolation to enforce the appearance of their own virtual resources.

Full virtualization runs an unmodified version of the guest’s OS. All instructions, I/O op-erations, memory, etc. are emulated. There may exist some hardware support providingbare metal access for some instruction sets. This type of virtualization used to have a highoverhead in operation due to the emulation of all system calls, but with the current develop-ment of hardware support for virtualization the overhead for full virtualization differs littlefrom other types of virtualization [17]. Even if there is a loss in performance this is oftenacceptable due to the usability of an OS with an unmodified kernel. Full virtualization isused by such software as VMWare, KVM and Xen HVM. Full virtualization can use a com-bination of binary translation and direct execution of system calls for applications [34]. Thistranslates kernel code to replace non-virtualizable instructions with new sets of instructionsyielding the desired effect on the virtual hardware.

Para-virtualization does not emulate everything, using a form of white-listing for certainpredefined tasks which is executed in the host domain rather than in the virtual domain(where execution performance is worse). This approach gives a good performance with littleoverhead, however guest OS must be slightly modified but applications do not require anymodifications. The para-virtualization hypervisor provides a “hypercall” interface for othercritical kernel operations such as memory management. In difference to full virtualizationwhere the unmodified OS does not know it is virtualized and sensitive system calls aretrapped using binary translation, para-virtualization OS cannot support unmodified guestOS, but offers lower virtualization overhead. Xen uses para-virtualization and modifiedguest OS to virtualize its hardware [36].

3.2 Cloud Computing

Cloud computing is a model for enabling a convenient on-demand pool of configurable com-puting resources. The essential characteristics [18] as described by NIST are: on-demandself-service – a customer can provision computational capabilities without a human inter-mediary, broad network access – service always available via network, resource pooling –the computational resources are pooled dynamically assigning and reassigning according todemand, rapid elasticity – the capacity can rapidly, and elastically, be provisioned, and mea-sured service – resources can be monitored, controlled and reported. The NIST definition ofCloud Computing specifies Could bursting under the section of Hybrid cloud where: “Thecloud infrastructure is a composition of two or more clouds (private, community, or public)that remain unique entities but are bound together by standardized or proprietary technol-ogy that enables data and application portability (e.g., cloud bursting for load balancingbetween clouds).” [18, p. 3]. To meet peaks in demand without having to expand the localinfrastructure with new hardware, cloud bursting can be used to mitigate these problems byoffloading to the cloud. The usage of a cloud bursting model may reduce overall latency athigh peaks in demand without a too great financial investment. By utilizing cloud burstinga local cloud can reduce the costs associated with hardware maintenance.

There are three fundamental service models of cloud computing: infrastructure as a ser-vice (IaaS) – this provides the client, with processing power, storage, networks, and otherfundamental computing resources where the consumer is able to deploy and run arbitrary

3.3. Cloud Operating System 7

software, which can include operating systems [18]. Another model is platform as a service(PaaS) – the client deploy their software on the cloud using the programming language andtools supported by the cloud provider, the client does not control over the underlying cloudinfrastructure, but has control over the deployed software. An example of this is GoogleApp Engine [37]. Additionally there is software as a service (SaaS) – the client has accessto a thin interface to a service, the client has no control over the underlying infrastructure,an example of a service using this structure is Gmail [35] which has a cloud back end andis accessible via a thin client interface, e.g., a web browser. Table 3-1 shows the hierarchyof the different models.

SaaSApplications | User Interface – Machine Interface

PaaSPlatform | Components – Services

IaaSInfrastructure | Compute – Network – Storage

Table 3-1: Cloud computing service models.

The IaaS model allows for total customization of a basic virtual machine where the client maydeploy any software including operating systems and applications. This model was selectedfor the development of the thesis prototype as the model allowed for usage of unmodifiedsoftware applications. The ability to modify the infrastructure using a systems integrationframework in order to setup the required software. This type of cloud computing modelscan also offer monetary savings since the compute power (hardware), storage and networkdoes not need to be purchased and maintained as investigated by Sushil Bhardwaj et al. [6]2010.

3.3 Cloud Operating System

The cloud operating system is the platform which provides the various services associatedwith cloud computing. The system developed for this thesis utilized a cloud-based platformfor the expansion of nodes known as OpenStack.

3.3.1 OpenStack

The OpenStack Cloud Operating System [22] is an open-source project which supports arich community of users and an continuous development. It was created July 2010 as a jointinitiative by Rackspace Hosting and NASA as a new open source cloud software. TodayOpenStack is used by as many as 150 well-known companies, among which are Canonical,IBM, Red Hat, Intel and PayPal [21]. OpenStack is licensed under the Apache 2.0 license.The OpenStack OS also offers Amazon Elastic Compute Cloud (similar to OpenStack Nova,see section 3.3.2) compatible interfaces [20]. OpenStack is divided into sub-projects, one

8 Chapter 3. Theory

of which being Nova, which offers control over OpenStacks compute part and allowing forcreation of compute instances (in an IaaS manner) [27].

OpenStack Nova can work with many types of virtualization as well as bare metal andhigh-performance computing. Virtualization technology supported and available is KVM,XenServer and qemu as hypervisor, together with Hyper-V and Linux containers such asLXC [23].

3.3.2 AWS

Amazon Web Services is a set of cloud services, where the Amazon Elastic Compute Cloud(EC2) service would be a similar service to the OpenStack Nova service. Launched in July2002, it was initially developed for internal purposes in supporting their electronic retailbusiness [9] and made available to the public in 2006 [4]. Amazon was one of the first majorcompanies to provide a cloud computing service to a broad public. Amazon EC2 computeunits work on a pay-as-you-go basis where the client specify which amounts of computationalresources he/she wants to be available and then pay for the usage of said resources accordingto some metrics; such as data transfer and hours of activity [2].

One advantage OpenStack offers over AWS is that it does not tie the user to a specificcompany’s hardware and business model. Also the monetary advantage of OpenStack is ofcourse an argumentative point. Anyone can setup an OpenStack cloud infrastructure, as itis free to use [25]. This is also however one of the disadvantages, the hardware support fallson the user. AWS also offers the ability to closely monitor created instances which could beused to create a billing model, a similar service is also available in OpenStack.

Amazon EC2 is build on top of a Xen hypervisor which can run a number of operatingsystems such as Windows Server 2008, Linux and OpenSolaris [3].

3.4 Video Encoding

A video in its raw format is a series of pictures (frames) which is played at a specific rate,creating the appearance of a moving picture. The raw format of video requires a largeamount of data and the communication bandwidth may limit the resolution of a video at itsraw format. This is shown in Equation (A-3.1), where W is the width of the frame in pixels,H the height in pixels, CD the color depth in bits, FPS is number of frames per second andBR is the bit rate per second.

W ×H× CD× FPS = BR (A-3.1)

Equation (A-3.2) shows a frame size of 720(H)×1280(W) (HD quality) pixels with a playbackframe rate (FPS) at 60 frames/second, a 3 color representation (RGB) with 8 bits per colorgiving a color depth (CD) of 24 bits. This gives a very data-dense medium which is notsuitable for a portable format. Let us consider this uncompressed format on a Blu-ray discwhich has a storage of 25 Gbytes. The example shown in Equation (A-3.2) would allow

3.4. Video Encoding 9

for 150 seconds of playback, since the bit rate is 1.33 Gbps. For most cases, this is asevere limitation, and to mitigate this issue a compression is applied to the data to allowfor increased information density, see Section 3.4.1.

1280× 720

pixles/frame× 24

bits/pixel× 60

frame/sec≈ 1.33Gbps (A-3.2)

3.4.1 Compression

To mitigate the bandwidth requirement of the raw video format a compression is intro-duced to shrink the size of the required data [7]. Typically, this is performed by reducingredundancy between highly correlating consecutive frames. The compression is usually lossywhere a loss in quality after compression can be expected. Figure 3.1 shows a generic com-pression flow, where the digital media enters the Encoder and is compressed in two stages;the core of the compression is the source coder which preforms the compression by reducingthe input data rate to a level that can be supported by the target format. The channelcoder translates the compressed bit stream into a signal suitable for the target format.

SourceCoder

ChannelCoder

SourceDecoder

ChannelDecoder

Encoder

Decoder

Digital Video

Digital Video

Figure 3.1: Generic compression system.

Redundancy removal is based on irrelevant data reduction. Information that is outsidehuman perception can be removed to reduce size of each frame. Each frame is in essence animage which can utilize known and efficient image compression algorithms such as DiscreteCosine Transform (DCT) transformation [19, 7]. The most commonly used form of DCT istype-II DCT which invention is accredited to K. R. Rao et al. [19], seen in Equation (A-3.3)where N is the block size.

Xk =

N−1∑n=0

xncos

N

(n+

1

2

)k

]k = 0, . . . , N − 1 (A-3.3)

10 Chapter 3. Theory

Still image compression such as the JPEG standard can be applied to each frame to exploitthe spatial and color redundancy that exists in a single still image. JPEG exploits the factthat the neighbouring pixels in an image are often highly similar, and partitions an imageinto 8×8 pixel blocks and compute DCT for each block. For RGB images the color space isconverted to a luminance (achromatic, black and white, information) and chrominance (colorinformation without brightness) color space where different human visual perception for theintensity and chrominance characteristics can be more effectively exploited. The humanvision is more sensitive to luminance differences, therefore the chromatic information canbe stored at a lower resolution. DCT transformation decomposes each block into a series ofwaveforms, each with a particular spatial frequency.

While compression (such as JPEG) can be applied to each individual frame, neighbour-ing frames often share similar features and much higher compression can be achieved byexploiting the spatial similarities between the frames.

W ×H× CD× FPS

CF= BR (A-3.4)

Equation (A-3.4) shows a representation of an equation for determining new bit rate aftercompression algorithm is applied. Note that the variable CF denotes compression factorand is not necessary applied equally to all frames.

I0 B1 B2 P3 B4 B5 P6 B7 B8 I9

Figure 3.2: Prediction dependencies between frames.

Figure 3.2 demonstrates an example of using motion estimation (ME). The process of form-ing a prediction while compensating for the relative motion between two frames is known asmotion-compensated prediction (MC-P). In MC-P the frame is partitioned into fixed sizedblocks of pixels, block motion compensation (BMC), the blocks correspond to a block ofsame size in the next frame. For MPEG Group of Pictures (GOP) the block size is 16× 16pixels for motion compensation and 8 × 8 for DCT coding [5, 30]. The blocks are nottransformed in any way other then applying a shift of the position, represented by a motionvector. The block may be shifted by a non-integer number of pixels, know as sub-pixelsprediction. Such “pixels between pixels” are generated by interpolating the neighbouringpixels. This is exploited where there is redundancy between neighbouring block’s motionvectors and it is common to to encode only the difference between the current and previousvector. There are three types of coded frames; I-frames are coded independently and does

3.5. Video Transcoding 11

not require any other frames in order to decode, P-frames (previously coded) are codedbased on a previous coded frame, and B-frames (bi-directional) can predict both the previ-ous and forward frames. Using BMC and DCT the bit rate can be greatly compressed, theusage of the 16×16 pixel blocks allow for error concealment where the prediction might notrequire all blocks to form an image. Redundancy in the motions can be compressed usinga vector. These blocks are grouped in macroblocks (MBs) where each MB typically consistof a luminance block along with corresponding chrominance blocks [33].

The temporal redundancy can be reduced by applying a motion compensation, expressedin Equation (A-3.5); where I(x, y, t) are pixel values at coordinate (x, y) in frame t andI(x − u, y − v, t − 1) are corresponding pixels values at (x − u, y − v) in frame t − 1. Thecoordinates (u, v) defines the relative motion of a block from one frame to another [7], thisis the motion vector as mentioned above.

e(x, y, t) = I(x, y, t)− I(x− u, y − v, t− 1) (A-3.5)

Many different standards exists for video encoding, such as; H.264/MPEG-4 AVC which hasmany implementations amongst them. Well known examples QuickTime H.264 and DivXPro Codec. Various companies also have their own codecs e.g., Microsoft Windows MediaVideo (WMV) and ProRest by Apple, Inc.

3.5 Video Transcoding

Transcoding shifts one or more aspects of a video to another, e.g., changing the bit rate andvideo encoding format. This type of service can be used in cases where a client requests acertain previously unavailable video format, or when a service has limited bandwidth and amore effective video container format can be utilized to mitigate this issue using transcoding.The introduction of smart-phones that can view video also enforced the need for transcodingmedia to a more portable format, with a low bit rate to avoid use of too much of the limitedbattery and bandwidth resources available. The general concept of transcoding is illustratedin Figure 3.3.

Bit rate: BR1Frame rate: FR1Resolution: S1Video stream: V1Audio stream: A1Container: M1...

Bit rate: BR2Frame rate: FR2Resolution: S2Video stream: V2Audio stream: A2Container: M2...

Transcoder

Figure 3.3: General transcoder.

An idealized implementation of a transcoder would contain a decoder cascading to an en-coder as the decoder decodes the compressed video and the encoder re-encodes the decoded

12 Chapter 3. Theory

video to the target format. The process of decoding and re-encoding is a computationalexpensive process and not necessary in all aspects, as many of previous encoding decisionscan be reused in the re-encoding process. Multiple consecutive encoding will result in a lossof quality if the encoding is not in a lossless format. Some of the steps of the decoding andre-encoding are therefore left out through reuse of past encoding decisions that already weremade during the last encoding, such as motion vectors and macro blocks. The basic conceptof transcoding in a cascade manner may also entail far too complex transcoders. Transcoderswill, generally, cascade a decoder and an encoder and then analyse which elements of thetwo can be combined, noted by Gertjan Keesman et al. [15] 1996. This is the main part ofthe process called transcoding and is highly optimized and more computationally efficientthen re-compression.

An example of transcoder application is, say, if a satellite transmits a MPEG-compressedvideo signal at 9 Mbit/s. The cable end that receives the signal wants to relay the videosignal at 5 Mbit/s. The presented problem is a high bit rate video that needs to meetthe lowest bandwidth limitation. Here a shift in bit rate can be applied by transcodingspecific properties of the video signal; such as a reduction of the frame size and compressingthe spatial resolution. This is performed by subsequently decoding, spatial-domain down-sampling, followed by a full re-encoding [33] in the desired target format and allowing for areduction of the bit rate.

3.6 MapReduce

MapReduce is a processing model for large data sets pioneered by Google and published2008 [10]. MapReduce is a highly scalable (processing petabytes of data in hours [31]),distributed, fast and fault-tolerant processing tool. The model has its basis in functionalprogramming where map and reduce functions are common, where map applies a functionto each element in a list and returns the results as a list and the reduce function recursivelyanalyses the elements and recombines them according to a specified combining operation.The programming model offers inherent distributed computing for problems. MapReducehas an inherent fault tolerance where failed jobs simply is re-executed by a new node, andnew worker nodes can be introduced at any time during the execution of the process.

A flow of the MapReduce function over a large network of nodes can be illustrated in thefollowing simplified steps:

1. Collect large amounts of data.

2. Master node process input and passes processed sub-problem to distributed networkof nodes.

3. Map: each node process data and collect the relevant information from input, con-structing partial answers.

4. Each work node passes back partial answers to master node.

5. Master node groups values.

6. Reduce: aggregate answers and combine them to a form of output.

3.6. MapReduce 13

In general terms, the map-function is described [10] as: Map(key1, value1) → list(key2,

value2), and the reduce-function as: Reduce(key2, list(value2)) → list(value3).

3.6.1 MapReduce Example: Word Counting

The below explained example of MapReduce creates a list of the number of times each wordis mentioned in a text collected from an URL.

A set of data with the structure: <URL, text> → list(<word, count>)

<URL, "the quick brown fox jumps over the lazy dog"> → list(<"the", 1>, <"quick",

1>, <"brown", 1>, <"fox", 1>, <"jumps", 1>, <"over", 1>, <"the", 1>, <"lazy",

1>, <"dog", 1>)

Using an implementation of the pseudo-code suggested by J. Dean and S. Ghemawat [10,p. 2], seen in Figure 3.4.

1 map(String key, String value):

2 // key: document name

3 // value: document contents

4 for each word w in value:

5 EmitIntermediate(w, "1");

Figure 3.4: Map-function as suggested by J. Dean and S. Ghemawat [10].

The grouping then combines the result by putting all values for same key together: <"the",list(1,1)>, <"quick", list(1)>, <"brown", list(1)>, <"fox", list(1)>, <"jumps",

list(1)>, <"over", list(1)>, <"lazy", list(1)>, <"dog", list(1)>

The reduce-function then processes the output from the grouping and aggregates the resultgenerating the final output. <"the", 2>, <"quick", 1>, <"brown", 1>, <"fox", 1>,

<"jumps", 1>, <"over", 1>, <"lazy", 1>, <"dog", 1>

The reduce-function pseudo-code suggested by J. Dean and S. Ghemawat [10, p. 2], seen inFigure 3.5.

MapReduce allows for easy distribution of computational problems, new workers can beadded on-the-fly to replace old ones or to increase the computational capacity of the network.The usage of inexpensive hardware is possible due to the relative ease of the computationalproblems (provided that the map-function is effective enough).

3.6.2 MapReduce for Transcoding

Using MapReduce for transcoding can be beneficial in many ways as suggested by NavdeepS. Chahal and Baljit S. Khehra [8] and Myoungjin Kim et al. [16]. Using a distributed file

14 Chapter 3. Theory

1 reduce(String key, Iterator values):

2 // key: a word

3 // values: a list of counts

4 int result = 0;

5 for each v in values:

6 result += ParseInt(v);

7 Emit(AsString(result));

Figure 3.5: Reduce-function as suggested by J. Dean and S. Ghemawat [10]

system like Hadoop Distributed File System (HDFS) Myoungjin Kim et al. [16] showed thatit is possible to distribute the process of transcoding using a MapReduce based solution.

The transcoder software used for this thesis was at an early stage indicated to be CPU-bound, and that the migration to a distribute model would require major reworking of corecomponents and possibly still result in I/O-bound queue instead. However Chao Tian etal. demonstrate a “A Dynamic MapReduce Scheduler for Heterogeneous Workloads” [32]having a high throughput.

The distribution of transcoding using MapReduce would require a chunk:ing of the mediafile in a manner which would create chunks capable of being individually transcoded andthen recombined to form the output, e.g., target media/format. The chunk:ing of the videowould have to be specified for each type of encoding, as the Figure 3.2 illustrates where theMPEG-4 format would entail a chunk:ing at I-frames and using a set of predictable andbi-directionally predictable frames to make up each segment.

Figure 3.6a shows an example of the normal load on a transcoder, where the client sendsmedia to be transcoded and the transcoder queues jobs which can not be executed in parallel.Then the output is produced and collected by the client. An example of a distributedapproach can be seen in Figure 3.6b where the job is split into computable chunks andsent over a network to transcoder nodes, which independently execute transcoding and theresults are combined in a separate stage in the end of the processing.

Ideally, parallelism should improve the availability and throughput of the system, and alsoprovide better utilization of the available resources. This approach using MapReduce todistribute transcoding could allow for a fast and fault tolerant system, assuming that thesegmentation into chunks have been created in an effective matter and that the groupingof all mapped answers can be performed in order to accommodate the requirements of thetarget format.

An implementation of MapReduce as distribution model for transcoding could be used tomitigate another issue, the cost of hardware. Instead of buying expensive high-performancemachines, the distribution of relatively computationally easy assignments can be done onlow-performance machines and still produce a high throughput.

3.6. MapReduce 15

(a) Normal load on single process

(b) Distribution of load on multiple processes

Figure 3.6: Distribution of transcoder load.

16 Chapter 3. Theory

Chapter 4

Experiment

During the course of this thesis work we have created a functional prototype that worksas a proof-of-concept for a cloud bursting service using a RESTful API. We have created aprototype of a RESTful API server which allows for easy integration to an external appli-cation. The usage of OpenStack allowed for testing of the cloud bursting service, and someindications of how a complete system would function.

The prototype uses several types of Chef recipes for testing of setup time-consumption. Thetype of IaaS instances requested by the prototype were OpenStack Nova “flavour” m1.small,which supplies 2 GB RAM, 1 VCPU and 10 GB of disk. The nodes were configured to runthe Apache HTTP Server as a stand-in for the transcoder software, and to serve a specifiedwebpage to allow for verification of correct configuration.

4.1 Preliminaries

The preliminary, and final, system flow is illustrated in Figure 4.1. Where the figure illus-trates the flow as a new compute node is requested by the client (step 1), created (step 2),configure to specification (step 3), and finally the client is notified of the new nodes existence(step 4 and 5).

This preliminary design of the system was used throughout the project and is stronglyreminiscent of the finished prototype. The different components have been selected in orderto fit a specific provider or service, this is elaborated in Section 4.2.

The development of the prototype started with an introduction to all of the framework whichwas to be utilized in the system, such as jclouds and Chef. The RESTful API was designedusing the basic idea of resource handling which is associated with a RESTful interface,where the REST style abstracts the implementation, protocol syntax and allows the userto interact with the roles of the components and their associated resources, as suggested byRoy Thomas Fielding [11].

17

18 Chapter 4. Experiment

Controller

1. Resource Request

Internet

2. Spawn n-number of nodes to meet demand

Cloud infrastructure

Setup server

3. Each node gets configuration from setup-server

4. Nodes alerts Controller when they are ready

5. Controller notifies client service

Client

Figure 4.1: System design

The usage of OpenStack was chosen due to the availability of this resource via the de-partment of Computing Science, it being free of charge, as well as having good integrationopportunities with AWS components of similar type such as OpenStack Nova and AmazonEC2. The choice of Chef as setup manager weighed heavily as jcoulds offered a built-in API[14].

4.2 Systems Components

Two services are deployed in the system. One uses JAX-RS (Java API for Restful WebServices) to expose a REST endpoint and host the jclouds cloud connection application(the Controller), and the other is a private Chef server with “recipes” for a number ofsystem configurations. These services uses network communication and can therefore eitherbe deployed on separate nodes, or co-located on a single node. Below is a summary ofcomponents used in the prototype, as suggested in Figure 4.1 and expanded in the systemflow, show in Figure 4.2.

4.2.1 Controller

The Controller exposes the RESTful API and creates the new service nodes in the cloud.It also destroys nodes which no longer are needed, on command. The Controller also allowsthe client to get the current progress of any jobs, additionally the Controller supports acall-back function which notifies the client when a job is completed.

In the back end; the connection to the cloud infrastructure OpenStack is a simplified cloudinterface called jclouds. jclouds is a library for Java which allows for high-level access tocloud provider API using Java classes, having an intuitive structure and a well supported

4.3. System Overview 19

forum and active development. jclouds provides an API in order to handle creation anddestruction of virtual machines programmatically as a cross-cloud abstraction layer [13].jclouds was selected as cloud interface due to its active development and good interfaceconnection to OpenStack and Chef (see Section 4.2.2). The functionality of the Controlleris accessible via a REST interface using the Jersey implementation of JAX-RS.

The HTTP communication is handled by Jersey, Jersey is an open source reference imple-mentation (of JAX-RS and JAX-RS 2.0; JSR 311, 339 [28, 29]) for RESTful web services.Jersey also allowed for integration with Gson [12] to parse JSON data into Java objects,giving an implicit format checking on the received data – this did however lack intuitivefeedback, yielding 500 on parsing error. A move to manual parsing allowed for a more intu-itive 400 return code on parsing failure. Jersey can be deployed on a number of applicationservers such as Glassfish, Jetty and Apache Tomcat.

Tomcat is an open source web server and servlet container developed by the Apache SoftwareFoundation (ASF). Tomcat can be used to deploy web archive files to run as web services.For this thesis prototype system Tomcat 7 (Apache Tomcat Version 7.0.14) was used asdeployment platform. Tomcat offered some basic implementations of authentication using asimple XML configuration and roles system which was used to illustrate some basic securityaspects. This deployment platform was chosen due to previous experience and some basicfamiliarity with the system.

4.2.2 Setup Server

The setup server configures new nodes and can update all existing (or a subset of) nodes.The system uses the systems integration framework Chef, to push out setup configuration tonew nodes and to push out future updates to the software. This is utilized in the prototypeto install the newly created compute unit in the cloud. The Chef server uses public keys forauthentication and offers encrypted connection to all clients. There is also a web-interfacethat, if installed, allows for easy overview of available nodes. The SSH connection usesa public key-pair installed at the creation of the node via OpenStack Nova association.Support for Chef integration in node creation exists in jclouds API as a library package [14],allowing for an easy integration with the prototype system.

The Controller send a recipe name to the Chef server which is matched to an install scriptfor the desired software setup. Using SSH the script is passed to the desired node andexecuted. The node is registered to the Chef server and this enables the system to push outany updates to all registered nodes via Chef server.

4.3 System Overview

This section elaborates on the conversation between client and the RESTful application andthe different types of requests that can be made. The back end jclouds connection createsOpenStack Nova instances and creates a public key-pair association.

20 Chapter 4. Experiment

4.3.1 Client to RESTful Server

The client requests a number of new instances via the RESTful service as show in Figure A.2.The request is authenticated using basic HTTP authorization and the body is verified usingGson [12] for Java, where the body is parsed into a Java object. If this fails an HTTP errorcode is returned to the client. Same type of basic authentication is applied for all calls tothe RESTful server.

In the creation call the user specifies a username for the jclouds cloud provider connec-tion and the same username will be used for any Chef configuration calls. The recipemay be any recipe which exists on the chef server and is configured to be available forChef usage. A callback address and method may be specified to receive notification whenthe creation of all instances have been successful. As seen in Figure A.2 the address ishttp://localhost:8080/Controller?ips=$1 where $1 will be replaced with public IPaddress of the newly created instances as such: IP1,IP2,...,IPN. If creation of all in-stances is completed without errors then the specified address will be connected to usingthe specified method. A body may also be specified following the same convention as theURL replacement i.e., a body with the content in Figure A.1, this would also require thecall to specify a Content-Type of the body.

The destruction of nodes follows a similar flow as in the creation of new nodes, as seenin Figure A.3, showing a POST call containing; number of instances to destroy and whichgroup these nodes exist in. The call can be done blocking, as this action rarely takes morethan one minute to complete (see Table 5-2) and the client may wish to take action directlyafter the nodes have been destroyed.

4.4 Protocol/RESTful API

Below the syntax for interaction with the prototype are demonstrated. Some HTTP statuscodes are not described, such as 403 Forbidden which indicates incorrect credentials – thismay happen for all REST calls. Also all error codes for the parsing of the POST body willyield a more descriptive error message. A correct body that contains incorrect values, suchas a non-existing username for the Chef server, will not generate any error codes at theinitial create call. This will however encounter an error at a later stage which will be visiblein the job status, see Figure A.5. The create and destroy request format may yield 400

for document format error this is due to the automatic casting of JSON to Java objects byGson and a basic value check, if no syntax error is detected.

Creation of new transcoder node syntax is show in Table 4-1. Destruction of existingtranscoder node syntax is show in Table 4-2. Get node creation status, and status of pastjobs complete with all potential errors seen in Table 4-3. By specifying the id parameterthe call attempts to collect status of a specific job.

4.4. Protocol/RESTful API 21

Method/URL POST /job/start

Accepts application/json Support data for node cre-ation.

Produces application/json A job document that de-scribes the job status.

Status codes201 Created A new node creation job is

started.400 Bad Request Job document wrongly for-

matted.

Table 4-1: Starting new nodes syntax.

Method/URL POST /job/stop

Accepts application/json Support data for node de-struction.

Produces text/plain A short confirmation ofasynchronous/blocking de-struction.

Status codes200 OK A blocking destruction job

is completed.201 Created An asynchronous destruc-

tion job is created.400 Bad Request Job document wrongly for-

matted.

Table 4-2: Destruction of nodes syntax.

Method/URL GET /job/status/{id}Accepts */*

Produces application/json Complete log of current andpast jobs.

Status codes200 OK Request successful.404 No Found No job with id {id}.

Table 4-3: Get status of all past and current jobs.

22 Chapter 4. Experiment

4.5 Production System

For the production system the communication to the transcoder must be confidential be-tween the client and the product. As part of the original plan, this thesis offers a designsuggestion for such a system.

The transcoder grabs the media via File Transfer Protocol (FTP) or Hypertext TransferProtocol (HTTP). The addition of SSL/TLS (SFTP/FTPS/HTTPS) would allow for en-cryption of the traffic to and from the transcoder. This will have an impact on the overallperformance as the system uses VCPU the task of encryption will consume substantial com-putational resources, however modern CPUs often have hardware supported encryption andthe traffic will likely still remain I/O bound by the bandwidth.

A common file surface for storage of the media files would be required, in order for thetranscoder to be able to access the media files. The current implementation of the transcoderrequires read access to the files. If the transcoder exists in the cloud the media files must bemade available outside of the initial upload instance. A possible solution to this issue couldbe to employ OpenStack Swift (or Amazon Simple Storage Service) which provides storagethrough web services. Using OpenStack Swift cloud also provide low latency if it occupiesthe same cloud as the nodes.

Client

Webstorage

Upload media topublic storage

transcoder

Start transcoding job, including address

to media data

Figure 4.3: A suggested system for preserving media privacy.

The ability to track usage of resources, as provided by OpenStack and AWS [26, 1] allowsfor a very efficient way to charge users for their usage. At times when the demand is lowerit is possible to rent out the nodes (giving exclusive access to the service), while still havingthe nodes active in preparation for a predicted increase in traffic in the foreseeable future.As the prototype uses OpenStack there should be little issues to migrate from OpenStackto Amazon EC2, since the OpenStack Nove API is compatible with the Amazon EC2 API[24].

4.5. Production System 23

REST

Parse JSON

Act

Terminate

Status

Spawn

Collect

Collect allrelevant machines

Returnstatus of allactive machines

Terminate

Send terminate tonon-working machines

Wait for confirmationthat an instance hasbeen spawned

Configure

Call chef for config

Work call from Internet

Figure 4.2: Initial RESTful controller system flow draft.

24 Chapter 4. Experiment

Chapter 5

Results

Table 5-1 shows creation and configuration times for a variety of simultaneous node creation.All the time data have been collected from 125 runs, data and box plots is available inFigure 5.1—5.10. Figure 5.2 also illustrates an encountered anomaly which can be used toexplain differences in time and extreme values. A comparison of all creation times can beseen in Figure 5.10.

Number of nodes Average time

1 7 Minutes 26 Seconds3 13 Minutes 51 Seconds5 22 Minutes 28 Seconds7 32 Minutes 45 Seconds

Table 5-1: Setup time for node creation, using configuration recipe apache2.

Number of nodes Average time

1 14 Seconds3 40 Seconds5 52 Seconds7 57 Seconds

Table 5-2: Destruction of instances, disassociation of Chef clients and deallocation of publicIP-addresses.

In Figure 5.6 there exists an outlier at sample 59 which deviates from the expected valuesat 3975, this value may be the result of any number of variables, such as extremely highload from other processes, and is not a fair representation of the overall performance of thesystem. This value was thus removed from the box plot in Figure 5.7 and 5.10.

The overall difference in creation time may vary due to the current load of the system. Ifthe load is high the assignment of resources may consume more time. Also the executionof commands may be scheduled to allow execution time for all currently running instances.Some extremely deviant values may be (see Figure 5.6) anomalies in the scheduling of

25

26 Chapter 5. Results

0 10 20 30 40 50 60 70 80 90 100 110 120 1300

100

200

300

400

500

Sample number

Tim

e(S

econd

s)

CreateDestroy

Figure 5.1: One node creation, configuration and destruction statistics.

processing access and disk I/O. The tests which included starting seven simultaneous nodes(see Figure 5.8) generated a number of failed attempts of creation.

Approximately 30 attempts failed for seven simultaneous nodes creation, generating nostatistics, this may be due to a number of reasons; the original test gathering did notproduce enough data points and another test was started to supply the missing amountsof data points and the two results was combined. One theory of why the creation failedfor some of the jobs is that the system had not been allowed sufficient time to release allresources associated with the previous test. The system does however wait for OpenStack tosend a TERMINATED status, which should indicate that the instance and all its resources havebeen released. This issue could be solved by adding a form of resource check, attempting toconfirm that all resources have been released after destruction of nodes to ensure that allassociated resources have been deallocated and returned to the system.

This assumption gains some merit in the experiments that produced Figure 5.2. Where theline showing the creation time for 1 node when the system is under no additional stress has,in comparison to the creation time of the node when the system is under high load, a stabletime consumption. To emulate high background load (HL) at the creation testing of nodesin OpenStack, the command dd if=/dev/zero of=/dev/null was started, causing 100%of CPU resources for one core to be utilized. HL shows much less stable time consumptionwith σ = 25.5 as compared to σ = 6.8 for the “No load” (NL) scenario, and the averagecreation time is HL 489 compared to 446 seconds for NL. Similar statistics can be found forthe destruction of nodes time, where HL average time is 21 seconds and σ = 8.77 compared14 seconds and σ = 4.5 for NL. The variations can be seen in Figure 5.3. The creationof 1 node under NL does not guarantee that all system resources are available as otherpeople also had access to the system and could utilize it at their own discrepancy. Howeverfrom Figure 5.2 we can draw the conclusion that system load has a significant impact on

27

0 10 20 30 40 50 60 70 80 90 100 110 120 1300

100

200

300

400

500

600

Sample number

Tim

e(S

econ

ds)

Create (High load)

Create (No load)

Destroy (High load)

Destroy (No load)

Figure 5.2: One node creation, configuration and destruction statistics; when the system isunder high load as well as no additional load.

the performance. The time data collected for seven node creation has a large amount ofvariation (see Figure 5.8 and 5.9), which may be due to the relatively long creation time,during which other processes will be scheduled to perform their tasks and thus impactingon the creation time. This could indicate somewhat poor isolation of the processes onOpenStack. A similar anomaly may exist in the three node creation, at sample number 57,a tangible increase in the overall creation time from 741 seconds to 888 seconds – possibledue to the same background load issue.

28 Chapter 5. Results

1.1 1.2

450

500

550

600

No additional load and high background load

Tim

e(Seconds)

Figure 5.3: Box plot for one node creation, where 1.1 is no additional system load creationand 1.2 high load creation.

0 10 20 30 40 50 60 70 80 90 100 110 120 1300

200

400

600

800

1,000

1,200

Sample number

Tim

e(S

econ

ds) Create

Destroy

Figure 5.4: Three simultaneous nodes creation, configuration and destruction statistics.

29

3

700

800

900

1,000

1,100

Number of nodes

Tim

e(Seconds)

Figure 5.5: Three nodes creation time variation.

0 10 20 30 40 50 60 70 80 90 100 110 120 1300

1,000

2,000

3,000

4,000

Sample number

Tim

e(S

econ

ds)

CreateDestroy

Figure 5.6: Five simultaneous nodes creation, configuration and destruction statistics.

30 Chapter 5. Results

5

1,100

1,200

1,300

1,400

1,500

1,600

Number of nodes

Tim

e(Seconds)

Figure 5.7: Five nodes creation time variation, outlier value (3975) from creation have beendisregarded.

0 10 20 30 40 50 60 70 80 90 100 110 120 1300

500

1,000

1,500

2,000

2,500

Sample number

Tim

e(S

econ

ds)

CreateDestroy

Figure 5.8: Seven simultaneous nodes creation, configuration and destruction statistics.

31

71,800

2,000

2,200

2,400

Number of nodes

Tim

e(Secon

ds)

Figure 5.9: Seven nodes creation time variation.

32 Chapter 5. Results

1 3 5 7

400

600

800

1,000

1,200

1,400

1,600

1,800

2,000

2,200

2,400

2,600

Number of nodes

Tim

e(Secon

ds)

Figure 5.10: All variation of number of nodes creation times with no additional backgroundload, with the outlier value removed from five node box.

Chapter 6

Conclusions

This thesis aimed to create a prototype for a cloud bursting transcoder service, which wouldcreate new transcoder nodes in the cloud and fully configure them, however due to licensingissues the prototype used a secondary software service, of similar complexity, as a stand-infor the transcoder – the web server Apache HTTP Server (commonly referred to as Apache)was selected.

The problem presented for this thesis work was a cloud-based solution for creating newtranscoder nodes. Also creating a RESTful interface, exposing the functionality, and con-figuring newly created nodes to be fully operational. These presented problems were solvedusing the cloud operating system OpenStack as cloud provider, jclouds as a connection tothe cloud and Chef as configuration framework.

This prototype demonstrates that the method is applicable for the described problem andcan mitigate demand peaks, only a few minutes after the call has been made to create nodein the cloud. The addition of the callback feature allows the systems to post the address tothe newly created nodes into the requested location allowing for easy integration and usageof the prototype.

The average creation times for the new compute nodes gives some indication that the systemis viable, as the times achieved is acceptable for the presented tasks. Our evaluation andexperiments shows that the impact of high load on the OpenStack system is tangible andmay be a limitation in a production system.

6.1 Limitations

The RESTful server keeps the status list in active memory as a sharedjava.util.concurrent.BlockingQueue which will not scale to an arbitrary number ofjobs. A production system would use a database for storing relevant data.

33

34 Chapter 6. Conclusions

6.2 Future Work

The following tasks have been identified as targets for future work:

– Creating a working transcoder setup Chef recipe, a prototype of this exists but needsrefinement. The licensing issue was resolved towards the end of the thesis projectbut at that time it was too late to include it in the report as no more time could beallocated towards implementation at the expense of the report progress.

– The work of this prototype to a functioning extension of an existing system is onits way. The addition of a database to store job statuses and more relevant infor-mation would be a feature to implement soon, as this would further increase thestability and traceability of the system. Expanding on the RESTful interface to ac-commodate application/xml as content-type and adding an Extensible StylesheetLanguage (XSL), for a more well versed web interface.

– Migrating the manual Chef setup to be part of an installable package or somethingsimilar where the entire service is packaged as a one-time setup.

– Implementing a form of redirection via the Controller to the new transcoder node asa gateway.

– Adding a form of billing system for users who requests a dedicated transcoder whichwill only be used by them, today the transcoders all share a work queue and the loadis distributed using a Round robin algorithm.

– The current implementation holds many variables only in memory and any alterationsto the values require a restart of the service. Some logs (such as job status andip addresses) are also only kept in working memory and will be purged on restart.Implementation of a more persistent system which reads configuration values fromsettings files would offer an improvement over the current setup.

Chapter 7

Acknowledgments

I would like to express my gratitude to my supervisors at the department of ComputingScience, Lars Larsson for supervising this thesis, Daniel Espling for the final approval andRickard Lonneborg CEO CodeMill AB for supplying this interesting work as a thesis. Inaddition I would like to thank all my friends and family. Finally I would like to give specialthanks to my lovely girlfriend Stina Holmgren for her support during this thesis project.

35

36 Chapter 7. Acknowledgments

References

[1] Amazon Web Services, Inc. Amazon cloudwatch. http://aws.amazon.com/

cloudwatch/. [Online; accessed 2013-04-20].

[2] Amazon Web Services, Inc. Amazon ec2 pricing, pay as you go for cloud computingservices. https://aws.amazon.com/ec2/pricing/. [Online; accessed 2013-04-20].

[3] Amazon Web Services, Inc. Amazon web services: Overview of security processes :Articles & tutorials : Amazon web services. http://aws.amazon.com/articles/1697.[Online; accessed 2013-04-20].

[4] Amazon Web Services, Inc. Aws offers fast, low-cost cloud application development &deployment. https://aws.amazon.com/what-is-aws/. [Online; accessed 2013-04-20].

[5] John G. Apostolopoulos, Wai tian Tan, and Susie J. Wee. Video streaming: Concepts,algorithms, and systems. Technical report, HP Laboratories, 2002.

[6] Sushil Bhardwaj, Leena Jain, and Sandeep Jain. Cloud computing: A study of in-frastructure as a service (iaas). International Journal of Engineering and InformationTechnology, 2(1):60–63, 2010.

[7] Vasudev Bhaskaran and Konstantinos Konstantinides. Image and Video CompressionStandards: Algorithms and Architectures. Kluwer Academic Publishers, Norwell, MA,USA, 2nd edition, 1997.

[8] Navdeep S. Chahal and Baljit S. Khehra. Performance evaluation of a hadoop-baseddistributed video transcoding system for mobile media service. In Advanced Scienceand Technology Letters. ISA-IST, 2012.

[9] George F. Coulouris, Jean Dollimore, and Tim Kindberg. Distributed Systems. PearsonEducation Limited, London, 2011.

[10] Jeffrey Dean and Sanjay Ghemawat. Mapreduce: simplified data processing on largeclusters. Commun. ACM, 51(1):107–113, January 2008.

[11] Roy Thomas Fielding. Architectural styles and the design of network-based softwarearchitectures. PhD thesis, 2000. AAI9980887.

[12] google gson. google-gson - a java library to convert json to java objects and vice-versa.http://code.google.com/p/google-gson/. [Online; accessed 2013-04-20].

37

38 REFERENCES

[13] jclouds, Inc. jclouds - home. http://www.jclouds.org/documentation/

gettingstarted/what-is-jclouds/. [Online; accessed 2013-04-20].

[14] jclouds, Inc. Quick start: Chef. http://www.jclouds.org/documentation/

quickstart/chef/. [Online; accessed 2013-04-20].

[15] Gertjan Keesman, Robert Hellinghuizen, Fokke Hoeksema, and Geert Heideman.Transcoding of mpeg bitstreams. Signal Processing: Image Communication, 8(6):481– 500, 1996.

[16] Myoungjin Kim, Yun Cui, Hyeokju Lee, and Hanku Lee. A comparative study foroptimization of video file compression in cloud environment. International Journal ofComputer Applications, 60, 2012.

[17] Richard McDougall and Jennifer Anderson. Virtualization performance: perspectivesand challenges ahead. SIGOPS Oper. Syst. Rev., 44(4):40–56, December 2010.

[18] Peter Mell and Tim Grance. The NIST Definition of Cloud Computing. Technicalreport, National Institute of Standards and Technology, Information Technology Lab-oratory, July 2009.

[19] Ahmed N., Natarajan T., and Rao K.R. Discrete cosine transform. IEEE Transactionson Computers, C-23(1):90–93, January 1974.

[20] OpenStack, LLC. Api endpoint - nova 2013.1 documentation. http://docs.

openstack.org/developer/nova/devref/api.html. [Online; accessed 2013-04-20].

[21] OpenStack, LLC. Companies >> openstack open source cloud computing software.http://www.openstack.org/foundation/companies/. [Online; accessed 2013-04-20].

[22] OpenStack, LLC. Home >> openstack open source cloud computing software. http:

//www.openstack.org/. [Online; accessed 2013-04-20].

[23] OpenStack, LLC. Openstack compute >> openstack open source cloud computingsoftware. http://www.openstack.org/software/openstack-compute/. [Online; ac-cessed 2013-04-20].

[24] OpenStack, LLC. Openstack compute >> openstack open source cloud computingsoftware. https://wiki.openstack.org/wiki/Nova/APIFeatureComparison. [On-line; accessed 2013-04-20].

[25] OpenStack, LLC. Openstack docs: current. http://docs.openstack.org/install/.[Online; accessed 2013-04-20].

[26] OpenStack, LLC. Systemusagedata - openstack¡.

[27] OpenStack, LLC. Welcome to nova’s developer documentation! - nova 2013.1 docu-mentation. http://docs.openstack.org/developer/nova/. [Online; accessed 2013-04-20].

[28] Oracle Corporation and/or its affiliates. The java community process(sm) program- jsrs: Java specification requests - detail jsr# 311. http://www.jcp.org/en/jsr/

detail?id=311. [Online; accessed 2013-04-20].

REFERENCES 39

[29] Oracle Corporation and/or its affiliates. The java community process(sm) program- jsrs: Java specification requests - detail jsr# 339. http://www.jcp.org/en/jsr/

detail?id=339. [Online; accessed 2013-04-20].

[30] T. Sikora. Mpeg digital video-coding standards. Signal Processing Magazine, IEEE,14(5):82 –100, sep 1997.

[31] A. Thusoo, J. S. Sarma, N. Jain, Z. Shao, P. Chakka, N. Zhang, S. Antony, H. Liu, andR. Murthy. Hive-a petabyte scale data warehouse using hadoop. In Data Engineering(ICDE), 2010 IEEE 26th International Conference on, pages 996–1005. IEEE, 2011.

[32] Chao Tian, Haojie Zhou, Yongqiang He, and Li Zha. A dynamic mapreduce sched-uler for heterogeneous workloads. In Eighth International Conference on Grid andCooperative Computing GCC2009, pages 218–224. IEEE Computer Society, 2009.

[33] A. Vetro, C. Christopoulos, and Huifang Sun. Video transcoding architectures andtechniques: an overview. Signal Processing Magazine, IEEE, 20(2):18 – 29, mar 2003.

[34] VMware. Understanding Full Virtualization, Paravirtualization, and Hardware Assist.Technical report, VMware, september 2007.

[35] Yifei Wang and Bingyao Jin. The application of saas model in network education-takegoogle apps for example. In Education Technology and Computer (ICETC), 2010 2ndInternational Conference on, volume 4, pages V4–191–V4–194, June.

[36] XenSource, Inc. Xen overview. http://wiki.xen.org/wiki/Xen_Overview. [Online;accessed 2013-04-20].

[37] Alexander Zahariev. Google app engine. In TKK T-110.5190 Seminar on Internet-working, pages 1–5, 2009.

40 REFERENCES

Appendix A

Sample usage

1 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>

2 <ConfigurationDocument xmlns="http://xml.example.com/schema/doc">

3 <key>ips</key>

4 <value>$1</value>

5 </ConfigurationDocument>

Figure A.1: Callback POST body

41

42 Chapter A. Sample usage

Request

1 POST /Controller/job/start HTTP/1.1

2 Authorization: Basic YWRtaW46YWRtaW4=

3 User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 ...

4 Host: localhost:8080

5 Accept: application/json

6 Content-Type: application/json

7 Content-Length: 193

Request body

1 {

2 "numberOfInstances":3,

3 "username":"ubuntu",

4 "groupname":"b-nodegroup",

5 "role":"webserver",

6 "command":"recipe:apache2",

7 "callAtComplete":{

8 "address":"http://localhost:8080/Controller/complete?ips=$1",

9 "method":"POST"

10 }

11 }

Response body - Content-Type: application/json

1 {

2 "completed": null,

3 "created": "Fri Jan 11 11:59:53 CET 2013",

4 "error": null,

5 "ip": [],

6 "jobId": 0,

7 "jobType": "ADD",

8 "jobs": [

9 "0",

10 "1",

11 "2"

12 ],

13 "status": [

14 "NO_STATUS"

15 ]

16 }

Figure A.2: Creation request call for spawning of 3 instances all configured to run an Apacheweb server.

43

Request

1 POST /Controller/job/stop HTTP/1.1

2 Authorization: Basic YWRtaW46YWRtaW4=

3 User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 ...

4 Host: localhost:8080

5 Accept: */*

6 Content-Type: application/json

7 Content-Length: 94

Request body

1 {

2 "numberOfInstances":-1,

3 "username":"ubuntu",

4 "groupname":"b-nodegroup",

5 "role":"webserver",

6 "command":"NO_BLOCKING"

7 }

Response body - Content-Type: text/plain

1 Running process to destroy node(s) in group b-nodegroup

Figure A.3: Destruction request call for all existing instances in group running asynchronous,can also be used as a blocking call – response is a plain text message.

44 Chapter A. Sample usage

Request

1 GET /Controller/job/status HTTP/1.1

2 Authorization: Basic YWRtaW46YWRtaW4=

3 User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 ...

4 Host: localhost:8080

5 Accept: application/json

Response body

1 [

2 {

3 "completed" : "Fri Jan 11 10:59:58 CET 2013",

4 "created": "Fri Jan 11 10:47:28 CET 2013",

5 "error": null,

6 "ip": [

7 "XXX.YYY.ZZZ.193",

8 "XXX.YYY.ZZZ.194",

9 "XXX.YYY.ZZZ.195"

10 ],

11 "jobId": 0,

12 "jobType": "ADD",

13 "jobs": [

14 "0",

15 "1",

16 "2"

17 ],

18 "status": [

19 "NO_STATUS",

20 "Creating node(s) in group: b-nodegroup",

21 "Running command on node group:

22 ’[[statements=[echo hello{lf}]]]’",

23 "Creation done",

24 "Setting up node(s) with chef",

25 "END_OF_JOB_FF"

26 ]

27 }

28 ]

Figure A.4: Process status request call – indicating that the creation job of nodes 0-2 hadno occurrences of error and also listing the newly created nodes public IP addresses

45

Request

1 GET /Controller/job/status/5 HTTP/1.1

2 Authorization: Basic YWRtaW46YWRtaW4=

3 User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 ...

4 Host: localhost:8080

5 Accept: application/json

Response body

1 {

2 "completed": "Fri Feb 01 13:43:40 CET 2013",

3 "created": "Fri Feb 01 13:37:40 CET 2013",

4 "error": "org.jclouds.compute.RunScriptOnNodesException error..",

5 "ip": [],

6 "jobId": 5,

7 "jobType": "ADD",

8 "jobs": [

9 "0"

10 ],

11 "status": [

12 "NO_STATUS",

13 "Creating node(s) in group: b-nodegroup",

14 "Running command on node group:

15 ’[[statements=[echo hello{lf}]]]’",

16 "Creation done",

17 "END_OF_JOB_FF"

18 ]

19 }

Figure A.5: Process status request call – indicating that the creation job of one node hasfailed, the error is truncated but contains a full stacktrace of the encountered exception.


Recommended