Cloud Computing Infrastructure Usage Estimation ...

5 downloads 340318 Views 4MB Size Report
model with guidelines, policies and best practices for experimentation. A federated multi-platform approach is ..... and Web-hosting service provider” (Business Insider, 2013). Almost all leading ...... to-exceed-72-billion-by-2016/. [Accessed 16 ...
University of Southampton, 2013 FACULTY OF BUSINESS & LAW SOUTHAMPTON MANAGEMENT SCHOOL

CLOUD COMPUTING USAGE GENERATION USING MONTE CARLO SIMULATION AND COPULA PROBABILITY THEORY

(AN INVESTIGATION INTO BUSINESS PLANNING FOR EUROPE’S FUTURE INTERNET CLOUD FACILITIES)

(ERGO ID: 6805) (STUDENT ID: 25841157) by Taiwo Ayanleye

A dissertation submitted in partial fulfilment of the requirements for the degree of MSc (Business Analytics and Management Sciences) by instructional course

Word Count: 14666 words

Executive Summary

Introduction This is the deliverable towards the business planning for BonFIRE Consortium’s future internet cloud facility. Majorly, this documentation contains the study regarding BonFIRE infrastructures’ capacity and future utilization possibility, as wells as relevant financial performance to guide towards the purpose of the study. The purpose of this study is to investigate the business sustainability of BonFIRE’s cloud computing service through the generation of future loads of the infrastructure’s demand, remodelling the existing cost model, defining the infrastructure’s usage sizes and experiments types. As BonFIRE’s sustainability aim is defined; the continuation of the essence, the benefits and key achievements of BonFIRE, beyond the end of the project. Mapping out the commercialisation of BonFIRE is crucial at this stage than ever before, as the sponsorship period is approaching its end, the project’s partners contract also elapse it time, not forgetting the increasing opportunity of being a part of the European multibillion euros cloud computing market.

Remapping the sustainability model During this study, it was made clear that BonFIRE’s sustainability aim is dependent on various factors, most of which are yet to be made clear quantitatively. The three key factors towards BonFIRE’s business development are the cost model, the demand model and the service pricing. Likewise, these three parameters were investigated based on the two service models that BonFIRE is considering for its operation. The Infrastructure as a Service model; which assumes that BonFIRE is the sole operator and provider of its cloud computing infrastructures, as well as the Third Party service model; here BonFIRE takes at maximum, partial control of its infrastructures’ service management while the Third party is outsourced the remaining service, or as the case may turn out, the Third Party may be outsourced the full service control of BonFIRE’s cloud infrastructure. To ensure a strategic view of BonFIRE’s business model, presented below is a graphical relationship made to define the relationship between BonFIRE’s three key factors and their relationship within the two service models. The cost model is inclusive of the capital investment and operational expenses. BonFIRE’s operational cost is varied as a result of its dependency on the infrastructures’ utilization. For example, an expectation of increase in BonFIRE’s cloud service demand would cause the extension of BonFIRE’s support staff Full Time Equivalent (FTE) at a given period, thereby varying the operational cost for BonFIRE. Service provision 1

option by a Third Party is assumed to be liable of consideration, when either BonFIRE’s infrastructure is unable to serve its cloud service demand. Or when it is comparatively low for the Third Party to provide for BonFIRE’s infrastructure services compared to BonFIRE’s. This model further concludes that the achievement of BonFIRE’s business sustainability will finally depend on the outcome between the total revenue of BonFIRE and the total cost.

Figure A: BonFIRE Sustainability chart

Approach towards sustainability

Figure B: Chart of approach As a summary of the approach used to carry out the study, from the collected infrastructure usage data for a 19 week period, statistical inferences were conducted and were used as input variables towards the infrastructures’ usage generation through Monte Carlo simulation of the annual usage. Among the insights achieved from the Monte Carlo usage generation was the measurement of the rate at which different experiment types are likely to utilize the BonFIRE’s infrastructure as depicted below, the Media experiments type are likely to utilize a higher share of BonFIRE’s storage infrastructure, while the High Performance Computing (HPC) experiment types are more likely to utilize more of the compute infrastructure than any other experiment types.

To overcome the weakness of the Monte Carlo usage simulation, for not including what relationship exists between the utilization of the BonFIRE’s Infrastructures, as observed, there is a certain level of relationship that occurs between each of BonFIRE’s infrastructure usages at a given period in time. Copula probability theory was used to define this relationship and the result was used to perform analysis towards the utilization of the infrastructures compared to what each infrastructure’s capacity can accommodate.

Key findings Among the discoveries made concerning BonFIRE’s resources capacity and utilization is that, BonFIRE’s compute infrastructure will not meet up with the expected demand beginning from its first year, it was estimated that over 30% of the first year expected demand will be churned of BonFIRE’s cloud computing service. A converse discovery was made for the storage infrastructure; the storage infrastructure was discovered not to run out of service provision for about the fourteenth year of BonFIRE’s usage. The reason for the predicted overutilization of 3

BonFIRE’s compute infrastructure may not be fully known, however for the storage resource underutilization, it was concluded that its predicted low level of utilization is as a result of a known technical difficulty that constraint users from using the level of storage resources they require.

Figure C: Five year period compute infrastructure demand Other findings regarding the financial performance of BonFIRE estimated that it would cost more for BonFIRE to offer its compute resource service provision under an Infrastructure as a Service model than it is to get it offered based on a Third Party service model. Conversely, the storage resource infrastructure was estimated to cost extensively lower for BonFIRE to provide it based on an Infrastructure as a Service model than on a Third Party model.

Figure D: Cost of compute infrastructure production The infrastructure’s capacity challenge for BonFIRE’s compute infrastructure’s overutilization and its service production cost disadvantage under an Infrastructure as a Service model was in contrast to its storage infrastructure’s underutilization and

it’s Infrastructure as a Service cost advantage. To achieve a significant milestone in this study, focus was made on possible medium to mitigate the compute infrastructure’s estimated overcapacity as well as financial performance. This brought about the decision of outsourcing certain levels of the compute infrastructure’s estimated demand to a Third Party while as an Infrastructure as a Service provider, BonFIRE provides it cloud computing service. Using Wellness Telecom as a Third Party service provider, we concluded that 70% of BonFIRE’s compute resource should be outsourced. With this assumption we estimated that BonFIRE’s compute infrastructure will meet both its estimated five year future demand as well as unexpected spikes in cloud service demand, with BonFIRE’s compute resource recoding about 30% average utilization in its first year. Likewise, at the concluded 70% level of compute infrastructure’s demand outsourcing, it was estimated that for the first year, compute resource will cost €320.42 (with BonFIRE I-a-a-S: €138.70 and Wellness Telecom 3rd Party: €181.72) compared to €462.35, if it was provided fully by BonFIRE.

Figure E: Five year period cost of compute infrastructure

Recommendation: 

Firstly the incompleteness of BonFIRE’s cost model need remodelling. As a key factor to BonFIRE’s sustainability all cost expenses are needed to be accounted for and managed, but without a proper accountable knowledge of BonFIRE’s cost, achieving sustainability will be similar to an “invisible hand” controlling the cost.

Although minimal work was done on the cost factor, the three stated cost are advised for consideration into BonFIRE’s cost model: 5

Power cost: as an estimate from the market, power accounts for between 70 to 80 percent of a datacentre operating cost. Likewise, the level of power consumption is directly related to the level of network usage. Network cost: Apart from the initial cost of the network facility, the cost of data transfer is an operational cost of the network facility. This cost is intertwined both with the powering cost of the cloud computing infrastructure and the network cost. Datacentre staffing: As cloud computing operations begin from the datacentre, as well as the administrative staffs such as the user support staff are considered, the datacentre engineers staffing cost should be given consideration. 

Secondly, concerning the infrastructures, as presently known the network infrastructure was not included in the study as its usage accountability is technically impossible to ascertain, this resource accountability is significant for pricing purpose and for power consumption purpose.



As a final recommendation, future studies of the BonFIRE’s cloud computing business should be specifically assigned, and not generally assigned. Improved result could be gained if factors of BonFIRE are singularly considered for specification. As listed above, the three main factors that may require research specialization are the cost, demand and pricing for BonFIRE.

Achieving the business sustainability of BonFIRE is not a one-time project, rather, a continual one. However, this study’s findings are only as good as the model inputs. The decision markers play a significant role in determining the result. Further exploration into this study may be needed in intrinsic components of BonFIRE such as the experiment types pricing, total cost optimization. However this study provided to add to the guide to BonFIRE sustainability.

Acknowledgements

It is a privilege to have Tiejun Ma as my university supervisor, who allotted me more hours than regulated. I wish to acknowledge the company, IT Innovations, who entrusted me the opportunity of being a part of this significant project, BonFIRE. I would like to acknowledge my company supervisor, Michael Boniface, who ensured my progress at IT Innovations and Juri Papay, who ensured my project’s progress as well as report’s progress. I would like to thank Sue Jenkins, Vegard Engen, Rosie Burt, Colin Upstil, Stephen Phillips, and Philip Inglesant who helped in small ways during my time at IT Innovations. I also give my utmost gratitude to my family, who permitted me their love. Lastly and most importantly, I would use this platform to acknowledge my God, who opened path in pathless places, provided himself all though the hikes of this project.

7

Glossary of Acronyms Acronym CAGR EaaS EC FIRE FTE IaaS PaaS PUE SaaS SIB VM 3rd Party

Definition Compound Annual Growth Rate Experiments-as-a-Service (potential business scenario) European Commission Future Internet Research and Experimentation Full Time Equivalent Infrastructure-as-a-Service (service model) Platform-as-a-Service (service model) Power Utilization Effectiveness Software-as-a-Service (service model) BonFIRE Sustainability Impact Board Virtual Machine Third Party (service model)

Table of Contents 1.

2.

3.

Introduction ................................................................................................................ 14 1.1.

Objectives ............................................................................................................................ 15

1.2.

Deliverables......................................................................................................................... 15

1.3.

Outline of methodology and approaches ........................................................................ 16

1.4.

An overview of the line of argument ................................................................................ 16

Background ................................................................................................................ 17 2.1.

The sponsor organisation ................................................................................................. 17

2.2.

Infrastructure ....................................................................................................................... 17

2.3.

Principles of BonFIRE ....................................................................................................... 18

Literature Review ....................................................................................................... 20

3.1. Industrial Review ....................................................................................................... 20 3.1.1.

Industrial review of Cloud Computing ......................................................................... 20

3.1.2.

Evolutionary stages of Cloud Computing ................................................................... 21

3.1.3.

Essentials of the Cloud .................................................................................................. 22

3.1.4.

Preceding Computing Paths to the Cloud .................................................................. 23

3.1.5.

Service models of cloud computing ............................................................................. 23

3.1.6.

Deployment Models of the Cloud ................................................................................. 25

3.1.7.

Perspectives of cloud computing benefits .................................................................. 26

3.1.7a. Provider’s Benefit .......................................................................................................... 26 3.1.7b. Clients’ Benefit............................................................................................................... 28 3.1.8.

New Opportunities with the Cloud ............................................................................... 30

3.2. Literature Review (Academic) ................................................................................... 31

4.

3.2.1.

Sustainability of the Cloud Business ........................................................................... 31

3.2.2.

Forecasting Cloud Usage.............................................................................................. 31

3.2.3.

Clearwater and Huberman swing option..................................................................... 32

3.2.4.

Wu et al.’s and Modified Wu et al.’s truth telling model ............................................ 33

3.2.5.

UK non-seasonality adjusted sales data for cloud forecast ..................................... 33

3.2.6.

Pattern Matching for cloud forecast ............................................................................. 36

3.2.7.

Central Limit Theorem ................................................................................................... 37

3.2.8.

Monte Carlo random generation and Copulas for Cloud usage forecast .............. 37

Methodology .............................................................................................................. 40 4.1. Project Objectives................................................................................................................... 40 9

4.2.

Problem structuring ............................................................................................................ 40

4.3.

Data description .................................................................................................................. 41

4.3.1. Cost data .......................................................................................................................... 42 4.3.2. Resources data ............................................................................................................... 43 4.3.3. Data tools ......................................................................................................................... 44 4.3.4. Statistical methods .......................................................................................................... 45 Normally distributed usage level .................................................................................................. 45 a. 3.

LoadGenerator’s Descriptive Statistics ............................................................................... 45 Pre-process: Cloud Usage Forecast......................................................................... 47

3.1.

Overview of historical data ................................................................................................ 47

3.2.

Experiment types of the Cloud ......................................................................................... 49

3.3.

Descriptive Statistics for LoadGenerator ........................................................................ 50

3.3.1.

Inference from original data ...................................................................................... 50

3.3.2.

Inference for generating an annual data ................................................................. 53

3.4.

4.

Generated usage ................................................................................................................ 55

3.4.1.

Description of Monte Carlo generated usage ........................................................ 55

3.4.2.

Sizes distribution of generated usage ..................................................................... 58

3.4.3.

Clustering of experiment types generated.............................................................. 59

Results and accuracy tests ....................................................................................... 61 4.1.

Result analysis .................................................................................................................... 61

4.1.1.

Cost: ............................................................................................................................. 61

4.1.2.

Usage and Experiment types: .................................................................................. 63

4.2.

Accuracy analysis............................................................................................................... 76

4.2.1.

Monte-Carlo: Kolmogorov-Smirnov and Shapiro-Wilk test for normality ........... 76

4.2.2.

Anderson Darling Test ............................................................................................... 80

4.2.3.

Copulas result: ............................................................ Error! Bookmark not defined.

5.

Research Limitation and Future Work ...................................................................... 82

6.

Conclusion ................................................................................................................. 84

References ........................................................................................................................ 85 Appendices ....................................................................................................................... 91

List of Tables Table 1: Current BonFIRE cost parameters ........................................................................ 43 Table 2: LoadGenerator's configuration values ................................................................... 46 Table 3: Resource usage distribution across experiments types ......................................... 49 Table 4: Approximated descriptive statistics........................................................................ 51 Table 5: Copula generated usage ....................................................................................... 63 Table 6: Percentage change in compute resources scenarios ............................................ 63 Table 7: Percentage change in storage resources scenarios .............................................. 64 Table 8: Comparison of historical and generated distribution .............................................. 77 Table 9: Historical and generated data test of normality ...................................................... 78 Table 10: Descriptive statistics for generated usage ........................................................... 79 Table 11: Normality test for generated usage ...................................................................... 79 Table 13: BonFIRE cost model ........................................................................................... 97 Table 14: Descriptive statistics of the historical resources usage ........................................ 98 Table 15: Python code for Monte Carlo simulation ............................................................ 122

11

List of Figures Figure 1: BonFIRE data centres and resources................................................................... 18 Figure 2: Key actors in different service models .................................................................. 24 Figure 3: Service models of cloud computing ...................................................................... 25 Figure 4: 3.6. Deployment models of cloud computing ..................................................... 26 Figure 5: Non- seasonally adjusted index of sales at current prices from January 1986 June 2013 for non-store retail ...................................................................................................... 35 Figure 6: BonFIRE sustainability chart ................................................................................ 41 Figure 7: Compute resource 19 weeks usage ..................................................................... 48 Figure 8: Storage resource 19 weeks usage ...................................................................... 49 Figure 9: Historical compute small usage ............................................................................ 52 Figure 10: Historical storage small usage............................................................................ 52 Figure 11: Historical compute medium usage .................................................................... 53 Figure 12: Historical storage medium usage ....................................................................... 53 Figure 13: Historical compute large usage .......................................................................... 53 Figure 14: Historical storage large usage ............................................................................ 53 Figure 15: 52 weeks generated compute usage .................................................................. 55 Figure 16: 52 weeks generated storage usage.................................................................... 56 Figure 17: Compute usage distribution size ........................................................................ 57 Figure 18: Storage usage distribution size .......................................................................... 57 Figure 19 Generated compute small ................................................................................... 58 Figure 20 Generated storage small ..................................................................................... 58 Figure 21 Generated compute medium ............................................................................... 58 Figure 22 Generated storage medium................................................................................. 58 Figure 23 Generated compute large.................................................................................... 58 Figure 24 Generated storage large ..................................................................................... 58 Figure 25: Clustered experiment types resource usage ...................................................... 60 Figure 26: Decision tree of compute resource usage per experiments types ....................... 60 Figure 27: Decision tree of storage resource usage per experiments type .......................... 61 Figure 28 : Probability measurement for EPCC's compute resource cost ............................ 62 Figure 29: First year compute resource usage .................................................................... 64 Figure 30: First year storage resource usage ...................................................................... 64 Figure 31: Weekly compute resource usage ....................................................................... 65 Figure 32: Weekly storage resource usage ......................................................................... 66 Figure 33: Five years compute usage ................................................................................. 66 Figure 34: Fifteen years storage usage ............................................................................... 67 Figure 35: First year compute resource cost ....................................................................... 68 Figure 36: First year storage resource cost ......................................................................... 69 Figure 37: BonFIRE first year total cost ............................................................................... 70 Figure 38: Optimistic cost for compute resource production given 50% outsourcing level ... 71 Figure 39: Realistic cost for compute resource production given 50% outsourcing level ..... 72 Figure 40: Pessimistic cost for compute resource production given 50% outsourcing level . 72 Figure 41: Five years compute usage at 50% outsourcing level .......................................... 73 Figure 42: Optimistic cost for compute resource production given 50% outsourcing level ... 74 Figure 43: Realistic cost for compute resource production given 70% outsourcing level ..... 74

Figure 44: Realistic cost for compute resource production given 70% outsourcing level ..... 75 Figure 45: Five years compute usage at 70% outsourcing level .......................................... 75

13

1. Introduction

On September 27, 2012, at the capital of the European Union, the European Commission embraced the strategic policy, “Unleashing the Potential of Cloud Computing in Europe” (European Commission, 2012). As part of the potential effects of the information, communication and technology adoption to the European macroeconomic, the strategic policy was aimed at advancing the union’s current level of human productivity, economic growth and job creation (Kretschmer, 2012) by 2020. 3.5million new jobs are estimated to be sprung out across Europe, aggregately injecting about €250billion to Europe’s GDP (IDC, 2012). As part of European Union’s project towards Europe’s future internet research and experimentation, BonFIRE Consortium was established in 2009 to bring together world leading industrial and academic organisations in cloud computing field to provide a robust, reliable and sustainable facility for large scale experimentally-driven cloud research (BonFIRE Consortium, 2013). For BonFIRE, the feasibility of achieving sustainability for future internet, research and experiments infrastructures have been vague, countless and puzzling (Boniface, et al., 2013). Sustainability here implies the future business feasibility of the BonFIRE project, as the assurance of BonFIRE’s existence, beyond it governmentally funded years are over. As it is for testbed providers, governmental bodies, partnering private firms, academic institutions and testbed users, who supplies and demands BonFIRE’s cloud service platforms, assurance of the service longevity is critical. As recommended by BonFIRE’s Sustainability Impact Board (Table I.1: Sustainability Impact Board recommendation ), BonFIRE’s financial estimate is needed to be established to determine its prospect of sustainability. In a service offering business as the cloud computing, business feasibility is dependent on both its operations management and financial performance (Bart Van Looy, 2003). However, BonFIRE’s existing business models have not yielded workable realistic results. This has further resulted into probabilistic complexities contained in the cost accountability, facilities performance measurements and utilization expectation, all, not being contained in the existing business models (Boniface, et al., 2013). Summing it up, the working business model is both incomplete and unquantifiable in a realistic measure. Currently, future internet facility such as BonFIRE needs robust

models for both cost accountability and operational performance monitoring which serves as necessary conditions into future performance research (Project Brief, 2013). As the prospect of fully operating in the multibillion euro cloud computing market (IDC, 2012) is aimed, financial sponsors’ input dwindles, and soon, expectation awaits BonFIRE Consortium’s management to drive the business incurable cost with ever possible prospective revenue.

1.1.

Objectives

The objective aimed to be achieved after this project was both predefined as well as redefined along with the sponsor’s organisation. The main objective is: To investigate sets of future business scenarios for the BonFIRE facility’s possible service models. Optimistic, realistic and pessimistic future business scenarios of the two service models; Infrastructure as a Service (I-a-a-S) and 3rd Party service models, are needed to be investigated towards achieving BonFIRE’s business sustainability. To achieve this objective, the following sub objectives must be fulfilled: 1. To develop model towards BonFIRE’s business sustainability 2. To generate future BonFIRE’s infrastructures demand by building upon the sponsor’s working tool, using theoretical methodologies. 3. To investigate into BonFIRE’s infrastructure usage sizes and its formation into BonFIRE’s experiment types. 4. To investigate into BonFIRE’s infrastructure utilization and BonFIRE’s financial performance based on the service models and business scenarios. 5. To investigate the in completeness of the business cost model. 6. To initiate managerial usable decision support tool to investigate future scenarios through what if analysis. What if analysis allows the exploration of uncertainties, its causes and effects across parameters?

1.2.

Deliverables

The main deliverable is the project’s documentation and initiated support tool. 15

1.3.

Outline of methodology and approaches

Here is a prologue of techniques and methods used in executing this study: Problem structuring and system thinking: Vast amounts of the problems tackled in this project were intertwined and abstract. Through series of meetings with the sponsor’s supervisors, research into collections of past documents, reports and spreadsheets, the problems were modelled for quantification. The abstract nature of the problem necessitated the logical support of qualitative methods through pictorial graphs as a medium of clarifying abstract ideas. Insight analytics: There was need to know the causes of the project’s current operations, so as comprehend the problem to be tackled and avoid renovation of unnecessary solutions. With the use of the collected documents, reports and spreedsheets, series of shorts and few long reports were presented among the academic and sponsor’s supervisors. Computational and statistical techniques: With the aid of statistical applications, simulations, tests, graphs, tools and results were presented.

1.4.

An overview of the line of argument

Commencing from the definitions of objectives to be achieved, the sponsor’s operations background was reviewed, with indications of relevant details to aid this project’s study. Further ahead, the industrial pace of cloud computing was reviewed alongside the academics, in relation to cloud computing and the approaches used in the study. It was important to quantify the current state of the business operations, in the methodology chapter, this was archived, alongside the achievement of some of the study’s objectives. As a result of the combination of Monte Carlo theory with Copula theory, supporting the final production of the study’s result, a chapter was set aside for the processes and results gained using Monte Carlo theory, as this also achieved part of the objectives. Finally, Copula theory was used to generate a more theoretical realistic result which was used to perform investigations into BonFIRE’s business scenarios, service models, infrastructure utilization, monetary performance and their relationships.

2. Background i 2.1.

The sponsor organisation

IT Innovation is part of the Faculty of Physical Sciences and Engineering at the University of Southampton. It focuses on enabling the innovative application of information technology in industry and commerce. It researches, develops, architects, engineers and integrates innovative IT systems, delivering proofs-of-concept, demonstrators and novel operational systems. The research and development of products and services for the Internet is an increasingly complex endeavour. This is especially true for disruptive technologies that impact current Internet business models. Investigating new ideas, verifying and validating systems as they grow in maturity from the laboratory to commercial deployments requires resources that are diverse, distributed, and of sufficient scale to test hypotheses and assumptions. The European Future Internet Research and Experimentation (FIRE) initiative offers a novel approach to European testbed provision that moves away from project- and industry-specific facilities to general purpose, reusable, experimentation platforms. 2.2.

Infrastructure

BonFIRE operates a cloud facility based on an Infrastructure as a Service delivery model with guidelines, policies and best practices for experimentation. A federated multi-platform approach is adopted, providing interconnection and interoperation between novel service and networking testbeds. The infrastructures are situated in datacentres

geographically

heterogeneous

cloud

distributed

services

across

resources,

six

including

locations, compute,

which storage

offers and

networking. The BonFIRE infrastructures are situated and provided by; EPCC (Edinburg, UK); HP (Bristol, UK); iMinds (Ghent, Belgium); INRIA (Rennes, France); USTUTT (Ghent, Germany); and PSNC (Poznan, Poland).

17

Figure 1: BonFIRE data centres and resources 2.3.

Principles of BonFIRE

The BonFIRE’s essential characteristics are as follows: Observability: BonFIRE provides the user the opportunity to observe their usage of resources at all levels; physical, virtual and applications, with no hidden usage and cost details, the BonFIRE user can understand the complex interaction between various system components. Control: the users of BonFIRE are given the power to control resource usage. This is to ensure users are able to solely determine the conditions required for accurate and reliable testing; the user can control, request, reject and edit the placement of virtual machines, get exclusive access to physical cost and load physical machines with preconfigured user customised features. Advanced Features: Bonfire offers users a combination of on demand cloud feature, elasticity to instantiate resources adjustment to the variation in workload changes as unforeseen usage changes occurs and scalability for foreseen changes in usage pattern, all of these are provided by BonFIRE as advanced cloud feature to meet future cloud scenarios .

Ease of Use: With user friendly graphical interfaces, online documentation, presentation, support assistance and media contents, wide range of medium are made available to ensure convenience for users. To summarize these principles in which BonFIRE is built around, they are to enable that the key cloud computing stakeholders (the user) are provided the resources they need and in the way that fits their demand.

19

3. Literature Review

3.1.

Industrial Review

3.1.1. Industrial review of Cloud Computing Over the last century, the advancement in computer research as challenged the economics principle of resources scarcity (Molnar & Schehter, 2010), as the possibility of the compute, storage and network resources, available at a point in time seems to be unlimited in the supply side. In the words of Microsoft’s software architect, “the infinite availability of computing resources” to the extent of having computing resources democratized and available on demand (Meijer, 2011), this has aided computing resource to be available, more as a function of its demand not any longer, its supply. The key characteristics of cloud computing is it “On-demand selfservice” (Mell & Grance, 2011), which gives the consumer the power to automatically control the compute, storage and network capabilities as needed. The emergent of cloud computing has been the result of preceding evolutions in the field of computer science (Hwang, 2008). Evolutionary paths through serviceoriented architectures, grid computing, parallel computing, cluster computing, utility computing, and peer-to peer as made resultant effect to the present field of cloud computing (Dudin & Smetanin, 2011). Concluding on the right definition of what cloud computing is could be restrictive, at the risk of captivating the explorative tendency of the field (Armbrust, et al., 2009). As its different parties (provider, broker and consumer) has witnessed its utility relatively (Barker, 2008), features that is almost impossible to sum up in few words, however, definition provided by the eleven team of researchers at the

University of California encompasses the

universal distinctive trait of cloud computing. The “cloud” term in “cloud computing” is a literal personification of the availability of hardware and software platforms in the datacentre but accessible away from the datacentre. An industrial description of this is the Amazon Web Service (AWS) which serves users in 190 countries with datacentres in sixteen countries (AWS, 2013). An overview definition of cloud computing is that it encompasses the Software as a Service platform and the Utility Computing platform, “both the applications delivered as services over the Internet and the hardware and systems software” (Armbrust, et al., 2009).

The virtual characteristics of cloud computing is that its nature of “interconnectedness” across set of “virtualised computers” are illusionary seen as “one or more unified computing resources” offered on a contractual bases “between the service provider and the consumers” (Buyya, et al., 2009). 3.1.2. Evolutionary stages of Cloud Computing Researchers expectation for the emergent to the cloud computing has been linked to historical leaders in the computing field, from John McCarthy’s (Arutyunov, 2012) MIT’s Centennial celebration talk in 1961 where he foresighted the cloud platform as the 5th economic utility (Buyya, et al., 2009), in comparison to the telephone, he weighed cloud computing as an economic utility reinventing a new industry into the computer industry, “…the computing utility could become the basis of a new and important industry” (Garfinkel, 2011). Similarly, a July 3, 1969 press release of Leonard Kleinrock, a major player in the Advanced Research Projects Agency Networks (ARPANET) (UCLA, 1969), records Leonard’s expectation that has computer network matures, “we will probably see the spread of ‘computer utilities’”, and like John McCarthy, he envisioned the public nature of cloud computing to welfare economics public utility (Kleinrock, 2005). The earliest of the historical assertion to cloud computing was at Google’s 2006 Search Engines Strategies Conference, where Eric Schmidt shared his foresight into cloud computing (Zhang, et al., 2010), (Sullivan, 2006), he discussed a new business model beyond the “client/server computing”, he expressed a cloud computing, where a user’s access to owned information would no longer be a function of the geographical location, or inexistence of it originally stored device, rather it will solely depend on the user’s cloud service embracement. Six years later, the Google Drive platform was released (Google, 2012). According to Gartner’s Hype Cycle for Cloud Computing 2013, the maturity stage of cloud computing was grouped into the “Early mainstream”, where it is been adopted by proven technology vendors, and still evolving (David Mitchell Smith, 2011). According to cloud computing evolution model published in 2008 by Gartner (Grebnev, 2011), three phases is expected to occur in the early main stream of the cloud’s evolution; the first of these phase is the Time pioneer stage recorded to have occurred between 2007 and 2011. During this stage, risk takers in the computing sector took up the challenge of the unknown in the feasibility of the cloud market, as Dudin and Smetanin recorded, the main usage of the cloud infrastructure 21

during the time pioneer stage were for internal and short term IT based projects rather than the public based project (Dudin & Smetanin, 2011). During the time pioneer stag, Amazon Web Services (AWS) and IBM cloud service were launched in 2006 and 2007 (AWS, 2013), (IBM, 2013). Titled in the New York Times publication of October 8 2007, “Google and I.B.M. Joined in ‘Cloud Computing’ Research” (Lohr, 2007), this was an historic achievement in the cloud computing field. The second phase was the Market consolidation stage believed to last till 2013. At this stage of the cloud, the feasibility of the cloud business became more certain, here, the technology evangelists has finally succeeded in translating the technical values of cloud computing to industries and the public (Dillon, et al., 2010). In August 5 2012, the NASA and JPL’s Curiosity project to the Red Planet used the AWS cloud platform to achieve the project’s mission (AWS, 2012), making high searches in Google trend as grid and parallel computing has dwindled; the Mass distribution phase is supposed to have been achieved by 2015, here cloud services is expected to be the norm, more open, yet more secure (Soderstrom & Shams, 2012). The third stage of cloud computing has been witnessed with mergers and acquisition between the cloud service providers with

lion market share and the emerging providers

(Dudin & Smetanin, 2011), this has been made vivid with June 24th 2013 partnering between Microsoft’s Windows Azure and Oracle’s Cloud Solutions (Microsoft, 2013), likewise, July 8th 2013 acquisition of SoftLayer Technologies by IBM (IBM, 2013). 3.1.3. Essentials of the Cloud The National Institute of Standards and Technology categorized the five indispensable traits of the cloud computing as listed below (Mell & Grance, 2011). 1. On-demand self-service: The distinctive feature of cloud computing compared to other utility computing is the democracy it offers to it users (Meijer, 2011), its users are provided the opportunity to access the level of resources not just needed, but desired, irrespective of the extent (Dudin & Smetanin, 2011). With cloud computing, users are the primary stakeholder, they are in the decision spot on what computing resource and capabilities are to be requested, accepted or paused (Arutyunov, 2012). 2. Broad network access: The remote capability of the cloud makes for the broad availability of the service.

3. Resource pooling: With multi located computing resources across data centres, resources are pooled to multiple consumers signified by virtual machines. The multi-tenancy of resources, 4. Rapid elasticity: Scalability is a norm of the cloud platform, without implications on the cost of resources reach. 5. Measured service: the transparency in resources usage measurement with respect to the service platform of the user. 3.1.4. Preceding Computing Paths to the Cloud Preceding the grid computing was the cluster computing which was gradually over taken by grid computing for its inability to provide needed high performance computing capability (Ian, et al., 2008). An example of researchers challenge with grid computing was when the European Council for Nuclear Research needed the capability of the high performance computing to perform experiment that required petabytes of data for the Large Hadron Collider project in 2008 (Christof, et al., 2009). 1. Grid Either grid or the cloud, both computing platforms permit remote computational activities (Dudin & Smetanin, 2011). The grid computing 2. Cluster and Cloud This is type of parallel or distributed computing processing system achieved through the interconnections of computer system to an objective computer (Buyya, 1999). 3.1.5. Service models of cloud computing

1. I-a-a-S Infrastructure as a service platform for a cloud provider means cloud infrastructure – servers, storage and networking on demand. This is fastest growing cloud service model (Gartner, 2012). I-a-a-S allows the users to control the usage of computer resources and run software, (Mell & Grance, 2011), without bearing its ownership cost, accrued cost or managing the infrastructure, this is perfect for business start-up (IBM, 2012).

23

2. P-a-a-S While the SaaS platform hosts ready to use software application platform, the Platform as a Service offers a ground to newly develop software applications and host ready to use software applications (Dillon, et al., 2010). 3. S-a-a-S Most internet users are avid to the cloud computing of Software as a Service (Deloitte, 2009), this platform provide software applications virtually to public and corporate users. 4. 3rd Party and Brokerage Recently, the Cloud Service Brokerage role has been important than ever, this is caused by complexity of the cloud technology management caused by the rate of growth of cloud vendors and cloud users. The place of the broker is an intermediary between the cloud user and the cloud technology provider. I-a-a-S

P-a-a-S

S-a-a-S

AWS

Force.com

Salesforce.com

Rack Space

Microsoft Azure

Google Apps

Google Apps Engine

Oracle

Key Actors

Facebook Figure 2: Key actors in different service models

3rd party

Figure 3: Service models of cloud computing

3.1.6. Deployment Models of the Cloud 1. Public Being the most prominent cloud deployment model, individuals, bootstrapping startup companies and top organisations have enjoyed the economics of the pubic cloud for its low economic cost of ownership and usage advantage. Being a public platform, security concerns has been a major focus and researches are on-going to tackle this weakness. 2. Private

25

For economic, security and standardization purposes, private cloud deployment has been deployed by standalone organisations and research institutes (Dillon, et al., 2010). This allows for sole management by the organisation, institute or a third party. 3. Hybrid Joint deployments of the public and private cloud models have been achieved for the key purpose of optimizing utilization so as to tackle challenges of load balancing.

Figure 4: 3.6.

Deployment models of cloud computing

3.1.7. Perspectives of cloud computing benefits 3.1.7a. Provider’s Benefit With IBM and EMC already finding their place in the cloud computing market, they both were reported competing to acquire the “largest privately held cloud-computing and Web-hosting service provider” (Business Insider, 2013). Almost all leading technology are taking on the platforms as cloud computing providers, Amazon, for example is an online retail firm who has a lion stack in the cloud market. One would

almost never imagine why firms like Salesforce.com (a global cloud competing firm), Amazon (global online retail firm), IBM (global technology and consulting corporation), Google (global internet service and media provider), Microsoft (global software firm), hp (global technology products provider) would all be competitors in the cloud market.

1. Increasing profitability: The revelation of the low cost of computing infrastructures through cloud computing has made it demand form clients increase, and even future demand expectations are high. This is undoubtedly a profitable market for any company with its capacity.

2. Leveraging provider’s capacity: With variability in the cloud’s service models, prospective producer’s entry requirement is even affordable. The infrastructure as a service platform allows more financially and infrastructure advantaged firms like Amazon web service to take up the market, the software as a service model allows more software intensive and innovative firms like DropBox a place in the market, and firms with platform to allow developers innovate their requirements and experiment them gives providers with this capacity the criteria to operate in the cloud market according to their strength.

3. Leveraging comparative advantage: With the inclusion of cloud brokers in the cloud computing parties, cloud providers are advantaged to play in the market according to their strength. For organisations that are capable to provide the services, they operate on the “as-a-service” cloud platform, while organisation that are able to manage the service between the producer and the client take up the brokerage party of the cloud.

4. Leveraging existing investment: For technology firms who have the capacity to provide cloud computing services to the public, but initially acquired such capacity level for it private demands, scaling up as a cloud provider opens up a significant level of investment. (Clamp, 2013) 27

5. Cost of power economies of scale: With cost of power taking up about a quarter of the data centres total cost of ownership (Microsoft, 2010), operators of smaller data centres tend to pay higher than those with larger data centres. As locating in varied geographical locations allows data centre operators to both locate in inexpensive electricity regions and benefit from geographical operating cost, both as a result of bulk purchases and geographic weather advantage (Microsoft, 2010). This eventually lessens the large data centres Power Usage Effectiveness, and operating in the cloud most likely would require operating large data centre 3.1.7b. Clients’ Benefit

1. Direct cost savings and flexibility: With businesses allocating 80% of its budget to maintaining computing infrastructure (Microsoft, 2010), the cloud’s most obvious benefit in is it cost savings advantage, as businesses using the cloud platform automatically abstract information technology fixed costs; infrastructures acquisition cost, annuity costs, maintenance charges, all, are centralised into a cost optimised model of adopting to the cloud service. This enables clients to bear cost for information technology infrastructure only when it is need and not as a fixed asset that bears cost even when left ideal. A case study of this is Avianca, one of Brazil’s top airlines. For Avianca, it IT department manages all infrastructures for it marketing department which means that all IT infrastructures are on-premises, creating complexity to manage with it airline infrastructures and complexity over cost control. On adopting Amazon Elastic Compute Cloud (Amazon EC2) and Amazon Simple Storage Service (Amazon S3), Avainca within six month experienced 100% service level agreement delivery (SLA) to its business partners, in addition to 60% cost savings (Avianca, 2012).

2. On-demand scalability: Pixar Animation Studios as an example benefits from the cloud’s on-demand scalability advantage whenever rendering requires

higher capacity and

usage

level experiences

high

spikes

unexpectedly, rendering need not be altered as almost automatically just the

required resources are added to operations. With On-demand benefit as a sole advantage, users only bear cost on resources used, in comparison to On-premises platform, users are not billed on fixed cost, maintenance, and depreciation whether or not resource are used, rather, users On-demand advantage allows them to request and modify resources deployment.

3. Market adaptability and competitiveness for start-ups: With the low cost of deploying on the cloud, start-ups are taking the advantage to compete in the market on a less costly platform than ever. A case study is Optensity, a software firm providing big data application and processing through cloud computer. Setting up such an intensive operations requires high cost which as a bootstrap start-up, Optensity could not comprehend it. Deploying its operation on AWS cloud platform, its annual total infrastructure computing cost was cut to about $2, 400 from the market’s $50, 000 estimate to get such a company started. As at January 2013, Optensity now provides services to US Department of Defence (DoD) and Intelligence agencies (Optensity, 2013).

4. Masked complexity: Abstracting all operations, facilities and sophisticated nature of a data centre from the cloud vendor to the user as a virtual machine allows for simplicity and time savings for more productive activities for users. Masking the intricate complexity of clients operations, a survey discovered it makes products and services platform engaging to consumers (IBM, 2012). As discovered in the survey, Xerox Cloud Print hides its complexity of storing, converting and distributing files to printers, from workers.

5. Increased innovations: With addition of masking complexity, On-demand scalability and cost savings advantage of cloud computing, operations, process and business innovations, “seed and grow” activities are encouraged on a more economical platform (Accenture, 2011). For an innovative short run project like Obama for America (OFA) campaign, it would be an economic waste to establish required sophisticated infrastructures to meet unknown campaign spikes, given that the project was to be on a short run, running on a limited expense, and expecting a national visitation. 29

6. Elasticity: With remarkable increase in the use of simulations and scenario modelling in products and service industries (PwC, 2013), likewise, there is rise in expectation for more sophisticated computing infrastructures; compute, storage and network. With cloud computing, “elasticity is a game-changer” (Microsoft, 2010), as adopting a unit of virtual machine for a thousand hour is approximately equal to adopting thousand unit of virtual machines for an hour, industries and researchers will be capacitated to achieve their complex task that were impossible with limited resources and costly possibilities. A case study is the prestigious Pixar Animation Studios. For Pixar, rendering productions is time intensive, it takes eight hours per frame to render a full movie of hundreds of thousands of frames, using a single processor, and this would take 272 years. Adopting Windows Azure, Pixar was able to render faster at an economical cost. 3.1.8. New Opportunities with the Cloud Cloud computing has gained support from environmentalists, because it increases energy efficiency. According to research by the WSP Company, performed by an order from Salesforce.com, in 2010, the savings via Salesforce.com through the use of a joint information infrastructure was 17900 tons of carbon; this is equivalent to the retirement from service of 37 000 automobiles (Dudin & Smetanin, 2011). 1. Cost Analysis of Cloud Computing for Education (Koch, et al., 2012) 2. Nexus of Forces 3. Big Data Analytics

3.2.

Literature Review (Academic)

Five interconnected factors determines the sustainability of the cloud business; usage, cost, pricing, experiment types, forward loads (predictive measurement of the four factors). 3.2.1. Sustainability of the Cloud Business

Business benefit hype about cloud computing has changed perspective from its early development age to its current advanced stage (Lutz & Keith, 2012). In Lutz and Keith’s European Commission’s 2012 cloud computing research, the cloud business and cost model was the major “essential research issues” towards the business sustainability of the cloud business. As prospective cloud vendors take up the challenge to share in the providers’ benefit in cloud computing, there is necessity to consider the implicit challenge in cloud computing business model, as it emergent has brought about new business model which implicit within them need refining attention to ensure there viability. As this study is about the provider’s side of cloud computing, achieving the business sustainability of the utility computing is about the optimum relationship between cloud computing business revenue and cost (Gabriel & Rene, 2003).

3.2.2. Forecasting Cloud Usage

Been that cloud computing is in its early evolving stage (David Mitchell Smith, 2011), researches in providing decision makers realistic cloud computing facilities demand forecasts have been a bootstrapping event for analyst, one of these reasons is the unavailability of public-domain data, (Rogers & Cliff, 2012) that represent the population traits researchers aim to provide insights into. Rogers and Cliff analysed researchers attempt to migrate the theoretical perception of swing options proposed by Clearwater and Bernando, where the feasibility of migrating cloud computing demand to 3rd party. For Rogers and Cliff, migration to a 3rd party was necessary for instances when the providing vendor’s resources has been fully utilised and to 31

ensure users are not denied requested cloud service. In forecasting the demand of the cloud computing use, Rodgers and Cliff need historical time series data and also under varied users’ cluster. Use of historical data has always been the primary tool for predicting the future in the distributed computing market (Huberman & Hogg, 1995), Huberman and Hogg examined the micro behaviour of distributed computing demand overtime with respect to resource allocation using streams of database at Xerox Research Centre. For Huberman and Hogg, there was available real world data compared to researchers’ like Clearwater and Huberman. As discussed in this section, researchers have forecasted the demand for distributed computing and cloud computing for sole purposes of ensuing that the quality of service is not disrupted due to unavailability of resources to meet cloud users demand (Rogers & Cliff, 2012) and introduction of outsourcing demand to a 3rd party, other purposes was to mitigate the incident availability of excess compute resources (Huberman & Hogg, 1995). Likewise, as a tool for compute resources pricing, Chebyshev’s inequality model was used to forecast the usage of distributed compute resource as a guide towards decision makers market pricing as a means of mitigating the uncertainty of poor quality os service at volatile seasons of the market calendar year (Sandholm & Lai, 2008). Public domain historical data from UK National Statistics Office was used to forecast the demand for cloud resources demand for a federated cloud market (Rogers & Cliff, 2012). 3.2.3. Clearwater and Huberman swing option

Truth telling reservation mechanism proposed by Wu et al was an extended work to mitigate the risk of untruthful public utility users under the swing options proposed Clearwater and Huberman (Rogers & Cliff, 2012). Forecasting consumer’s probability to use public utility was dependent on consumer notify the utility producer of user’s probability of demanding utility ahead of time. The fall of the Clearwater and Huberman proposition was that not all users will eventually fulfil their notification to patronize for utility. Wu et al.’s Truth telling reservation however mitigated Clearwater and Huberman’s swing options proposition. In truth telling options, a third party was introduced to propose the notification of future demand, and the third party served as

an intermediary between the cloud service producer and the user, who buys directly from the producer and sells at a profit margined price to the users.

3.2.4. Wu et al.’s and Modified Wu et al.’s truth telling model

2012 publication by Rogers and Cliff, there, was a remarkable achievement in forecasting the demand for cloud computing (Rogers & Cliff, 2012) using a two tiered approach agent-based simulation. The research’s result aided further research into introducing financial brokers (known as third party) to provide resources at instances when the cloud vendor’s resource can no longer accommodate the coming demand from cloud user (Rogers & Cliff, 2012). Clamp and Cartildge, 2013 was a result of an extended work of Rogers and Cliff research on forecasting demand of cloud resources and Wu et al Truth- Telling pricing model (Clamp & Cartlidge, 2013), (Wu, et al., 2008). The latest of the extension of Rogers and Cliff research was in using planning for the cloud data centre energy cost using, (Rogers & Cliff, 2013) this was made possible through using the forecasting procedure published earlier in 2012. The importance of being able to forecast effectively for the cloud demand is an essential foundation to other insights needed to enable the effective planning for the 3.2.5. UK non-seasonality adjusted sales data for cloud forecast

The value of Clearwater and Huberman’s swing option proposition and Wu et al.’s truth telling proposition as pricing models were made significant through the complimentary of usage data used by introduced by Rogers and Cliff (Rogers & Cliff, 2011). Using obtained data from UK National Statistics Office on the NonSeasonality Adjusted Index of Sales at Current Prices from 1988 to 2011, Rogers presented the work for four different market segments (Rogers & Cliff, 2012). Using A modified version of the Wu et al.’s model was used to test the performance on the data collected from the UK National Statistics Office. 3.2.5a. Modified Model Clamp and Cartildge, 2013 summarized the Wu et al.’s modified model below: 33

4. At Period 1, which is the first period the customer purchases a a unit of resources from the third party (the coordinator), each user 𝑖 makes prior notification of the chance of purchasing another unit of resources in the coming period (Period 2), notification is made with probability 𝑞𝑖 .

5. Haven received prior notification, the third party goes ahead to reserve units of resources if available resource can serve the prior notifications and also, if from three years historical performance, the proportion that any addition unit of resources will be utilised is positive, this is represented by Marginal Resources Utilization (MRU), that is, if 𝑀𝑅𝑈 > 0 additional resources will be acquire from the producer.

6. At the Period 2, the third party delivers the units to users 𝑖 who finally buys them at price 𝑓(𝑞𝑖 ) if resource is required; 𝑔(𝑞𝑖 ) if resource is not required.

The modified Wu et al model presented by Rogers and Cliff was integrated with the UK’s non-Seasonality adjusted sales data. Firstly the sales data was observed to have a gradually increasing trend as shown, depicting a lognormal distribution. From the implantation of the model, the third party was discovered to make profit either in cases when profit is maximized or not. Permitting federations of the cloud as suggested by Buyya et al, gave three possible interjections to enable future demand are properly fulfilled; first is introducing “Cloud Coordinators”, “Cloud Brokers” and the “Cloud Exchange” (Buyya, et al., 2010).

Figure 5: Non- seasonally adjusted index of sales at current prices from January 1986 June 2013 for non-store retail The integration of the Rogers and Cliff research into this study will be in the terms of the influence a coordinator plays in the cloud computing, and most importantly, the growth trend contribution to demand forecasting in the cloud computing. Rogers and Cliff’s assumption of using the non-seasonally adjusted sales data of non-store retail market (which is inclusive of mail orders and e-commerce related business) as a strong representative of the IT industry would have been more valid if erroneous unrepresentative share of the non-store retail market was accounted for. Validating the percentage of the internet related activities from the non-store retail trade could have some influence to the model’s result. As at 2013, online

35

transactions were estimated to contribute less than 15 per cent to the annual total retail sales (Schultz, 2013). 3.2.6. Pattern Matching for cloud forecast

As a proposition to the workload prediction in cloud computing, Caron et al analysed data for on-demand grid computing and produced predictions of future usage using pattern matching from historical data (Caron, et al., 2010). To overcome the unavailability of cloud computing’s public domain data, Caron et al made use of three grid computing clients (Large Hadron Collider, NorduGrid and SHARCNET) and a cloud computing client (Animoto). Rather than focusing on the whole virtual machine usage, the compute usage was made the focused point as the storage system data was inaccessible. Caron et al extended Kuperferman’s predictive model into predicting for grid and cloud compute resources demand model using time slices of 100 seconds using UCSB scoring metric (𝐴𝑙𝑜𝑔 )𝜎 𝛾∁ − + 𝛽 𝐶 𝐴𝑙𝑜𝑔

𝐴𝑙𝑜𝑔 = − log(1 + 𝛿𝑎 − 𝐴) , 𝛿𝑎 < 1

𝑊ℎ𝑒𝑟𝑒:

𝐶=

#𝐶𝑃𝑈 ℎ𝑜𝑢𝑟𝑠 ∗ 0.10

∝, 𝛽, 𝛾, 𝛿𝑎 , ℎ𝑎𝑣𝑒 𝑏𝑒𝑒𝑛 𝑐ℎ𝑜𝑜𝑠𝑒𝑛 𝑡ℎ𝑟𝑜𝑢𝑔ℎ 𝑒𝑥𝑝𝑒𝑟𝑖𝑚𝑒𝑛𝑡𝑎𝑡𝑖𝑜𝑛 𝐴 𝑟𝑒𝑝𝑟𝑒𝑠𝑒𝑛𝑡𝑠 𝑡ℎ𝑒 𝑎𝑣𝑎𝑖𝑙𝑎𝑏𝑖𝑙𝑡𝑦 𝑜𝑓 𝑙𝑜𝑔𝑟𝑖𝑡ℎ𝑚𝑖𝑐 𝑠𝑐𝑎𝑙𝑟

𝐴𝑙𝑜𝑔 𝑟𝑒𝑝𝑟𝑒𝑠𝑒𝑛𝑡𝑠 𝑡ℎ𝑒 𝑎𝑣𝑎𝑖𝑙𝑎𝑏𝑖𝑙𝑖𝑡𝑦 𝑖𝑛 𝑙𝑜𝑔𝑟𝑖𝑡ℎ𝑒𝑚𝑖𝑐 𝑠𝑐𝑎𝑙𝑒

𝐶 𝑟𝑒𝑝𝑟𝑒𝑠𝑒𝑛𝑡 𝑡ℎ𝑒 𝑐𝑜𝑠𝑡

Caron et al.’s background using pattern matching was based on Kupferman’s autoscaling algorithms of; Auto-Regression (AR1), Linear Regression, and Rightscale algorithms method of forecasting (Kupferman, et al., 2009). Kupferman’s predictive

mechanics result concluded that using the auto scaling predictive approach , reactive results are ascertained given the historical data contains sharp changes. 3.2.7. Central Limit Theorem

Moivre and Laplace theorize the probability theory that the sum of independently generated random variables, assuming that their means and variances are finitely scaled results to a normal distribution (Susan & Jess, 2003).This theory has been widely used by statisticians to estimate poorly distributed data as normal distribution and also data with unknown distributions. The central limit theorem holds that given set of 𝑁 independent random variables 𝑋1, 𝑋2, 𝑋3,…, 𝑋𝑁, with mean 𝜇𝑖 , variance 𝜎𝑖2 and

probability distribution 𝑃(𝑋1 , … , 𝑋𝑁 ) apportioned to each independent variant, the sum

of the independent variant will result to a normal variant as given below 𝑋𝑛𝑜𝑟𝑚 =

𝑁 ∑𝑁 𝑖=1 𝑥𝑖 − ∑𝑖=1 𝜇𝑖 2 �∑𝑁 𝑖=1 𝜎𝑖

This Central limit assumption was implemented in this study, as will be seen in the Methodology section, Monte Carlo distribution was used to generate usage data for each of the BonFIRE sites, with assumption of normality.

3.2.8. Monte Carlo random generation and Copulas for Cloud usage forecast Haven reviewed previous work done with forecasting the resource usage (or demand) in the information technology sector, we decided to take up a novel approach to result desired forecast. The novel approach was necessary due to the scarcity of realistic data. The available data was not just for a limited in population of experiments and time scale of 19 weeks; also it was highly biased with over 90% level of biasedness as the cloud vendor has control of over 90% of the cloud users as hired users. In

physical

sciences,

engineering,

computer

graphics,

applied

statistics,

computational biology, applied statistics, artificial intelligence for games, design and

37

visuals, risk analysis, finance and business, Monte-Carlo simulation has been used to analyse problems under uncertainties (Wikipedia, 2013). The use of the Copulas probabilistic theory for defining dependencies between models for multivariate distributions have been widely applied; in economics, (Brendstrup & Paarsch, 2007) used Frank of the Archimedean family of copulas to explore the equilibrium behaviour and best profitability scenarios of serially made sales against individually made sales at the at the English format auctions event; in epidemiological studies where (Clayton, 1978), extended Cox’s regression model (Cox, 1972)on the dependency between individual victims disease frequency. Although Clayton did not theorize Copulas joint distribution theory (Sklar, 1973) defined copulas. Clayton’s copulas model resulted in one of the Archimedean family of copulas (Sklar, 1973) by the extraction of the joint cumulative distribution of the parameters marginal distributions;

𝐺(𝑥1 , . . . , 𝑥𝑛 ) = 𝐶(𝐹1 (𝑥1 ), . . . , 𝐹𝑛 (𝑥𝑛 ))

𝑊ℎ𝑒𝑟𝑒:

𝐶 = 𝑛 − 𝑐𝑜𝑝𝑢𝑙𝑎 𝑓𝑢𝑛𝑐𝑡𝑖𝑜𝑛

𝐺 = 𝑛 − 𝑑𝑖𝑚𝑒𝑛𝑠𝑖𝑜𝑛𝑎𝑙 𝑗𝑜𝑖𝑛𝑡 𝑑𝑖𝑠𝑡𝑟𝑖𝑏𝑢𝑡𝑖𝑜𝑛 𝑓𝑢𝑛𝑐𝑡𝑖𝑜𝑛

(𝑥1 , . . . , 𝑥𝑛 ) = 𝑟𝑒𝑎𝑙 𝑛 − 𝑡𝑢𝑝𝑙𝑒𝑠

(𝐹1 (𝑥1 ), . . . , 𝐹𝑛 (𝑥𝑛 ) = 𝑚𝑎𝑟𝑔𝑖𝑛𝑎𝑙 𝑑𝑖𝑠𝑡𝑟𝑖𝑏𝑢𝑖𝑜𝑛

Deciding on which of the copulas to be used was based more on subjective assumptions than theoretical, as (Oh & Patton, 2013) stated the necessity of ongoing work in defining the right copula model is right for the industrial and academic goals intended. As an extension of work done to mitigate the limitations in the use of copulas, (Oh & Patton, 2013) performed simulations to derive like hood estimates of copulas based models’ parameters. Other researches to improve the accuracy measurement of copula based models have measured the accuracy boundary between the t and Gaussian Copulas against alternative Gumbel (or Galambos) and

Clayton copulas, (Demarta & McNeil, 2005) concluded with the validity in swapping the t lower tail copulas with the Gumbel copulas as well as (Breymann, et al., 2003) previous research on trading-off the t lower tail copulas for the Clayton copulas. The trade off against the t lower tail limit copulas was necessitated for its limitation of estimating the degree of freedom for realistic purpose.

39

4.

Methodology

This chapter describes and explains the methodology deployed in this study to collect the research data, the purpose of collecting the data, description of each techniques used in collecting the data and the limitations of the methodology. This study is a practical project-based study which employs largely primary data for quantifications while archives of secondary data were used to qualify the results and analysis. 4.1. Project Objectives 1. To investigate the sustainability of BonFIRE given the I-a-a-S and the 3rd Party platform. 2. To generate MonteCarlo future usage using the LoadGenerator. 3. To explore relationships between key model parameters of cost, usage within the two platforms named above.

4.2.

Problem structuring

In the real world, most problems encountered are ill structured, ambiguous and with much unknowns than known (Rosehead & Mingers, 2001). Undertaking this study; being an investigation into the business sustainability of the BonFIRE cloud computing prospective full operation. It was necessary to structure the problem so as to recognize were focus is mandatory and to allow focus towards achieving a substantial work. From Figure 6, the project’s overall focus were divide into two service models platform, which we aim to consider Infrastructure as a Service (I-a-aS) and the 3rd Party. Under either platform we needed to have models for the cost, demand and pricing. Given that BonFIRE operates an Infrastructure-as-a-Service platform, the total cost and expected demand will determine the cost per usage of BonFIRE’s resources which determines the pricing (assuming that pricing is not focused on market competitiveness). Otherwise, under a 3rd Party resources provision, BonFIRE’s pricing is dependent on the 3rd party. Likewise, from Figure 6 we could assume situations that are likely to necessitate outsourcing to a 3rd Party. If BonFIRE Cost

BonFIRE’s per unit of service production (

𝑈𝑠𝑎𝑔𝑒

) is costlier than the 3rd Party’s

pricing (in the case of outsourcing cost), or if BonFIRE’s usage (Usage = Demand ≤

BonFIRE Capacity) has attained it optimum, then 3rd Party resource provision is necessary (in the case of outsourcing usage). What results with the combination BonFIRE’s total cost (I-a-a-S total cost and 3rd Party outsourcing cost) and the BonFIRE’s total revenue (I-a-a-S total revenue and 3rd Party’s outsourcing revenue) determines what the sustainability of BonFIRE’s consortium sustainability is. However, this is not a one year journey, as will be discussed in the concluding chapter, the quality of our input data is the single most important tool towards attaining a quality forecasting analysis. For this research, we decided to focus on the demand of BonFIRE’s resources, as this is the model much investigation could be achieved based on available Sponsor’s data.

Figure 6: BonFIRE sustainability chart

4.3.

Data description

Data were electronically gathered from the preceding outputs of previous work done towards the sustainability of the BonFIRE project within the sponsoring organisation. 41

The data collected were supported with assumptions and sources supporting the assumptions made are included in Table of the appendix. 4.3.1. Cost data BonFIRE cloud computing cost have been previously estimated by the sponsoring organisation, the data were gathered through the Sponsors’ communication with each datacentre, also, a large amount of the cost data were based on realistic assumptions as noted in the Table

of the appendix,

assumptions were based on information regarding other information technology companies like Amazon AWS, Intel, Dell. The surveyed data was quantified into Excel spreadsheets, and are described below. Cost data description BonFIRE’s datacentres initial cost, operating cost and other cost were grouped into two, the fixed cost and the marginal cost, as shown in Table 1. 1. Fixed cost data: The capital cost for the BonFIRE’s six collocated datacentres are the cost invested in the hardware, the cost includes the compute hardware cost and the storage hardware cost. Likewise, three years depreciation cost was allocated for the hardware. The fixed cost basically consist of all cost incurred during the operation of BonFIRE that are unchanging, meaning this cost are not determined by the usage of BonFIRE, they remain fix and are expended upon whether experiments are carried out by users or not. It is important to note here that BonFIRE’s operation also involves the network facility, (the combination of the compute, storage and network hardware forms the cloud’s virtual machine). However, the BonFIRE’s technical team currently cannot provide information about the network usage and its capital cost.

2. Marginal cost data: Additional cost of operation refers to the marginal cost, while its nature to change overtime makes it varied. For BonFIRE, much of its operational cost is dependent on the cloud’s resources usage. This constitutes the cost of human resources which are: the User Support staff, Software Development staff, and Systems Admin staff. These are varied because the number of staff is determined by the development work to be

done and maintenance work to be managed, all of which are determined by the demand overtime. Other variable cost includes cost of maintenance, operating system, the space, power. This cost varies and are determined per experiment hour of cloud services used. This cost expands when more experiment hours possibility are to be accommodated, and shrinks whenever experiment level shrinks, thus, this cost is directly related to the level of experiments hour. This variable cost elements experience a marginal cost increase or decrease whenever the utilization level (or demand level) rises or fall. Fixed (Euros)

Marginal cost (Euros)

Compute hardware

Hardware maintenance cost

Storage hardware

System administration cost

Hardware depreciation Software development User support Percentage of marginal cost to Compute Percentage of marginal cost to Storage hardware Percentage of marginal cost to Network hardware Table 1: Current BonFIRE cost parameters 4.3.2. Resources data

4.3.2. Datacentre resource data description Capacity level of hardware: Hardware for each site is measured for capacity. a) Compute resources: this is measured in core hour capacity. For these to be measured, the numbers of servers are multiplied by the numbers of cores to arrive at the total number of cores. The number of hours in a year (8760 hours) was multiplied by the total number of cores in each site to arrive at the total number of core hours available for the BonFIRE facility. 𝑁

𝑁

𝑖=1

𝑖=1

𝑀𝑎𝑥𝑖𝑚𝑢𝑚 𝑐𝑜𝑚𝑝𝑢𝑡𝑒 𝑐𝑜𝑟𝑒𝑠/𝑎𝑛𝑛𝑢𝑎𝑙 = �� 𝑆𝑖 ∗ � 𝐶𝑖 � ∗ 𝑌𝑒𝑎𝑟𝑙𝑦 ℎ𝑜𝑢𝑟𝑠 43

𝑤ℎ𝑒𝑟𝑒:

𝑆 𝑟𝑒𝑝𝑟𝑒𝑠𝑒𝑛𝑡 𝑛𝑢𝑚𝑏𝑒𝑟𝑠 𝑜𝑓 𝑠𝑒𝑟𝑣𝑒𝑟𝑠

𝐶 𝑟𝑒𝑝𝑟𝑒𝑠𝑛𝑡 𝑛𝑢𝑚𝑏𝑒𝑟𝑠 𝑜𝑓 𝑐𝑜𝑟𝑒𝑠 𝑖𝑛 𝑠𝑒𝑟𝑣𝑒𝑟𝑠

Assumptions regarding the number of servers and number of cores were made for most sites, as some sites were reported not have disclosed the real measurement of capacity at their reach.

b) Storage resources: this is measured in storage gigabyte per hour. To account for the number of total storage gigabyte for the BonFIRE project, the number of storage nodes was multiplied by the number of storage gigabyte, this was done for all sites. To arrive at the total Storage gigabyte hours available for the BonFIRE project for one year, the total number of hours in a year was multiplied by the total number of storage gigabyte.

