Implementation of a Simulation Environment for Cloud Object Storage Infrastructures

Implementation of a Simulation Environment for Cloud Object Storage Infrastructures Bachelor Thesis of Tobias Sturm At the Department of Informatics Steinbuch Centre for Computing (SCC) Erstgutachter: Zweitgutachter: Betreuender Mitarbeiter: Prof. Dr. Achim Streit Prof. Dr. Bernhard Neumair Foued Jrad Bearbeitungszeit: 23.5.2013 22.8.2013 KIT University of the State of Baden-Wuerttemberg and National Research Center of the Helmholtz Association www.kit.edu

I declare that I have developed and written the enclosed thesis completely by myself, and have not used sources or means without declaration in the text. Karlsruhe, 22.8.2013......................................... (Tobias Sturm)

Zusammenfassung Cloud Computing ermöglicht es Unternehmen, ihren Bedarf an IT-Resourcen wie Rechenleistung oder Speicherkapazität durch Nutzung externer Dienste zu befriedigen. Große Investitionskosten entfallen, da Cloud-Dienste nach dem Pay-as-You-go-Prinzip abgerechnet werden. Für Benutzer aber auch Betreiber ist es wichtig, Abschätzungen machen zu können, welche Kosten anfallen werden, oder welche Hardwarekonstellation in der Cloud verwendet werden sollte. Fragen zu z.b. Multi-Cloud Nutzung oder welche Allocation-Policies verwendet werden sollen, spielen ebenso eine sehr große Rolle. Aus diesem Grund wurde CloudSim [3] entwickelt - ein eventbasiertes Simulationsframework mit dem IaaS Clouds (Infrastructure-as-a-Service) modelliert und deren Verwendung simuliert werden kann. Neben Kosten und Ressourcenauslastung stehen auch Metriken wie Energieverbrauch im Vordergrund. Diese beliebte Simulationsumgebung stellt jedoch keinerlei Mechanismen zur Verfügung, um heutige Object Storage basierte Cloud-Dienste (STaaS, Storage-Service-asa-Service) zu simulieren. In dieser Arbeit wurde CloudSim um eine STaaS-Komponente erweitert. Dabei wurden bekannte Cloud-Standards wie CDMI (Cloud Data Management Interface) als Vorbild für die User-Cloud-Schnittstellen verwendet. Cloud-interne Prozesse wie Speicherzugriffe und Netzwerkkommunikation innerhalb einer STaaS-Infrastrukur, sowie die Verwendung von Multi-Cloud wurden modelliert. Die Resourcennutzung und Kosten, die durch Nutzung der STaaS-Komponente auftreten, wurden anhand verschiedener Simulationszenarien evaluiert. v

Abstract Cloud computing empowers organizations to satisfy their need of IT resources like computing power and storage capacity by using external services. Since Cloud services are billed by the pay-as-you-go principle, organizations can save huge investment costs. Users want to know, what costs will arise by the usage of those services - Cloud providers want to provide the best-matching hardware configurations. Different allocation policies or multi- Cloud usage are two topics, that are in the focus of interest as well. Therefore, CloudSim [3], a popular event-based framework, was developed to model and simulate the usage of IaaS Clouds (Infrastructure-as-a-Service). Metrics as for instance costs, resource utilization and energy consumption can be also investigated using CloudSim. But this favored simulation framework does not provide any mechanisms to simulate today s object storage based Cloud-services (STaaS, Storage-as-a-Service). This work extends CloudSim with a STaaS-component. The well-known standard CDMI (Cloud Data Management Interface) was the model for the user Cloud interface. Cloud internal processes were modeled, like for example storage accesses and network communication inside the STaaS infrastructure, as well as the usage of multiple Clouds. Resource utilization and costs that arise by the usage of the STaaS component were evaluated on basis of multiple simulation scenarios. vi

Table of Contents Zusammenfassung Abstract v vi 1. Introduction 1 1.1. Motivation.................................... 1 1.2. Goal of this Thesis................................ 2 1.3. Structure of this Thesis............................. 2 2. Fundamentals 3 2.1. Cloud Computing................................. 3 2.2. Characteristics of a Cloud............................ 4 2.3. Cloud Deployment Models............................ 4 2.4. Cloud Service Models.............................. 4 2.5. Data Storage as a Service............................ 5 2.5.1. STaaS Storage Types.......................... 6 2.5.1.1. Structured Storage....................... 6 2.5.1.2. Block Storage......................... 6 2.5.1.3. Object Storage......................... 7 2.5.2. Example STaaS Provider - Amazon S3................. 7 2.5.3. Example STaaS Middleware - OpenStack Swift............ 8 2.5.4. Example STaaS API - CDMI...................... 8 2.6. CloudSim..................................... 10 3. Modeling of a STaaS 12 3.1. Architecture.................................... 12 3.1.1. User Code and User Interface Structures................ 12 3.1.2. Provided Storage Services........................ 13 3.1.3. Resources, Resource Usage and Network................ 13 3.2. Sequence Diagram................................ 14 4. Implementation 17 4.1. Development Envorinment............................ 17 4.2. STaaS Provider Models............................. 17 4.2.1. CDMI Implementation.......................... 19 4.2.1.1. CDMI Entity.......................... 19 4.2.1.2. CDMI Object......................... 19 4.2.1.3. CDMI Container........................ 19 4.2.1.4. CDMI Metadata and Cloud Characteristics......... 20 4.2.2. Internal Storage Models......................... 21 4.2.2.1. Blob and Bloblocators..................... 21 4.2.2.2. Servers and Hard Drives................... 21 vii

viii Table of Contents 4.2.3. Object Storage Cloud Model...................... 22 4.3. User Models.................................... 22 4.3.1. StorageBroker Class........................... 22 4.3.2. UsageSequence Class........................... 23 4.3.3. Service Level Agreements........................ 23 4.3.4. MetaStorageBroker Class........................ 24 4.3.5. Latency Models.............................. 25 4.3.6. Request Layers.............................. 25 4.3.7. CDMI Requests.............................. 26 4.3.7.1. Cloud Discovery Request................... 26 4.3.7.2. GET Container Request.................... 26 4.3.7.3. GET Object Request..................... 27 4.3.7.4. PUT Container Request.................... 28 4.3.7.5. PUT Object Request - creation............... 28 4.3.7.6. PUT Object Request - update................ 30 4.3.8. UserRequest and UserMetaRequest Class............... 30 4.4. Monitoring.................................... 31 4.4.1. TrackableResource Class......................... 31 4.4.2. EventTracker and ResourceUsageHistory Class............ 32 4.4.3. Accounting................................ 32 4.4.4. Report Generation............................ 32 4.5. Scenario Generation............................... 32 5. Evaluation 34 5.1. Simulation Setup................................. 34 5.2. Simulation Scenarios............................... 35 5.2.1. Single Cloud Scenario.......................... 35 5.2.2. Multi-Cloud Scenario.......................... 35 5.3. Simulation Results................................ 37 5.3.1. Used Storage and SLA fulfillments................... 37 5.3.2. Cost evaluation.............................. 40 5.3.3. Effect of the used Sequence Type.................... 41 6. Conclusion and future Work 42 Bibliography 43 Appendix 45 A. Additional figures................................. 45 B. Monitoring Outputs............................... 46 C. Input Files.................................... 50 viii

List of Figures 2.1. CDMI root container with multiple containers................. 9 2.2. CloudSim Overview............................... 10 3.1. Architecture Overview.............................. 13 3.2. Interaction Overview............................... 15 4.1. System Class Diagram.............................. 18 4.2. Relationship between Objects and Containers 1................ 20 4.3. CDMI Object, Blob and Blob Locators..................... 21 4.4. Server and Disk IO limitations......................... 22 4.5. Timeaware Resource Utilization......................... 25 4.6. Request Layers.................................. 26 4.7. Get Container State Diagram.......................... 27 4.8. Get Object State Diagram............................ 28 4.9. Put Container State Diagram.......................... 29 4.10. Put Object State Diagram (creation)...................... 29 5.1. Distribution of the Size of single Objects in all scientific Access Patterns.. 35 5.2. Distribution of the Size of single Objects in all normal Access Patterns... 36 5.3. Number of Request Types in all normal Access Patterns........... 36 5.4. Distribution of Traffic per Sequence (both Types)............... 37 5.5. Succeeded Requests and SLA Violations in single Cloud Experiment with 5000 Sequences.................................. 38 5.7. Used Storage in multi-cloud Experiment, with 5000 sequences....... 39 5.6. Used Storage in multi-cloud Experiment with 50 Sequences......... 39 5.8. Total Cost per Experiment........................... 40 5.9. Costs per Sequence Type with 250 Input sequences.............. 41 A.1. Average Response Time for mixed input Sequences.............. 45 A.2. Distribution of Request Types in scientific Sequences............. 45 B.3. Plot of Monitored Number of Requests in Cloud............... 48 B.4. Plot of Total physical used Storage Capacity in Cloud............ 48 ix

List of Tables 2.1. Comparison between Block Storage and Object Storage........... 7 2.2. Storage Prices for Amazon S3 standard Storage in the US.......... 8 2.3. Costs per Request for Amazon S3 in the US.................. 8 2.4. Traffic Cost for Amazon S3 in the US..................... 9 4.1. Implemented CDMI Metadata.......................... 20 5.1. Cloud Configurations compared......................... 37 5.2. Calculated StorageMetaBroker Score per Provider and Access Pattern.. 40 5.3. Average Price per accepted Sequence in Cents................. 41 5.4. Matrix of total Costs for 250 Input Sequences in Dollar........... 41 x

1. Introduction 1.1. Motivation Cloud computing is one of the most emerging technologies of the past few years. Start-ups, big companies and the scientific community explore the benefits of this kind of resource utilization. Cloud users and providers enjoy the advantages of less configuration overhead, less investments, less operation costs, highly flexible systems that scale out, up to large systems, or scale in to a minimal resource utilization, depending on the current needs. The main motivation is to reduce the cost for computation and storage by sourcing these services out to a third-party provider. The crucial questions are about the costs and the performance of the usage. Users want to know, how much money they are going to spend, if they switch to a Cloud solution. On the other side, providers have to know, what is the best hardware constellation and configuration for them. These questions can be answered by simulating Cloud environments. CloudSim is a popular simulation environment, which offers capabilities to simulate computing Clouds that provision computing infrastructures as a service. The focus of CloudSim is on the modeling of so-called Cloudlets which are jobs, that can be scheduled on VMs (Virtual Machines). Models for hard disks, SAN and files do already exist [3]. However, capable interfaces to simulate object STaaS are missing, as well as a fine-grained model for the size of files (see 2.6). There are also few research works that address the above mentioned functionalities. The only work with storage modeling in CloudSim was performed by Zhao and Long. They propose an extension of the existing Data Center model [11] by introducing a Replica Catalog 1 and Block Catalog 2 to benchmark different configurations. All operations are started from within a Cloudlet, which means that the VM is the requesting entity. By this, their work presents a mixture of data centers that offer computing power and storage capacities. This work in contrast focuses on the strict separation of those two capabilities, because the real-world infrastructure-as-a-service providers do the same. 1 One piece of information is stored multiple times on different physical locations. Locations are managed by the Catalog. 2 One piece of information is striped and distributed on different physical locations to gain a parallelized and therefore faster access. Catalogs can provides query interface to retrieve those locations. 1

2 1. Introduction 1.2. Goal of this Thesis Considering that there is no known simulation environment for object STaaS, which includes a proper modeling of the interfaces, this work extends the existing framework CloudSim by adding components for an accurate modeling of object storage. New models are introduced to model the behavior of hard disks, storage servers and storage data centers. Interactions between the user and the Cloud are based on the CDMI standard, which enables the users to model Cloud usage scenarios with a low effort. Concurrent accesses to one physical resource, caused by two or more requests will be modeled as well as network delays between different simulation entities. A so-called meta broker aims to provide a transparent access to multiple Clouds by scheduling sequences of requests to different Cloud providers, depending on the SLA 3 requirements for those sequences. The usage of one or multiple Clouds will be compared to each other in terms of billed costs, required storage space and SLA violations. 1.3. Structure of this Thesis The thesis is structured as followed: The fundamentals of Cloud computing and it s deployment models as well as service models are described in chapter two, followed by an introduction to different storage types and one example for each of an STaaS provider, middle ware and API. The architecture of the existing simulation framework CloudSim will also be described in chapter two, afterwards the software architecture of the extended CloudSim with the STaaS models, the focus of this work, is demonstrated in chapter three. After that, a more detailed description of the implementation follows in chapter four, which focuses on the subset of implemented CDMI elements and features, as well as the internal storage model (such as servers and hard drives). Following the user s models like broker, SLA and request sequences are explained. After a detailed explanation of the proposed latency model, the thesis addresses on the communication between different entities and describes possible user requests, that can be sent to a simulated STaaS. After that, some monitoring techniques are described, before the generation process for scenarios is explained. In chapter five the developed STaaS simulator is evaluated and the results are depicted and discussed, where a single-cloud environment is compared to a multi-cloud environment. The work closes with a conclusion and an outlook of the future work. 3 service level agreements 2

2. Fundamentals This section gives a summary of the fundamentals of Cloud-related technologies, providers, middle-ware and standards. The simulation framework CloudSim[3], which is extended by this work, will be described as well. 2.1. Cloud Computing The Cloud represents any-to-any network connectivity in an abstract way. In this abstraction, the network connectivity in the Cloud is represented without concern for how it is made to happen. [4] The term Cloud stands for the highly elastic provisioning of services (either computing power, networking, storage or applications). Providers of Clouds acquire hardware (hard drives, CPUs, network infrastructure, etc.) and set a Cloud platform on top of that physical infrastructure by using virtualization technologies[9]. Users are given accesses to that platform via network in a transparent way, so that they do not need to have knowledge about the underlying hardware. Billing is typically based on a pay-per-use principle. Users gain a simpler, more flexible and cheaper way of accessing the infrastructure [14]. Cloud computing is the IT foundation for Cloud services and it consists of technologies that enable Cloud services [6]. Providers offer physical machines, that are pooled and can be allocated to virtual machines (VM ), that are created by the users (customers). Users pay per computing instance per time. A computing instance defines a specific amount of guaranteed CPU power, available RAM and hard disk storage. This server template and other metrics (like maximum network latency, minimal network bandwidth, maximum time to turn additional VMs on for scale-out, etc.) are defined in the service level agreements (SLA). The service level management is done via dynamic orchestration of physical resources[6]: Multiple VMs can run on the same physical host simultaneously (using virtualization technologies). Virtual machines are migrated between physical hosts. Physical machines are powered off or on, depending on the current requirements. 3

