StackAct: Performance Evaluation in an IaaS Cloud Multilayer.

Transcription

1 th International Symposium on Parallel and Distributed Computing StackAct: Performance Evaluation in an IaaS Cloud Multilayer. Gustavo C. Bruschi, Roberta Spolon, Leandro L. Pauro, Renata S. Lobato, Aleardo Manacero Jr São Paulo State University Department of Computing Bauru/São José do Rio Preto - Brazil gustavo@bruschi.net, roberta@fc.unesp.br, leapauro@hotmail.com, renata@ibilce.unesp.br, aleardo@ibilce.unesp.br Marcos A. Cavenaghi Humber Institute of Technology & Advanced Learning The Business School Toronto, ON Ontario, Canada marcos.cavenaghi@humber.ca Abstract Cloud Computing has become synonymous of quality, efficiency, and return of investment in Information Technology, creating new challenges for processing and data integrations. This paper presents the StackAct, a mechanism that allows performing monitoring and obtaining data on the consumption of computing resources of a solution in three layers using orchestrator IaaS Apache CloudStack, XenServer hypervisor and data storage on the NAS OpenFiler system. Performance tests were conducted using three different instances profile in a private cloud computing, allowing measuring CPU consumption, I/O disk and memory in three layers with different service offerings. The tests resulted in a comparison between the layers, it is possible to note the high consumption of disk in the data storage layer, in particular I/O data recording and the high memory consumption on the hypervisor layer, which is justified by the hypervisor itself to allocation of VMs being created and used in the process. Keywords StackAct, Cloud Computing, Virtualization, Performance, CloudStack, XenServer, Benchmark. I. INTRODUCTION Each year, more companies and users adhere to cloud computing, allowing for a significant decrease in investment on the purchase of hardware resources, software and corporate technology infrastructure. Cloud computing is a model for enabling ubiquitous access, convenient and under network via demand a shared and configurable pool of computing resources that can be quickly supplied and released with minimal effort management or interaction with the service provider [1]. Cloud computing distributes the funds in the form of three models of service levels, which are Infrastructure as a Service (IaaS), Software as a Service (SaaS) and Platform as a Service (PaaS). The IaaS model is defined, as the ability of the provider has to provide a processing infrastructure, storage, and other fundamental computing resources in a transparent manner in which the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. Virtualization technology [2] is the key that enables cloud computing, transcending the static view of a system as a piece of hardware, and creates the systems view in views as dynamic entities. Recently, the virtualization [3] allowed the collection of computing resources such that a single physical machine is able to function as a set of multiple logic VMs (Virtual Machines). A key benefit of VMs is the ability to host multiple operating system environments that are completely isolated from each other on the same physical machine. Another benefit is the ability to configure VMs to use different resource partitions on the same physical machine. The Server Virtualization [4] is a practical and fast way used in the creation of computational resources used in Cloud Computing. Its main feature is to use, manage and provide optimally the capacity of physical devices thus preventing its underutilization. The terms Virtualization and Cloud Computing are often confused and used to the same setting, which should be considered a mistake. Essentially virtualization is different Cloud Computing because the virtualization is achieved by software that handles hardware, while Cloud computing refers to a service that is conducted through this manipulation. This paper presents the StackAct, a mechanism that makes it possible to measure the consumption of various resources related to CPU, disk consumption (I/O) and memory, in a multilayer model IaaS, using the orchestrator Apache CloudStack, hypervisor XenServer in virtualization layer and the NAS open source Openfiler software in storage layer of VMs. In order to validate the mechanism, tests were performed in a laboratory environment, creating profiles 3 instances with different configurations of computer resources. A series of tests were carried out with up to 4 instances being manipulated simultaneously, allowing the evaluation of resource consumption (CPU, I/O and memory) in 3 layers involved with different workloads. This paper is organized as follows: Section II presents a review of works related to performance measurement in IaaS clouds. Section III to perform a bibliographic review on cloud computing and server virtualization. Section IV is presented to Stack Act, a mechanism developed to perform the monitoring and collection of data on the consumption of resources in an /16 $ IEEE DOI /ISPDC