Usage level of hardware: this was the only data that was needed to be collected using the Python script. a) Real usage data: Using the python script, the weekly usage of the hardware can be collected for all sites, this data is believed to be rich enough to specific user details, whether a high core user or low core user, whether an experiment, whether failed or successful attempt. b) Generated usage data: Assuming a normal distribution, the python load generator (script in Appendix VIII) can generate usage of the hardware over a given numbers of users. The purpose of this is to simulate the behaviour of the hardware against the capacity of the hardware when needed.

4.3.3. Data tools The tools used for this research includes; MatLab, IBM SPSS, Excel, @Risk and Python Script LoadGenerator.

4.3.4. Statistical methods Distribution fitting to usage data The use of density functions to generate future loads with the knowledge that 19 weeks data of the resources usage is all we have to provide knowledge of what will happen with the future usage, we aimed to know the distribution of this usage over time. Normally distributed usage level Given that the available data was short, and that its behaviour over the 19 weeks was not a good representation of the likely BonFIRE infrastructure usage, we assumed a normal distribution for likely BonFIRE usage performance. The assumption guided the Python coded LoadGenerator to be normally distributed in it generation of BonFIRE resources usage across BonFIRE’s six sites. a. LoadGenerator’s Descriptive Statistics To generate a result structured in the nature of the original resources usage for the BonFIRE capacity, the LoadGenerator was used to quarry usage data in a similar. The LoadGenerator has 19 variables which are all needed to be fixed before the result could be produced. The variables for are grouped into the following two groups: 1. Number of experiments Resource usage sizes distribution (normally distributed). The notation 𝑁(𝜇, 𝜎 2 )