4 2. Fundamentals Customers can upload their own images of their VMs, that can then be dispatched on one or multiple instances. The complete software stack, beginning at the level of the operating system, is customizable by the user. All interactions between the user and the Cloud provider are typically carried out via a web console. Security can be enforced via storage isolation, VM isolation, VLANs, SSL/SSH[6]. 2.2. Characteristics of a Cloud According to NIST, there are five essential characteristics of a Cloud [13]: On-demand self-service: Users can allocate resources whenever they need. Broad network access: Fast data transfers between the Cloud and all users. Resource pooling: Resources are pooled via virtualization technologies and then allocated to user requests by the Cloud operator. Resources can be re-allocated. Users do not have control, which physical device is allocated. Rapid elasticity: The amount of allocated resources depends on current need. Rapid elasticity ensures, that changes of these allocations can be done within very short time intervals. Measured Service: Different dashboards provide metrics for providers as well as for users. 2.3. Cloud Deployment Models Four different deployment models can be defined[13] as follow: Private Cloud. The whole infrastructure serves only one customer. The Cloud provider is either the user himself (same company) or another company, but the Cloud hardware is separated on hardware level, which leads to more security and privacy. Community Cloud. Similar to the private Cloud, the physical resources are only available to a limited group of users. Multiple organizations share a hardware pool and agree amongst each other on policies. The community Cloud is useful, if the organizations follow a common mission and have to share data between each other. Public Cloud. General accessible platform, owned by a company that sells the service to users. Hybrid Cloud. Combination of either private or community Cloud together with public Cloud. High peaks of resource utilization can be backed by the public Cloud. This requires a common interface of involved Cloud platforms. 2.4. Cloud Service Models Three different service models describe the different levels of abstraction, that is offered by the provider. The highest level of abstraction is the Software as a Service (SaaS) [13]. Whole applications like email or group-ware are provided via web-interfaces. The user can not use other applications than the offered ones, but he does not have to worry about installation, updates or configuration. Popular examples are icloud 1 or Evernote 2 for end users or Amazon Simple Work-flow Service 3 for companies. [14] 1 see https://www.icloud.com/ 2 see https://evernote.com 3 see http://aws.amazon.com/en/swf/ 4

2.5. Data Storage as a Service 5 The second level of abstraction is Platform as a Service (PaaS). The Cloud provider offers an API and a runtime to the user, which can develop own applications. The runtime and the API offer libraries and mechanisms to the developer, which speeds up the development of software, but limit the developer to a specific provider (Vendor-lock-in). Well-known examples are Google App Engine 4, Microsoft Windows Azure 5 or Amazon Elastic Beanstalk 6. The lowest level of the abstraction is called Infrastructure as a Service (IaaS) [13] which simply provides virtual machines, virtual switches and virtual network connections that can be used like physical devices. The user can determine the configuration of all these devices and can choose his own operating systems. 2.5. Data Storage as a Service Like Cloud Computing, data storage as a service (STaaS) is a specialization of IaaS. The term storage with respect to STaaS means non-volatile (permanent) memory with read and write possibilities via network, which can be offered in different forms by a Cloud provider. Most STaaS solutions offer on-line secondary storage, but tertiary off-line or near-line solutions do exist (for example Amazon Glacier 7 ). This work focuses on an on-line secondary storage. Storage can be analyzed by the following characteristics [15]: Random vs. sequential access: Jump between specific positions in a file or access in consecutive manner Minimum, maximum and average read/write latency: Delay, introduced by storage devices, that occurs before data transfer can be achieved between user and storage medium read/write throughput: Maximum transfer rate Granularity: Size of accessible chunks Reliability: Probability of spontaneous bit value change by mistake Energy use: Power consumption during standby and performance Storage density: Required space per megabyte The cost per storage depends on the energy use and storage density. Many different factors have to be considered, before building and configuring a storage system, for example: Geographic backups: Encounter loss of whole data centers or deletion by mistake Replication systems: Encounter disk failure and serve many consecutive read requests of the same content Anti-bit-rot mechanisms: Detect data inconsistency, caused by storage devices or write/read operations Total costs: Based on energy usage and storage density Scalability: Prevent bottlenecks and single-points-of-failures Encryption: Secure stored data and/or transfer between the client and the Cloud 4 see https://developers.google.com/appengine/?hl=en 5 see http://www.windowsazure.com/en-us/solutions/ 6 see http://aws.amazon.com/de/elasticbeanstalk/ 7 see http://aws.amazon.com/en/glacier/ 5

6 2. Fundamentals Companies that do not have the required knowledge or money to invest in such a storage facility, become STaaS customers. Providers guarantee certain SLAs (Service Level Agreements, see 4.3.3), like the costs per gigabyte, the number of replicas or the geographic availability. STaaS solutions scale-out, like the Cloud Computing solutions, which save customers high investment costs, for example if, less storage capacity is required than beeing bought. Providers on the other side do not know what kind of data is stored by their customer and how the data will be accessed. One possible scenario would be a popular website: Very few write operations, a high burst on a specific content. Another scenario would be a document management system: Ratio between read and write operations is close to 1. There is no prediction, which content could be requested in the future, is available and therefore no good caching possibilities are known. Providers can reduce the amount of actual used space by using compression and deduplication [4]. One infrastructure has to serve these and other possible scenarios. 2.5.1. STaaS Storage Types There are basically three known types of storage types: structured, block and object storage. Every type has different characteristics and is therefore preferred in different use-cases. 2.5.1.1. Structured Storage Structured storage systems are also known as Databases. Content (or entries) follow a schema and have a defined structure (field A of type a, followed by field B of type b,...). Database systems follow the client-server pattern (both can be on same machine), which means that the server stores and manages the content. The client requests or writes content via a specific interface (for example SQL). The biggest advantage of this kind of storage over other storage systems is, that the server can use the content schema to filter, sort or compute outputs. DBMSs (database management systems) hide the physical organization of the data, are responsible for avoiding mutual overwrites and perform optimizations in order to retrieve data as fast as possible 8. 2.5.1.2. Block Storage Block storage is the kind of storage that is typically used on every personal computer: hard disks, optical disks or magnetic tape. Devices can be only read or written on blocks (also known as chunks of data). Except for the magnetic tape, block devices are accessed via a file system in order to achieve random access to content. Optionally a DBMS can provide a convenient way to organize data on the storage device 9. File systems define the logical unit file that combines one or multiple blocks on a storage device to one entity. Files can be organized hierarchically in directories. While the mapping from file to blocks on the storage device is done by the file system, the organization and retrieval of files from different directories, replication, backups, etc. has to be done by the user or programs that run on top of the operating system and use the file system. Security is enforced by the operation system in cooperation with the file system via flags, access control lists[? ] or similar mechanisms 10. 8 see http://en.wikipedia.org/w/index.php?title=database&oldid=564466297 9 see http://en.wikipedia.org/w/index.php?title=block_(data_storage)&oldid=540858882 10 see http://en.wikipedia.org/w/index.php?title=file_system&oldid=563716718 6

2.5. Data Storage as a Service 7 Virtual file systems allow to access remote storage devices via network, for example NAS (network attached storage), or pool multiple devices to one logical device, like SAN (storage area network). SAN offers only block-based storage which leaves the file system concerns to the client 11. 2.5.1.3. Object Storage The concept of object storage was introduced in the early 1990 s and gains an increasing interest in the Cloud computing community. Object storage pools multiple physical devices together and provides one logical medium to store and retrieve many different pieces of information (called objects). According to [1], SAN lacks in three important aspects: security and protection, end-to-end management at a meaningful semantic level, and scalability (in particular for allocation). In contrast to conventional file systems, the physical location of an object is determined by the storage controller. Like structured storage, object storage follows the client-server pattern. Every operation has an attached credential in order to enforce security[1]. Object storage systems can usually handle multiple users: Their stored objects are separated from each other on the logical representation layer [4]. Besides user data, an object contains so called metadata [1], like timestamps, information about the content (for example via MIME type) or number of replicas. Objects can be accessed by their server-wide unique ID and can be created, updated, read (complete or partially) by all authorized clients [1]. Objects may have a name, like a filename in conventional file systems, to achieve a more convenient way for the user to identify files. These filenames must be unique in a specified scope: This scope is either the set of all files of one user or all objects within the same container. Containers are virtual organization units for objects and may be hierarchical like folders on conventional file systems. Metadata can even be attached to containers (like number of replica of every stored object in that container) [4]. Object storage systems provide a set of capabilities (like versioning, replication, user groups,...), which can usually be queried by customers. [4] Table 2.1 compares block storage to object storage, according to [7]. Table 2.1. Comparison between Block Storage and Object Storage Block Storage Object Storage read object offset, read block, write object offset, Operations write block create object, delete object weak, strong, Security full disk per object allocation external internal 2.5.2. Example STaaS Provider - Amazon S3 One of the most popular object storage providers is Amazon S3. Amazon S3 provides a simple web services interface that can be used to store and retrieve any amount of data, at any time, from anywhere on the web. It gives any developer access 11 see http://en.wikipedia.org/w/index.php?title=network-attached_storage&oldid=560730128 7

8 2. Fundamentals Table 2.2. Storage Prices for Amazon S3 standard Storage in the US used storage / month price in $/GB First 1 TB $0.095 Next 49 TB $0.080 Next 450 TB $0.070 Next 500 TB $0.065 Next 4000 TB $0.060 Over 5000 TB $0.055 Table 2.3. Costs per Request for Amazon S3 in the US Pricing PUT, COPY, POST, LIST $0.005 per 1k requests GET and all others $0.004 per 10k requests DELETE free to the same highly scalable, reliable, secure, fast, inexpensive infrastructure that Amazon uses to run its own global network of web sites. [10] Developers (the users) create so-called buckets (which are equivalent to the object containers of CDMI), which isolates the stored objects from different users. Objects are then stored in those buckets without any additional hierarchy (no nested buckets possible). The number of objects is not limited, but the size of one object cannot exceed 5 petabyte. Objects are stored in three different facilities (replication) and the backup mechanisms are designed for 99.999999999% durability and 99.99% availability of objects over a given year. All operations are passed via REST / SOAP interfaces. Object downloads can be done via HTTP or BitTorrent. Objects can be made public so they can be accessed via HTTP by end users without any authentication, which means that in fact the object storage can serve as a CDN (content distribution network). Amazon calls this feature CloudFront. Pricing depends on the region. Amazon offers currently two locations in the US, one in the EU, three in Asia Pacific, and one in South Africa. Data will never be transfered between regions, except the developer transfers them by himself. [10]. The total costs for a bucket depend on the region, the used space per month, amount of transfered data and the number of different operations according to [10] are shown in table 2.2, 2.3 and 2.4: 2.5.3. Example STaaS Middleware - OpenStack Swift OpenStack [8] is an open source initiative, founded in 2010 by NASA (project Nebula) and Rackspace Hosting (Cloud Files platform). OpenStack is very popular for developing private or community Clouds. Organizations like ebay, CERN and Deutsche Telekom use the projects 12. One of the OpenStack projects is called Swift, which is a STaaS system that offers basic features (storage, retrieve, deletion, updates of objects) as well as replication, integrity audits and statistics. Swift was designed to have no single point of failure and scale horizontally (see 2.2). 2.5.4. Example STaaS API - CDMI The Cloud Data Management Interface (CDMI) is a standard, defined by the SNIA (Storage Networking Industry Association). CDMI defines a RESTful HTTP interface to access 12 see http://en.wikipedia.org/wiki/openstack 8

2.5. Data Storage as a Service 9 Table 2.4. Traffic Cost for Amazon S3 in the US Uploads Transfer out from S3 to same region Transfer out from S3 to different region Transfer out from S3 to CloudFront Transfer out from S3 to the internet Pricing free free $0.02 per GB $0.02 per GB $0.00 up to $0.12 per GB User A CDMI Cloud Container bar Root Container User A Container foo Nested Container Root Container User B Root Container User C Figure 2.1.: CDMI root container with multiple containers an object storage system. Export capabilities to CIFS, NFS, iscsi, WebDav and OCCI are generally possible, but optional. Besides objects and containers, more advanced features like Domains and Queues are provided. The offered features can be expressed via capabilities. Containers are being used as simple grouping of objects for convenience and may be hierarchical [4] as depicted in figure 2.1. The provider creates exactly one root container for every customer (user). Users can only access their own root containers, but can create multiple credentials for different access levels for objects inside their root container via Domains. Metadata is being used to keep the storage system simple, but empowers the provider to build quality services (like automatic, selective backups) on top of an object storage system. The schema of metadata can be defined by the user. Containers as well as objects do have metadata. If a new object is created, it inherits some metadata from the container it is located in (and containers inherit metadata from the parent containers). Metadata of an instance (container or object) may then be changed at any further time in order to overwrite the inherited metadata. There are different types of metadata, like HTTP (content length, content type,...), user and storage system metadata. Such information are key-value pairs, that are encoded as JSON strings.[4] Queue objects are used to store values like containers, but offer access in a first-in-first-out manner. Domain objects can be used for administrative groupings and accounting [4]. Both kind of those objects will not be discussed or further used in this thesis. Every object and every container must have an URI, which is unique in scope of the Cloud and is generated by the Cloud itself. Users then can change names of objects or containers 9

CloudSim User Code 10 2. Fundamentals Cloud Scenario User Requirements.. Data Center Broker User Broker Cloudlet Virtual Machine Cloud Coordinator VM Provisioning CPU Allocation RAM Allocation Data Center Bandwidth Allocation Storage Allocation Network Topology Message Delay Calculation Sensor CloudSim Core Simulation Engine Figure 2.2.: CloudSim Overview to assign a more expressive identifier. In contrast to the Amazon S3 own API, CDMI offers the four HTTP request verbs (GET, PUT, POST, DELETE). CDMI was chosen for this work, because it provides all core features of a Cloud service interface, but is not limited to a single provider (like Amazon S3). In addition, it is a fact that CDMI is an open standard, leads to an open environment for interoperability between different Cloud Providers. Customers can use one interface definition to access many different Clouds. There is also a CDMI implementation for OpenStack 13. 2.6. CloudSim CloudSim is a time discrete simulation framework for Cloud computing. The framework consists of three layers as shown in figure 2.6 (from bottom to top): 1. Core Simulation Engine: Queuing and processing of events, management of Cloud system entities such as host, VMs, brokers, etc. 2. CloudSim: Representation of network topology, delay of messages, VM provisioning, CPU, storage and memory allocation, etc. 3. User code: General configuration such as Cloud scenarios and user requirements, User Broker 13 see https://github.com/osaddon/cdmi 10