2 IaaS Cloud multilayer. Section V presents the environment settings created to validate the StackAct. Section VI presents the results obtained in the tests, and finally the conclusions and contributions are presented in Section VII, as well as suggestions for future work. II. RELATED WORK In [5], the authors used the SIGAR framework (System Information Gatherer and Reporter), a tool that accesses information from the operating system to perform the tests that allowed measuring the consumption of CPU, memory, E/S and networking in an environment Apache CloudStack, with 4 different hypervisors: XenServer, VMware ESXi, KVM and Hyper-V. In [6], the authors present a performance analysis based on the collection of metrics via SNMP (Simple Network Management Protocol) of physical and virtual resources, including the main components of CloudStack (virtual machines, secondary storage, primary storage and server management ), and make these accessible and readable data, which is quite friendly to CloudStack users. In [7], the authors demonstrated the importance of understanding the need to benchmark in cloud platforms, in order to get an overview of the performance of platforms, focusing on the two most widely used open source: OpenStack and CloudStack. The author emphasized that the performance tests were focused strictly on the platforms, testing on the same hypervisor and resources available. III. APACHE CLOUDSTACK, XENSERVER AND OPENFILER In this work, it is proposed a private IaaS cloud architecture using three layers, as shown in Figure 1. The layer with higher level of abstraction to the administrator is the orchestrator. It uses Apache CloudStack. The XenServer hypervisor is used in the intermediate layer, which is responsible for managing the virtual machines in the cloud. In the storage layer, it was used the storage management system Openfiler NAS. Figure 1. Model of the Private IaaS with orchestration layer (L.1), hypervisor layer (L.2) and storage layer (L.3) A conceptual view of the Apache CloudStack architecture has other layers in addition to the ones addressed in this paper. The Cloud Infrastructure Managed [8] consists of seven layers, as can be seen in Figure 2: Figure 2. Apache CloudStack architecture. Region: is the largest available organizational unit within a CloudStack deployment. Availability Zones: typically corresponds to a single datacenter. Pods: often represents a single rack in datacenter. Cluster: composed of one or more hosts enabled hypervisor and a primary storage system. Hosts: provide the computing resources that run guest virtual machines. Primary Storage System: is associated with a cluster, and it stores virtual disks for all the VMs running on hosts in that cluster. Second Storage System: store templates, ISO images and disk volume snapshots. This paper addressed only the layers of primary storage, host and Apache CloudStack management system, because the representation of physical components that present the architecture, demonstrating greater impact on the performance of the solution. In general, the layers not covered by performance tests in this paper are organizational logical layers (such as layer Region) or are layers of little impact on the performance of the solution (such as secondary storage layer). According to [9], the Apache CloudStack is an open source cloud infrastructure system. The use of a portable and modular design criterion is compatible with existing infrastructure resources, with good usability. The modular design allows the user to customize the system's operation as required. In addition, the Apache CloudStack provides an API that is compatible with AWS EC2 and S3 for organizations that want to deploy hybrid clouds. Hardware resources are abstracted and separated in computing resources, storage and cyber sources by the