means normally distributed with mean 𝜇 and variance 𝜎 2 . Using python’s

normal random number generation funtion 𝑟𝑎𝑛𝑑𝑜𝑚. 𝒈𝒂𝒖𝒔𝒔�mu, sigma�

𝑚𝑢 ⇨ 𝑚𝑒𝑎𝑛

𝑠𝑖𝑔𝑚𝑎 ⇨ 𝑠𝑡𝑎𝑛𝑑𝑎𝑟𝑑 𝑑𝑒𝑣𝑖𝑎𝑡𝑖𝑜𝑛

The required parameters to be fixed are as follows in Table 2. Compute

Mean

Storage

Network

Smal

Mediu

Larg

Smal

Mediu

Larg

Smal

Mediu

Larg

l

m

e

l

m

e

l

m

e

2.

4.

6.

8.

10.

12.

14.

16.

18.

(µ)

45

Standar

3.

5.

7.

9.

11.

13.

15.

17.

19.

d deviation (δ) Table 2: LoadGenerator's configuration values Given that these 19 values have been fixed, the LoadGenerator performs a onetime normal distribution simulation which distributes the usage of the two resources i.e. compute and storage, across the six sites.

3. Pre-process: Cloud Usage Forecast 3.1.

Overview of historical data

To generate future loads, it is a criterion to use replicable performance parameters of the previous data. This makes the generated data to be dependent (to certain degrees of dependency) on the previous data: This makes our load generation model 𝑌𝑡 + 1 = 𝑌𝑡 + 𝑌𝑡 − 1 + 𝜀.