2.6. CloudSim 11 Users of the framework can either modify the top layer to change the scenarios to simulate, or extend the second layer, to test different allocation policies in a Cloud system. The user code layer defines so-called cloudlets that define a specific amount of computation requirements (like a Cloud job). These jobs are then dispatched on available VMs by the CloudSim layer. Communication between the entities is done via messages that are represented as events that are sent to the core simulation engine, which handles all events in the correct order and manages the simulated time. Events between two remote entities are automatically delayed, if the network topology is represented.[2] CloudSim can simulate SAN storage, hard drives and files, that are stored on hard drives directly or via SAN storage. But the modeling of those lacks for object storage: File size magnitude: CloudSim models the file size in megabyte, but 90% of all web objects fit within 16KB [5] 14 Hard drive models: The hard drive models do not provide all metrics that are required to model the read and write durations accurately. No storage controller: CloudSim does not offer a controller that determines the storage location of objects. No appropriate object storage interface: No model for any STaaS interface, as for example CDMI. 14 Which means that a CDN scenario can not be modeled accurately. File sizes are stored in Java Integer variables: Only files up to 2.147 PB can be modeled. 11

3. Modeling of a STaaS The previous chapter described all fundamentals in detail, including the existing simulation framework CloudSim. This chapter describes the extension of this framework to enable the simulation of STaaS. Class names are formated as the following: SomeClass. classes can be found in chapter 4. 3.1. Architecture Detailed descriptions of these The following section provides an outlook, how the existing architecture of CloudSim will be extended, to provide a simulation environment for STaaS Clouds. Some classes are shared with CloudSim, some are completely independent. Therefore contents of figure 3.1, which represents the overall architecture of the modeled StaaS Cloud, will be discussed in the following sections. Blue boxes represent components of CloudSim, green boxes are components that are described in this work and purple boxes are components that have to be provided by the user of the simulation framework. 3.1.1. User Code and User Interface Structures The user code describes the general Cloud scenario: What kind of requests shall be simulated in which order? For classical usage of CloudSim, the user creates different parameters, that are then converted into cloudlets and sent to the Cloud. One cloudlet represents a single job, that cannot be divided into two jobs and is independent of other jobs. The similar concept for STaaS is the UsageSequence. Instances of this class define the requirements that are demanded of the Cloud (e.g. pricing, capabilities,...). After that, a series of User-Cloud interactions follows (see 4.3.8). Possible interactions are: Creation or deletion of a container, upload or modification or deletion or download of an object and idle operations (see more in section 4.3.7). All operations within one UsageSequence depend on each other in their given order (a download of an object can only succeed, if it was uploaded previously to the very same Cloud). UsageSequences are brought to a MetaStorageBroker (see 4.3.4), which chooses one Cloud that matches the SLA requirements the best. For this process the MetaStorageBroker starts multiple Cloud discovery requests (see 4.3.7.1) that retrieve current capacities and capabilities of the Clouds. After all Clouds have been discovered, the best one is chosen. The UsageSequence is then forwarded to the StorageBroker (see 4.3.1), which then 12

3.1. Architecture 13 Figure 3.1.: Architecture Overview creates further CDMI requests and interacts with the Cloud. A more detailed description of the different interactions can be found in section 4.3.6. 3.1.2. Provided Storage Services The services that are provided by the modeled STaaS Cloud are: Object Storage: Storage, organization and retrieval of objects as described in 2.5.4. Replica: Objects are stored multiple times on different locations. The number of required replica can be adjusted per container. Store operations only succeed if there is sufficient storage for all replicas of the object. Storage Accounting: Every operation in the Cloud is logged. One purpose is billing, the other is general monitoring of delay and duration of operations. Storage Policy Enforcement: Object Replicas are stored as remotely distributed from each other as possible to reduce the possibility of failure. Limits like the maximum number of children or maximum object size are enforced as well. 3.1.3. Resources, Resource Usage and Network There are two resources that are limited in the STaaS Cloud: Number of bytes that can be stored at a given time and the available bandwidth (user to Cloud, Cloud interface 13

14 3. Modeling of a STaaS to storage server, server interface to hard disk). The total used storage capacity changes only when an object is uploaded, deleted, modified. In contrast, the available bandwidth changes very often during the simulation. Whenever an object is uploaded, downloaded, modified or moved the used bandwidth will increase when the operation starts and then decrease when the operation is finished. Multiple operations can be executed at the same time, so the available bandwidths of the different operations depend on each other. This is modeled with the TimawareResourceUtilization (see more in section 4.3.5). Storage servers and hard disks model the hardware that is used by the Cloud provider. They model the technical details like maximum read/write throughput or the total available capacity. Network links are modeled via BRITE topology. Messages are delayed, depending on some fixed delay that is defined in this topology [12]. Another crucial factor is the size of a network transmission (upload and download of objects). This delay is calculated based on the currently available bandwidth (timeaware resource utilization) and the size of the message. 3.2. Sequence Diagram The sequence diagram depicted in figure 3.2 shows an example of interaction from the User Code down to the hard disks and will be discussed in the following paragraphs. As described in 3.1.1 all commands have to be encapsulated in a UsageSequence. In this case, there is only one available Cloud provider, so there is only one broker and no need to do a cloud discovery process. This UsageSequence consists of only two commands: The creation of a container and the upload of one object into that container. The broker acts on behalf of the user and is identified via the ID that is defined by the CloudSim core simulation framework. The Cloud instance checks on every request, if the user is already known and either rejects the request or creates a new user account (with a new root container). On the case of a PUT container request, a new user is created. Every other request will fail (PUT object requests require an existing container, GET and DELETE request does not make sense at all, because there are no container or objects of a new created user). Every container that is created by the user is a direct child of the user s root container. Policy enforcement mechanisms will ensure, that the user is able to create the container. The creation of a child container requires virtually zero time, so the Cloud instance can send a success response immediately after the container was created. It can be seen that the PUT container request was blocking, so the broker waits until the operation succeeds before proceeding with the next operation. This is required, because the object shall be put into the newly created container. The Cloud instance checks all prerequisites (does the user exist, does the target container exist,...). Every container in the Cloud is virtually attached to several storage servers. Containers control where to store objects by choosing one of the attached servers. In the simplest case, every container is attached to all servers. Another possibility would be some regional limitations (e.g. one container can only access servers in one geographical region). As soon as all prerequisites are met (sufficient storage and no policy violation), the Cloud will send an acknowledgment to the broker, which signals that the operation will succeed, but is not finished yet. The PUT operation may be delayed, because some resources are totally occupied at that time. In addition, the duration of the operation is calculated, which depends on the maximum bandwidth and workload of the hard disks, server and cloud network interface. 14

3.2. Sequence Diagram 15 User Code Broker Storage Cloud Usage Sequence PUT Container check User create & set Meta root Container create child CDMI Response PUT Object check User getchild object Container store Object expected delay and duration CDMI ACK delay response CDMI SUCC poll Report & Stats poll Report & Stats object Container probe succeed reserve space Server Harddrive probe probe sufficient storage sufficient storage reserve space reserve space Harddrive Figure 3.2.: Interaction Overview 15

16 3. Modeling of a STaaS The lowermost bandwidth and longest delay specify the total delay, before the SUCC response is sent back to the broker. Depending on the scenario and user code, it might be useful to retrieve some statistics and reports from the brokers and the Cloud providers. The broker can provide information on the user level, like total duration of operations (where delay and duration can not be distinguished) or the number of succeeded operations for the user. The information that can be pulled from the Cloud is more detailed. There are logs available, describing which resource was used for which purpose and how long operations were delayed for which reason. In addition, the Cloud instance provides these information for all users. The total costs are available per user and aggregated for all users as well. 16

4. Implementation The previous chapter gave a brief outlook over the architecture and the interactions of different components inside the storage cloud simulation framework, which extends CloudSim. This chapter covers the detailed description of the implementation of single classes and their interaction with each other. Figure 4 gives a broad overview over all important classes in this work. Green classes represent the CDMI implementation, yellow ones the internal storage model, blue classes represent user models and purple classes are for monitoring purposes. A more detailed description of the single components will follow. Names of methods, constants and so on are formated as the following: void foo(string bar), SOME_CONST or SomeClassName. 4.1. Development Envorinment This work extends CloudSim version 3.0.3 1. Beside the The Apache Commons Mathematics Library 2, which is required by CloudSim, the Simple framework version 2.7 3 is used for the serialization and deserialization of XML files. Both libraries are published under the Apache License 4. The complete extention of CloudSim is written in Java 5. Netbeans 7.3.1 6 was used for profiling 7 and IntelliJ IDEA was used as primary IDE 8 4.2. STaaS Provider Models This section is about the models that are required to simulate all states, processes and policies that are inside the Cloud and invisible to the Cloud user. 1 https://code.google.com/p/cloudsim/downloads/detail?name=cloudsim-3.0.3.tar.gz, released on May 02, 2013 2 version 3.2, see http://commons.apache.org/proper/commons-math/ 3 see http://simple.sourceforge.net/, published on 18 February 2013 4 version 2.0, see http://www.apache.org/licenses/ 5 version 1.7.0 update 25 6 see https://netbeans.org/ 7 see https://profiler.netbeans.org/ 8 version: 12.1.4 Build: 129.713 Released: June 10, 2013, see http://www.jetbrains.com/idea 17

18 4. Implementation EventTracker TrackableResource UsageHistory <<reads>> CdmiEntity ReportGenerator StorageCloud CdmiRootContainer CdmiObjectContainer CdmiObject <<processes>> CdmiCloud- Characteristics CdmiMetadata <<creates>> StorageBlob TimeawareResource GETContainerRequest CdmiRequest IObjectStorageDevice StorageBlobLocation ScheduleEntry <<create>> CdmiResponse <<create>> <<receives>> StorageBroker <<creates>> / <<destroys>> <<processes>> UserRequest ObjectStorageServer SLARequest * GETObjectRequest PUTObjectRequest DELETEObjectRequest... StorageMetaBroker UsageSequence TrackableResource <<forwards>> <<creates XML for>> UsageSequenceFile- Generator SLARequirement Figure 4.1.: System Class Diagram 18

4.2. STaaS Provider Models 19 STaaS Clouds do have different capabilities and characteristics that differ from each other. Some providers might be cheaper than others, but offer less services (for example the number of replica). This issue will be highlighted in the section 4.2.1.4. As described in section 2.5.4 the CDMI interfaced Cloud is accessed via a RESTful interface that is based on HTTP. The following section will cover the implementation of this interface. 4.2.1. CDMI Implementation This section will give a closer look to the implementation of a CDMI-like interface to a STaaS provider. This implementation is only a subset of the CDMI interface which was described in section 2.5.4. 4.2.1.1. CDMI Entity Every object, which can be stored, and every storage container is modeled as an instance of CdmiEntity. Entities must have a provider-wide unique ID (represented by CdmiId ) and may have a name for convenient access. The class CdmiID provides unique IDs within Clouds (distinguished by their rooturl) for the creation of new objects and containers. The user has no control over the choice of IDs. Containers and objects can be accessed via their CDMI ID or via their name (unless the name was never set / is empty). Some entities, like CdmiRootContainer or CdmiObject- Container can contain children, which are, again, CDMI Entities. 4.2.1.2. CDMI Object Instances of CdmiDataObject represent the smallest addressable storage units and extend the class CdmiEntity. Every object has its own metadata, that is inherited from its parents. The size of an object is defined as the number of bytes that are stored by the user as the content of the object. The physical size is defined as the size plus the space that is required to store the metadata (see 4.2.1.4). 4.2.1.3. CDMI Container Containers are entities that contain children. They provide a namespace separation for object names. No two objects with the same name can exist in the same container. The mapping of names to the ID of all stored children is stored in every container. Containers do have metadata that are inherited from the parent 10. Containers can enforce policies that are parameterized through their metadata: For example NUM_REPLICA defines the number of required replications of one object to fulfill the Quality of Service (QoS). Every container can have a different QoS regarding replication. The size and physical size is defined as the sum of sizes/physical sizes of all children plus the space that is required to store the metadata (see 4.2.1.4) of the container. The CdmiRootContainer is a specialized container, because there exists exactly one root container for every Cloud user. Root containers have an additional mapping from object ID to the container that stores the object, in order to retrieve objects through their ID without providing the name of the container. 9 The figure shows the implementation of the constellation of the classes as they are in Java on the lefthand side. The right-hand side is a simplified version that models the constellation on the layer of the models. 10 CdmiObjectContainer s inherit from the CdmiRootContainer of the user and the root container inherits from the cloud default metadata setting when it is created. 19

20 4. Implementation Generics Simplified assocations Metadata Has children <T extends Entity> * 1 1 1 Entity Container CdmiID Object Root Container * ObjectID- Container- Mapping Object- Container- Mapping CdmiID Root Container Object Container 1 * 1 * Object Metadata Object Container Figure 4.2.: Relationship between Objects and Containers 9 4.2.1.4. CDMI Metadata and Cloud Characteristics The Cloud, containers and objects store metadata, which is a simple key-value storage. Metadata can be inherited from parents to new created children, but some metadata are restricted from inheritance (e.g. the capabilities of the cloud are represented as metadata values, but are not inherited by root containers). The Cloud user can read and modify the metadata of objects and containers, depending on the configuration of capabilities of the Cloud provider. Typically the number of key-value pairs per object and the length of the value are limited. All values are stored as UTF-8 characters. The required space to store Table 4.1. Implemented CDMI Metadata Key Value Cloud Root Container Object SIZE size of object in bytes X TYPE e.g. MIME type X CREATED_AT creation time-stamp X X LAST_WRITE_ACCESS last modification X X X time-stamp LOCATION geographical position X X X NUM_REPLICA number of replications X X X of object NUM_VERSIONS number of old versions X X X to keep MAX_OBJECT_SIZE max. allowed size of X X X container in bytes MAX_CHILD_COUNT max number of children per container X X X the metadata is modeled to be the number of bytes to store the string concatenation of all keys, values and two separator characters for every pair. All these metadata instances are created by the Cloud provider, but users can introduce new kinds of metadata simply by putting a new key-value pair into the metadata, if the capabilities allow users to modify metadata. 20