3 hypervisor, which are organized as virtual resources. The Apache CloudStack integrates and manages these virtual resources to build cloud platform, and provides transparent cloud services to users. It is responsible for mapping virtual resources to hardware resources and enables the safety isolation between users. The Apache CloudStack works with a variety of hypervisors, and only one cloud may contain multiple hypervisors of different implementations. The current version (4.6.0) Apache CloudStack supports: BareMetal (via IPMI), Hyper-V, KVM, LXC, vsphere, XenServer and Xen Project. The XenServer [10] is an open source virtualization platform, based on the Xen hypervisor Project. The hypervisor Xen Project is a BareMetal virtualization platform used by XenServer to deliver native application performance for workloads on an Intel x86 environment and AMD. XenServer has several features, allowing for example the live migration of virtual machines between hosts, hosts fault protection - enabling high availability in most critical environments, host power management, among others. According to [10] XenServer is executed directly on the server hardware without the need for an underlying operating system, which results in an efficient and scalable system. Abstracts the resources of the physical machine (such as hard drives, memory and CPU) allocating them to the virtual machines (VMs) that run on it. In regards to Openfiler [11] is an operating system that allows file storage by NFS (Network Attached Storage) and block-based storage area network. It was created by Xinit Systems and is based on rpath Linux distribution. It is free software, licensed under the GNU General Public License version 2. It is possible to create network shares on file level and distribute through protocols like CIFS (Common Internet File System), NFS e HTTP (Hypertext Transfer Protocol), or support to iscsi (Internet Small Computer System Interface) and FC (Fiber Channel). IV. STACKACT The StackAct allows performing the monitoring and collection of data on the consumption of various computing resources, such as CPU, memory, disk, processes, among others. Developed to enable monitoring of the components of a computing cloud up to three layers suggested in this work by: orchestrator Layer, using the Apache CloudStack, the hypervisor layer using XenServer, and finally the data storage layer using OpenFiler. As shown in Figure 3, the sequence of actions performed by the engine comprises the following steps: Definition of service offer, setting the number of concurrent instances, the target environment definition, the definition of routine to be executed, begin to SAR collection, routine performed in CloudMonkey and finally filtering of the data received in the SAR. Figure 3. Sequence performed by StackAct. The StackAct was developed in Shell Script using CloudMonkey [12], which is a tool that is distributed by the CloudStack community, command line interface (CLI) tool for CloudStack written in Python. It can be used both as an interactive shell and as a command-line tool that simplifies configuration and management of Apache CloudStack. The CloudMonkey allows, for example, the creation and removal of new instances, Zone, Pod and Cluster configuration, profile management, etc. Just about everything that can be configured using the CloudStack graphical user interface (GUI), one can configure using the CloudMonkey command line. Besides CloudMonkey, it was used the SAR tool (System Activity Reporter) to collect resource consumption. SAR [13] is a set of tools, originally developed for Solaris and later ported to Linux. It carries out the monitoring of system resources consumption such as CPU, memory and swap, I/O read and write, System Load Average, Network Activity, and Process Creation Activity. The process created to measure the performance realized in four phases, all of which are initially created in the Apache CloudStack via CloudMonkey, as shown in Figure 3: (1) instance creation and initialization, (2) instance snapshot creation, (3) instance shutdown and (4) instance exclusion. Figure 4. Sequence of events held in the script for the benchmark. V. EXPERIMENTS SETUP To validate the StackAct, was developed an environment with five physical servers, as shown in Figure 5: the first (CSGL01) is a server, which was installed OS Linux CentOS 6.6 and Apache CloudStack The second and third servers (CSGL02 and CSGL03) have the same physical configuration of CSGL01, except for the amount of memory, which is

4 doubled on these two servers. XenServer hypervisor were installed. A cluster between the two hosts has been created, implementing the primary and secondary storage for Apache CloudStack, two servers were used, with the same characteristics from the others, which was installed Openfiler OS 2.99 to store the files of virtual machines, OS images, snapshot, etc. To share folders on the network, it has been set using NFS (Network File System), with unrestricted access and public shared folders on the network. Figure 5. Environment created for preparation of experiments. The StackAct was executed in server CSGL01 (CloudStack), and only modified the session collects of resources consumption on the remote server when the goal was to measure the performance of CSGL02 and CSGL04 servers (XenServer and Openfiler), defined in the initial scope for performance evaluation. To test execution and the ability to measure performance using different loads, three templates with different sizes of allocated resources were created in the Apache CloudStack, as shown in Table 1. The sizes of instances were limited by available environment for testing, where physical servers had resource constraints. Table 1. Resources available in the templates used in the tests. Cores CPU (Mhz) Memory (MB) Small Medium Large With up to 4 routine, tests were performed (1 - VM creation and initialization, 2 - snapshot instantiation, 3 - VM shutdown and 4 - removal) being simultaneously created and for each one of the profiles created test, were performed 20 times as shown in Table 2. This routine testing collected the resource consumption of each of the servers initially proposed: CSGL01 (CloudStack), CSGL02 (XenServer01) and CSGL04 (Openfiler, Primary Storage). Table 2. Methodology applied in the tests. 1 instance 2 instances 3 instances 4 instances Small 20 executions 20 executions 20 executions 20 executions Med 20 executions 20 executions 20 executions 20 executions Large 20 executions 20 executions 20 executions 20 executions After performing all tests, the script developed generated 20 CSV files with different resource consumption information during execution of the routine. The data were extracted and the following information was considered: (1) Total available CPU, (2) Total CPU resources used by each processes, (3) Total CPU waiting for disk access, (4) disk reading operations, (5) disk writing operations, and (6) Memory utilization. As [14], the descriptions of the filtered items in the SAR are: Total CPU availability: Percentage of CPU idle time. Total CPU resources required by user processes: CPU utilization (percentage) that occurred while executing at the user level (application). Note that this field does not include the time spent running virtual processors. Total CPU waiting for I/O to disk: Percentage the CPUs were idle while waiting for the disc to perform the requested I/O operation. I/O Reading Operation: Total number of reading requests per second sent to the physical devices. I /O Writing Operation: Total number of write requests per second sent to the physical devices. Memory consumption: Total memory consumed, excluding the amount of buffer memory. The KSAR [15] software was also used in the StackAct, which is a tool that builds graphs and charts from the results obtained from the SAR tool. KSAR enables to export the SAR results in PDF graphics, JPEG or export to CSV spreadsheets, the last one used in the production of the tests of this paper. In order to have a single comparison value for analysis, the arithmetic mean of the total consumption of each resource has been calculated, since the data were collected every second during the tests, these resulted in different times, with different number of executions of the SAR. For example, the test performed at lower instance (SMALL) with only one isolated instance were captured on average 50 times running in 50 seconds. Since the test with higher instance (LARGE) with four concurrent instances, an average of 288 results have been captured, since the total time for this test was on average 288 seconds. In order to analyze and compare the results, metrics filtered for each process (creation and initialization of instance, snapshot, shutdown and delete the machine) has summarized the arithmetic mean of the whole process. In table 3, it is shown the arithmetic mean of all test times for each instance and the number of tests performed