Equation 1: LoadGenerator’s model

𝑊ℎ𝑒𝑟𝑒 𝑌𝑡 𝑖𝑠 𝑢𝑠𝑎𝑔𝑒 𝑎𝑡 𝑝𝑟𝑒𝑠𝑒𝑛𝑡 𝑡𝑖𝑚𝑒

𝑌𝑡 + 1 → 𝑢𝑠𝑎𝑔𝑒 𝑎𝑡 𝑓𝑢𝑡𝑢𝑟𝑒 𝑡𝑖𝑚𝑒 𝑌𝑡 – 1 → 𝑢𝑠𝑎𝑔𝑒 𝑎𝑡 𝑝𝑎𝑠𝑡 𝑡𝑖𝑚𝑒 𝑒 𝑡ℎ𝑒 𝑒𝑟𝑟𝑜𝑟 𝑡𝑒𝑟𝑚

(Makridakis, et al., 1998) From the previous data dated January to June 2013, the usage for all sites were collected and a total of 7989 experiments were conducted. The compute capacity was used at a maximum of 55, 651 core hours by any one experiment, while the minimum compute core hour used was 0.0001 core hours.

The total compute

utilization for the 19 weeks recorded was 574,241.4881 core hours. Also, 90% of all experiments conducted did not use more than 29 core hours in single experiments, as can be seen in Figure 7, the legible spikes are few, indicating that thousands more are using very little of the compute resource. The average of total experiments was 71.88 core hours at a deviation value of 1005.12 core hours. The high level of deviation dictates the high level of uncertainty in expecting what the compute usage could be. Finally, for the compute, all this indicate that most experiments conducted were not large experiments and the variation in all experiments conducted is wide, which makes for wide errors in predictability. Also, the average weekly utilization for BonFIRE compute during the 19 weeks was 37.63%. As shown in Figure VII of the 47