4.2. STaaS Provider Models 21 The Cloud characteristics are an extension of a simple key-value storage by providing some convenient methods to access the data. The characteristics extend the set of possible keys by the following: MIN_BANDWIDTH, MAX_LATENCY, PROVIDER_NAME, AVAILABLE_CAPACITY, STORAGE_COSTS, DOWNLOAD_COSTS, UPLOAD_COSTS, CAPABILITY_CREATE_CONTAINER, CA- PABILITY_DOMAINS, CAPABILITY_EXPORT_ISCSI, CAPABILITY_EXPORT_NFS, CAPABILITY_EXPORT_WEBDAV, CAPABILITY_LIST_CHILDREN, CAPABILITY_MOD_METADATA, CAPABILITY_NOTIFICATIONS, CAPABILITY_QUERY, CAPABILITY_QUEUES, AVAILABLE_CAPACITY, MAX_METADATA_ITEMS, MAX_MEDATADA_ITEM_SIZE, CAPABILITY_DELETE_CONTAINER, CA- PABILITY_READ_METADATA These characteristics are then used by the MetaBroker to find a provider that fulfills all the SLA requirements (see 4.3.3). 4.2.2. Internal Storage Models The last section describes containers, objects and metadata, which are classes that can be used to model requests and responses between the user and the Cloud. Models that are required to simulate the processes inside the Cloud are described in the followed subsections. 4.2.2.1. Blob and Bloblocators One blob can be seen as a file - information that is written on a physical medium. One object has one or multiple blobs (depending on the number of replicas). Two blobs that belong to the same object can not be stored on the same disk. Instances of BlobLocator map one location (server and disk ID) to one object ID. Object containers manage the locations of one object: one list of BlobLocator s are stored for each object in a container. 4.2.2.2. Servers and Hard Drives Every hard drive (disk) has to be attached to exactly one server. Hard drives have to implement the interface IObjectStorageDrive, that models storage drives more accurately than CloudSim. Capacity, used storage and blob sizes are modeled as Long, which allows a modeling of file sizes from 1 byte to 8 Exabyte. Every disk has a device name that has to be unique within a server system (e.g. /dev/sda1 ). Write latency and read latency (in ms) as well as the maximal write and read throughput (in byte / ms) can be modeled independently. ObjectStorageServer 1 * ObjectStorageBlob- Locator 1 1 ObjectStorageBlob * 1 1 ObjectStorageDrive CdmiDataObject Figure 4.3.: CDMI Object, Blob and Blob Locators Servers manage disks and can either decide where to store a blob or store a blob to a given disk. Therefore ObjectStorageServer provides a method to probe disks. This operation returns all disk names that have enough capacity left to store a blob. The method takes optionally a list of drives, that will be excluded from the disk probe, in order to enforce the policy that no two blobs of a single object can be stored on the same disk. Hard drives and Servers are time-aware resources, as described in 4.3.5. The connection from the hard drive to the system bus is an independent instance of the IO limitation between server and network controller, because internal copy operations from one disk to another, within the same server, will not use any network bandwidth. 21

22 4. Implementation Server System Bus sda1 sda2 sda3 Disk Interface Cloud internal network Cloud internal network interface Cloud-internet connection Figure 4.4.: Server and Disk IO limitations 4.2.3. Object Storage Cloud Model This model is the the central coordination entity of the STaaS simulation. Incoming requests from brokers are checked and executed. Every server, container and object is coordinated by this class. The StorageCloud enforces all policies, such as number of required replications per object or available capabilities. Every operation can be delayed for a certain time if any involved resource (server, hard drive, Cloud bandwidth) is not available at the moment. Operations like GET and PUT do have a certain duration, depending on the current workload of all involved hardware. Operations are billed, depending on a pricing model, which is updated every time a user performs an action (start request, upload object, download object, delete object). Price models can be the one of Amazon S3 (see section 2.5.2) or more complex price functions are possible. This work will focus on linear price models. Every broker (see 4.3.1) represents one user, whereas the ID of SimEntity is used for user identification. The Cloud checks for each incoming request if the requesting user is already known. If this is not the case, a new root container is created. Every other type of request requires an existing root container. Root containers are strictly separated from each other, and do not interfere with each other. Users can only access their own root container. 4.3. User Models After describing the most important classes, which are required to model the states and processes inside the Cloud, the next section will give an outlook of the classes that represent the behavior of the user of the Cloud. 4.3.1. StorageBroker Class The class StorageBroker represents a single user that is connected to exactly one Cloud. The main purpose is to generate CDMI requests that are then sent as simulation events via the CloudSim core simulation framework. The UsageSequence (4.3.2) defines the order and type of the requests to be generated. Lists of all created requests and their states (acknowledged, failed, succeeded) as well as the responses are stored in the broker for detailed analysis after the simulation. Furthermore a reference to all stored objects and all 22

4.3. User Models 23 containers is held in the broker. The StorageBroker class implements the TrackableResource interface, by providing the metrics total number of events, events per second and events per minute. In addition, all metrics that are provided by the UsageHistory of the associated cloud are provided. All UserRequest s are stored in a queue and enqueued at the end by default. Another method allows to enqueue requests at the beginning of the queue as well. New User- Request s can be generated during runtime. The broker is able to send CDMI requests asynchronously or synchronously (waits for response of request, before sending the next one). Another synchronization mechanism is the barrier UserRequest. This request forces the broker to wait until all running operations either failed of succeeded. 4.3.2. UsageSequence Class One UsageSequence represents a series of UserRequest s in a defined order plus an instance of StorageCloudSLARequest. Each request may depend on previous requests 11. Thus the order of the UserRequest s inside the UsageSequence is critical. No dependencies between two instances of UsageSequence are allowed, therefore the order of execution between UsageSequence s is irrelevant. 4.3.3. Service Level Agreements The StorageCloudSLARequest class defines requirements that have to be considered, when the MetaStorageBroker chooses a Cloud provider. Service level agreements (SLA) are therefore modeled as a set of predicates (SLARequirement )that can be combined via and and or operations. Each SLARequirement provides the method match which takes an instance of StorageCloudCharacteristics and returns either true if the requirements are fulfilled or false otherwise. There are some predefined SLARequirement subclasses like SupportsCapability DoesNotSupportCapability MaximumCharacteristicsValue : Checks if a numeric characteristics property (e.g. upload price per GB) does not exceed a given threshold. MinimumCharacteristicsValue CharacteristicMatchesString : given string. Checks if a characteristics property matches a The class StorageCloudSLARequest provides the following methods in order to create a complex SLA request via the builder pattern: minbandwidth (double), maxlatency (double), maxstoragecost (double), maxuploadcost (double), maxdownload- Cost (double), mincapacity (long), maxcontainersizeatleast (long), maxobject- SizeAtLeast (long), locationis (String), locationisin (List<String>), hasnoobjectsizelimit (), hasnocontainersizelimit (), cancreatecontainers (), candelete- Containers (), canmodifymetadata () If more than one Cloud provider fulfills all SLA requirements, there must be some ranking algorithm to compare the different providers to choose the one with the best match. The StorageMetaBroker has to choose the best Cloud by some policies that are modeled with instances of SLACloudRater which provide a score method that takes an instance of StorageCloudCharacteristics and returns a double which can be negative, zero or 11 e.g. the GET operation can only succeed if the according element has been uploaded via a PUT beforehand. 23