5 simultaneously. The total amount at the end of the studies were 240 tests, with a total of 600 instances created, initialized, and deleted in each profile. However, the number of CSV files created was 3 times the total number of tests since each test resulted in a CSV file in each one of the analyzed layers. consumption. However, the storage layer has a slightly higher than others. Table 3. Total time taken to perform the tests. 1 Instance 2 Instances 3 Instances 4 Instances SMALL 44 sec 132 sec 209 sec 263 sec MEDIUM 49 sec 140 sec 218 sec 273 sec LARGE 102 sec 154 sec 228 sec 288 sec It is important to highlight these times, since it was revealed that during the process with multiple instances being created simultaneously, the hypervisor puts instance creation actions, creating the snapshot, shutdown and delete the instance in the queued. This is evident when evaluating the comparative results between each feature assessed with different profiles. Due to this factor, we chose to not display the values of the tests with 2 and 3 instances being created simultaneously - will be displayed only 1 and 4 instances. Figure 7. CPU consumed by user process. Figure 8 explains why higher CPU consumption by the storage layer, since it was an average of approximately 15% with respect to the CPU consumption due to waiting for disk resources, while the average of the other layers was approximately 2.5%. VI. RESULTS The most relevant results obtained in the tests are shown in Figures 6 to 11, with the comparison between the layers involved. Through analysis of these figures, it was possible to evaluate the more resources consumed, according to the characteristics of the services running on each. To perform this comparison, we used only the great service offer configuration with 4 simultaneous instances. As shown in Figure 6, CPU consumption during testing and in CSGL01 and CSGL02 machines was lower than in CSGL04 machine. This means that the machine hosting the Openfiler NAS storage service consumed more CPU during testing, because the data storage service perform a lot of reading and/or read disk recording, making CPU consumption increase considerably. It is important to highlight that this disc on this device is a SATA 500GB 7200RPM drive. Figure 6. CPU Available in 3 layers evaluated. Figure 7 shows the use of user processes, that is, only the amount that services consume itself and can be identified, in all cases, are services with low CPU power with less than 7% Figure 8. CPU waiting for I/O in Disc. Figure 9 shows the use of I/O write to the CSGL01, CSGL02 and CSGL04 machine. As expected, the use of the resource in CSGL04 server was about 7 times higher because the number of recordings that is required to drive. At this point, it is noteworthy that this server offers primary storage service for CloudStack orchestrator, storing the files relating to instances (VMs). Therefore, at this point it is noteworthy that this server offers primary storage service to the orchestrator CloudStack every time the orchestrator accrues, it creates a snapshot, power off or delete a new instance. It communicates with the hypervisor layer - in the case of this study, XenServer - which sends the requests to the storage layer, which causes a high number of requests from E/S write the internal disks present in this server