appendix, the maximum BonFIRE utilization was 61.83% in the 16th week and a minimum of 6.68% in the 1st week.

All storage resource usage were totalled 2,384,872.03 gigabyte hours with a maximum of 169,234.46 gigabyte hours and minimum of 0.0039 gigabyte hours at a deviation of 4389.85 core hours, the average total usage of storage resources was 298.52 gigabyte hours. As with the compute usage, 90% of all experiments conducted used not more than 72 storage gigabyte hours. From the graph in Figure 7, only 4 experiments conducted used more than 20,000 core hours, while majority of the 7989 experiments conducted were rarely represented in the graph as their usage level was very low, as mentioned early, 90% of all experiments conducted utilised not more than 29 core hours. Similar occurrences were recorded for the storage resource usage as less than 1% (0.003%) the experimenters utilized more than 20,000 gigabyte hours. Likewise, the average weekly utilization for the BonFIRE storage resources during the 19 weeks was 3.66%. From Figure of the appendix, it is shown that the maximum storage utilization was recorded in the 9th week at 6.67% and a minimum of 0.43%, also in the first week.

Figure 7: Compute resource 19 weeks usage

Figure 8: Storage resource 19 weeks usage 3.2.

Experiment types of the Cloud

For the BonFIRE cloud platform, four different types of experiments are possible. These are; High Performance Computing (HPC) experiments type, Media experiments type, Network experiment type and Multi-cloud experiments type. Table 3 shows that the HPC experiments type uses, large compute resource, medium storage resource and small network resource. Experiment

Compute

Storage

Network

type

resource

resource

resource

usage

usage

usage

HPC

Large

Medium

Small

Media

Large

Large

Large

Network

Small

Small

Large

Multi-cloud

Small

Small

Large

Table 3: Resource usage distribution across experiments types

49

3.3.

Descriptive Statistics for LoadGenerator

3.3.1. Inference from original data The normally distributed usage generation (using the LoadGenerator) is needed to infer the BonFIRE’s different experiment types. Using descriptive statistics, we quantitatively described the main features of the 19 weeks data. With the aim to provide inference of the original data through the experiments sizes and the resource usage density distribution parameters, descriptive statistics was carried out on the original data.

Firstly, there was need to technically decide what the sizes of resource usage means. To set the range for each resource usage sizes, initially, we decided to set the size ranges (small, medium and large) of the resources as a function of the overall capacity, but this would be infeasible at this stage of BonFIRE’s development as recorded that the average weekly utilization level achieved in the recorded 19 weeks was less than around 38% for the compute resource, and most especially at 4% for the storage resource (Figure and Figure ). With this observation, we objected in using the previous 19 weeks data as a test sample to get the size ranges. Therefore, the 19 weeks usage data was divided into three; Small usage level, medium usage level and large usage level. The weighted percentile of the 19 weeks usage data core hours and storage hours

was used to allocate the first one-third (from

ascending order) to the small compute usage level, the second one-third was allocated to the medium usage level and the last third to the large usage level. With this, the small usage level for the resources was set to the first 33.3% weighted percentile of the usage data total for each resource. This accounted for 99% of compute resource and storage resource users. Medium was set between the 33.3% to 66.6% weighted percentile while the large resources usage sizes was the upper third weighted percentile. 0 < 𝐶𝑜𝑚𝑢𝑝𝑡𝑒𝑆𝑚𝑎𝑙𝑙 ≤ 33.3% < 𝑀𝑒𝑑𝑖𝑢𝑚 ≤ 66.6% < 𝐿𝑎𝑟𝑔𝑒 > 66.6% Equation 2: Distribution of usage sizes

Using the IBM SPSS tool, descriptive statistics was performed with the result shown in Table . Table 4 shows the approximated result to its nearest thousand, the reason for the approximation was to ensure a more realistic representation of the usage sizes is achieved. For clarification, initially, usage range for the small compute was extended to 2102.717 core hours (using the first 33.33% weighted percentile), however, haven applied approximation, the small compute usage size was no longer more than 1999.99 core hours at 1992.79. Similar reprocessing was applied for the storage resources and the sizes. Descriptive Statistics N

Minimum

Maximum

Mean

Std. Deviation

Core hours Small Medium Large

7941

0 1992.793333 22.78361443

117.2183184

39

2019.9675 9812.236667 4773.078264

2283.29866

9 10000.97444 55651.00028 23020.75041

16361.74767

7989 Gigabyte hours Small Medium Large

7965

0 29112.45369 100.3678538

928.6027253

17

30555.29

60489.92 42616.11179

11268.12181

7

71651.80

169234.46 122995.4533

38510.8704

7989 Table 4: Approximated descriptive statistics From Table 4, it could be seen that over 90% of the 19 weeks BonFIRE usage were small type experimenters for both resources. The minimum compute core hours and storage gigabyte hours used by small usage sizes were 0 core hours. Over the nineteen weeks usage distribution, Figure 9 and Figure 10 shows that most of the experiments conducted were very close to zero, this made graph not to be perfectly represented as over 4000 of compute users used very close to zero core hours, his means that not just 90% of usage were small usage, but over half of the small compute and storage users were very small users. For the distribution of the size 51

ranges gives a better knowledge of the behaviour within this size ranges, normal distribution curves were plotted with the histogram of each. Observing the Compute Large and Storage Large diagram, with a high rate of standard deviation given the small numbers of experiments, the is possibility of resulting in high resource usage overtime, given larger numbers of experiments, likewise the reason for the low deviation values for all small sizes is as a result of the high numbers of values clustered into the small size ranges. Although the numbers of medium size resources usage were higher than the large compute users, for both resources, Figure 11 to Figure 14 shows that the deviation for the large compute users was in tens of thousands scaling while the medium compute users was in a thousand scaling. Overall, the standard deviation for large size compute usage was 16361.75 core hours against 2283.30 core hours for medium size compute usage. Similar deviation difference was experienced for the storage resources usage. The advantage of this is that, even with few large size resources user, most resources utilization level should be expected from them.

Figure 9: Historical compute small Figure 10: Historical storage small usage

usage

Figure

11:

medium usage

Historical

compute Figure 12: Historical storage medium usage

Figure 13: Historical compute large Figure 14: Historical storage large usage

usage

3.3.2. Inference for generating an annual data

Haven gotten a descriptive understanding of the input data towards which future usages will be generated, we at this stage aim to generate a full one year usage inferring from the available usage data, average weekly experiments performed was fixed at 420 experiments (this was gotten from the initial 19 weeks usage average); it was assumed that for an annual usage of the BonFIRE’s infrastructure, 21840 experiments were to be performed (420 experiments in 52 weeks). Using the usage sizes mean and standard deviation from Table 4, the LoadGenerator’s input 53

configuration values in Table 2 was determined. The first parameter, 𝑁, of the

normal distrubtion function 𝑁(𝜇, 𝜎 2 ) was fixed as the annual numbers of experiments (21840). Figure of the appendix pictorially describes the processing used to generate the annual data using the LoadGenerator. Haven defined the values of the LoadGenerator, Table describes the characteristics of the generated annual data. A major indication from the statistical inference form Table is that as the size of 𝑁 increases from 7989 experiments for 19 weeks to 21840 experiments for 52 weeks, some of the confidence level intervals have

changed. The standard deviation of the large size usage of the compute resource improved its confidence level be 23.59% (percentage change in standard deviation) from 16361.7 core hours to 12501.5 core hours. While the large resources size deviation level improved by 13.12% (from 38510.9 storage gigabyte to 33458 gigabyte). Also, the small size, the small size usage of both resources types worsened in their confidence level as the standard deviation. Descriptive Statistics Maximu

Core hours

𝑵

𝐌𝐢𝐧𝐢𝐦𝐮𝐦

m

1128 Small

0

Std. Mean

Deviation

124.344261 0

1995.48

5

201.8321106

6059.66399 Medium

1676

2003.73

9994.19

8

2318.135703

28941.4211 Large

8884

10018.83

86024.24

3

12501.46893

2184

Gigabyte hours 1170 Small

7

2318.24524 0.01

29997.09

2

6058.475112

45971.5017 Medium

5076

30027.72

69950.83

9

9372.405997

Large

5057

298838.9

128486.046

2

5

70015.46

33458.00112

2184 0 Table 5: Generated usage descriptive statistics 3.4.

Generated usage

3.4.1. Description of Monte Carlo generated usage Running the LoadGenerator for a 52 weeks (21840 experiments) period, Figure 15 shows the compute resource usage reaching its weekly peak at 6,042,603.580 core hours with a base of 4,614,668.070 core hours, during the simulated one year period, the average weekly compute usage was at 5,161,811.259 core hours. The storage resource usage, from Figure 16 was at a base of 1,014,633.030 gigabyte hours with a peak of 2,940,132.430 gigabyte hours. A critical observation between the storage resource usage and the compute resource usage is the high level of variation that occurred within their respective usage. The high level of difference (66%) between the base and peak of the storage resource usage and the compute resource usage (24%) dictates a reason why the storage resource usage would be more flawed to forecast than the compute resource usage. In all, the input data available is not sufficient enough to provide an accurate level of forecast.

Figure 15: 52 weeks generated compute usage

55

Figure 16: 52 weeks generated storage usage

Investigating each of the resources sizes behaviour through the 52 weeks simulation, it was discovered that over 50% of experiments conducted in both the compute and storage resource were recorded to be small experiments type; this is shown is shown in Figure 17and Figure 18. Figure 20 shows the obvious positive skewness recorded for the small compute resource users was as a result of having over 98% of the small experiments using less than 1000 core hours. And only about 2% were users, using between 1000 to 1999.99 core hours per experiment. For the medium type users, opposite behaviours appeared for each resource types, the medium type experiment histogram graph is positively skewed for storage resource users, this is indicating that most of the medium type experiments are using a lower limit of the medium (Figure 21 and Figure 22) storage resource size range, while for the medium compute resource usage varies randomly across the compute medium size range. Lastly, the large size experiment usage (Figure 23 and Figure 24) the resource usage are highly varied and at a more normal distribution. The implication of this is the unpredictability of the extreme large and extreme low compute resource users.

Figure 17: Compute usage distribution size

Figure 18: Storage usage distribution size

57

3.4.2. Sizes distribution of generated usage

Figure 19 Generated compute small

Figure 20 Generated storage small

Figure 21 Generated compute medium

Figure 22 Generated storage medium

Figure 23 Generated compute large

Figure 24 Generated storage large

3.4.3. Clustering of experiment types generated As an investigation into MonteCarlo generated data, Figure 25 shows the experiment types share of the annual resources usage. The most obvious nodes are the HPC experiment type and the Media experiment types. As clarified in Table 3, the HPC experiments type uses a large size of the compute hardware as well as the Media experiments type users. Although, there is a minute gap between the HPC and Media experiments types utilization share of the compute hardware, this is expected over time not to have equal usage even though both experiments types consumes equal size, the numbers of experiments conducted by either experiments types will vary, realistically, as can be seen from Figure 26, in Node 5, which is the largest 40% utilization division of the compute resources, the HPC experiments type had 50.2% share of the maximum 40% utilization ahead of the Media experiments type (the remaining 49.8%) it can also be noted from Figure 26 that no Multi-cloud and Network experiment types users had a share of the compute hardware maximum 40% utilization. Likewise, over 99% of the Multi-cloud and Network experiment types utilized the lowest 50% total utilization of the compute hardware. In total, the experiments conducted were randomly distributed across the experiments type, as Node 0 depicts. The storage usage had the largest share for the Media experiments type (Figure 25), also clarified in Table 3. Almost all the capacity (approximately 100%) of the maximum 20% utilization level of the storage resources was used by Media experiments type according to Node 5 of Figure 27, which refers to 90,513.78 gigabyte utilization and above.

59

Figure 25: Clustered experiment types resource usage

Figure 26: Decision tree of compute resource usage per experiments types

Figure 27: Decision tree of storage resource usage per experiments type

However, using Monte Carlo simulation did not finally result to the expected outcome, as there appears to be a statistical bias of independency in the process. This was as a result of not defining the relationship that exits between the two parameters (compute hardware usage and storage hardware usage). As shown in Figure to Figure , the correlation of resource usage across the six sites of BonFIRE, most especially for HP (Figure ), INRIA (Figure ) and PSNC (Figure), there appears to be a positive correlation over the 19 weeks. These allowed the inculcation of the Copulas probability theory into the Monte Carlo generated annual usage data.

4. Results and accuracy tests Present results in as complete, clear and helpful way as possible, analyse results in a useful way, and include critical commentary on the quality and the reliability/limitations of findings. 4.1.

Result analysis

4.1.1. Cost: The cost parameters were assigned probabilistic estimates as outlined in the methodology section of this project. Using industrial based Monte-Carlo risk analysis simulation software, simulations were performed for to know the probabilistic scale of 61

the estimated cost levels. For the BonFIRE project, the overall allocated cost level was discovered to have less than 10% probability of occurring. For example for one of the sites, EPCC the, with 1000 simulations over it was discovered that site’s cost allocated to compute resources, as can be seen in figure would be at least about 36% higher 90% of the time, while the cost allocated to storage resources would be 33% higher than the estimated amount 90% of the time.

Figure 28 : Probability measurement for EPCC's compute resource cost This wide level of deviation of probability indicates that the current cost model requires more complete estimates. With further investigations into the cloud computing cost estimates, we discovered three missing cost inputs factors that would need more realistic estimate from each BonFIRE partners. Power, Network and the Data centre staffing were three cost input models that were not realistically considered, but findings from the market estimate revealed that 7080 percent of the total operating cost of a data centre is accounted for by the power expenses (Pham, 2013). Researchers at HP LABS (Popa, et al., 2010)analysed selected data centre vendors’ power consumption of related networking equipment, a major focal point here is the high level of correlation between power usage and network traffic. Likewise, the high cost of energy was in 2009 estimated to be far more expensive for data centre providers than the cost of hardware infrastructure, for European countries information technology trend (Bertoldi & Atanasiu, 2009).

4.1.2. Usage and Experiment types: 4.1.2.1.

Copula result:

Using the Copula probability result, we were limited to getting information of the demand based on the three scenarios (Optimistic scenario, Realistic scenario and Pessimistic scenario) and not based on the experiment types. With this, we were able to estimate an annual usage of the total BonFIRE resources. We were able to go further with the 5 to 15 year usage possibility of the compute and storage resources demand. Also, the financial performances were estimated for the I-a-a-S and 3rd party platforms. The assumptions made for the three scenarios were based on the 60% of the Monte Carlo generated usage data for the optimistic scenario, 40% for the realistic scenario and 20% for the pessimistic scenario for the two resources demand. With the three scenarios of demand assumed for the BonFIRE infrastructures. The optimistic level was arrived at as 8,282,527.519 compute core hours as shown in Figure 29 and 27,898,354.08 gigabyte hours for the storage resource (Figure 30). The realistic scenarios were assumed to be 5,521,685.013 core hours and 18,598,896.68 gigabytes hours for the BonFIRE resources. While the pessimistic scenarios were 2,760,842.506 core hours and 3,719,779.337 gigabyte hours for the pessimistic compute and storage resource scenarios. For the compute resource usage, Table 6 shows that there is 33.33% difference between the optimistic and realistic resource usage and 50% difference between the realistic and pessimistic resource usage. Optimistic Compute (core hours)

Realistic

Pessimistic

8,282,527.519 5,521,685.013 2,760,842.506

Storage (gigabyte hours) 27,898,354.08 18,598,896.68 3,719,779.337 Table 5: Copula generated usage Compute Optimistic Realistic

Optimistic Realistic Pessimistic 0.00% -33.33%

-66.67%

0.00%

-50.00%

Pessimistic

0.00%

Table 6: Percentage change in compute resources scenarios Storage

Optimistic Relistic

Pessimistic 63

Optimistic

0.00% -33.33%

-86.67%

0.00%

-80.00%

Realistic Pessimistic

0.00%

Core hour (Millions)

Table 7: Percentage change in storage resources scenarios 9

8.282527519

8 7 6

5.521685013

5

Optimistic

4

Realistic 2.760842506

3

Pessimistic

2 1 0 Optimistic

Realistic

Pessimistic

Gigabyte hour (Millions)

Figure 29: First year compute resource usage

30

27.89834503

25 18.59889668

20

Optimistic 15

Realistic Pessimistic

10 3.719779337

5 0 Optimistic

Realistic

Figure 30: First year storage resource usage

Pessimistic

Shown in Figure 31 and Figure 32, the weekly compute usage was less varied than the storage resource weekly usage. This could be linked to the variability experienced with the initial usage data used, as shown in Figure 16 where the level of the storage resource used varied from a very low level to a very high level. From Figure 31, the realistic scenario’s weekly compute resource usage ranges between 140,853.2045 core hours to 179,412.7783 core hours.

While for the storage

resource, the weekly variation lies between 149376.804 gigabyte hours to

Core hour (Thousands)

623,675.964 gigabyte hours. 200 180 160 140 120 Optimistic 100

Realistic

80

Pessimistic

60 40 20 0 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51

Figure 31: Weekly compute resource usage

65

Gigabyte hour (Thousands)

700 600 500 400

Optimistic Realistic

300

Pessimistic 200 100 0 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51

Figure 32: Weekly storage resource usage Making a forward note for the resources usage against the sites capacity in Figure 33and Figure 34, the compute resource usage will attain its maximum capacity for the pessimistic scenario toward the fourth year of BonFIRE’s operation, although, from the first year operating at a utilization of 65%. While for the realistic and optimistic scenario, the usage level is estimated to be above the BonFIRE’s capacity

Core hour (Millions)

right from the commencement of BonFIRE’s operation. 20 18 16 14 12

Optimistic

10

Realistic Pessimistic

8

Capacity

6 4 2 0 1

2

3

Figure 33: Five years compute usage

4

5

For the storage resource usage, as shown in Figure 34, it was estimated that BonFIRE’s capacity used will not attain its Maximum until about the thirteenth year of BonFIRE’s operation, given the optimistic scenario. Making an inference of BonFIRE’s previous operation from Figure of the appendix, it was shown that during the first 19 weeks BonFIRE’s operation, the average resource usage of BonFIRE was about 4%. As a result of this report to the BonFIRE’s management, it was suggested that the reason for the low utilization of BonFIRE’s storage infrastructure was linked to occurring technical difficulty. For BonFIRE’s realistic scenario, toward the beginning of the fifteenth year of the BonFIRE operation, the operations capacity is expected to be attained, while for the pessimistic result, the maximum usage is not expected to be reached until more future years. From this two analysis, we could conclude that the BonFIRE’s consortium have a higher tendency of serving its users storage resource at excess availability than it will be able to serve with the compute

Gigabyte hour (Millions)

resources.

400 350 300 250

Optimistic Capacity

200

Realistic 150

Pessimistic

100 50 0 1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

Figure 34: Fifteen years storage usage Making an estimate of the financial performance of the BonFIRE’s consortium for a year, the overall cost for the BonFIRE compute resource was higher if the BonFIRE operates an Infrastructure as a Service platform while it will be cheaper given the BonFIRE is operated on a 3rd party service platform as shown in Figure 35. The 67

optimistic compute cost is estimated at €693,523.57 given it operates as an Infrastructure as Service model, while it will be about 44% cheaper at €389,403.03 is operated as a third party platform. The realistic scenario for BonFIRE consortium will be 44% cheaper on a third party platform at a cost of €259,602.02, while the infrastructure as a service platform will cost €462,348.84. Overall, it is about 50% cheaper if BonFIRE is to provide its compute resource through a 3rd Party. Reversing to Figure 33, the BonFIRE’s compute resource is limited within the next three years given its pessimistic scenario; this will be operating at a high risk knowing that under the optimistic and pessimistic scenarios, BonFIRE’s current compute capacity will

Cost (Thousands)

not be sufficient to serve the forecasted demand. €800 €700

€693.52

€600 €462.35

€500

€389.40

€400 €300

IaaS Optimistic IaaS Realistic

€259.60

€231.17

€200

€129.80

IaaS Pessimistic 3rdParty Optimistic

€100

3rdParty Realistic

IaaS

Pessimistic

Realistic

Optimistic

Pessimistic

Realistic

Optimistic

€0

3rdParty Pessimistic

3rdParty

Figure 35: First year compute resource cost Likewise, haven estimated the financial performance for BonFIRE’s storage infrastructure demand capaity (Figure 30, Figure 32 and Figure 34), it was discovered that, it is less costly if BonFIRE’s storage resources are operated within BonFIRE’s Infrastructure as a Service model as shown in Figure 36. For BonFIRE, it was estimated that if BonFIRE’s storage infrastructure is operated using the Infrastructure as a Service model, it will be 85% cheaper compared to a 3rd party service model. Under the BonFIRE’s optimistic scenario operation, it was estimated that it will cost BonFIRE, €1,156,330.60 given the storage infrastructure was provided on a 3rd party’s platform. Given its realistic assumption, it will cost the

BonFIRE €114,656.19 if BonFIRE is to provide the infrastructure, while given the

Cost (Thousands)

third party platform, it will cost €770,887.07. €1,400 €1,156.33

€1,200 €1,000

€770.89

€800

IaaS Optimistic

€600

IaaS Realistic

€400 €200

IaaS Pessimistic €171.98

€114.66

€154.18 €22.93

3rdParty Realistic

IaaS

Pessimistic

Realistic

Optimistic

Pessimistic

Realistic

€0 Optimistic

3rdParty Optimistic

3rdParty Pessimistic

3rdParty

Figure 36: First year storage resource cost Referring to the two resources as a whole, given that BonFIRE provides it infrastructures (compute and storage infrastructure) under an Infrastructure as a Service model, it will cost BonFIRE largely cheaper at about 56%, than if the two resources were to be provided as a 3rd party service model. Given the different perspectives from the demand capacity (Figure 33 and Figure 34) and the financial performance (Figure 35 to Figure 37), as previously commented, for BonFIRE’, it would be economically stringent for its compute infrastructure to be provided under an Infrastructure as a Service platform. Knowing that its compute infrastructure service provision in the nearest years is highly limited compared to its excess ownership of its storage resources operation. On the other side, it costs BonFIRE more to provide its compute resources given an Infrastructure as a Service platform than a 3rd party service platform. The storage resources cost estimate is about 85% cheaper for BonFIRE given that, BonFIRE offers its storage capacity based on an Infrastructure as a Service platform.

69

Cost (Thousands)

€1,800 €1,545.73

€1,600 €1,400 €1,200 €1,000

€1,030.49 €865.51

€800

IaaS Optimistic IaaS Realistic

€577.01

€600 €400

€283.98

€254.11

IaaS Pessimistic 3rdParty Optimistic

€200

3rdParty Realistic

IaaS

Pessimistic

Realistic

Optimistic

Pessimistic

Realistic

Optimistic

€0

3rdParty Pessimistic

3rdParty

Figure 37: BonFIRE first year total cost Haven realised the comparative advantage for BonFIRE to own the operation of its storage facility at cheaper rate than it is to operate its compute facility; we revisited the modelled BonFIRE sustainability map in Figure 6, we observed both of the conditions why may require to outsource production has been encountered. Considering that BonFIRE will be at advantage of reduction marginal cost of infrastructure production given a 3rd party takes up the compute resource production, and that there is possibility of running out of compute capacity, we considered outsourcing the compute infrastructure capacity to the 3rd party. Making the first assumption of BonFIRE outsourcing 50% of its compute infrastructure’s demand to a 3rd party (as shown in Figure 38 to Figure 40), in total, it costs BonFIRE €541,463.15 to operate its cloud facility using the compute and storage resources in BonFIRE’s first year, given an optimistic scenario. Of the 50% provided by BonFIRE (as stated that the remaining 50% for demand of compute infrastructure is outsourced), it costs BonFIRE €346,761.63 to provide the compute infrastructure service and the remaining 50% is provided by the third party, costing a lower at €194,701.52 given an optimistic scenario. Given the realistic scenario, assuming a 50% outsourcing of the compute resource, in total it costs €350,975.43 compared to the optimistic scenario’s €541,463.15 and pessimistic scenario’s €180,487.72. The fifty per cent compute resources offered through the BonFIRE infrastructure costs BonFIRE to provide for its €231,174.42, while the 50% provided by the third party

cost €129,801.01. Given that BonFIRE outsourcing 50% of its compute capacity to the third party in total may not be sufficient haven that the compute resource maximum utilization for a realistic scenario will be attained towards the third year of BonFIRE’s operation while the Optimistic scenario’s optimum utilization will be

Cost (Thousands)

attained towards the first year of BonFIRE’s operation, given a 50% outsourcing. €1,200 €1,000 €403.73 €800

€336.44 €280.37

€600 €400 €200

3rd

€233.64

BonFIRE

€194.70

€346.76

€416.11

€499.34

€599.20

€719.04

€0 1

2

3

4

5

Figure 38: Optimistic cost for compute resource production given 50% outsourcing level

71

Cost (Thousands)

€800 €700 €269.16

€600 €224.30

€500 €186.91

€400 €300

€155.76

BonFIRE

€129.80

€200 €100

3rd

€231.17

€277.41

€332.89

€399.47

€479.36

€0 1

2

3

4

5

Figure 39: Realistic cost for compute resource production given 50%

Cost (Thousands)

outsourcing level €400 €350 €134.58

€300 €112.15

€250 €93.46

€200 €150

€77.88

BonFIRE

€64.90

€100 €50

3rd

€115.59

€138.70

€166.45

€199.73

€239.68

€0 1

2

3

4

5

Figure 40: Pessimistic cost for compute resource production given 50% outsourcing level

Core hour (Millions)

10 9 8 7 6

Optimistic

5

Realistic

4

Pessimistic Capacity

3 2 1 0 1

2

3

4

5

Figure 41: Five years compute usage at 50% outsourcing level

We investigated further into assuming 70% outsourcing of the BonFIRE compute infrastructure’s demand. Outsourcing 70% of compute infrastructure demand to the third party under a realistic scenario cost €181,721.41 while the remaining 30% offered by BonFIRE cost €138,704.65 in total, comparing the 50% and the 70% (€320,426.07) outsource scenario of the cloud compute facility for the first year, it cost BonFIRE consortium less if 70% of the cloud compute facility is outsourced to a third party than if 50% (€360,975.43) of its cloud compute facility is outsourced to cloud service provider. At the same time,

73

Cost (Thousands)

€1,200 €1,000 €800 €565.23 €600

3rd

€471.02

BonFIRE

€392.52 €400

€272.58

€327.10

€200 €208.06

€249.67

€299.60

€359.52

1

2

3

4

€431.43

€0 5

Cost (Thousands)

Figure 42: Optimistic cost for compute resource production given 50% outsourcing level €700 €600 €500

€376.82

€400

€314.01

€300 €200 €100

3rd

€261.68

BonFIRE

€218.07 €181.72

€138.70

€166.45

€199.73

1

2

3

€239.68

€287.62

€0 4

5

Figure 43: Realistic cost for compute resource production given 70% outsourcing level

Cost (Thousands)

€350 €300 €250

€188.41

€200

€157.01

3rd

€130.84

€150

BonFIRE

€109.03 €90.86

€100 €50

€69.35

€83.22

€99.87

1

2

3

€143.81

€119.84

€0 4

5

Core hour (Millions)

Figure 44: Pessimistic cost for compute resource production given 70% outsourcing level 6 5 4 Optimistic Realistic

3

Pessimistic Capacity

2 1 0 1

2

3

4

5

Figure 45: Five years compute usage at 70% outsourcing level However, BonFIRE attains its realistic maximum in the third year, given a realistic assumption, and 65% utilization level in the first year 78% utilization level in the second year and 94% utilization level in the beginning of the third year. If BonFIRE was to outsource 70% of its compute resource usage, given a realistic scenario, 39.07% of the compute capacity will be achieved maximally for the first year, and 37% in the second year and 56% in the third year.

75

In conclusion, the result suggested that as long as it cost the BonFIRE consortium comparatively more to offer the cloud compute facility than it is to offer the storage compute facility in the infrastructure as a service platform against the third party service platform. It will be both financially and operationally efficient to outsource as more cloud computing service to the third party at about 70% level of outsourcing of the compute resource especially. Also since the BonFIRE consortium has more storage capacity than it can offer within the next 10 years as estimated, possible approaches from the technical and from the business decision makers should be taken to ensure more usage of the resource capacity.

4.2.

Accuracy analysis

Three accuracies tests were conducted; there aim were to know if the generated 52 weeks compute and storage resource usage data simulated were generated from a normal distribution. Also a sample of 19 weeks data was taken from the first 19 weeks data generated out of the 52 weeks generated data, this was to test if the originally recorded 19 weeks data and the first 19 weeks data of the 52 weeks generated data for each resources usage were generated from the same statistical distribution. 4.2.1. Monte-Carlo:

Kolmogorov-Smirnov

and

Shapiro-Wilk

test

for

normality 4.2.1.1.

Comparison test for the distribution of the actual and generated 19 weeks usage data

Compute resource hypothesis: H0 – Actual and generated 19 weeks compute usage data are normally distributed H1 – Actual and generated 19 weeks compute usage data are not normally distributed

Storage resource hypothesis: H0 – Actual and generated 19 weeks storage usage data are normally distributed H1 – Actual and generated 19 weeks storage usage data are not normally distributed.

Actual

Generated

Actual storage

Generated storage

compute

compute usage

usage (gigabyte

usage (gigabyte

Usage

(core hours)

hours)

hours)

(core hours) Static

29356.94

5148302.69

162411.01

2226683.04

3408.17

74905.63

16959.95

108303.37

22196.65

4990931.81

126779.48

1999146.10

36517.24

5305673.57

198042.54

2454219.99

Median

29155.07

5146849.21

160942.05

2191354.87

Std. Dev

14855.86

326506.05

73926.70

472083.46

Min

5449.80

4614668.07

21357.48

1014633.03

Max

50413.57

5644631.61

295929.53

2940132.43

Skweness

-0.19

-0.15

-0.16

-0.68

Kurtosis

-1.33

-1.22

0.03

1.06

Std. Error Lower Bound Upper Bound

Table 8: Comparison of historical and generated distribution

Actual

Generated

Actual

Generated

Compute

Compute Usage

Storage

Storage Usage

Usage

Usage

KolmogorovSmirnov Statistic

0.156

0.097

0.185

0.138

df.

19

19

19

19

Sig

.2

.2

.085

.2

77

Shapiro-Wilk Statistic df Sig

0.932

0.95

0.93

0.941

19

19

19

19

0.188

0.388

0.17

0.28

Table 9: Historical and generated data test of normality Testing the actual usage data against the first 19 weeks sample of the generated data, for there test of normality, and to conclude whether they were derived from the same distribution, we conducted a Shapiro-Wilk normality test as it is more appropriate for low data set (usually less than 50). From the descriptive statistic, the Skewness and the Kurtosis of the actual and generated compute usage data are significantly equal to zero; this partly fulfils compute resource normality conformity. Observing the result for the Shapiro-Wilk test, at 5% significant level, the significant value for the actual and generated compute resource usage data is significantly larger than 0.05, since 0.188

and 0.388 greater than 0.05. Therefore, we can

conclude that the actual and the generated 19 weeks usage data are derived from a normal distribution and therefore, accept the null hypothesis H0. As can be seen from the Q-Q plot and histogram of the actual compute usage and the generated compute usage, there is degree of normality in their pictorial fitting to the standard normal distribution. Also, by observing the histogram of the generated compute usage data , it is observed to be more positive skewed can be observed against that of the actual compute usage. For the storage resource usage, the Skewness test for the actual and generated usage data is significantly greater than zero and both the Shapiro-WIlk significant test and the Kolmogorov-Smirnov test are significantly larger than 0.05. Whereas, the Kurtosis test for the generated storage usage data is significantly larger than zero (1.06). This makes for conclusion that the generated storage resource data is not generated from a normally distributed data as the actual storage data. And therefore, H1 hypothesis is accepted for the storage resource usage hypothesis.

4.2.1.2.

Normality test for the generated 52 weeks usage data

H0 – Generated usage data is normally distributed H1 – Generated usage data is not normally distributed

Compute (core hours) Storage (gigabyte hours) Static

5166811.26

2052620.85

44131.10

54894.38

Lower Bound

5078214.37

1942415.78

Upper Bound

5255408.15

2162825.92

Median

5153178.08

2001940.01

Std. Dev

318233.92

395849.02

Min

4614668.07

1014633.03

Max

6042603.58

2940132.43

0.27

0.11

-0.16

0.08

Std. Error

Skweness Kurtosis

Table 10: Descriptive statistics for generated usage

Compute Usage Storage Usage Kolmogorov-Smirnov Statistic

0.08

0.98

df.

52

52

Sig

0.2

0.2

0.98

0.98

52

52

0.60

0.68

Shapiro-Wilk Statistic df Sig

Table 11: Normality test for generated usage

From the descriptive statistics test, the Skewness and the Kurtosis test for the compute resource is 0.27 and -0.16, theoretically, this is approximately equals to zero, and therefore partially fulfils one of the requirements to conclude that the 52 79

weeks generated compute usage data is normally distributed. The same conclusion was made for the storage usage parameter where it Skweness and Kurtosis tests are 0.11 and 0.08. The Kolmogorov-Smirnov normality test at a 5% confidence interval resulted that the significant value for both the Compute and Storage usage resources are 0.2. Theoretically, the Shapiro-Wilk is used for data set < 50; likewise, it is appropriate for data set larger, using the Shapiro-Wilk to determine the normality of the compute and storage usage distribution, the significant value of the test is 0.60 and 0.68 for the compute resource usage and the storage resource usage data, since this is larger than the theoretical limit of 0.05 at 95% critical level, we can conclude that the generated 52 weeks usage data for both the compute and the storage resource usage are normally distributed.

4.2.2. Anderson Darling Test The Anderson-Darling test for normality measures the variance between the hypothesised distribution (generated compute and storage usage data), and the empirical distribution. It is an extension of the Kolmogorov-Simonov test. An advantage of the Anderson-Darling test is that it calculates and makes use of the critical values for individual distributions, thus there is dependency between the critical value and the individual distributions.

H0 – the sample data is generated from a normal distribution H1 – the sample data is not generated from a normal distribution

Anderson Darling Hypothesis P value Test statistics Critical vaue Compute H0

0.8818

0.1996

0.7404

Storage

0.5667

0.3107

0.7404

H0

Table 10: Anderson-Darling normality test Conducting the Anderson Darling test for the generated 52 weeks usage data to test if the data is generated from a normal distribution, with a probability value higher

than 0.05, both the compute and storage resource are accepted to be generated from a normal distribution. With the Anderson-Darling test statistics greater for the Compute usage lower than the critical value (0.1996 < 0.7404), we can conclude at accepting the null hypothesis at a 5% confidence interval. Similar conclusion was made for the storage resources, since the p value at 5% confidence interval is high at 0.5667 and the Anderson-Darling test statistics is lower than the 95% critical value (0.3107 < 0.7404). Comparing the probability value for the compute resource usage against the storage resource usage, the probability that the compute resource is normally distributed is higher than the storage resource usage, this support both the high variance in the storage resource usage (Figure 9.) and the KolmogorovSimonov test observation.

81

5. Research Limitation and Future Work

The application of these research findings into the BonFIRE’s operation is limited through the statistical methods, programing techniques and the results compliments with how it can be applied into a cloud computing business like the BonFIRE. Firstly, advancing our SQL and Python programmed LoadGenerator Monte Carlo to enable for series of iterations was not possible due to the time this would take considering the limited time available. The implication of this is that the probability that an experiment will occur could not be determined. Secondly, using the Copula technique, the details of the experiments types (HPC, Media, Multicloud and Network) could not be analysed. This limitation was however mitigated through the experiments types insights provided by LoadGenerator’s Monte Carlo technique. Nevertheless, the implication of this is that the financial performance; expected cost to be allocated to each experiment types; could not be ascertained. Thirdly, the conclusion made about outsourcing a certain level of the compute resources explicit of the storage resources is technically infeasible for a cloud computing market such as BonFIRE. Outsourcing in the cloud computing market is collectively done and not explicitly done for the resources. This was not considered in the research project. More accurate models and findings can be obtained with more iteration possibilities using the Monte Carlo method, better still, the availability of large real life representative data (beyond the 19 weeks data used) would enhance the resources usage predictions. Also, to achieve optimality in the sensitivity measurement for the resources outsourcing decision, since there is limitation to outsource the compute infrastructure explicitly of the other cloud computing infrastructures, including mathematical programming optimality techniques such as goal programming technique would improve the feasibility of a more applicable research conclusion.

As part of the future work interest would be to analysis the variability differences in the percentage of the BonFIRE cost allocated to each of the resources. Finally, the inclusion of the network resource parameter into the cost and usage model would immensely advance this research work. As stated in 4.1.1, the network resource parameter and power parameter are highly significant in the cost model and usage model.

83

6. Conclusion

In this study, future business scenarios for the BonFIRE facility were investigated. By extracting information within the BonFIRE facility’s 19 weeks usage data through descriptive statistics, the usage sizes of the BonFIRE cloud resources were defined into small, medium and large sizes. These was further used to define the four different types of experiments; High Performance Compute (HPC) type experiment, Media type experiment, Network type experiment and the Multicloud type experiment. With the LoadGenerator, the normal distribution parameters (mean and standard deviation) of the experiment sizes were defined (with inference of the normal distribution parameters from the 19 weeks usage data)

to introduce normal

distribution models into the LoadGenerator. Using the Copula probability theory, the correlation between the Monte Carlo LoadGenerated resources usage was established Haven the usage data generated for the first year, 20% compound annual growth rate was assumed for the future years, financial performance for the cost of providing the cloud service given an Infrastructure as a Service platform and a third party platform were investigated. Among the findings made in this study was that, BonFIRE could gain some levels of comparative cost advantage if the compute resources was provided on a third party service platform, while the storage resource remains as Infrastructure as a Service. Further findings indicated that power and network cost are among the highly significant cost model and usage model parameters that were not presently included in the BonFIRE working models. The most important factors in achieving a reliable planning, analysis and prediction is the availability and accuracy of input data used in the modelling, if an accurate data of the BonFIRE usage, over a long period of time is available, with a realistic cost data over the usage data period, a definitive pricing data in the 3rd party and Infrastructure as a Service platform for the resources used, more reliable analysis would be achieved.

References Accenture, 2011. A new era of innovation: Cloud and the future of business, s.l.: s.n. Armbrust, M. et al., 2009. Above the Clouds: A Berkeley View of Cloud Computing, Berkeley: UC Berkeley Reliable Adaptive Distributed Systems Laboratory. Arutyunov, V. V., 2012. Cloud Computing: Its History of Development, Modern State, and Future Considerations. Scientific and Technical Information Processing, pp. 173-178. Avianca, 2012. AWS. [Online] Available at: http://aws.amazon.com/solutions/case-studies/avianca/ [Accessed 25 September 2013]. AWS, 2012. Amazon Web Service. [Online] Available at: http://aws.amazon.com/solutions/case-studies/nasa-jpl-curiosity/ [Accessed 11 September 2013]. AWS, 2013. Amazon Web Services. [Online] Available at: http://aws.amazon.com/about-aws/ [Accessed 11 September 2012]. AWS, 2013. AWS Edge Locations. [Online] Available at: http://aws.amazon.com/about-aws/globalinfrastructure/regional-productservices/ [Accessed 19 September 2013]. Barker, C., 2008. ZD Net. [Online] Available at: http://www.zdnet.com/news/hp-dismisses-cloud-hype/255222 [Accessed 2 September 2013]. Bart Van Looy, P. G. R. V. D., 2003. Services Managment. 2nd ed. Harlow: Financial Times, Pretice Hall. Bertoldi, P. & Atanasiu, B., 2009. Electricity Consumption and Efficiency Trends in European Union, Ispra: European Commission. BonFIRE Consortium, 2013. BonFIRE. [Online] Available at: www.bonfire-project.eu/about [Accessed 29 August 2013]. Boniface, M., Inglesant, P. & Papay, J., 2013. Counting the Cost of FIRE. The Future Internet, May, Volume LNCS 7858, pp. 296-309. Brendstrup, B. & Paarsch, H. J., 2007. Semiparametric identification and estimation in multiobject, English auctions. Journal of Econometrics, pp. 84-108. Breymann, W., Dias, A. & Embrechts, P., 2003. Dependence structures for multivariate highfrequency data in finance. Quantitative Finance, Volume 3, pp. 1-14.

85

Business Insider, 2013. The 10 most important companies in cloud computing, s.l.: Business Insider. Buyya, R., 1999. High Performance Cluster Computing: Architectures and Systems. Upper Saddle River, New Jersey: Prentice Hall . Buyya, R., Ranjan, R. & Calheiros, R. N., 2010. InterCloud: Utility-oriented federation of cloud computing environments for scaling of application services. Algorithms and Architectures for Parallel Processing, Volume 6081, pp. 13-31. Buyya, R. et al., 2009. Cloud computing and emerging IT platforms: Vision, hype, and reality for delivering computing as the 5th utility. Future Generation Computer Systems, pp. 599616. Caron, E., Desperez, F. & Muresan, A., 2010. Forecasting for grid and cloud computing ondemand resources based on pattern matching. Cloud Computing Technology and Science (CloudCom), pp. 456-463. Caron, E., Desprez, F. & Muresan, A., 2010. Forecasting for grid and cloud computing ondemand resources based on pattern matching. IEEE International Conference on Cloud Computing Technology and Science, Volume 2nd, pp. 456 - 463. Christof, W., Benjamin, B. & Jochen, S., 2009. Cloud Computing - A Classification, Business Models, and Research Directions. Business and Information Systems Engineering, Volume 5, pp. 391-399. Clamp, P. & Cartlidge, J., 2013. Pricing the Cloud: An Adaptive Brokerage for Cloud Computing, Bristol: Department of Computer Science, Univeristy of Bristol. Clamp, P. J., 2013. Pricing the cloud: An investigation into finnacial , Bristol: University of Bristol. Clayton, D., 1978. A model for association in bivariate life tables and its application in epidemiological studies of familial tendency in chronic disease incidence. Biomeirika: Oxford Journals, pp. 141-151. Cox, D. R., 1972. Regression Models and Life-Tables. Journal of the Royal Statistical Society. Series B (Methodological), 34(2), pp. 187-220. David Mitchell Smith, 2011. Hype Cycle for Cloud Computing, 2011, s.l.: Gartner. Deloitte, 2009. Cloud computing: Market overview and perspective, Belgium: Deloitte Consulting. Demarta, S. & McNeil, A. J., 2005. The t Copula and Related Copulas. International Statistical Review, 73(1), p. 111–129. Dillon, T., Wu, C. & Chang, E., 2010. Cloud Computing: Issues and Challenges. IEEE International Conference on Advanced Information Networking and Applications, pp. 27-33. Dudin, E. B. & Smetanin, Y. G., 2011. A Review of Cloud Computing. Scientific and Technical Information Processing, Vol. 38(No. 4), p. 280–284.

European Commission, 2012. Unleashing the Potential of Cloud Computing in Europe., Brussels: COM. Gabriel, B. & Rene, C., 2003. An Overview of Pricing Models for Revenue Management. Manufacturing and Service Operations Management, 5(3), pp. 203-229. Garfinkel, S., 2011. MIT Technonolgy Review. [Online] Available at: http://www.technologyreview.com/news/425623/the-cloud-imperative/ [Accessed 2 September 2013]. Gartner, 2012. Gartner Newsroom. [Online] Available at: www.gartner.com/newsroom/id/2074815 [Accessed 3 September 2013]. Google, 2012. Google. [Online] Available at: http://googleblog.blogspot.co.uk/2012/04/introducing-google-drive-yesreally.html [Accessed 11 September 2013]. Grebnev, E., 2011. Clouds: from old technology to the broad prospects. [Online] Available at: http://www.cnews.ru/reviews/index.shtml?2011/05/20/440918_2 [Accessed 2 September 2013]. Huberman, B. & Hogg, T., 1995. Distributed Computation as an Economic System. Journal of Economic Perpectives, pp. 141-152. Hwang, K., 2008. Massively Distributed Systems: From Grids and P2P to Clouds, Los Angeles: University of Southern California. Ian, F., Yong, Z., Raicu, I. & Shiyong, L., 2008. Cloud Computing and Grid Computing 360Degree Compared. Grid Computing Environments Workshop, pp. 1 -10. IBM, 2012. SmartCloud. [Online] Available at: http://www.ibm.com/cloud-computing/us/en/what-is-iaas.html [Accessed 3 September 2013]. IBM, 2012. The power of the cloud, New York: IBM Global Services. IBM, 2013. IBM Cloud computing. [Online] Available at: http://www-03.ibm.com/press/us/en/presskit/29681.wss [Accessed 11th September 2012]. IBM, 2013. IBM News room. [Online] Available at: http://www-03.ibm.com/press/us/en/pressrelease/41430.wss [Accessed 2 September 2013]. IDC, 2012. Quantitative Estimates of the Demand for Cloud Computing in Europe and Likely Barriers to Take-up, s.l.: IDC. Kleinrock, L., 2005. A VISION FOR THE INTERNET. ST JOURNAL OF RESEARCH, 2(1), pp. 4-5.

87

Koch, F., Assuncao, M. & Netto, M., 2012. A Cost Analysis of Cloud Computing for Education. Economics of Grids, Clouds, Systems, and Services, 27-28 November, Volume 7714, pp. 182-196. Kretschmer, T., 2012. Information and Comunication Technologies and Productivity Growth. OECD Digital Economy Papers No. 195, p. 5. Kupferman, J., Silverman, J., Jara, P. & Browne, J., 2009. Scaling into the cloud. Lohr, S., 2007. The New York Times. [Online] Available at: http://www.nytimes.com/2007/10/08/technology/08cloud.html?_r=0 [Accessed 2 September 2013]. Lutxz, n.d. s.l.: s.n. Lutz, S. & Keith, J., 2012. Advances in Clouds- Research in Future Cloud Computing, Belgium: European Union. Makridakis, S., Wheelwright, S. & Hyndman, R., 1998. Forecasting: Methods and Applications. 3rd ed. New York: Wiley. Meijer, E., 2011. Wisdom of the cloud. [Online] Available at: http://www.tedxdelft.nl/tedxdelft2011/ [Accessed 2 September 2013]. Mell, P. & Grance, T., 2011. The NIST Definition of Cloud, Gaithersburg: Information Technology Laboratory, National Institute of Standards and Technology. Microsoft, 2010. The economics of the cloud, s.l.: Microsoft. Microsoft, 2013. Microsoft News Center. [Online] Available at: http://www.microsoft.com/en-us/news/Press/2013/Jun13/0624WSNewsPR.aspx [Accessed 2 September 2013]. Molnar, D. & Schehter, S., 2010. Self Hosting vs. Cloud Hosting: Accounting for the security impact of hosting in the cloud, s.l.: Microsoft Research. Oh, D. H. & Patton, A. J., 2013. Simulated Method of Moments Estimation for Copula- Based Multivariate Models. Journal of the American Statistical Association, 108(502), pp. 689-700. Optensity, 2013. AWS Case Study: Optensity. [Online] Available at: http://aws.amazon.com/solutions/case-studies/optensity/ [Accessed 25 September 2013]. Pham, T., 2013. OnLINE TECH. [Online] Available at: http://resource.onlinetech.com/cloud-infrastructure-as-a-service-iaas-spendingto-exceed-72-billion-by-2016/ [Accessed 16 September 2013]. Popa, L., Ratnasamy, S., Ianna, G. & Krishnamurthy, A., 2010. A Cost Comparison of Datacenter Network Architectures. Philadelphia, CoNEXT.

Project Brief, 2013. MSc Student Summer Placements. s.l.:University of Southampton. PwC, 2013. Digital IQ: 2013 Top technology trends for business, New York: PwC US. Rogers, O. & Cliff, D., 2011. The effects of market demand on truthfulness in a computing resource options market. Rogers, O. & Cliff, D., 2012. A financial brokerage model for cloud computing. Journal of Cloud Computing: Advances, Systems and Applications, 1(2). Rogers, O. & Cliff, D., 2012. Forcasting demand for cloud computing resources. [Online] Available at: http://lscits.cs.bris.ac.uk/docs/ICAART%20FINAL.pdf [Accessed 04 September 2013]. Rogers, O. & Cliff, D., 2013. Contributory provision point contracts-a risk-free mechanism for hedging cloud enegry costs. Journal of Cloud Computing: Advances, Systems and Applications, 2(10). Rosehead, J. & Mingers, J., 2001. Rational Analysis for a Problematic World Revisted: Problem Structuring Methods for Complexity, Uncertained and Conflict.. Chichester: Wiley. Sandholm, T. & Lai, k., 2008. A Statistical Approach to Risk Mitigation in Computational, Kista: KTH School of Information and Communication Technology. Schultz, D. P., 2013. Stores. [Online] Available at: http://www.stores.org/top-100-retailers [Accessed 24 September 2013]. Sklar, A., 1973. Random Variables, Joint Distribution Functions, and Copulas. Kybernetika, 9(6), pp. 449-460. Soderstrom, T. & Shams, K., 2012. Youtube. [Online] Available at: http://www.youtube.com/watch?v=GRVPGC1haTM [Accessed 11 September 2013]. Sullivan, D., 2006. Google Press Center. [Online] Available at: http://www.google.com/press/podium/ses2006.html [Accessed 2 Seprember 2013]. Susan, M. & Jess, A., 2003. Introdution to Probability theorty and Statistics. 3rd ed. s.l.:McGraw Hill. UCLA, 1969. The University of Califonia Computer Scinece Department. [Online] Available at: http://www.lk.cs.ucla.edu/data/files/Kleinrock/UCLA%20to%20be%20First%20Station%20in %20Nationwide%20Computer.pdf [Accessed 2 September 2013]. Wikipedia, 2013. Wikipedia. [Online] Available at: http://en.wikipedia.org/wiki/Monte_Carlo_method [Accessed 9 September 2013].