24 4. Implementation positive. The higher the score, the better the match of the characteristics. Multiple instances of SLACloudRater can be combined (summation of all scores). Some tuning may be required in order to achieve a reasonable rating with multiple SLACloudRater because the range of the scores of the different raters has to be similar. These fundamental rating classes are implemented: 1. RateBoolCharacteristics positivescore score = negativescore neutralscore if charactaristic = true if charactaristic = false if charactaristic non-existent 2. RateCharacteristicsWithScale { neutralscore if charactaristic non-existent score = scale value otherwise 3. RateCharacteristicsWithInvers { neutralscore if charactaristic non-existent score = 1 value otherwise The two described methods (requirement predicates and ratings) allow the modeling of SLA requirements as seen in the following example: StorageCloudSLARequest SLA = new StorageCloudSLARequest ( ) ; SLA. cancreatecontainers ( ). candeletecontainers ( ). hasnocontainersizelimit ( ). mincapacity ( F i l e S i z e H e l p e r. tobytes (10, GIGA BYTE) ). orderbyprice ( ). addrating ( new R a t e C h a r a c t e r i s t i c s W i t h S c a l e (MIN BANDWIDTH, 0. 1, "bandwidth * 0.1", 0) ) ; 4.3.4. MetaStorageBroker Class The meta broker can be used to run multiple UsageSequence s on different Clouds. Therefore the MetaStorageBroker chooses the best matching Cloud for every UsageSequence by using the SLARequirement which is attached to every UsageSequence. Before rolling out all UserRequest s, the meta broker starts one new instance of StorageCloudBroker for every known Cloud provider and enqueues a UserRequest with the operation code DIS- COVER_CLOUD which prompts brokers to retrieve and store the latest available Cloud characteristics from their associated clouds. After all discovery requests returned successfully, the StorageMetaBroker can choose the best matching Cloud. For this purpose, the meta broker calls the already described match function of the StorageCloudSLARequest instance for every received cloud characeristic (see 4.3.3). Usually the SLA requirement are composed with and and/or or statements, so that only a single method call of the meta broker is necessary. All Clouds that matched the SLA requirement predicates are then scored, using the previously described SLACloudRater. Scores of different rating policies are summed up for each Cloud characteristics and then sorted by the overall score. The Cloud with the highest score is the best matching and therefore chosen Cloud for the sequence. All brokers that are not connected with the chosen cloud are shutdown. The UserRequest s in the UsageSequence are then forwarded to the remaining StorageBroker instance. The meta broker stores mappings from the ID of the UsageSequence s to the chosen Cloud ID and associated broker ID. 24

4.3. User Models 25 Figure 4.5.: Timeaware Resource Utilization 4.3.5. Latency Models CloudSim provides a static model for latency calculations between two SimEntity instances. Data is provided via BRITE notation 12. Delay and bandwidth is stored in a matrix, which enables the modeling of links, that provide different bandwidths in different directions. This model is however not sufficient enough to imitate realistic behavior of the storage Cloud. The interface TimeawareResourceLimitation is a more accurate model to simulate the use of bandwidth of multiple operations that run concurrently. Consider the figure 4.5. At first there are three operations that begin at t1, t3 and t5 (all these events are in the future). Operation one and three use only 60% of the available capacity of the resource, whereas operation two uses 100%. Let operation four be an operation that will be scheduled for the same resource: It has no restrictions and could use up to 100% of the resource, but only 40% are left from t1 to t2. Hence operation four is scheduled with different execution speeds (40% from t1 to t2, 100% from t2 to t3, a pause from t3 to t4 and so on). Let now operation 5 being scheduled for t1 as well. The operation uses 30% of the available capacity. Because no capacity is left, the operation is delayed until t6, where some resources are available. TimeAwareResourceLimitation provides two methods: use(double amount, [double maxrate], [long startat]) and getfirstfreetimeslot(long time). The first one will return a sequence of intervals that indicate timeslots that are connected to a rate, at which the requested operation can be performed. The second method calculates the minimal delay before an operation can be started. 4.3.6. Request Layers Messages between different types of entities are modeled with different classes as shown in figure 4.3.6. The user of the simulation creates a set of UserRequest instances and one instance of StorageCloudSLARequest which is wrapped in a UsageSequence and sent to the StorageCloudMetaBroker. This entity will create an instance of UserMetaRequest to retrieve the latest Cloud characteristics such as price and available capacity. As soon as the broker has received more UserRequest instances out of the UsageSequence it will start to generate CDMIRequest instances that are sent towards the Cloud. The Cloud itself 12 http://www.cs.bu.edu/brite/ 25

26 4. Implementation... DeleteObject- Request GetContainer- Request UserRequest CDMIRequest StorageCloud PutObject- ScheduleEntry StorageCloud- MetaBroker StorageCloud- Broker Schedule- Entry<T> GetContainer- ScheduleEntry Usage- Sequence UserMeta- Request CDMIResponse <T>... UserRequest UserRequest UserRequest Usage- Sequence GetContainer- Response GetObject- Response... T extends CDMIRequest Figure 4.6.: Request Layers will create multiple ScheduleEntry instances in order to store the state for each request. The cloud-internal messaging is done via method invokes only. The ScheduleEntry will generate the according CDMIResponse which is then sent back to the broker. 4.3.7. CDMI Requests Section 4.3.6 describes the different kind of messages that are sent between instances during simulation runtime. This section deals with the messages that are transmitted between StorageCloudBroker and StorageCloud. For every kind of request there exist one class that inherits from CdmiRequest. Requests are modeled with the generic class CdmiResponse that takes <T extends CdmiRequest> as generic parameter. This allows to create specialized responses, that contain detailed information like an object, but at the same time, it is not necessary to create a new class for every response type (for example DeleteObjectResponse and DeleteContainerResponse ), which can be modeled by the specialized version of the generic response class. Another generic class CloudScheduleEntry allows the modeling of the state inside the Cloud. For example a PutObjectRequest has to perform multiple store operations on different disks to succeed. The state of such processes is stored in the schedule entries. As for the generic response class, this class may have specialized sub classes. 4.3.7.1. Cloud Discovery Request The CloudDicoveryRequest is used to request the latest instance of StorageCloudCharacteristics in order to choose the best matching Cloud among multiple Cloud providers. The request has no parameters. The response contains a deep-copy of the StorageCloud- Characterstics instance of the cloud, which is completed with the maximum available bandwidth and latency between the requesting entity and the Cloud. The currently remaining capacity is calculated and included in the response. This operation never fails and returns immediately. It does not trigger any accounting mechanisms. 4.3.7.2. GET Container Request The GetContainerRequest takes the name of the requested container as the only parameter. The response contains the metadata of the container and the CdmiID s of all objects 26

4.3. User Models 27 no user exists? yes Accounting retrieve user'sroot send fail no requested container exists? yes yes allow list children? no send container retrieve children Figure 4.7.: Get Container State Diagram that are inside the container 13. The state diagram 4.3.7.2 explains the retrieval of a container in detail. If the user does not exist, the operation will fail, because unknown users do not have any stored objects or containers in the Cloud, which could be retrieved. If the user is known, the accounting method is triggered, which logs different operational verbs. After the root container of the user is determined, a check will be performed whether the container with the given name is a direct child of the root container of the user. If this is not the case, the operation will fail. If the container is existent, the response will be prepared. The children are either included or not, depending on the Cloud characteristics (see 4.2.1.4). This operation returns without delay and triggers accounting mechanisms. 4.3.7.3. GET Object Request This request takes either the CdmiId of the object that is to be retrieved or a name of a container plus the name of the requested object. This allows a convenient way to access the object from its logical location and in the same time provides a way to retrieve objects without using any container names. The request object is equivalent to one of the following CDMI request strings: GET <root url>/object by id/<cdmiid of object> or GET <root url>/<container>/<name of object>. The corresponding response contains a deep copy of the instance of the CDMI object that is stored in the Cloud and thus provides access to the metadata. Internal information like the location of the blobs, is not included in the response. Thus StorageCloudSim is a simulation environment, no real data is stored in objects. The content is reduced to the information about the number of bytes that are required to store the object on disk. The process of retrieving an object is described in the diagram 4.3.7.3. The user has to exist in order to perform the operation. After the accounting mechanism was invoked to log the GET operation, the object is retrieved by either the ID or via the name of the container. If the CdmdID is given, the mapping from CdmdID to ObjectContainer from 13 depending on the Cloud capabilities, see 4.2.1.4 27

28 4. Implementation Accounting yes user exists? retrieve user's root ID provided? yes no ID-Container mapping exists? yes resolve container send fail no no no yes yes resolve object via ID send object Container exists Name-ID mapping exists? send ACK calc & wait spec. delay choose Blob on Server with lowest utilization Figure 4.8.: Get Object State Diagram the rootcontainer is used. The retrieved container can retrieve the requested object from its child list. If the object can be retrieved successfully, an acknowledgement is sent back to the user. The Cloud will choose the one blob (see 4.2.2.1) that is attached to the server with the currently lowest utilization. After that, the delay and duration for the operation on the hard disk, the server and the Cloud is calculated via the latency models described in 4.3.5. After the delay and duration, the response is generated and sent back to the user. At the very end, the amount of downloaded data is updated via the invocation of the accounting mechanisms. 4.3.7.4. PUT Container Request The PutContainerRequest takes a name and an instance of CdmiMetadata as parameter. The metadata may be ignored, depending on the capabilities of the Cloud (see 4.2.1.4). As seen in figure 4.3.7.4, the Cloud will create a new instance of rootcontainer if the requesting user has never sent a request before. After the checks whether the user is able to create containers, whether the limit of number of maximum children of the root container is reached or the amount of stored data of the root container, the new container is created with a new CdmiId, if there is no other container in the rootcontainer with the same name. Some or all servers are assigned to the new container (see 4.2.1.3). After that, the new created container is returned in the response. The response is sent immediately. described in detail. There exists a delete method as well, which is not 4.3.7.5. PUT Object Request - creation Diagram 4.3.7.5 shows the different states during the creation of a new object. The PUT operation can either perform the creation of a new object, or start an update process of an existing object. In both cases, the request carries data, that is uploaded from the user to the Cloud and then stored in blobs (see 4.2.2.1). As for every other operation, checks are performed before the operation starts, for example: 28

4.3. User Models 29 Accounting yes user exists? no retrieve user's root initialize Accounting create root for user name taken by other container? yes #children limit reached? no no create Container send fail send container inherit Metadata associate Servers Figure 4.9.: Put Container State Diagram Accounting yes user exists? retrieve user's root container exists? yes yes no retrieve container obj. size exceeds limits? name provided? send ACK create Object no no no no choose storage locations name already taken? #children limit exceeded? storage limit exceeded? store on next location send Object wait calculate slowest delay & duration Figure 4.10.: Put Object State Diagram (creation) succeeded? required #blobs reached? no no 29

30 4. Implementation Existence of user Compliance of limits (number of objects, max. size of objects), if any Existence of container to put the object into If either the object name that is included in the request is empty, or the name is not given to any existing object in the target container, the request is considered as a creation request for a new object. Otherwise it is an update of an existing object. Both cases require sufficient storage capacities on n different disks in order to create n replica (n is determined by the metadata of the container, see 4.2.1.3). If enough storage targets could be identified, the Cloud instance will send an acknowledgement to the user and schedule the transfer process by choosing the target devices by sorting them according to some policy that can be defined. The default policy will sort the StorageServer instances by the lowest number of stored blobs on the object 14. The operation can fail while choosing those targets, even if there is enough storage space left, but it is not distributed enough to store n different replica versions. After all storage targets could be found, the delay and duration of every single transfer operation from Cloud to server and from server to hard drive is calculated. The slowest one determines the maximum possible speed of the upload from the user to the Cloud. The operation is checked against the IO-limitations of the Cloud (see 4.3.5). The response that indicates the success of the operation is then being sent delayed. A delete operation for objects exists, but is not described in further detail here. 4.3.7.6. PUT Object Request - update The update of an existing object is exactly the same as the creation of an object, except the old storage blobs are being removed, as soon as the new storage blobs have been stored successfully. Depending on the capabilities of the Cloud, the metadata (see 4.2.1.4) that are included in the PUT operation, are merged into the metadata of the objects. 4.3.8. UserRequest and UserMetaRequest Class The previous section covered the different types of messages that are being used to communicate between a StorageBroker and a Cloud instance. The following section is about the requests that are generated by the user code and forwarded to the StorageMetaBroker, and to the StorageBroker to model the sequence of requests independently of any Cloud interface. For every CloudRequest (as alredy described) exists a UserRequest operation field that distinguishes between different requests (PUT OBJECT, PUT CONTAINER, GET OBJECT, GET CONTAINER, DELETE CONTAINER, DELETE OBJECT, PAUSE, WAIT ). Aside from the operation field, the UserRequest class provides fields for objectname, containername, objectid, rooturl, metadata, delay (in ms) and a size field. Apart from that, UserRequest instances can be blocking calls (wait until operation finished before proceeding to next operation) or not (modeled with the WAIT operation code). Static methods allow the convenient creation of UserRequest instances, for example: 14 Consider a Cloud with only two servers. The number of required replica is 2. For a new object both servers are equally suitable, but as soon as one server has been chosen for the storage of one blob, the other server is ranked higher in order to achieve more physical distribution to aim a more fault-tolerant system. After the second blob was scheduled to the other server, both servers are ranked equivalently. Now the policy enforces to take any hard drive of one of the servers, which does not store one of the first two blobs. 30

4.4. Monitoring 31 List <UserRequest> r = new ArrayList <>() ; r. add ( UserRequest. b l o c k i n g ( UserRequest. putcontainer ( "somecontainer" ) ) ) ; r. add ( UserRequest. b l o c k i n g ( UserRequest. putobject ( "somecontainer", " objectname", 1024) ) ) ; r. add ( UserRequest. downloadobject ( "somecontainer", "objectname" ) ) ; As described in 4.3.2 multiple instances of UserRequest are enqueued in a UsageSequence in addition to a SLARequest which is then forwarded to the StorageMetaBroker. The MetaRequest class inherits from the UserRequest class and introduces a new operation field that prompts StorageBroker s to retrieve the latest characteristics of their associated Cloud. By this, the StorageMetaBroker can choose the best matching Cloud regarding specific SLA requests. The MetaRequest s are only created by the StorageMetaBroker and then inserted at the very beginning of the UsageSequence as a blocking request. 4.4. Monitoring Due to the purpose of this simulation, logging and measuring of metrics is crucial. There are three different methods to observe the behavior of different entities after the completion of the simulation. Logging as textual output of processes and decisions (see 6.4). TrackableResources that log a metric over time. Dump methods to print the state of a Cloud at the end of the simulation (see 6.1). 4.4.1. TrackableResource Class A trackable resource has one or multiple streams of so-called samples. One sample is defined as s = (timestamp, value) whereas the time stamp is the simulation time in ms, the value is some metric, in most cases a double. These streams are identified by keys that are presented by the method getavailabletrackingkeys(). Typical keys are for example: used storage (physical) used storage (virtual, in %) user s debts total earnings total number of GET requests number of requests per minute... Sequences can then be processed with the SampleCombinator class, which provides fold methods as for example: flatten(list<samplestream<t> >) -> SampleStream<T> to preserve order of samples without changing values sum(list<samplestream<double> >) -> SampleStream<Double> min(list<samplestream<double> >) -> SampleStream<Double> max(list<samplestream<double> >) -> SampleStream<Double> 31

32 4. Implementation avg(list<samplestream<double> >) -> SampleStream<Double> divide(samplestream<double>, SampleStream<Double>) -> SampleStream<Double> samplespertime(duration, SampleStream<T>) -> SampleStream<Double> where duration is in ms filter(predicate, SampleStream<T>) -> SampleStream<T> 4.4.2. EventTracker and ResourceUsageHistory Class The EventTracker class implements the TrackableResource interface. SampleStream entries are of the type Tuple<Long, T> whereas T can be for example a CdmiRequest or a double value. The offered keys (see 4.4.1) are NUM EVENTS TOTAL, NUM EVENTS PER MINUTE, NUM EVENTS PER SECOND. The EventTracker can be used to monitor events that are not measured in discrete values. In contrast, ResourceUsageHistory implements the TrackableResource interface by defining a sample as Tuple<Long, Double>, so the time discrete changes of numeric values, like the used bandwidth of a ObjectStorageServer can be monitored over time. ResourceUsageHistory instances only provide one key, which is defined as a parameter of the constructor. 4.4.3. Accounting The interface IUsageHistory defines methods that are being called every time a Cloud user sends a request. The Cloud instance creates an IUsageHistory instance for every user. The following methods are provided by the interface: void DownloadTraffic ( long s i z e ) ; void UploadTraffic ( long s i z e ) ; void query ( CdmiOperationVerbs verb ) ; void updatecurrentlyusedspace ( long s i z e ) ; void endaccountingperiod ( ) ; The abstract class UsageHistory implements these methods without calculating the costs which is done by other classes. Instead, all user s actions are being logged by using multiple instances of ResourceUsageHistory (debt history, upload and download traffic) and EventTracker (one for every query type). Two subclasses are SimplePricing, which multiplies a cost factor to traffic and used storage and AmazonUS which provides a cost model that is equivalent to 2.5.2. 4.4.4. Report Generation ReportGenerator s take references to objects that provide methods of the TrackableResource interface and extract all sample streams for all available keys. These streams are processed (round up, magnitudes are changed,...) and then written to a file, either as CVS (CVSGenerator, see listing 6.2 and 6.3 in appendix) or as LaTex source to generate graphs (GraphGenerator, see appendix B). 4.5. Scenario Generation In order to make simulations significant, scenarios need to include many different requests in order to benchmark the performance of the Cloud under heavy load. To fulfill this requirement, scenarios can be generated automatically and stored as XML files (simulations 32

4.5. Scenario Generation 33 are repeatable on these input data). The class UsageSequenceGenerator creates one valid 15 sequence of UserRequest instances. Three statistical distributions are used, to make the UserRequest realistic: filesizedistribution determines the size of objects that are created (1KB.. 1GB uniform) intervaldistribution determines the idle time between two requests - (5ms.. 5min uniform) downloadprobability determines whether to download an object or not. If sampled value exceeds 0.5, a download is started. Otherwise, an upload is initialized - (0.. 0.6 uniform) All distributions can be exchanged by other distributions 16. With the current version only one container is created at the beginning of the scenario, but further modifications for a more complex UsageSequence can be done. SequenceFileGenerator provides a command line interface (CLI) to create XML files of UsageSequence s (see listing 6.8 and 6.9 in the appendix). Generated sequences are put together with matching SLAs 17. The exact configuration of this class is explained in section Simulation Scenarios. An example configuration can be found in 6.7 in the appendix. 15 valid - containers are only uploaded into containers that have been created before, files are only downloaded, if they have been created before. 16 CloudSim provides classes for exponential-, gamma-, lognormal-, pareto-, weibull- and zipf- distributions 17 The SLAs contain requirements to the Cloud, so enough storage capacity will be provided to fulfill the sequence of requests. But this value can be disturbed by a random value, because normally users do not know how much data they will be storing in the future. 33

5. Evaluation This chapter describes the experiments that were carried out using the previously presented simulation environment and explains the observed results. 5.1. Simulation Setup All Experiments run on the very same input data, which was created only once and stored in files, to make the experiments repeatable. Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode) was used as virtual machine. Experiments were done with three different amount of request sequences (UsageSequence, see 4.3.2) - 50 and 500 sequences. To create ambiguous requests, two different sequence models were used: On the one hand a Cloud access pattern was used, which models the storage of scientific backups 1 : Large amount of data is only written, but no reads follow. UsageSequence s produce 1 to 100 GB traffic and objects can be up to 100 GB. Sizes of uploaded objects are equally distributed as seen in figure 5.1. Accesses follow in bursts of five PUT requests, followed by a pause of 5 to 10 minutes. Every scientific UsageSequence requires a Cloud with no restrictions on the size of a container. The minimal accepted limit for the object size is determined individually for every sequence. In real life applications, users may not know how much data they want to store exactly, but estimations are possible. Thus the required SLA (required storage space and minimal accepted object size limit) are disturbed by a random value that can be up to 25% of the actual value (requested = actual ± actual 25 100 ). Furthermore, the capabilities for creating and deleting containers are requested as well. The ranking of multiple SLA matches for the scientific access pattern are as following: score = 1 costsp erstoredgb + 1 costsp eru ploadedgb Different Clouds are modeled with a simple pricing policy: Billing is modeled by a single, constant pricing factor that is multiplied to the amount of uploaded, downloaded and stored data. This is required, because the SLA modeling allows only simple pricing models at the moment (see 4.3.3). On the other hand there are access patterns that model a more general way of use of the Cloud 2. Objects are not only uploaded, but downloaded as well. The probability for a 1 named scientific access pattern or scientific sequence from now on. 2 named normal access pattern or normal sequence from now on. 34

5.2. Simulation Scenarios 35 Figure 5.1.: Distribution of the Size of single Objects in all scientific Access Patterns PUT operation is higher than for a GET operation, as shown in 5.3 Objects are up to 1 GB big (equally distributed, see 5.2), the total traffic of all sequences is determined by a Gamma distribution (α = 3, β = 2). As for the scientific access pattern, this access pattern model requires the capabilities for deleting and creating containers and requests a minimal available capacity, which is distributed as described above. The ranking of multiple SLA matches are as following: score = 1 costsp erstoredgb + 1 costsp eruploadedgb + 1 costsp erdownloadedgb Both access patterns combined produce a spectrum of sequences which forms a variating traffic from 1 KB to 100 GB. The distribution of the sizes is shown in figure 5.4 5.2. Simulation Scenarios 5.2.1. Single Cloud Scenario This experiment includes one Cloud provider, which was named Amazon AWS 3. The offered service provides a total storage capacity of 72 TB. Because of the three-replica policy, only 24 TB can be offered to clients. 5.2.2. Multi-Cloud Scenario To see if the StorageMetaBroker works correctly, a multi-cloud scenario was investigated. Three different Cloud providers were created (see table 5.1): In addition to the Amazon AWS Cloud, a second third-party provider is available who offers cheaper storage than Amazon AWS, but without support for object replicas. Therefore the costs per downloaded gigabyte is much higher (ten times higher, compared to Amazon AWS). The third Cloud provider is an in-house setup which may be based on hardware that was acquired and is unused at the moment. For legacy reasons the limit of the size of each object is set to 16 GB, but the storage prices are very low, because existing LAN infrastructure can be and there is no interest in generating financial profit by providing the hardware. 3 Specifications of the Cloud are note based on actual characteristics of the Service that is offered by Amazon. 35

36 5. Evaluation Figure 5.2.: Distribution of the Size of single Objects in all normal Access Patterns Figure 5.3.: Number of Request Types in all normal Access Patterns 36

5.3. Simulation Results 37 Figure 5.4.: Distribution of Traffic per Sequence (both Types) Table 5.1. Cloud Configurations compared Amazon AWS SCC intra Swift Cloud max. allowed Object size unlimited 16 GB unlimited number of servers 6 1 4 disks per server 6 3 4 write rate 156 MB/s 64 MB/s 156 MB/s read rate capacity read latency 156 MB/s 2 TB 8.5 ms 156 MB/s 1 TB 9 ms 156 MB/s 2 TB 8.5 ms write latency 9.5 ms 11 ms 9.5 ms total physical capacity 72 TB 3 TB 32 TB number of replica 3 3 1 stored GB/billing period Dollar per uploaded GB downloaded GB 0.05$ 0.0002$ 0.01$ 0.04$ 0.0002$ 0.0002$ 0.01$ 0.0002$ 0.1$ 5.3. Simulation Results 5.3.1. Used Storage and SLA fulfillments We conducted the above described experiments many times and each time we competed the mean values. A mixture of both sequence types was used (out of 5000 sequences, there are 2486 scientific and 2514 normal sequences). First, we observed that both experiments (single and multi-cloud) with 50 and 500 sequences succeeded 4, but the experiment with 5000 mixed sequences can not be executed on the single-cloud environment completely: a total of 4150 sequences are declined, because the storage capacity is exhausted. The only purpose of the StorageMetaBroker in the single Cloud experiment is to check if the Cloud can handle the required storage space. The broker can not choose between different Cloud providers, because only one is available. But the broker detects 4150 sequences which are impossible to be fulfilled, because no more storage is available. These sequences will not be dispatched on any StorageCloudBroker instance, because no Cloud offers SLAs that fulfill the requested conditions. These sequences are declared as declined. 4 succeed - no sequence is declined. 37

38 5. Evaluation Figure 5.5.: Succeeded Requests and SLA Violations in single Cloud Experiment with 5000 Sequences Figure 5.5 visualizes a subset of the measured number of succeeded requests on the single Cloud (blue), the number of failed requests (grey) and the number of declined sequences (orange) which starts to rise shortly before simulated 28000 minutes 5. On the very same time, the number of succeeded requests stops to rise. In total 15 requests fail in the single Cloud experiment with 5000 mixed sequences. Three reasons (or any combination of them) explain this behavior: Inaccurate SLA: UsageSequence requests less capacity than it will consume. Cloud storage may be used by 99.99%, but approves the request, because the requested size fits into the remaining storage. Unsatisfiable policies: One reason could be the policy, that forces the storage controller to locate StorageBlob s of one object not to be on the same disk. Maybe there is enough physical storage available, but it is not distributed as required. Concurrent access: Clouds use the currently available storage, when responding to a cloud discovery request. Requests do not allocate any memory. Two storage capacity requests can be met, but one of them fills all of the remaining storage, so the other request can not be fulfilled. To investigate the decisions of the StorageMetaBroker in a multi-cloud environment, one can observe the amount of used storage in each Cloud over time. For this purpose, the simulation can output streams of samples to CSV files (see 4.4.4), which are then plotted as seen in figure 5.6. Each dot in the plot represents one sample, whereas only samples are displayed that are at least one gigabyte apart from each other. For the multi-cloud experiment with 50 mixed input sequences, one can see in figure 5.6, that the Amazon AWS Cloud was never chosen by the StorageMetaBroker, because all requests could be fulfilled with the other two providers and the meta broker chooses the cheapest available Cloud (see table 5.2). The used storage capacity on the Swift provider is much higher compared to the SCC-intra, because of the restrictions that are demonstrated in the SLA of the requests: The minimum limit of the maximum object size suspends the access to the SCC-intra Cloud for some scientific UsageSequence s. 5 The number of declined sequences rises further which is not displayed in the plot. 38

5.3. Simulation Results 39 Figure 5.7.: Used Storage in multi-cloud Experiment, with 5000 sequences Figure 5.6.: Used Storage in multi-cloud Experiment with 50 Sequences The same experiment with 5000 mixed input sequences shows that the total number of accepted UsageSequence s is higher, compared to the single Cloud scenario: 2986 sequences were declined due to no SLA matches, compared to 4150 in the single Cloud experiment with the same number of input sequences (increase of 28.0%). In the multi-cloud experiment there is more total storage capacity available (increase of 32.7%). The number of SLA violations 6 increases by factor 7.6 (from 15 to 115), which can be explained by the fact, that there are more sequences accepted in the multi-cloud experiment, which gives more possibilities for SLA violations. Figure 5.7 (which is a plot of the first 2000 sequences of the 5000 multi-cloud experiment), visualizes the fact, that multiple SLA violations occur, when switching from one Cloud provider to another provider (capacities of one Cloud provider draw to close, so the broker 6 Number of Requests that fails, even though the Sequence SLA were accepted. 39

40 5. Evaluation Figure 5.8.: Total Cost per Experiment schedules future sequences to a provider that offers more storage space). As shown in figure 5.6, 5.7 and table 5.2, the StorageMetaBroker chooses the best suiting Cloud provider, wherever possible: If a sequence contains no object bigger than the limit of the SCC-intra Cloud, the broker will choose this provider, because it is the cheapest one. Sequences that contain bigger objects are scheduled on the Swift provider, because the price per uploaded and stored gigabyte results in the best score. As soon as the SCCintra Cloud has no capacities left over, sequences (that are not scientific) get scheduled onto the Amazon AWS Cloud,as broker calculates a higher score due to the price per downloaded gigabyte. Scientific sequences are still scheduled onto the Swift cloud, because the calculated score is the best for scientific sequences. Table 5.2. Calculated StorageMetaBroker Score per Provider and Access Pattern Access Pattern Amazon AWS SCC intra Swift Cloud default 5120 10025 5110 scientific 5020 5025 5100 5.3.2. Cost evaluation One of the most interesting points are the costs that are billed when the sequences are run on the different constellations. Figure 5.8 visualizes the fact that multi-cloud experiments generate less costs than the single Cloud experiment for the runs with 50 and 500 sequences 7 (60% less costs in the 500 sequence experiment). This can be explained by the capacity of the SCC-intra Cloud, which provides resources for a fraction of the costs of the Amazon AWS Cloud. But the total costs for the 5000 sequence experiment shows that the multi-cloud constellation can generate more costs, which is in the interest of the user, because far more sequences are processed, compared to the single Cloud experiment. However, the multi-cloud setup provides lower prices per accepted sequence in each experiment, as seen in table 5.3. 7 Both types of sequences combined 40

5.3. Simulation Results 41 Table 5.3. Average Price per accepted Sequence in Cents Number of input Sequences Single Cloud Multi Cloud 50 1.50 0.70 500 1.49 0.58 5000 1.49 1.28 5.3.3. Effect of the used Sequence Type All previously described experiments were done with a mixture of both types of sequences (see 5.1). This section describes the impact of the type of the chosen sequence. For this purpose, four experiments were conducted: Only scientific / normal input sequences, each on a single Cloud and a multi-cloud environment. As we submitted 250 sequences, no sequence was rejected in any experiment, because enough storage capacities could be provided by either one or all Clouds. Figure 5.9 and Table 5.4 prove that the multi-cloud variant generates less or the same costs as the single Cloud variant. The costs for single and multi-cloud for the scientific sequences is the same (rounded to cents), whereas the difference for normal sequences is 4.52$ (saving of factor 16). This can be explained by the fact, that the scientific sequences have a tighter restriction on the SLA: The minimal accepted value for the maximum object size depends on the largest object of the sequence, which can be between 1 and 100 GB. Thus, the majority of scientific sequences can not be scheduled for the SCC-intra Cloud, which is deciding for the costs for normal sequences. Figure 5.9.: Costs per Sequence Type with 250 Input sequences Table 5.4. Matrix of total Costs for 250 Input Sequences in Dollar Single Cloud Multi-Cloud Scientific 2.62 2.62 Normal 4.82 0.3 41

6. Conclusion and future Work Emerging Cloud computing and more STaaS technologies are developed and used more than ever. This work extends the existing Cloud simulation framework CloudSim by adding features to simulate STaaS providers and users. Policies and different hardware models as well as the network topology can be exchanged with low effort. The concurrent use of resources is modeled accurately in order to gain realistic simulation results. The interface between broker and Cloud is inspired and modeled using the standard CDMI. Detailed models for storage disks, servers and storage controller are provided and can be easily extended. A detailed monitoring allows users to investigate a broad spectrum of metrics from the inside of each simulated STaaS Cloud as well as from the user s perspective. Different access patterns can be modeled and used to generate sequences of requests. These sequences can be stored and read to/from file to provide random, but repeatable experiments. In addition, Different SLA can be modeled (static or via generator tools) and checked during execution of experiments, such as certain capabilities of a Cloud or some restrictions (as for example the physical location of the STaaS). A StorageMetaBroker enables simulations of multiple clouds, where different UsageSequence s can be dispatched on different Clouds, depending on the matched SLA prerequisites and a rank, which can be calculated based on the characteristics of each Cloud. With this feature, users are able to use multiple Clouds in a more differentiated manner to reduce the total costs and fulfill more requests, than it is possible with only a single Cloud (up to 60%). Costs can only be saved by users, if the SLA of the request sequences are not very strict. In the future, different blob location strategies will be implemented, like for example the ring mechanism in OpenStack s Swift, as well as more realistic pricing models for STaaS, that are not only linear functions as proposed in this work. 42

Bibliography [1] A. Azagury, V. Dreizin, M. Factor, E. Henis, D. Naor, N. Rinetzky, O. Rodeh, J. Satran, A. Tavory, and L. Yerushalmi. Towards an object store. pages 165 176, 2003. [2] Rodrigo N Calheiros, Rajiv Ranjan, Anton Beloglazov, César AF De Rose, and Rajkumar Buyya. Cloudsim: a toolkit for modeling and simulation of cloud computing environments and evaluation of resource provisioning algorithms. Software: Practice and Experience, 41(1):23 50, 2011. [3] Rodrigo N Calheiros, Rajiv Ranjan, César AF De Rose, and Rajkumar Buyya. Cloudsim: A novel framework for modeling and simulation of cloud computing infrastructures and services. arxiv preprint arxiv:0903.2525, 2009. [4] Cloud Data Management Interface (CDMI) Version 1.0.2. [5] Nandita Dukkipati, Tiziana Refice, Yuchung Cheng, Jerry Chu, Tom Herbert, Amit Agarwal, Arvind Jain, and Natalia Sutin. An argument for increasing tcp s initial congestion window. [6] Armando Escalante. Handbook of cloud computing. Springer, 2010. [7] M. Factor, K. Meth, D. Naor, O. Rodeh, and J. Satran. Object storage: the future building block for storage systems. pages 119 123, 2005. [8] OpenStack Foundation. Openstack open source cloud computing software, 2013. [Online; accessed 19-Aug-2013]. [9] U. O. Gagliardi. Trends in computing-system architecture. Proceedings of the IEEE, 63(6):858 862, 1975. [10] Amazon Inc. Amazon s3, cloud computing storage for files, images, videos, 2013. [Online; accessed 17-July-2013]. [11] Saiqin Long and Yuelong Zhao. A toolkit for modeling and simulating cloud data storage: An extension to cloudsim. pages 597 600, 2012. [12] A. Medina, A. Lakhina, I. Matta, and John Byers. Brite: an approach to universal topology generation. In Modeling, Analysis and Simulation of Computer and Telecommunication Systems, 2001. Proceedings. Ninth International Symposium on, pages 346 353, 2001. [13] Peter Mell and Timothy Grance. The nist definition of cloud computing (draft). NIST special publication, 800(145):7, 2011. [14] A. Schill and T. Springer. Verteilte Systeme: Grundlagen und Basistechnologien. Springer London, Limited, 2007. [15] Abraham Silberschatz, Peter Baer Galvin, and Greg Gagne. Operating System Concepts. Wiley Publishing, 8th edition, 2008. 43

Appendix A. Additional figures Figure A.1.: Average Response Time for mixed input Sequences Figure A.2.: Distribution of Request Types in scientific Sequences 45

46 Appendix B. Monitoring Outputs Listing 6.1: Beginning of Cloud dump file cloud c l o u d f r o n t. net / l o c a t e d in us c a p a b i l i t i e s : { c d m i e x p o r t i s c s i : f a l s e, l o c a t i o n : us, SLA cloud id : 2, c d m i d e l e t e c o n t a i n e r : true, cdmi export webdav : f a l s e, cdmi modify metadata : true, c d m i l i s t c h i l d r e n : true, max size : 9223372036854775807, cdmi read metadata : true, c d m i e x p o r t n f s : f a l s e, cdmi metadata maxitems : 1024, cdmi query : f a l s e, c d m i c r e a t e c o n t a i n e r : true, cdmi metadata maxsize : 4096, SLA p r o v i d e r name : amazon us, c d m i n o t i f i c a t i o n : f a l s e, number replicas : 3, cdmi queues : f a l s e, SLA download c o s t s : 0. 0 1, cdmi domains : f a l s e, SLA s t o r a g e c o s t s : 0. 0 5, SLA upload c o s t s : 0.0002} User 4 with root c o n t a i n e r IDIBAFFIBE ( 7 4. 8 5 6GB/74.856GB Container files (HJIEBCBHJH), s i z e 74.856GB (80376328271B), 1 c h i l d r e n, metadata { cdmi metadata maxitems : 1024, cdmi metadata maxsize : 4096, number replicas : 3, c r e a t e d a t : Wed Aug 14 1 5 : 1 7 : 3 8 CEST 2013, max size : 9223372036854775807, l a s t w r i t e : Wed Aug 14 1 5 : 1 7 : 3 8 CEST 2013} Object 3je4omvxcoimmc7v ( DJIGIFJIJJ ), s i z e 74.856GB (80376328119B), metadata : { cdmi metadata maxitems : 1024, cdmi metadata maxsize : 4096, c d m i s i z e : 80376327963, c r e a t e d a t : Wed Aug 14 1 5 : 1 7 : 3 8 CEST 2013, max size : 9223372036854775807, l a s t w r i t e : Wed Aug 14 1 5 : 1 7 : 3 8 CEST 2013} User 5 with root c o n t a i n e r DCFECIGFBF ( 9. 2 0 8GB/9.208GB Container files (DACEHCCDJH), s i z e 9.208GB (9887071026B), 1 c h i l d r e n, metadata { cdmi metadata maxitems : 1024, cdmi metadata maxsize : 4096, number replicas : 3, c r e a t e d a t : Wed Aug 14 1 5 : 1 7 : 3 8 CEST 2013, max size : 9223372036854775807, l a s t w r i t e : Wed Aug 14 1 5 : 1 7 : 3 8 CEST 2013} Object t17tetzlxv0jcmgr1 (IGGCGFIFHB), s i z e 9.208GB (9887070874B), metadata : { cdmi metadata maxitems : 1024, cdmi metadata maxsize : 4096, c d m i s i z e : 9887070719, c r e a t e d a t : Wed Aug 14 1 5 : 1 7 : 3 8 CEST 2013, max size : 9223372036854775807, l a s t w r i t e : Wed Aug 14 1 5 : 1 7 : 3 8 CEST 2013} Listing 6.2: Request Stats s t a r t e d verb s i z e duration delay 1376486810204 / f i l e s /k7 f 4 q 3 9 9 8 l z 7 9 n l mok (PUT o b j e c t by user 58) 204194753 14 0 1376486811743 cloud c h a r a c t e r i s t i c s d i s c o v e r y r e q u e s t by user 61 0 0 0 1376486816417 / f i l e s / ilngu7awiw (PUT o b j e c t by user 58) 402434514 16 0 1376486820986 / f i l e s / ki59mvpczeppr (PUT o b j e c t by user 58) 295521742 15 0 1376486834713 / f i l e s / tr87ulnlruuw2 (PUT o b j e c t by user 58) 944811994 25 0 1376486849599 n u l l f i l e s i l n g u 7 a w i w (GET Object by user 58) 402434660 11 0 1376486855395 / f i l e s / n71r7w8d4tbvhodqx (PUT o b j e c t by user 58) 503134743 18 0 1376486875537 n u l l f i l e s k i 5 9 m v p c z e p p r (GET Object by user 58) 295521888 10 0 1376486883705 / f i l e s / zlh8zw00ez7b5cz61cev (PUT o b j e c t by user 58) 411649824 17 0 46

B. Monitoring Outputs 47 1376486887089 n u l l f i l e s r 2 m 8 4 9 2 e t y i n l 3 6 7 l 0 7 (GET Object by user 58) 37739824 9 0 1376486902788 n u l l f i l e s r 2 m 8 4 9 2 e t y i n l 3 6 7 l 0 7 (GET Object by user 58) 37739824 9 0 1376486916596 cloud c h a r a c t e r i s t i c s d i s c o v e r y r e q u e s t by user 64 0 0 0 1376486916596 / f i l e s / (PUT Container, requested by 64) 0 0 0 Listing 6.3: SLA Stats time ( acked r e q u e s t s in ms) ; time ( acked r e q u e s t s ) ; acked r e q u e s t s ; time ( f a i l e d r e q u e s t s in ms) ; time ( f a i l e d r e q u e s t s ) ; f a i l e d r e q u e s t s ; time ( succ r e q u e s t s in ms) ; time ( succ r e q u e s t s ) ; succ r e q u e s t s ; time ( d e c l i n e d r e q u e s t s in ms) ; time ( d e c l i n e d r e q u e s t s ) ; d e c l i n e d r e q u e s t s 1376485966631;08/14/2013 0 3 : 1 2 : 4 6 : 6 3 1 ; 0. 0 ; 1 3 7 7 0 6 7 2 9 2 0 6 0 ; 0 8 / 2 1 / 2 0 1 3 0 8 : 4 1 : 3 2 : 6 0 ; 0. 0 ; 1 3 7 6 4 8 5 9 6 6 6 3 1 ; 0 8 / 1 4 / 2 0 1 3 0 3 : 1 2 : 4 6 : 6 3 1 ; 1. 0 ; ; ; 1376485966631;08/14/2013 0 3 : 1 2 : 4 6 : 6 3 1 ; 5. 0 ; ; ; ; 1 3 7 6 4 8 5 9 6 7 1 3 1 ; 0 8 / 1 4 / 2 0 1 3 0 3 : 1 2 : 4 7 : 1 3 1 ; 6. 0 ; ; ; 1376485966631;08/14/2013 0 3 : 1 2 : 4 6 : 6 3 1 ; 1 0. 0 ; ; ; ; 1 3 7 6 4 8 5 9 6 7 1 3 1 ; 0 8 / 1 4 / 2 0 1 3 0 3 : 1 2 : 4 7 : 1 3 1 ; 1 1. 0 ; ; ; 1376485966631;08/14/2013 0 3 : 1 2 : 4 6 : 6 3 1 ; 1 5. 0 ; ; ; ; 1 3 7 6 4 8 5 9 6 7 1 3 1 ; 0 8 / 1 4 / 2 0 1 3 0 3 : 1 2 : 4 7 : 1 3 1 ; 1 6. 0 ; ; ; 1376485966631;08/14/2013 0 3 : 1 2 : 4 6 : 6 3 1 ; 2 0. 0 ; ; ; ; 1 3 7 6 4 8 5 9 6 7 1 3 1 ; 0 8 / 1 4 / 2 0 1 3 0 3 : 1 2 : 4 7 : 1 3 1 ; 2 1. 0 ; ; ; 1376485966631;08/14/2013 0 3 : 1 2 : 4 6 : 6 3 1 ; 2 5. 0 ; ; ; ; 1 3 7 6 4 8 5 9 6 7 1 3 1 ; 0 8 / 1 4 / 2 0 1 3 0 3 : 1 2 : 4 7 : 1 3 1 ; 2 6. 0 ; ; ; 1376485966631;08/14/2013 0 3 : 1 2 : 4 6 : 6 3 1 ; 3 0. 0 ; ; ; ; 1 3 7 6 4 8 5 9 6 7 1 3 1 ; 0 8 / 1 4 / 2 0 1 3 0 3 : 1 2 : 4 7 : 1 3 1 ; 3 1. 0 ; ; ; 1376485966631;08/14/2013 0 3 : 1 2 : 4 6 : 6 3 1 ; 3 5. 0 ; ; ; ; 1 3 7 6 4 8 5 9 6 7 1 3 1 ; 0 8 / 1 4 / 2 0 1 3 0 3 : 1 2 : 4 7 : 1 3 1 ; 3 6. 0 ; ; ; 1376485966631;08/14/2013 0 3 : 1 2 : 4 6 : 6 3 1 ; 4 0. 0 ; ; ; ; 1 3 7 6 4 8 5 9 6 7 1 3 1 ; 0 8 / 1 4 / 2 0 1 3 0 3 : 1 2 : 4 7 : 1 3 1 ; 4 1. 0 ; ; ; 1376485966631;08/14/2013 0 3 : 1 2 : 4 6 : 6 3 1 ; 4 5. 0 ; ; ; ; 1 3 7 6 4 8 5 9 6 7 1 3 1 ; 0 8 / 1 4 / 2 0 1 3 0 3 : 1 2 : 4 7 : 1 3 1 ; 4 6. 0 ; ; ; 47

48 Appendix Figure B.3.: Plot of Monitored Number of Requests in Cloud Figure B.4.: Plot of Total physical used Storage Capacity in Cloud 48

B. Monitoring Outputs 49 Listing 6.4: Sequence Log INFO DiscoveryProcess sequsagesequence5 meta5 08/26/2013 0 5 : 2 5 : 5 9 : 6 4 2 broker 26 responded, 0 to go. Received c h a r a c t e r i s t i c s : { c d m i e x p o r t i s c s i : f a l s e, SLA minimum bandwidth : 0. 0, l o c a t i o n : us, SLA cloud id : 4, c d m i d e l e t e c o n t a i n e r : true, cdmi export webdav : f a l s e, SLA a v a i l a b l e c a p a c i t y : 34896044298891, cdmi modify metadata : true, c d m i l i s t c h i l d r e n : true, max size : 9223372036854775807, cdmi read metadata : true, c d m i e x p o r t n f s : f a l s e, cdmi metadata maxitems : 1024, cdmi metadata maxsize : 4096, c d m i c r e a t e c o n t a i n e r : true, cdmi query : f a l s e, number replicas : 1, c d m i n o t i f i c a t i o n : f a l s e, SLA p r o v i d e r name : s w i f t cloud, cdmi queues : f a l s e, SLA download c o s t s : 0. 1, SLA s t o r a g e c o s t s : 0. 0 1, cdmi domains : f a l s e, SLA maximum l a t e n c y : 0. 0, SLA upload c o s t s : 0.0002} INFO DiscoveryProcess sequsagesequence5 meta5 08/26/2013 0 5 : 2 5 : 5 9 : 6 4 2 d e l e g a t e d to cloud s w i f t cloud FINE StorageCloudBroker 5 26 4 08/26/2013 0 5 : 2 5 : 5 9 : 6 4 2 enqueue user r e q u e s t edu. k i t. cloudsimstorage. cloudbroker. UserRequest@7686652a FINE StorageCloudBroker 5 26 4 08/26/2013 0 5 : 2 5 : 5 9 : 6 4 2 enqueue user r e q u e s t edu. k i t. cloudsimstorage. cloudbroker. UserRequest@715be530 FINE StorageCloudBroker 5 26 4 08/26/2013 0 5 : 2 5 : 5 9 : 6 4 2 enqueue user r e q u e s t edu. k i t. cloudsimstorage. cloudbroker. UserRequest@ 4823ec74 INFO StorageCloudBroker 5 26 4 08/26/2013 0 5 : 2 5 : 5 9 : 6 4 2 send user r e q u e s t to cloud : / f i l e s / (PUT Container, requested by 26) INFO StorageCloudBroker 5 26 4 08/26/2013 0 5 : 2 5 : 5 9 : 6 4 2 Response o f s u c c e s s f u l o p e r a t i o n : PutContainerResponse: created Container files (IBBEABIDIF), s i z e 0B (152B), 0 c h i l d r e n, metadata { cdmi metadata maxitems : 1 0 2 4, cdmi metadata maxsize : 4096, number replicas : 1, c r e a t e d a t : Mon Aug 26 1 7 : 2 4 : 2 1 CEST 2013, max size : 9223372036854775807, l a s t w r i t e : Mon Aug 26 1 7 : 2 4 : 2 1 CEST 2013} INFO StorageCloudBroker 5 26 4 08/26/2013 0 5 : 2 5 : 5 9 : 6 4 2 o p e r a t i o n eadb5479 d978 444e b5ad 7c55a08f6014 f i n i s h e d INFO StorageCloudBroker 5 26 4 08/26/2013 0 5 : 2 5 : 5 9 : 6 4 2 waited f o r t h i s o p e r a t i o n to f i n i s h continue with e x e c u t i o n INFO StorageCloudBroker 5 26 4 08/26/2013 0 5 : 2 5 : 5 9 : 6 4 2 send user r e q u e s t to cloud : / f i l e s / g87asy5fh9pwc3ravuv1 (PUT o b j e c t by user 26) INFO StorageCloudBroker 5 26 4 08/26/2013 0 5 : 2 6 : 0 0 : 4 6 Response o f s u c c e s s f u l o p e r a t i o n : PutObjectResponse: created Object Object g87asy5fh9pwc3ravuv1 (IBAJHIDABC), s i z e 60.213GB (64653152148B), metadata : { cdmi metadata maxitems : 1024, cdmi metadata maxsize : 4096, c d m i s i z e : 64653151992, c r e a t e d a t : Mon Aug 26 1 7 : 2 4 : 2 1 CEST 2013, max size : 9223372036854775807, l a s t w r i t e : Mon Aug 26 1 7 : 2 4 : 2 1 CEST 2013} INFO StorageCloudBroker 5 26 4 08/26/2013 0 5 : 2 6 : 0 0 : 4 6 o p e r a t i o n ecb9db80 0931 4b37 b40a 0463db17aba6 f i n i s h e d INFO StorageCloudBroker 5 26 4 08/26/2013 0 5 : 2 6 : 0 0 : 4 6 pause f o r 360000ms FINE StorageCloudBroker 5 26 4 08/26/2013 0 5 : 3 2 : 0 0 : 4 6 user r e q u e s t queue empty q u i t broker Listing 6.5: Cloud Log INFO c l o u d L o g g g e r s w i f t cloud 08/26/2013 0 5 : 2 4 : 3 0 : 3 9 2 cloud 49

50 Appendix c h a r a c t e r i s t i c s d i s c o v e r y r e q u e s t by user 8 > o p e r a t i o n 5901ab1d -58f8-436f- b01c - a0272daf3f40 INFO c l o u d L o g g g e r s w i f t cloud 08/26/2013 0 5 : 2 4 : 3 0 : 3 9 2 o p e r a t i o n 5901 ab1d 58f8 436f b01c a0272daf3f40 succeeds FINE c l o u d L o g g g e r s w i f t cloud 08/26/2013 0 5 : 2 4 : 3 0 : 3 9 2 Operation 5901ab1d -58f8-436f-b01c -a0272daf3f40 succeeded ( c a l l b a c k ) INFO c l o u d L o g g g e r s w i f t cloud 08/26/2013 0 5 : 2 4 : 3 0 : 3 9 2 / f i l e s / (PUT Container, r e q u e s ted by 8) > o p e r a t i o n 160ecf1b -b22e -428bbf9a -2883 a36e61fa INFO c l o u d L o g g g e r s w i f t cloud 08/26/2013 0 5 : 2 4 : 3 0 : 3 9 2 Create user with ID 8 FINE c l o u d L o g g g e r s w i f t cloud 08/26/2013 0 5 : 2 4 : 3 0 : 3 9 2 a s s i g n e d the metadata { cdmi metadata maxitems : 1024, cdmi metadata maxsize : 4096, number replicas : 1, c r e a t e d a t : Mon Aug 26 1 7 : 2 4 : 2 1 CEST 2013, max size : 9223372036854775807, l a s t w r i t e : Mon Aug 26 1 7 : 2 4 : 2 1 CEST 2013} FINE c l o u d L o g g g e r s w i f t cloud 08/26/2013 0 5 : 2 4 : 3 0 : 3 9 2 a s s i g n e d the CDMI ID CJDEBAJEBC INFO c l o u d L o g g g e r s w i f t cloud 08/26/2013 0 5 : 2 4 : 3 0 : 3 9 2 o p e r a t i o n 160 ecf1b b22e 428b bf9a 2883 a36e61fa succeeds FINE c l o u d L o g g g e r s w i f t cloud 08/26/2013 0 5 : 2 4 : 3 0 : 3 9 2 Operation 160ecf1b -b22e -428b-bf9a -2883 a36e61fa succeeded ( c a l l b a c k ) INFO c l o u d L o g g g e r s w i f t cloud 08/26/2013 0 5 : 2 4 : 3 0 : 3 9 2 / f i l e s /3 je4omvxcoimmc7v (PUT o b j e c t by user 8) > o p e r a t i o n e20f46f9-1067-49f1-ab98-1c022f54829b C. Input Files Listing 6.6: Input Sequences Stats id model maxobjsize maxobjsize in SLA r e q i r e d S p a c e requiredspace in SLA i n i t i a l delay 0 1 9887070719 9832871767 9887070719 10143590083 2444 1 1 44621724313 46077870305 44621724313 47936921811 6357 2 1 46264314663 44973950815 46264314663 43487424632 9546 3 1 107178351503 117873997799 107178351503 117327511722 16005 4 0 688779669 1 1806019203 1685012187 24500 5 1 64653151992 69605959288 64653151992 65579218673 30398 6 0 1009614518 1 7512922954 6863084366 39050 7 0 1039393485 1 5665286077 5927253093 44303 Listing 6.7: Cloud Definition XML <cloudmodel name="scc -intra" l o c a t i o n="us" rooturl="intra.scc.kit.edu/" > <c h a r a c t e r i s t i c s> <metadata> <entry> <s t r i n g>c d m i e x p o r t i s c s i</ s t r i n g> 50

C. Input Files 51 <s t r i n g>f a l s e</ s t r i n g> </ entry> <entry> <s t r i n g>l o c a t i o n</ s t r i n g> <s t r i n g>us</ s t r i n g> </ entry> <entry> <s t r i n g>number replicas</ s t r i n g> <s t r i n g>3</ s t r i n g> </ entry> <entry> <s t r i n g>c d m i d e l e t e c o n t a i n e r</ s t r i n g> <s t r i n g>true</ s t r i n g> </ entry> <entry> <s t r i n g>cdmi export webdav</ s t r i n g> <s t r i n g>f a l s e</ s t r i n g> </ entry> <entry> <s t r i n g>cdmi modify metadata</ s t r i n g> <s t r i n g>true</ s t r i n g> </ entry> <entry> <s t r i n g>c d m i l i s t c h i l d r e n</ s t r i n g> <s t r i n g>true</ s t r i n g> </ entry> <entry> <s t r i n g>max size</ s t r i n g> <s t r i n g>17179869184</ s t r i n g> </ entry> <entry> <s t r i n g>cdmi read metadata</ s t r i n g> <s t r i n g>true</ s t r i n g> </ entry> <entry> <s t r i n g>c d m i e x p o r t n f s</ s t r i n g> <s t r i n g>f a l s e</ s t r i n g> </ entry> <entry> <s t r i n g>cdmi metadata maxitems</ s t r i n g> <s t r i n g>1024</ s t r i n g> </ entry> <entry> <s t r i n g>cdmi metadata maxsize</ s t r i n g> <s t r i n g>4096</ s t r i n g> </ entry> <entry> <s t r i n g>c d m i c r e a t e c o n t a i n e r</ s t r i n g> <s t r i n g>true</ s t r i n g> </ entry> <entry> <s t r i n g>cdmi query</ s t r i n g> <s t r i n g>f a l s e</ s t r i n g> </ entry> <entry> <s t r i n g>c d m i n o t i f i c a t i o n</ s t r i n g> <s t r i n g>f a l s e</ s t r i n g> </ entry> <entry> 51

52 Appendix <s t r i n g>cdmi queues</ s t r i n g> <s t r i n g>f a l s e</ s t r i n g> </ entry> <entry> <s t r i n g>sla download c o s t s</ s t r i n g> <s t r i n g>0.0002</ s t r i n g> </ entry> <entry> <s t r i n g>sla s t o r a g e c o s t s</ s t r i n g> <s t r i n g>0.04</ s t r i n g> </ entry> <entry> <s t r i n g>cdmi domains</ s t r i n g> <s t r i n g>f a l s e</ s t r i n g> </ entry> <entry> <s t r i n g>sla upload c o s t s</ s t r i n g> <s t r i n g>0.0002</ s t r i n g> </ entry> </ metadata> </ c h a r a c t e r i s t i c s> <p r i c i n g P o l i c y c l a s s="edu.kit.cloudsimstorage.pricing.simplepricing" > <centsperuploadedgb>0. 0 0 0 2</ centsperuploadedgb> <centsperdownloadedgb>0. 0 0 0 2</ centsperdownloadedgb> <centsperstoredgbperperiod>0.04</ centsperstoredgbperperiod> </ p r i c i n g P o l i c y> <s e r v e r s c l a s s="java.util.arraylist"> <objectstorageservermodel> <name>s e r v e r 0</name> <i o L i m i t a t i o n s c l a s s="edu.kit.cloudsimstorage.storagemodel. resourceutilization. FirstFitAllocation" maxrate=" 1.34217728 E11"/> <d i s k s c l a s s="java.util.arraylist"> <objectstoragediskmodel> <d r i v e c l a s s="edu.kit.cloudsimstorage.cloudfactory. harddrives. GenericDrive" name="/ dev/ sda0"> <c a p a c i t y>1099511627776</ c a p a c i t y> <r e s e r v e r d S p a c e>0</ r e s e r v e r d S p a c e> <usedspace>0</ usedspace> <readrate>1.63577856e8</ readrate> <writerate>6.7108864e7</ writerate> <readlatency>9. 0</ readlatency> <writelatency>11.5</ writelatency> <i o L i m i t s c l a s s="edu.kit.cloudsimstorage.storagemodel. resourceutilization. FirstFitAllocation" maxrate= " 1.63577856 E11"/> </ d r i v e> <name>/ dev/ sda0</name> </ objectstoragediskmodel> <objectstoragediskmodel> <d r i v e c l a s s="edu.kit.cloudsimstorage.cloudfactory. harddrives. GenericDrive" name="/ dev/ sda1"> <c a p a c i t y>1099511627776</ c a p a c i t y> <r e s e r v e r d S p a c e>0</ r e s e r v e r d S p a c e> <usedspace>0</ usedspace> <readrate>1.63577856e8</ readrate> <writerate>6.7108864e7</ writerate> <readlatency>9. 0</ readlatency> 52

C. Input Files 53 <writelatency>11.5</ writelatency> <i o L i m i t s c l a s s="edu.kit.cloudsimstorage.storagemodel. resourceutilization. FirstFitAllocation" maxrate= " 1.63577856 E11"/> </ d r i v e> <name>/ dev/ sda1</name> </ objectstoragediskmodel> <objectstoragediskmodel> <d r i v e c l a s s="edu.kit.cloudsimstorage.cloudfactory. harddrives. GenericDrive" name="/ dev/ sda2"> <c a p a c i t y>1099511627776</ c a p a c i t y> <r e s e r v e r d S p a c e>0</ r e s e r v e r d S p a c e> <usedspace>0</ usedspace> <readrate>1.63577856e8</ readrate> <writerate>6.7108864e7</ writerate> <readlatency>9. 0</ readlatency> <writelatency>11.5</ writelatency> <i o L i m i t s c l a s s="edu.kit.cloudsimstorage.storagemodel. resourceutilization. FirstFitAllocation" maxrate= " 1.63577856 E11"/> </ d r i v e> <name>/ dev/ sda2</name> </ objectstoragediskmodel> </ d i s k s> </ objectstorageservermodel> </ s e r v e r s> <cloudiolimits c l a s s="edu.kit.cloudsimstorage.storagemodel. resourceutilization. UnlimitedResource"/> </ cloudmodel> Listing 6.8: XML Representation of SLA of normal sequence <SLA> <requirements c l a s s="edu.kit.cloudsimstorage.objectstorageslas. SLARequirementAND"> <a c l a s s=" edu. kit. cloudsimstorage. ObjectStorageSLAs. SLARequirementAND"> <a c l a s s=" edu. kit. cloudsimstorage. ObjectStorageSLAs. SupportsCapability" d e s c r i p t i o n="cdmi_create_container! " c a p a b i l i t y k e y="cdmi_create_container"/> <b c l a s s=" edu. kit. cloudsimstorage. ObjectStorageSLAs. SupportsCapability" d e s c r i p t i o n="cdmi_delete_container! " c a p a b i l i t y k e y="cdmi_delete_container"/> </a> <b c l a s s=" edu. kit. cloudsimstorage. ObjectStorageSLAs. MinimumCharactersisticValue" d e s c r i p t i o n="sla available capacity& gt;=1.685012187 E9" key=" SLA available capacity" min=" 1.685012187 E9"/> </ requirements> <r a t i n g s c l a s s="edu.kit.cloudsimstorage.objectstorageslas. RateByPrice"> <d e s c r i p t i o n>r a t e 1/ p r i c e f o r up and download and s t o r a g e c o s t s</ d e s c r i p t i o n> </ r a t i n g s> </SLA> Listing 6.9: XML of a scientific sequence <usagesequence sequenceid="0" b l o c k i n g="false" i d l e="2444"> <SLA> 53

54 Appendix <requirements c l a s s="edu.kit.cloudsimstorage.objectstorageslas. SLARequirementAND"> <a c l a s s=" edu. kit. cloudsimstorage. ObjectStorageSLAs. SLARequirementAND"> <a c l a s s=" edu. kit. cloudsimstorage. ObjectStorageSLAs. SLARequirementAND"> <a c l a s s=" edu. kit. cloudsimstorage. ObjectStorageSLAs. SLARequirementAND"> <a c l a s s=" edu. kit. cloudsimstorage. ObjectStorageSLAs. SupportsCapability" d e s c r i p t i o n=" cdmi_create_container!" c a p a b i l i t y k e y=" cdmi_create_container"/> <b c l a s s=" edu. kit. cloudsimstorage. ObjectStorageSLAs. SupportsCapability" d e s c r i p t i o n=" cdmi_delete_container!" c a p a b i l i t y k e y=" cdmi_delete_container"/> </a> <b c l a s s=" edu. kit. cloudsimstorage. ObjectStorageSLAs. SLARequirementOR"> <a c l a s s=" edu. kit. cloudsimstorage. ObjectStorageSLAs. DoesNotSupportCapability" d e s c r i p t i o n="does not support max_container_size" c a p a b i l i t y k e y=" max_container_size"/> <b c l a s s=" edu. kit. cloudsimstorage. ObjectStorageSLAs. MinimumCharactersisticValue" d e s c r i p t i o n=" max_container_size& gt;=9.223372036854776 E18" key= " max_container_size" min=" 9.223372036854776 E18"/> </b> </a> <b c l a s s=" edu. kit. cloudsimstorage. ObjectStorageSLAs. MinimumCharactersisticValue" d e s c r i p t i o n="sla available capacity& gt;=1.0143590083 E10" key=" SLA available capacity" min=" 1.0143590083 E10"/> </a> <b c l a s s=" edu. kit. cloudsimstorage. ObjectStorageSLAs. MinimumCharactersisticValue" d e s c r i p t i o n="max_size&gt ;=9.832871767 E9" key=" max_size" min=" 9.832871767 E9"/> </ requirements> <r a t i n g s c l a s s="edu.kit.cloudsimstorage.objectstorageslas. RakingSum"> <a c l a s s=" edu. kit. cloudsimstorage. ObjectStorageSLAs. RateCharacteristicsWithInverse" key=" SLA storage costs" d e f a u l t S c o r e="-infinity" s c a l e="1.0"> <d e s c r i p t i o n>lowest s t o r a g e c o s t s</ d e s c r i p t i o n> </a> <b c l a s s=" edu. kit. cloudsimstorage. ObjectStorageSLAs. RateCharacteristicsWithInverse" key=" SLA upload costs" d e f a u l t S c o r e="-infinity" s c a l e="1.0"> <d e s c r i p t i o n>lowest upload c o s t s</ d e s c r i p t i o n> </b> </ r a t i n g s> </SLA> <r e q u e s t s c l a s s="java.util.arraylist"> <userrequest delay="0" b l o c k i n g C a l l="true" opcode="1" s i z e="0"> <containername> f i l e s</ containername> <objectid>unknown</ objectid> <metadata> <metadata /> </ metadata> 54

C. Input Files 55 </ userrequest> <userrequest delay="0" b l o c k i n g C a l l="false" opcode="0" s i z e=" 9887070719"> <objectname>t 1 7 t e t z l x v 0 j c m g r 1</ objectname> <containername> f i l e s</ containername> <objectid>unknown</ objectid> <metadata> <metadata> <entry> <s t r i n g>c d m i s i z e</ s t r i n g> <s t r i n g>9887070719</ s t r i n g> </ entry> </ metadata> </ metadata> </ userrequest> <userrequest delay="0" b l o c k i n g C a l l="false" opcode="6" s i z e="0"> <objectid>unknown</ objectid> </ userrequest> </ r e q u e s t s> </ usagesequence> 55