6 Figure 9. Write requests per second sent to disk. The consumption of I/O to disk read follows the same trend shown above, as can be seen in Figure 10. Figure 10. Read requests per second sent to disk. Figure 11 shows the memory consumption in the physical equipment tested. CSGL02 (XenServer) utilization more memory than the other servers. Some points, which will be analyzed below, can explain this: According to [16], three components contribute to memory consumption in XenServer, namely: (a) the memory consumed by hypervisor XenServer itself, (b) the memory consumed by the Control Domain (dom0) on the host and (c) XenServer Kernel Crash. The amount of memory used by the hypervisor will be larger for hosts with more memory. As more instances are created, more memory of the physical host (dom0) is automatically used, but not proportionally, because the way it allocates memory for VMs in XenServer. In the environment created for the tests, the hosts have 8GB of memory each, but at the specific test with this host, it was configured to carry cargo only in instances of host CSGL02. It can also be seen in Figure 11, a high memory consumption on CSGL04 host (openfiler), which can be explained by the high consumption of E/S recording in disk, which it could have an effect on this host memory consumption. Figure 11. Memory consumed, excluding buffer processes. A summary of the results obtained in comparison between the three layers can be seen in Table 4, which was exposed to the arithmetic average of 20 runs analyzed for the items in each layer. In this way, it becomes possible to show the high consumption in the I/O to read and write in the storage layer between 5 and 10 times higher than that of the same item in the other layers which also results in a high number of CPU used due to waiting for I/O. Table 4. Summary of results obtained in the comparison between layers. CSGL01 (CloudStack) CSGL02 (XenServer) CSGL04 (OpenFiler) CPU Idle (%) 93,8 96,7 84,7 % CPU 1,3 1,2 5,8 Consumed by User Process % CPU Wait I/O 3,2 1,1 15,5 I/O Write(RPS) 97,3 11,3 560 I/O Read (RPS) 54,1 22,8 223 Memory Used (MB) VII. CONCLUSIONS, CONTRIBUTIONS AND FUTURE WORK This paper presents a data collection mechanism related to the consumption of computing resources in a cloud IaaS multilayer, called StackAct, using the orchestrator Apache CloudStack, XenServer hypervisor and storage system NAS OpenFiler, in addition to running performance tests using the mechanism set up in a private cloud environment, generating important conclusions: Through free open source tools, such as SAR, KSAR, and CloudMonkey command-line tool and the use of SHELL SCRIPT, it was possible to draw up a performance collection engine that works in environments using Apache CloudStack, and any hypervisor and file storage system that runs in an environment with SAR execution enabled, with the set of SYSSTAT packages; Using this mechanism as benchmark in Apache CloudStack environment, it can perform the collection and subsequent analysis of utilization of various computing resources - all of which the SAR tool can monitor, such as Load Average (1, 5 and 10 minutes), network interfaces activity, NFS traffic, Swap Page, startup system processes, among others. Analysis was performed on total available CPU, total CPU consumed by user processes, total CPU waiting for I/O to/from disk, and memory consumption, using a maximum