89

Wu, F., Zhang, L. & Huberman, B., 2008. Truth-Telling Reservations, s.l.: Algorithmica. Zhang, Q., Cheng, L. & Boutaba, R., 2010. Cloud computing: state-of-the-art and research challenges. The Brazilian Computer Society 2, pp. 7-18.

Appendices I.

WORKING SUSTAINABILITY PLAN

II.

MONTE CARLO’S ADDITIONAL RESULTS

III.

MONTE CARLO’S ACCURACY TESTS

IV.

COPULA PROBABILITY THEORY RESULT

V. VI. VII. VIII. IX.

COPULA’S ACCURACY TEST

ADDITIONAL RESULTS AND MISCELLANEOUS CORRELATION OF SITES INFRASTRUCTURES’ UTILIZATION SAMPLE OF PYTHON CODE USED FOR MONTE CARLO USAGE GENERATION ADDITIONAL SUPPORT TOOL INITIATED

91

I.

WORKING SUSTAINABILITY PLAN

Table I.1: Sustainability Impact Board recommendation Table I.2: BonFIRE cost model

Recommendation

Expected

Impact

on

Business

Model

Understanding Establish Open Access

Customer Relationship: Move the facility towards on-demand usage by transitioning from the project funding,

as

in

open

call

experimenters,

to

experiments funding themselves, a necessary step towards paying customers. Consider Open Access Customers:

Understanding

of

key

customer

as a business model segments and the needs of potential customers. investigation

Osterwalder and Pigneur suggest that customer segments is the first building block to put in place in the business model. Depending on the definition of customer segments, it may be necessary to revise value propositions.

Establish Open Access Value Usage Agreement

Proposition:

An

agreement

between

BonFIRE sites to offer capacity to customers outside of the consortium is one step to a broader partnership agreement.

Establish Open Source Key Resources: Resolve the IPR issues in the Licensing Policy

software required to operate open access resolves IPR issues prior to the end of the project

Implement

cost- Cost

Structure

&

Revenue

Streams:

accounting and pricing Understanding of how to operate a facility under models

using realistic circumstances including the relationship

quantitative data

between demand, capacity, and other KPIs, using quantitative data. Establish operational link between A2 accounting software, A3 usage reports and impact on facility performance targets in A6

Add commercial could Key Partners: Understanding of how, and to what provider

extent, 3rd party cloud providers can offer BonFIRE capability and capacity. Table I.1: Sustainability Impact Board recommendation

93

Parameter

Assumption

Source

Initial (capital) costs Disk storage Based

on

infrastructure http://www.bonfire-

Capacity

chart

project.eu/infrastructure/testbeds

Storage

Assumed

Hardware

storage solutions from Dell p/

Costs

rather than cheap (e.g. storage-products.aspx

middle

range http://www.dell.com/uk/business/

http://www.backblaze.com/ ) or enterprise grade – could vary by a factor of 10 Compute

Based

on

infrastructure http://www.bonfire-

Capacity

chart

Compute

From

Hardware

server types, from recent 6/

Costs

purchases

project.eu/infrastructure/testbeds current

partners

costs

by or

of http://ark.intel.com/products/3444

project Intel-Xeon-Processor-X5450-

web

sites 12M-Cache-3_00-GHz-1333-

where this is not available

MHz-FSB and similar web pages (however, this is only a processor cost – indicative, but not the same as a server cost)

Cost

of Assumed

network Amazon TCO spreadsheet

network

hardware costs 20% of

hardware

server (compute + storage) costs

Marginal (overhead) costs Power Storage

Assumed 300-600W per http://www.dell.com/uk/business/

Power

storage node, based on p/

Compute Power

Dell power ratings

storage-products.aspx

Assumed 100W per core

Based

on

a

recent

paper;

probably over-estimate – see http://blogs.amd.com/work/2011/

Parameter

Assumption

Source 11/17/watts-per-core/

Power Usage Assumed Effectiveness

an

efficiency http://www.datacenterknowledge.c

rating of 1.8

om /archives/2011/05/10/uptimeinstitute-the-average-pue-is-1-8/

Cost per KWh The

cost

of

electricity, www.energy.eu

assumed industrial use for each country Hardware maintenance Default cost

% Assumed

hardware Amazon TCO spreadsheet

for maintenance costs 10% of

hardware

initial capital (compute +

maintenance

storage + network) costs per year

Network volume costs Network

Sites are on 1 Gbps links, Estimate

Capacity

but

there

are

no

guarantees on achievable bandwidth. assumed

We a

have

500Mbps

symmetrical leased line for each site. Network

Assumed £1000 (€1241) Estimate by system administrator

volume cost

per Gbps per month for a at IT Innovation systems leased line We assume 500Mbps (ie, 0.5 Gbps, at 0.5 of the cost) throughput uniformly for each site

Staff costs Systems admin rate

Average UK salary

http://www.cwjobs.co.uk/salarychecker/average-system95

Parameter

Assumption

Source administrator-salary

Servers

per Number

admin

of

systems

servers admin

a Amazon TCO can

support 50 servers/sysadmin FTE, including storage nodes Software

Average UK salary

http://www.cwjobs.co.uk/salary-

developer

checker/

rate

average-software-engineersalary

Number

of Assumed linear distribution Estimate

developers

of FTEs across sites for

FTE

BonFIRE developments

related with

a

minimum of 0.5 giving 3 FTEs in total Support rate

Average UK salary

http://www.cwjobs.co.uk/salarychecker/ average-software-support-salary

Number

of Assumed linear distribution Estimate

users

of users across sites, 10

expected

per site, 60 in total per year

Number

of Assumed that each person Estimate

users

can support 20 users

supported

Assigned linearly across

per

support each site

staff

Allocation of overhead costs to compute, storage, and networking % of marginal The percentage of costs Estimate cost

to excluding capital allocated

Parameter

Assumption

compute

to compute usage

Source

60% % of marginal The percentage of costs Estimate cost

to excluding capital allocated

storage

to storage usage 20%

% of marginal The percentage of costs Estimate cost

to excluding capital allocated

networking

to network usage 20%, but since we ignore network

costs,

this

is

allocated to Compute for the current calculation Compute and storage hours Site Core Hr Total number of core hours http://www.bonfireCapacity

calculated from the cores project.eu/infrastructure/testbeds per server defined in the infrastructure chart

Site

Storage Total number of storage http://www.bonfire-

Hr Capacity

hours calculated from the project.eu/infrastructure/testbeds cores per server defined in the infrastructure chart

Table I.2: BonFIRE cost model and assumptions

97

II.

MONTE CARLO’S ADDITIONAL RESULT

Table II.1: Descriptive statistics of the historical resources usage

Descriptive Statistics N

Minimum

Maximum Mean

Std. Deviation

core hour Small

7945 0

2102.717

23.80769 125.7614

Medium

36

2110.67

10000.97

5220.101 2322.148

Large

8

10001.63 55651

24648.22 16694.53

gigabyte hour Small

7964 0

28895.81

96.72495 869.8831

Medium

18

29112.45 60489.92

41865.91 11385.61

Large

7

71651.8

122995.5 38510.87

169234.5

Table II.1: Descriptive statistics of the historical resources usage

III.

MONTE CARLO’S ACCURACY TESTS

Figure III.1: Histogram of actual compute usage Figure III.2: Q-Q Plot of actual compute usage Figure III.3: Histogram of generated compute usage Figure III.4: Q-Q Plot of generated compute usage Figure III.5: Histogram of actual storage usage Figure III.6: Q-Q Plot of actual storage usage Figure III.7: Histogram of generated storage usage Figure III.8: Q-Q Plot of generated storage usage Figure III.9: Histogram of 52 weeks compute usage Figure III.10: Q-Q Plot of 52 weeks compute usage Figure III.11: Histogram of 52 weeks storage usage Figure III.12: Q-Q Plot of 52 weeks storage usage

Figure

III.1:

Histogram

compute usage

of

actual Figure

III.2:

Q-Q

Plot

of

actual

compute usage 99

Figure III.3: Histogram of generated Figure III.4: Q-Q Plot of generated compute usage

Figure

III.5:

Histogram

compute usage

of

actual Figure III.6: Q-Q Plot of actual storage

storage usage

usage

Figure III.7: Histogram of generated Figure III.8: Q-Q Plot of generated storage usage

storage usage

Figure III.9: Histogram of 52 weeks Figure III.10: Q-Q Plot of 52 weeks compute usage

compute usage

101

Figure III.11: Histogram of 52 weeks Figure III.12: Q-Q Plot of 52 weeks storage usage

storage usage

IV.

COPULA’S PROBABILITY THEORY RESULT

Figure IV.1: Correlation of generated resources usage Figure IV.2: Transformation of generated resources usage into a Copula function Figure IV.3: Fitting a Gaussian copula into the Copula transformed data Figure IV.4: Rescaling fitted Gaussian copula into original data scale Figure IV.5: Fitting a Clayton copula into the Copula transformed data Figure IV.6: Rescaling fitted Clayton copula into original data scale Figure IV.7: Fitting a Frank copula into the Copula transformed data Figure IV.8: Rescaling fitted Frank copula into original data scale Figure IV.9: Fitting a Gumbel copula into the Copula transformed data Figure IV.10: Rescaling fitted Gumbel copula into original data scale

Figure IV.1: Correlation of generated resources usage

103

Figure IV.2: Transformation of generated resources usage into a Copula function

Figure IV.3: Fitting a Gaussian copula into the Copula transformed data

Figure IV.4: Rescaling fitted Gaussian copula into original data scale

Figure IV.5: Fitting a Clayton copula into the Copula transformed data

105

Figure IV.6: Rescaling fitted Clayton copula into original data scale

Figure IV.7: Fitting a Frank copula into the Copula transformed data

Figure IV.8: Rescaling fitted Frank copula into original data scale

Figure IV.9: Fitting a Gumbel copula into the Copula transformed data

107

Figure IV.10: Rescaling fitted Gumbel copula into original data scale

V.

COPULA’S ACCURACY TEST

Figure V.1: Compute resource Gaussian copula normality test Figure V.2: Storage resource Gaussian copula normality test Figure V.3: Compute resource Clayton copula normality test Figure V.4: Storage resource Clayton copula normality test Figure V.5: Compute resource Frank copula normality test Figure V.6: Storage resource Frank copula normality test Figure V.7: Compute resource Gumbel copula normality test Figure V.8: Storage resource Gumbel copula normality test

Figure

V.1:

Compute

resource Figure

Gaussian copula normality test

V.2:

Storage

resource

Gaussian copula normality test

109

Figure V.3:Compute resource Clayton Figure V.4: Storage resource Clayton copula normality test

copula normality test

Figure V.5: Compute resource Frank Figure V.6: Storage resource Frank copula normality test

copula normality test

Figure V.7: Compute resource Gumbel Figure V.8: Storage resource Gumbel copula normality test

copula normality test

111

VI.

ADDITIONAL RESULTS AND MISCELLANEOUS

Figure VI.1: Compute resource 19 weeks utilization Figure VI.2: Storage resource 19 weeks utilization Figure VI.3: Compute resource usage by HPC and Media Type Experiments Figure VI.4: EPCC’s real and simulated 19 weeks compute resource usage Figure VI.5: EPCC’s real and simulated 19 weeks storage resource usage Figure VI.6: BonFIRE data centres Figure VI.7: LoadGenerator's input processing Figure VI.8: Gartner 2013 hype cycle Figure VI.9: Distributed computing trend 2007 – 2013 70.00% 60.00% 50.00% 40.00% 30.00% 20.00% 10.00% 0.00% 1

2

3

4

5

6

7

8

9 10 11 12 13 14 15 16 17 18 19

Figure VI.1: Compute resource 19 weeks utilization

8.00% 7.00% 6.00% 5.00% 4.00% 3.00% 2.00% 1.00% 0.00% 1

2

3

4

5

6

7

8

9 10 11 12 13 14 15 16 17 18 19

Figure VI.2: Storage resource 19 weeks utilization

Figure VI.3: Compute resource usage by HPC and Media Type Experiments

113

Figure VI.4: EPCC’s real and simulated 19 weeks compute resource usage

Figure VI.5: EPCC’s real and simulated 19 weeks storage resource usage

Figure VI.6: BonFIRE data centres

115

Figure VI.7: LoadGenerator's input processing

Figure VI.8: Gartner 2013 hype cycle

Figure VI.9: Distributed computing trend 2007 – 2013

117

VII.

CORRELATION OF SITES INFRASTRUCTURES’ UTILIZATION

Figure VII.1: Correlation of USTUTT resource usage Figure VII.2: Correlation of PSNC resource usage Figure VII.3: Correlation of INRIA resource usage Figure VII.4: Correlation of HP resource usage Figure VII.5: Correlation of EPCC resource usage Figure VII.6 Correlation of iMinds resource usage

Figure VII.1: Correlation of USTUTT resource usage

Figure VII.2: Correlation of PSNC resource usage

Figure VII.3: Correlation of INRIA resource usage

119

Figure VII.4: Correlation of HP resource usage

Figure VII.5: Correlation of EPCC resource usage

Figure VII.6 Correlation of iMinds resource usage

121

VIII.

Sample of Python code used for Monte Carlo usage generation

# Generate a list of experiments with different resource usages def createExperimentList(fileName): parameters = {} parameters = readConfig(fileName) numberOfExperiments = int(parameters['numberOfExperiments']) # Compute distribution parameters computeSmall = float(parameters['computeSmall']) computeSmallSigma = float(parameters['computeSmallSigma']) computeMedium = float(parameters['computeMedium']) computeMediumSigma = float(parameters['computeMediumSigma']) computeLarge = float(parameters['computeLarge']) computeLargeSigma = float(parameters['computeLargeSigma']) # Storage distribution parameters storageSmall = float(parameters['computeSmall']) storageSmallSigma = float(parameters['storageSmallSigma']) storageMedium = float(parameters['storageMedium']) storageMediumSigma = float(parameters['storageMediumSigma']) storageLarge = float(parameters['storageLarge']) storageLargeSigma = float(parameters['storageLargeSigma']) # Nework distribution parameters networkSmall = float(parameters['networkSmall']) networkSmallSigma = float(parameters['networkSmallSigma']) networkMedium = float(parameters['networkMedium']) networkMediumSigma = float(parameters['networkMediumSigma']) networkLarge = float(parameters['networkLarge']) networkLargeSigma = float(parameters['networkLargeSigma']) experiment = [] experimentList = [] # select type of experiment at random from the interval (0,4) for i in range(0,numberOfExperiments): experimentID = "experiment_%d" %(i) experiment.append(experimentID) experimentType = random.randint(0,3) experiment.append(experimentType) # HPC type experiment (large, medium, small) if experimentType == 0: computeLoad = abs(random.gauss(computeLarge, computeLargeSigma)) storageLoad = abs(random.gauss(storageMedium, storageMediumSigma)) networkLoad = abs(random.gauss(networkSmall, networkSmallSigma)) experiment.append(computeLoad) experiment.append(storageLoad) experiment.append(networkLoad) # media type experiment (large, large, large) if experimentType == 1: computeLoad = abs(random.gauss(computeLarge, computeLargeSigma)) storageLoad = abs(random.gauss(storageLarge, storageLargeSigma)) networkLoad = abs(random.gauss(networkLarge, networkLargeSigma)) experiment.append(computeLoad) experiment.append(storageLoad) experiment.append(networkLoad) # network type experiment (small, small, large) if experimentType == 2: computeLoad = abs(random.gauss(computeSmall, computeSmallSigma)) storageLoad = abs(random.gauss(storageSmall, storageSmallSigma)) networkLoad = abs(random.gauss(networkLarge, networkLargeSigma)) experiment.append(computeLoad) experiment.append(storageLoad) experiment.append(networkLoad)

# multi-cloud type experiment (small, small, large) if experimentType == 3: computeLoad = abs(random.gauss(computeSmall, computeSmallSigma)) storageLoad = abs(random.gauss(storageSmall, storageSmallSigma)) networkLoad = abs(random.gauss(networkLarge, networkLargeSigma)) experiment.append(computeLoad) experiment.append(storageLoad) experiment.append(networkLoad)

123

IX.

Additional support tool initiated

Figure IX.1: Developed cost and utilization tool Figure IX.2: Tool graphing 19 weeks compute infrastructure’s utilization for two sites (EPCC and HP) Figure IX.3: Tool graphing 19 weeks storage infrastructure’s utilization of two sites (INRIA and USTUTT)

Figure IX.1: Developed cost and utilization tool

Figure IX.2: Tool graphing 19 weeks compute infrastructure’s utilization for two sites (EPCC and HP)

Figure IX.3: Tool graphing 19 weeks storage infrastructure’s utilization of two sites (INRIA and USTUTT)

125

i

The company’s background information was gotten from the firm’s website (https://bonfire-project.eu/) and student’s project brief.