7 of 4 instance processes (creation and initialization, snapshot, shutdown and delete instance) being created simultaneously, due to the limitations imposed by the environment used in the studies; As regards the results of the tests, despite the limited available environment in relation to computing resources, it was possible to successfully demonstrate the mechanism created for performance evaluation in a multi-layer environment using CloudStack. It was found, for example, high consumption disk in the data storage layer, in particular I/O write data. It was also possible to observe the high memory consumption on the hypervisor layer, which can be justified by the allocation of the hypervisor itself beyond the VMs being created and used in the process. Furthermore, it found that the multilayer system proposed in this study, the orchestrator layer - in the case Apache CloudStack is the one with less consumption of computational resources, taking into account selected for further analysis. The studies for the preparation of this study, the mechanism developed and the results obtained in testing environment enabled the following contributions to the area: Cloud Computing and Virtualization: Through the study of the concepts explored, it was possible to reinforce the differences between the features of both layers that are commonly confused. The definition of layers used in this paper enables a better understanding of the activities of each existing resource in an IaaS structure, it is possible identify the importance of virtualization layer on a Cloud Computing scenario; StackAct: Due to the small number of studies found for assessment of performance and resource consumption in an IaaS cloud with the orchestrator Apache CloudStack, the mechanism can become a reference for future work. It has flexible features as the target layer to be analyzed, the size of the cloud, beyond the resources you want to evaluate. Moreover, it was used only open source tools, which tends to become even more flexible mechanism; Results: Even considering the scenario constructed for validating the mechanism, limiting the development of more extensive testing, it was possible to detect a pattern of behavior in the services offered to the selected items. Furthermore, in [5] the authors use a framework already on the market - SIGAR - that does not have a specific function for data collection in IaaS clouds. In addition, despite having used three different hypervisors into different clusters, there was no apparent concern for the consumer in the orchestrator layer itself focused exclusively on the hypervisor layer. The StackAct has proposed as a mechanism that uses open-source tools, and it can be multi-hypervisor, despite being used in the tests only XenServer. Moreover, the consumption of the 3 layers involved were analyzed, enabling an understanding of all proposed scenario. Compared to the work [6], the authors emphasize that the mechanism is designed to enable monitoring the physical and virtual level, but do not describe the tool operation language, target layer, how to data was collection. Different from previous work, this study focuses only on the uptake of computational resources in orchestrator layer, ignoring the layer of hypervisor and storage. The StackAct covers three layers involved in environment. Compared to the work [7] the authors carried out a comparative between the 2 IaaS cloud platforms, structuring the similar tests that found this paper, but separating the results for each event held (inclusion and exclusion startup instance). The authors use virtualized environment, all CloudStack and OpenStack environments were built on the VirtualBox software, which can compromise the collection of data on resource consumption. The StackAct was developed using CloudMonkey, tool created to automate processes for Apache CloudStack so it not work with another orchestrator. However, in the created environment, physical machines were used, and virtualization was used only in the hypervisor layer, as is done in a real IaaS Cloud environment. As a proposal for future work, it is possible perform the following suggestions for the development and evolution of the work: Using the mechanism developed in this work to evaluate an IaaS Cloud multilayer selecting another hypervisor such as KVM, and other data storage systems, such as Ceph, enabling the comparison with the results obtained in this work; Carry out the assessment of other items available in the SAR reports that were not selected for analysis in this paper, as Load Average, activity of the network interfaces, NFS consumption, Page Swap and startup system processes; Perform data analysis by separating each of the events included in the test. Thus, it would be possible to separately evaluate the resource consumption at the time of creation and initialization of the instance, the creation of the snapshot, and shutdown and delete the instance, allowing an individual examination of each of the events. It is also proposed the use of StackAct with better features, such as Amazon EC2, making it possible to test the scalability of the cloud with a service offer configuration and number of higher instances. REFERENCES [1] Mell, P. and Grance, T. (2009) "The NIST Definition of Cloud Computing". National Institute of Standards and Technology, Information Technology Laboratory. [2] R. Buyyaa, C. S. Yeoa, S. Venugopala, J. Broberg and I. Brandic (2009) Cloud computing and emerging IT platforms: Vision, hype, and reality for delivering computing as the 5th utility. [3] V. Salapura, Cloud Computing: Virtualization and Resiliency for Data Center Computing, Computer Design (ICCD), 2012 IEEE 30th International Conference. [4] P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, R. Neugebauer, I. Pratt, A. Warfield, Xen and the art of virtualization, in: Proc. 19th ACM Symposium on Operating Systems Principles, SOSP 2003, Bolton Landing, USA,Oct

8 [5] P. V. V. Reddy and L. Rajamani, "Evaluation of Different Hypervisors Performance in the Private Cloud with SIGAR Framework", International Journal of Advanced Computer Science and Applications, Vol. 5, No. 2, [6] L. kai, T. Weiqin, Z. Liping, H. Chao, "SCM: A Design and Implementation of Monitoring System for CloudStack", 2013 International Conference on Cloud and Service Computing. [7] A. Paradowski, L. Liu, B. Yuan, "Benchmarking the Performance of OpenStack and CloudStack", 2014 IEEE 17th International Symposium on Object/Component-Oriented Real-Time Distributed Computing [8] F. Gomez-Folgar, A.J. Garcia-Loureiro, T.F. Pena. Improving CPU Service Offerings in Apache CloudStack. IEEE 17th International Conference on High Performance Computing and Communications (HPCC), 2015 [9] Apache. (2015, October 23, 2015). Apache CloudStack Documentation. Available: [10] XenServer. (2015, November 12, 2015). XenServer Documentation. Available: [11] B. Childers, "OpenFiler: an Open-Source Network Storage Appliance". Available: [12] Apache. (2015, November 20, 2015). CloudStack cloudmonkey CLI in Apache Documentation. Available: loudstack+cloudmonkey+cli [13] Godard, Sebastien. "SYSSTAT utilities home page." )[ ]. pagesperso-orange, fr/sebastien. godard (2010). [14] Lim, Il-Kwon, et al. "The SAR Chart Viewer design and Implementation in mobile web." Journal of the Korea Institute of Information and Communication Engineering 17.9 (2013): [15] KSAR Page. (2015, February 21). Available: [16] XenServer. (2015, November 26). XenServer Technical FAQ. Available: