Figure 119 – uploaded by Ivan Rodero

See full PDF downloadDownload figure

FiRST Cloud AM is given the status of a sliver. Additionally, AM requests the connection to the OpenStack Cloud that verifies the status of the instance as well as the sliver. Retumed status information is based on the instance information for the corresponding slice um (uniform resource name). Based on this instance information, the final status of the sliver is determined and returned to the client as in ListResources() A PI. — Figure 119 FiRST Cloud AM is given the status of a sliver. Additionally, AM requests the connection to the OpenStack Cloud that verifies the status of the instance as well as the sliver. Retumed status information is based on the instance information for the corresponding slice um (uniform resource name). Based on this instance information, the final status of the sliver is determined and returned to the client as in ListResources() A PI.

Related Figures (241)

When a service request is generated, one optimal center is selected from among k centers, and the processing ability and bandwidth in that center are allocated simultaneously to the request for a certain period. If no center has sufficient resources for a new request, the request is rejected. These

4.1 Principle The above guidelines could also be effective to the resource allocation in a hybrid-cloud. In hybrid-cloud, either a private or a public cloud will be selected depending on the required levels of security or reliability, as shown in Figure 3. Requests that require a normal security should be allocated to the public cloud first, and then to the private cloud so that the resources in the private cloud can be kept available for future requests that require a critical security. It turns out that security level or reliability level need to be considered as one of resource-attributes. As discussed in Section 3.2, it is difficult to take multiple resource-types and multiple resource-attributes for each resource-type into consideration simultaneously. It is

consideration, goes on to select Center 2 for type_1 requests if the appropriate resources are not available in Center 1. Therefore, the amount of resources available in Center 2 decreases rather than that in Center 3. As a result, the request loss probability of type_2 requests increases, which require different. The differences in the request loss probability between different request-types can also be made smaller by Method 3E. < Reason> Method 3, which does not have the concept of key resource-attribute and takes attribute high 2 into

IDSaaS, which is shown in Figure 1, assists cloud consumers with securing their virtual machines by deploying an intrusion detection system in public clouds. It protects them against attacks initiated from any external source over the internet in addition to those originating from inside the cloud. Here, cloud consumers implement the applications they want to protect in the form of Virtual Machine Instances (VMI) within a secure virtual network (V-LAN). Concurrently, IDSaaS components can be placed in the same V-LAN to guard these valuable assets.

Figure 2. ID SaaS Components IDSaaS, as shown in Figure 2, consists of five main components: the Intrusion Engine, the Output Processor, the Events Database, the Alerts Management, and the Rule-set Manager.

Figure 4. IDSaaS Components Overhead Figure 3. IDSaaS in Amazon Cloud

Figure 5. IDSaaS Rule Overhead Experiment Results

The average dispatching time for 145 alerts from the pcap file using 100 trails was 2.35 seconds in configuration 1. In configuration 2, the same number of alerts was received on an average of 30.94 seconds. However, the highest dispatching time was obtained from configuration 3 with 119.70 seconds. The results are demonstrated in Figure 7. We believe this high value is due to alerts transmission time between the two Amazon regions. In this paper, we introduced IDSaaS, which is a framework that enables consumers to protect their virtual

Figure 6. Distributed IDSaaS in Public Cloud

The previous analysis of current cloud offering has shown that provider and customer perspectives are quite different. The former seeks to maximize the profit and the utilization level of the IT asset that they have invested on. The latter just needs to make fine-tuned searches in the market in order to discover the service fitting their specific business needs. We have then designed a service discovery framework that exploits semantic mechanisms to favour the matchmaking of the providers’ offer and the customers’ demand. Two OWL-based ontologies have been developed to characterize respectively the provider and the customer perspectives. In particular, the first ontology semantically describes the features of the resources being offered by cloud providers (see Figure 1), the second one describes the application’s business requirements demanded by customers (see Figure 2). For a detailed description of these ontologies refer to [8]. Since each ontology contains semantic concepts belonging to two different domains, we have devised a mapping process that transforms application requirements into “semantically” equivalent resource features, i.e., features that best represent the application requirements in the domain of resources. The mapping’s purpose is to put application requirements and resource features on a common semantic ground (that of cloud resources) on which a semantic procedure will try to make the match.

In the following subsections we provide some details on how the mapping and matchmaking processes work.

Figure 2. Application requirements ontology

Figure 1. Storing Data at Undesired Locations

Figure 1. Proposed Architecture

Figure 3. Attestations of Popa et al. [18] Figure 2. Data block and family key block table sent to the cloud

DPOR [21] uses BLS or RSA in such a way that multiple signatures verification can be done very efficiently. Thus, for each block family F’, the data owner runs the signature generatour algorithm (®, sigs,(H(R))) <— SigGen(sk, F) which takes the signing key of the family (sk) and the en- crypted block family F' and generates the signature set for this family ® = {01,09,....,0n}; where o; < (H(m;) - u™)s* for each family block m;; u < G is a random element choosed by the data owner. In addition, a signature of the root that associated MHT is generated sig.,(H(R)). Then, each block m,; will be associated with its signature o; and some metadata such as block version and version of k and pk; b; = {m,||block Ver||k Ver||pk Ver||o;} (Fig. 2). Finally, the data owner sends to the cloud storage the block family {b,, bg,....,bn}, its signature set ®, the family key block table, and the root signature of this block family sig.,(H(R)) (Message 1.1 of Fig. IV).

Figure 4. Merkle Hash Tree i) Attestations: As in CloudProof [18] we build a hash chain from all data changes and requires signing from both parties on all updates. Thus, any misbehaviour could be de- tected and proved by exchanging attestations for each request or response between data owner, clients and cloud provider. The structure of exchanged attestations includes metadata such as the block version and current hash which are used to maintain the write-serialisability (when each client placing an

Figure 1. Test Cases in Traditional Environment

Figure 3. Test Cases in Cloud Virtual Environment Figure 2. OpenStack dual node deployment [9]

Figure 4. Speed comparison for traditional / virtual machine allocated with all hardware resources (4 threads)

Figure 5. Relative speed comparison for Fig. 4.

Figure 6. Speed comparison for traditional machine allocated with different resources per thread

Figure 7. Relative speed comparison for Fig. 6.

Figure 8. Speed comparison for virtual machine(s) in cloud allocated with different resources per machine and per thread

Figure 9. Relative speed comparison for Fig. 8

NUMBER OF LI AND L2 DATA CACHE MISSES IN CLOUD AND TRADITIONAL ENVIRONMENT IN SOME POINTS IN L2 AND L3 REGIONS

Figure 10. Speed comparison for sequential execution in the three environments

Figure 11. Relative speed comparison for Fig. 10.

Figure 12. Relative comparison for L1 data cache misses

Figure 13. Relative comparison for for L2 data cache misses

Fig. 1. Architecture of the execution environment.

Fig. 2. Components of the Condor mediator.

execution of a job fails, the corresponding mediator captures the fault and puts an error tuple into the message repository. This tuple, which will be processed by the Fault management component, contains information about the cause of the fault that will be used by the manager to take a decision with respect to the job execution. Different decisions could be taken: to submit the job again to the same grid computing platform, to submit the job to an alternative and reliable grid computing platform or to notify the error to the workflow executing environment in case the error persists, for instance. In the last case, most grid solutions offer two different ways to manage the fault: corrective actions or alternative workflows. Fig. 3. Components of the fault management component.

Fig. 4. | Nets-within-Nets based implementation of the First Provenance Challenge workflow.

Fig. 5. Taverna implementation of the First Provenance Challenge workflow.

To do that, the advanced scheduler also considered the average load of each infrastructure at every moment. Figure 6 depicts the daily average load (% of the maximum load) in the HERMES and AraGrid computing infrastructures. As it can be observed, both computing infrastructures have different load models. Their trends during the day as well as the previous execution time are used to decide the most suitable candidate for each task deployment. Fig. 6. Hermes and AraGrid daily utilization (in percentaje).

Figure 7 depicts the results obtained for 900 executions of the FPC workflow deployed on the framework. Average exe- cution times (in seconds) are shown for each separated infras- tructure (HERMES and AraGrid) and also for the framework for each stage of the First Provenance Challenge workflow. The overall execution time (average) is better when using the framework. This is due to the best candidate selection performed by the advanced scheduler (in most cases). The analysis of each separated stage depics that most of the time (70%) the HERMES cluster computing infrastructure gets a better execution time that AraGrid, which is related to the fact that the framework execution time is closed to the HERMES one. Fig. 7. Experimental results for the First Provenance Challenge workflow.

Figure 2. Compute node uses local copy from disk images

\BLE I. CONFIGURATION OF THE TEST BED

Figure 4. Semi-shared storage is using local- and shared resources at the same time

KVM and caches as well as buffers were disabled on every hypervisor, etc.) for more accurate diagram (Fig. 5) presents the results layer (files-system, results [5]. The first when a shared storage server and one com semi-shared storage or benchmarking. The pute node use available I/O performance was measured in the image repository, compute node and ind ividually in the VM ins tances as well. The benchmark values are the sequential read throughputs when all the 8 virtual | machines are running. The first test batch has 9 pairs of columns. The pairs are distributions of VM instances between local and remote resources. In a pair, the first column is the aggregated I/O performance of the VMs and the second is the aggregated I/O performance of image repository and compute node. In order to prove achievable by using the that higher I/O performance is semi-shared storage subsystem than the prior (shared and non-shared) solutions could provide, 1/O benchmarks were performed on the test cloud. The benchmarks were sequential read throughput tests because sequential read is a ty pical storage parameter [6]. At the same time, 8 exactly the same virtual machine instances were used to stress and load the I/O subsystem, while the performance was measured inside the virtual machine and directly on the physical block device with the iostat tool. Tostat is an I/O performance monitoring tool for Linux based systems. During the tes ts, the virtualization hypervisor was

Figure 5. 1/O benchmark with the image repository and one compute node Figure 6. I/O benchmark with the image repository andtwo compute nodes

Figure 1. Live-migration for personal use.

Table I. Pre examination environments which executed only web-browsing operations, including the playback of YouTube videos.

Figure 2. Three machines and three different workloads.

Figure 3. Our prototype system overview

Figure 4. The structure of diff disk image.

Figure 5. The result of writing benchmark.

Table II. Storage migration measurement result on Ubuntu 11.04 desktop (32bit) Table III. Storage migration measurement result on Windows 7 Professional (32bit)

exploit deduplicated VM disk blocks. This approach also provides deduplication on local VM disk storage to reduce the volume of local storage data. Although this approach somewhat complicated, it is better than our bitmap approach. Therefore, we will implement the deduplication system using a fingerprint algorithm. of a DELL LATITUDE D630 laptop computer booted with an Intel Core 2 Duo T7300 @ 2.0 GHz with 2 GB of memory. Both computers are connected in a 1 Gbps LAN environment.

More specifically, MWLAN has full knowledge of the network topology, network configuration (routing info), the switch link bandwidth, the physical host capacity and the mapping of applications to physical host. By taking a globa view of routing and VM traffic demands, MWLAN can identify the load of physical host and the switch link in data centers. If a hotspot occurs (e.g., network congestion and physical host overloaded), MWLAN can use VM migration to balance the overloaded resources (e¢.g., physical host or links). Figure 1 shows the virtualized data center and MWLAN. Figure 1. The virtualized data center and MWLAN architecture.

MWLAN is consisting of three components: Node Controller, Network Controller and VM Migration Manager. Node Controller is responsible for gathering VM resource usage statistics on each physical host and VMs, doing demand estimation (physical host resource demand and bandwidth demand) and detecting physical host hotspot. Network Controller periodically gathers link bandwidth usage statistics of data center network and the routing info, and then does the link load hotspots detecting process. VM Migration Manager is responsible for choosing the migration VM candidate and the destination physical host candidate. Therefore we propose the MWLAN architecture depicted in Figure 2, the principal components and their interplay are described in more detail in the following architecture section.

LE I. THE DEFINITION OF VARIABLES IN THE EQUATION Since our objective is to balance the link traffic load, the utilization of links should also be taken into account. So if the VM,, is migrated from physical host PM,, the effect to the network traffic load can be defined as: The variables in the Equation are defined as Table | shown.

TABLE IL. PARAMETER FOR SIMULATIONS Because the efficiency of migration schemes may vary with different traffic patterns caused by the initial placement of VMs before migration, we run the compared test on three different VM initial placement patterns. In the first pattern, the initial placement of arrived VM is random (Random Pattern). And the VMs which have traffic are placed in the same 1-level switch in the second pattern (Same Pattern). And in the last pattern, the VMs which have traffic are placed in different 1-level switches (Different Pattern).

make sure the VM migration achieves the maximum benefit, while MWLAN2 always chooses the VM and destination physical host which can get the maximum benefit. Figure 3 shows the application average T’CP transfer rate of Sandpiper and MWLAN as time changes on different VM _ placement patterns. The result indicates that the application performance of MWLAN2 is better than the other scheme as the VM load increasing. The average improvement of application rate is up to 24% compared to Sandpiper. As shown in Figure 3, the average TCP rate is nearly the same in the beginning. And as the VM load increases, the TCP average rate three VM migration approaches. The traffic rate declines more obviously when using Sandpiper compared to our approaches. The reason is that there is no network congestion when the traffic load network. But as underl with elimin TCP ra MWLA they wil oaded links heavy traffic near to eac bandwidth cost. Thus MWLAN1 ate the local traffic conges tion of network resources. differs to each other for is not heavy in data cent So the VMs can achieve the demand TCP rate. the VM load is increasing, the link traffic load is becoming heavier. When network congestion occurs, the te decreases, as what we see in Figure 4. And 1 and MWLAN2 consider the link load cost. So move the traffic flows from the loaded links to the by using VM migration or move the VMs h other for saving link and MWLAN2 not only tion but also improve the These two factors make MWLA 1 and MWLAN 2 have better network improvement com indica tes that MWLANZ2 has be pared to Sandpiper. The Figure 3 also tter network performance improvement than MWLANTI. The reason is that MWLAN1 consid er the migration revenue and cost separately, it can’t

PIQure L. ATCMLECWUIe OL DY DATUC VV CDSLUe multi-tier workloads. However, in a real Cloud data center, multi-tier workload is one of the most commonly used Some research work has been done to measure the influence of live migration on single-tier workloads [5, 6] instead of

Figure 3. Experiment overlay of VIRTUAL MODE

In phase 2, we measure virtual machines. In order to of experiments, we allocate machine to get an equivalen the performance of RUBiS or compare with the previous se’ two VCPUs for each virtua configuration compared witt the PHYSICAL MODE. A virtual machine with 2 VCPU: will be created on PM1, running the RUBiS Web Server, we call this virtual machine VM 2 VCPUs will be created on Server, we call this virtual memory is allocated for V ; another virtual machine witk PM2, running the RUBiS DB machine VM2. Then enougt 1 and VM2, so that memory will not become a bottleneck. The Client Emulator Server still runs the RUBiS Client Emulator program. The architecture is shown in Figure 3. We call this phase VIRTUAL MODE. Figure 2. Experiment overlay of PHYSICAL MODE

Figure 6(b). CPU usage when clients = 1400 ~ Compared with Figure 4, it’s easy to determine in Figure 5 that throughput in VIRTUAL MODE goes up almost the same way as that in PHYSICAL MODE. It implies that virtual machines with equivalent configuration of hardware Figure 6(a). CPU usage when clients = 1300

Figure 7(b). CPU usage when clients = 1400 Figure 7(a). CPU usage when clients = 1300 Figure 6. CPU usage ration as a function of time in seconds in PHYSICAL MODE

Figure 6(e). CPU usage when clients = 1700 Figure 6(f). CPU usage when clients = 2300

Figure 7(f). CPU usage when clients = 2300

Figure 8. The memory usage graph when client=1600 in VIRTUAL MODE

Figure 9. Migration Time as the Client Number Increases Figure 10. Downtime Time as the Client Number Increases accessing RUBiS will fail. What’s more, the throughput in MIGRATION-WEB MODE is much less than that in the MIGRATION-DB MODE because of its longer downtime in migration. So it’s better to avoid migrating virtual machines running memory intensive workloads (the Web server virtual machine in our experiment).

environments to achieve the goals of dynamic resource management. For example, when the physical machine is nearly exhausted of CPU resource, it is better to migrate some of the virtual machines on this physical machine to other physical machines, because the lack of CPU resource also decreases the workloads’ performance and might even lead to application failure. After the virtual machine is migrated to the physical machine rich with CPU resource, the performance of the physical machine will return to the normal level, and eventually avoid server or application failure. In this subsection, we wil investigate performance issues in such scenarios. Based on the above analysis of MIGRATION-DB MODE and MIGRATION-WEB MODE, we can determine that live migration indeed has an adverse effect on the running of multi-tier workloads. It’s better to avoid the live migration of virtual machines as much as possible. When live migration cannot be avoided on demand of load balancing, fault tolerance, or power saving, it’s better to not migrate the virtual machine hosting memory intensive workloads.

Figure 12. Throughput under different CPU usage rate when client=1600 loaded. The applications running on virtual machines work well before point T, and will tum bad after T. The tuming point T might be a proper point to migrate the virtual machine on the nearly fully loaded physical machine. We conduct the following experiment to determine the T point specifically in our system.

Figure 3. Relationship between workflow instance, Cloud instance, and authentification center. The process of executing a workflow with Cloud Tasks is summarized in the following with reference to Figure 3 where the numbers in circles indicate the order. First the user requests an assertion token (1) with only limited use at the secure token service by providing her/his own identification together with the identification of all Cloud Tasks she/he wants to use. The secure token service evaluates the request and decides if the assertion can be granted. If the result is positive, the user instantiates the workflow (2). The Create Task uses this assertion at the factory (3) to proof its eligibility. The factory then loads the Cloud account authentication data from a secure storage (4) and starts the Cloud instance (5) with the deployed web service. The assertion is now invalidated. The APURVA Cloud Task invokes the web service (6) that is running on the Cloud instance. The web service processes the data on the high performance Cloud hardware. After the web service returns its results, the Destroy Task shuts down the Cloud instance.

Figure 5. Dynamic assignment of Cloud Tasks to Cloud resources.

Figure 1. A software system that integrates mobile and cloud computing services. The remaining structure of this paper as follows: In Section II, we explain existing infrastructure of HPCAs, in both fixed/static and mobile cloud environment. Section III discusses the importance of offloading for HPCCAs in desired environment. Section IV describes the required service-architecture of HPCCA in mobile environment. Section V presents HPCAs offerings by different service providers. In Section VI, we also discuss HPCCA economics. In Section VII, we discuss the much needed security and challenges issues and best suited solutions; result analysis. Finally, we conclude with our findings and future work.

Figure 2. Percentage of users who uses wearable devices for each activity and shows content consumption [5]. The HPC architecture requires intensive applications to rum on multiple processors, rather than on single, to achieve the desired performance. Virtualization, parallel and vector processing, multi and co-processing are the fundamentals of HPC. Applications such as, 3D- imaging processing, financial commerce, medical imaging, data compression, seismic data interpretation, search, security, and many more have been efficient in desktop environment. Shall be the same in mobile environment? Today, many service providers offer HPCA as a service, available for enterprise users, community users, and individual subscribers in mobile cloud environment.

The integrated (mobile and cloud) technology describes as MC2 deploys in heterogeneous radio access environment such as WiFi, 3G, WLAN, WiMax, GPRS. It is implemented through wireless connectivity. The prime features are access 24X7, on-demand, energy efficient, and economically feasible even for low data rate cloud controlling signals. Mobile applications can be launched on the device or cloud, and can be migrated between them according to dynamic changes of the computing context or user preferences [6]. Smartphone and tablets are quickly becoming the information worker’s most valuable tools. Young workers and their strong affinity for go-anywhere technology is changing the shape of the enterprise right here, right now!! Enterprise Mobility is becoming more and more Anytime, Anywhere service in a true sense!! Smart-phones [7]. The most frequent and intensive users of HPC systems are researchers from academic and research oriented business establishments, investigating and __ specific government agencies; whereas the common users heavily use HPCAs for communication, entertainment and such many more activities. All need effective, improved, convincing,

reliable and efficient performance in both, fixed/static and mobile cloud-based environment. Advancing the efficient HPC architecture is a big challenge, particularly in mobile cloud environment. It includes processing, managing, using existing architecture, mobility, and offering services anywhere anytime from individual user to enterprise subscription locally and globally. The following features are most desirable for efficient HPCCA: DS ceuot beckett tides. TITS vss wean bec Bex chick Aebecoswce Tifsdic teu

Figure 6. Service Architecture in Mobile Cloud Environment. Storage and memory requirement: Memory and storage requirement is a major parameter. Applications requiring huge memory and storage cannot be executed on mobile devices as they are generally poor in the resources; these applications need to be offloaded. The service architecture shown in Figure 5 describes how the cloud resources can be utilized by mobile devices for executing high performance applications.

Figure 5. Offloading trend in mobile cloud environment [10]. As shown in figure 5, “percentage of total mobile data traffic from handsets and tablets, mobile offload will be 31 percent (3.1 Exabyte/month) in 2016.

TABLE 1. SERVICES OFFER BY THE RESPECTIVE PROVIDERS IN CLOUD-BASED MOBILE ENVIRONMENT

Figure 7. Mobile device computing storage and display trends [18].

Figure 1. Intercloud object storage service. Academic cloud users can access their own containers and objects from clouds that are remote from the one they usually use. The machine images stored as objects in storage-I can be used to launch virtual machines in these remote clouds. Machine image conversion might be needed before the launch, depending on the heterogeneity of the source and destination clouds.

We thought that we should not start developing our intercloud storage service from scratch and that it would be better to utilize existing open source object storage service software. Figure 2 compares the various candidates that we examined in focusing on AWS S3 type Web API base object storage open source projects. S3 is a de-facto standard among object storage services, and there is a software eco system around it. Baltic-avenue [3], boardwalk [4], fs3 [5], sinatra-s3 [6] are effectively development test beds for S3, because they are not designed to have redundancy mechanisms. Because of this limitation, they cannot support huge intercloud object storage services.

Swift has proxy nodes and auth nodes acting as the front- end and storage nodes acting as the back-end for accounts, containers, and object storage. Let us begin by discussing the intercloud object storage service architecture by categorizing how to allocate swift components such as proxy nodes, auth nodes, and storage nodes. The proxy nodes and auth nodes categorized as front- end. The storage nodes are categorized as back-end. We examined the suitability of the following architectures.

Figure 5. Swift dispatcher. When swift sends responses to the client, it merges the response from each swift, as described in Figure 5.

Figure 4 shows an overview of the colony architecture. New components such as swift dispatcher, VM info converter, and caching module were developed by analyzing this prototype. The dispatcher calls the local swift or intercloud swift depending on the container attributes. The VM info converter is used to convert the virtual machine image metadata for one cloud to metadata for another cloud in order to launch the machine image in the other cloud. The content cache helps to make the data transfer efficient. The swift client can send requests to swift-A and swift-I through the swift dispatcher. In the prototype, the dispatcher can find the destination swift by looking at the prefix string in the container names. In the example in Figure 5, the prefix ‘A:’ indicates that the container resides in the local cloud, which is ‘cloud-A.’ The prefix ‘I:’ specifies that the containers having this prefix are located in the intercloud, which is ‘cloud-I.’

Swift dispatcher can use a cache proxy per swift proxy to retrieve objects from remote swifts (Fig. 6). In the prototype, the cache is implemented using a squid content proxy cache mechanism [12]. This sort of simple caching mechanism works because the swift proxies in the swift-I are located remotely from the swift client. We implemented a prototype of our intercloud storage service using colony and have started evaluating the performance and usability in three geographically distributed sites. So far, we can say that the colony load balancing seems to contribute to the performance of the intercloud object storage service. We located inter-region swift between three regions, i.e., Tokyo, Chiba, and Hokkaido, and investigated its performance in relation uploading/downloading objects. Throughputs between Tokyo and Chiba were about 1 Gbhits/s while throughputs between Hokkaido and Tokyo/Chiba were about 7 Mbits/s.

In this case, uploading of objects is always the worst case because swift proxy puts objects in three zones, sets replication to default, and waits until all objects are uploaded. n contrast, the worst case of downloading objects is one-third of all transactions because the swift proxy randomly chooses one of three object servers. When downloading objects through web cache proxy 1, the first download will likely be the worst case, but the results nonetheless show the cache proxy is effective (see Fig. 7).

Swift should be zone-aware for geographically distributed use. For example, swift dispatcher can choose the best swift proxy to transfer a request to if it knows the network latency (see Fig. 8).

Figure 1. Mobile Cloud Computing (MCC) Model with High Performance Computing (HPC) for Mobile Distance Learning (MDL)

Figure 2. Mobile Cloud Computing (MCC) System Architecture with High Performance Computing (HPC) for Mobile Distance Learning (MDL)

Figure 5. A Screenshot from the testing of WebEx on International Distance Leaming Conference

Figure 6. HTC Sensation as a Part of the Learning System

Figure 3. iPhone 4 as a Part of the Learning System

Figure 4. iPad as a Part of the Learning System

Figure 7. Comparison of QoE Evaluation Results in %

Figure 1. Extended architecture of Eucalyptus Cloud.

Figure 2. Framework components.

is essential. The increase in time is too less and negligible when considering the advantages like fault tracking, resource utilization, patterns finding and energy consumption of a provenance enabled Cloud. Furthermore, the successful de- ployment of provenance collection to Axis2/C and Mule frameworks support our theory of a generalized and inde- pendent provenance framework Figure 3. Test results of Echo service.

From the results in Table 1, we can conclude that the proposed data access mechanism is the safest for cloud tenants. Although symmetric encryption algorithm has some advantage in key bit and time cost, the fatal weakness is that encryption key and decryption key are same and kept by different parties, in addition, the RSA encryption and symmetric encryption had been cracked and the attempt for cracking more bits of them will continue. TABLE 1 COMPARISON OF DIFFERENT ENCRY PTION ALGORITHM aa WEercur i de SEEMS Yee Uslee SAN ELSES SEE bOUre (1) As we know, except for key leaking, the security of key not only is related with key length, but also depends on encryption algorithm. Symmetric encryption algorithm DES with 64-bit key (DES-64) has been cracked for about 20 years and RSA algorithm with 768-bit key (RSA-768) was cracked in 2009 by some scientists in Switzerland [16]. So, for the sake of making data access secure in cloud computing, we have to find suitable secure encryption algorithm and secure key length. Identity based encryption algorithms are based on Elliptical curve cryptography ECC). Related research results [17] show that the traditional asymmetric RSA algorithm with 1024-bit key RSA-1024) provides the currently accepted security level, in order to reach the same security level, ECC key length is 160-bit (IBE-160) and symmetric key length is 80 bits. Ona PC with Redhat Linux 9.0, P42.8G processor and 512M DDR, we tested the average encryption and decryption time for different encryption algorithm, these time cost does not include keys distribution and parameters setup, the comparison is listed in Table 1.

recognition community benefited a lot from this project and built a large datasets collected to test face recognition echnology, the large datasets push the research of echnology forward quickly. Figure 1 show that from the beginning of the Facial Recognition Technology (FERET) program to the Face Recognition Vendor Test 2006 (FRVT 2006). The remarkable improvement of face recognition has five important milestones since 2003. To each representative algorithm, they wereevaluated on the false reject rate (FRR) at a false accept rate (FAR) of 0.001 (1 in 1000). The algorithm for 1993 was Turk and Pentland’s eigenface algorithm [18] and for 1997 is Sept97 FERET evaluation [19]. The 2002 evaluation result is from the FRVT 2002 and the 2006 and 2010 is from the FRVT 2006 and FRVT 2010. From the evaluation results in Figure 1, we can conclude that as the representative of the biometric authentication technology, the face recognition attained an enormous improvement these year, especially, from 2002 to 2010, the improvement was very evident. The factors on the improvement due to advancement in algorithm design, advanced multimedia devices and more deep understanding of image processing. So, the low false reject rates (FRR) ata false accept rate (FAR) of the biometric authentication will enhance the security of the proposed data access mechanism.

Figure 2. The causal loop diagram of a dynamic model of trust establishment in the public cloud service market The ratio of a good type provider’s signaling cost to a bad type provider’s cost, y, affects the signaling costs of two type providers and the levels of signals are affected by these costs. The probability of being selected by a user and the signaling cost affect the utility of a provider as well as the non-signaling price, w. The utility of a provider affects the entrance and leaving rate of a provider. The amount of damage from misbehavior by a bad type provider, L affects the utility of a bad type provider

Figure 1. Dynamic states of trust establishment by Equation (3). When the damage from a bad type provider’s behavior increases exceptionally, the separating equilibrium in which the two types of providers select the different trustworthiness level as a signal fails to stay stable. Figure 1 illustrates the relationship between the dynamic states of trust establishment and the proportion of bad type providers. Part (a) indicates the possible region of separating equilibrium, part (b) is the transition region of separating equilibrium and non-signaling pervasive trust and (c) is the market reduction region.

The proposed architecture consists of loosely coupled systems, capable of providing various kinds of services like replication, storage, I/O specific, computation specific and discovery of resources. Based on the application requirement, the resources are made available to other nodes. Figure 1 shows a network of three clusters that are connected to each other via intercommunication network. Each cluster consists of a group of trusted nodes and a File Replicating Server (FRS) assigned to these nodes. A FRS One node in each cluster is designated as FRS. FRS can also be replicated on some other node in the cluster for backup and recovery. The scenario presented in the paper is illustrated in Figure 1 and is elaborated subsequently.

Figure 3. File De-replication Model Flow Graph in Process Algebraic Approach

Figure 4. State Transition Diagram of Source Node (FRS;) a © 1) Illustration of State Transition of Source Node: As shown in Figure 3, FRS, will act as a source node. Status change illustration of source node (FRS,), as shown in Figure 4, will be described as follows:

.BLE II. DATA STRUCTURE EXAMPLE FOR COMPARISON BETWEEN APPROACHES Replicated files on the storage site will be sorted based on least recently used parameter which will be obtained using the combination of both last modification date and last modification time. The list of replicated files will be sorted in descending order. Example of a data structure of available files maintained at the storage site is described in Table 2.

To overcome from the overhead of space management issue, a data structure consisting of a table considered which is described in Table 1. The proposed model is simulated on linux platform and LAN having speed of 100.0 Mbps.

Figure 6. Comparison of the Three A pproaches The Figure 6 plots efficiency of all the three approaches versus load based on the data shown in Table 2 and the three proaches based on least recently used parameter, replica counts and file size parameters. Efficiency calculated is yroportional to the reciprocal of extra memory size vacated luring de-replication based on low, low-medium, medium- 1igh and high load for which range of file size (Rg) is ¢<20MB, 20MB<R;<60MB, 60MB<R;<100MB, and X->100MB, respectively.

TABLE III. DE-REPLICATION TIME IN REQUIRED SPACE Finally, equation 11 establishes a relationship between the formal aspect of file de-replication server and its architectural model through process algebra approach. The stability analysis ensures that the system will run in the finite sequences of interaction and transitions. On the basis of these equations, a transparent, reliable and safe file de- replication model is build. De-replication time increases, as the number of files not accessed for the longest period and smaller in size, are more as compared to the files that are larger in size. Table 3 shows when the space required is same but the number of files to be de-replicated varies, de-replication time also varies depending on the number of files to be de-replicated. De- replication time will be more for the case having large number of files. Table 3 shows that if file size increases by the multiple of 7, i.e, from 6 MB to 43.9405 MB, de- replication time will get increase by the multiple of 1.5, ie., from 60millisecond to 98 millisecond. This shows that the de-replication time is decoupled from the size of files that are de-replicated dynamically and does not _ increase proportionally with respect to the file size.

Eucalyptus platform supports different virtual machine (VM) [9][15]. The supported virtual machines and the

TABLE I. VIRTUAL MACHINE INSTANCE TY PES

The me thodology consists of five activities, which are system understanding, measurement planning, measurement, analysis of first activi performance metrics and statistical analysis. The ty concerns understanding the system, its components, their interfaces and interactions. This activity should provide the set of metrics that should be evaluated. Among suc utilization, h metrics, some might be highlighted such as average service time, average response time, average queue time, average queue length.

The first step instantiates the virtual machines. The second step starts the performance monitoring tools IOstat and MPstat on virtual machines. The third step configures the benchmarks Bonnie++ and LINPACK on virtual machines. The fourth step executes the benchmarks. These benchmarks are the workload adopted. When benchmarks execution end, in the fifth step, the monitoring processing finishes. Then, the virtual machines are shutdown. Next, logs with the measured data are created. After, the measurement process is restarted. In each measurement process, the monitoring tools are started before the benchmarks execution. These measured data must be removed; therefore, the fourth activity analyzes the measured data.

TABLE II. SCENARIOS As previously mentioned, we adopt the benchmarks LINPACK and Bonnie++ and the performance monitoring tools IOstat and MPstat in order to obtain the desired performance metrics. TABLE II shows the relationship between the benchmarks adopted to provide workload to processor and disk and monitoring tools adopted in order to provide processor and disk metrics.

Table V shows the performance metrics evaluated in this case study. TABLE IV. PERFORMANCE TEST

TABLE V. PERFORMANCE METRICS

Figure 5 shows a percentage reduction in the disk utilization level when analyzing the Scenarios 1 to 4 for all reading and writing tests (files with 512MB, 1GB, 1.5GB and 2GB sizes). This metric indicates the percentage of time that the disk was used. If the disk utilization is high, the resource must be carefully evaluated. The threshold for this disk metric is close to 100%. Hence, this metric should be investigated if itis close to 100% [21]. Figure 5, Figure 6 and Figure 7 show the results of disk metrics which are utilization, average service time and average response time, respectively. The values of these disk metrics vary proportionally to the testing of reading and writing considering files with 512MB and 1GB sizes. These tests were performed for all scenarios evaluated (see TABLE II).

| ater aad Processor results reveal that the processor utilization of virtual machines exceed 80% for all scenarios [21], hence these processing infrastructures should be updated or the processor resource of the node controllers should be replaced as a preventive measure for taking into account further workload demands.

Figure 6 presents a decrease in the average service time in milliseconds) for Scenarios 1 to 4 and all reading and writing tests performed by benchmark Bonnie++. This metric describes how long time the disk is taking to fulfill the requests. When more time is spent on fulfilling the requests, slower is the disk controller. It is recommended that the values of these metric be less than 270 ms [21]. The results show that the storage resources do not exceed the threshold of this disk metric.

Figure 7 presents a decrease in the average response time (in milliseconds) for Scenarios 1 to 4 when considering al reading and writing tests (files with 512MB, 1GB, 1.5GB and 2GB sizes). This disk metric includes the time spent by the requests in queue and the time spent servicing them. If the average response time is high, the resource must be carefully evaluated. The threshold for this disk metric is 2.7 seconds [21]. The average response time of Scenario exceed 2.7 seconds when considering tests of reading and

Fig. 1. The Three-tier Innkeeper structure

Fig. 2. Host and VM Resource Consumption host resources and is forced to queue for CPU resources. This creates the illusion, in the reported VM performance metrics, that the VM is not consuming resources due to lack of demand on the VM when in fact the drop in CPU consumption is because the VM does not have the opportunity to consume the host’s CPU. This is backed up the graph in Fig. 3 where OpenLoad reports an increasing response time, as the number of VMs on the host is increased, for the monitored VM. The horizontal dashed line on Fig. 2 illustrates a potential host CPU utilisation threshold beyond which no further VMs should be added. With this threshold defined within a HIk, the HIk would prevent further VMs being added beyond the second VM, as illustrated by the vertical dashed line in Fig. 2.

Fig. 3. VM Response Times

Figure 1. Framework architecture. The Cloud Service Broker builds the heart part of our implemented framework by offering attractive value-added services to users. Its Cloud provider w main task is to find the most suitable hile satisfying the users’ service requirements in terms of functional and non-functional Service Level Agreement parameters. Additionally, its high- level architecture design allows the deployment and monitoring of services on top of heterogeneous Cloud providers. More detailed descriptions on the internal broker design can be read in 11).

Figure 2. Simulation environment. allow the dynamic creation, destroying and monitoring of the VMs during simulation runtime and therefore to enable the automatic service deployment in the broker.

Figure 3. Simulation flow.

\BLEV. BROKER DEPLOY MENT PERFORMANCE (%) While maintaining the number of datacenters constant, we measured the deployment rate, which is defined as the percentage of successfully deployed VMs, by varying the request number from 50 to 2000. We repeated the same experiment by decreasing the number of datacenters from six to three and then to only one. The results presented in Table V after one day simulation time, show that the broker deployment rate scales well with the increasing number of service requests and Cloud providers.

Figure 4. Broker matching performance. In fact, the support of more than one SLA parameter in the matching increases the customer satisfaction, but at the cost of a low match rate. Thus, the matching algorithm should optimize this trade-off by modeling the dependency between the customer utility function and his requested functional and non-functional SLA parameters, while considering the current provider monitoring information.

Fig. 1. The concept of proposed remote cloud based on mobile cloud architecture

TABLE III. AVERAGE DATA RATE ON 4 SCENARIOS

Figure 1. Generalized Cloud Architecture.

Figure 2. Provenance Service as Part of Cloud Services.

Figure 3. Provenance as an Independent Module

our framework into different components. The future of provenance in Cloud lies in a lightweight and independent provenance scheme to address cross platform, Clouds IaaS and application domains. The proposed framework can be deployed without making any changes to the Cloud services or architecture. Advantages of the scheme are: IV. CLOUD PROVENANCE: A USE CASE FOR EFFICIENT RESOURCE INITIALIZATION AND ENERGY CONSUMPTION

Figure 6. Resource Initialization Using Provenance

Figure 1. Mobile System Architecture with Cloud Proxy

Figure 2. Mobile Security Taxonomy Overview Figure 2 illustrates which properties have to be considered for mobile security devices into the categories: user, mobile device, communication channel, and backend.

Figure 3. Security Levels

Figure 4. RBAC Security Level Integration - RBAC Extension Integration by RBAC Extension: This approach inte- grates security level requirements into RBAC using context constraints (see Figure 4 (S)ecurity (L)evel Check = Context Constraints). This means in addition to needing a specific role for accessing certain objects, a certain minimum secu- rity level is also required. The minimum security level is a context condition and the currently applied security level for a device is a context attribute. Together they form a context constraint which is bound to an operation. Before an actual access decision, based on the user, his role and the object, is made the context constraint is evaluated. If and only if the context constraint is met, the access control decision is made. During evaluation of the context condition, the current security level is pulled from the proxy (see Figure 4 step 3). The proxy is always informed about the currently applied security level. Is the current security level (context attribute) equal or higher than that defined in the context constraint of the object, the evaluation of the access control decision may continue. If the current security level is less than required, no further evaluation takes place and access is blocked.

Figure 5. RBAC Security Level Integration - Two Phase Flow Integration by Two Phase Flow: The two phase flow splits security level evaluation and actual access control decision into two phases. Figure 5 illustrates this concept. The proxy is the central component for accessing any services on the intranet and the internet and also stores the current security level assignment. Because of this it can easily be used to control security level evaluation. Every object (e.g., data object in Figure 5) possesses a minimum security level, which needs to be matched to gain access via a mobile device. This information is stored in the access control system. Usually, this information is very static and does not change too often. The proxy stores a copy of these object/minimum level mappings. If the required minimum level is changed, the updated mapping is pushed to the proxy. Now, if a mobile device is requesting access to access control protected data or services, the proxy first evaluates whether the minimum security level requirement is met or not. If it is, the request passes for further evaluation by the access control system, if not the request is refused by the proxy. This approach has the advantage of being access control model agnostic. It actually does not matter which system is used for access control, as long as object’s requirements are available to the proxy. Also, the proxy can be used to terminate requests even before they reach the access control system located behind it. Pushing object requirements on update or in regular intervals also greatly reduces round trips during fetching of the current security level assignment. A problem of this approach is having to keep the same infor- mation (minimum requirements for objects) synchronized in

When building a data center, which of course includes private clouds, the investor will probably want to ensure that it is utilized as much as possible. The private cloud can help achieve that, but not when the entire load is interactive. This is due to the fact that interactive load depends on user activity, which varies throughout the day, as seen in Figure 1. Figure 1. Daily load graph of an e-business website [2] In our opinion, the only way to increase the utilization of a private cloud is to introduce non-interactive tasks that will fill in the white parts of the graph, i.e., capacity left unused by interactive traffic (which of course needs to have priority over batch jobs).

It can control multiple Amazon EC2 [19] compatible clouds. The queuing logic resides outside the MVC (Model, View, Controller) scheme of Rails, but shares database access with it. The communication scheme is on Hio 2 Figure 3. Communication scheme in Cloud Gunther [6]

As one can see in Figure 4., the system is ready for private clouds. It can extract the amount of free resources from Eucalyptus and the scheduler takes it into account when launching new instances. Figure 4. Cloud Gunther — part of the New Task screen [6]

Figure 1. NIST Cloud Computing Reference Architecture (CCRA) [2]

Figure 2. Project oriented collaborative infrastructure containing Grid based Scientific Instrament managed by Grid VO-A, 2 campuses A and B, and Cloud based infrastructure provisioned on-demand.

Figure 3. Inter-Cloud Architecture for Cloud interoperability and integration.

(a) Current relation between Cloud service models

Figure 4. Main actors, functional layers and processes in on-demand infrastructure services provisioning

Figure 5. Relation between different resource presentations in relation to different provisioning stages. common data or semantic model) is then used by VICM/VIP composition service to create the requested infrastructure using a combination of (instantiated) Virtual Resources and interconnecting them with a network infrastructure. In its own turn the network can be composed of a few network segments run by different network providers.

Figure 1. Block diagram of IPFIX data profiling. This algorithm checks in a cycle each traffic class with maximum entropy approach and estimates weights of each traffic class in a model. The algorithm’s result is the network traffic profile in which only the most significant traffic classes in a given pattern are stored. The algorithm stops when the next traffic class does not improve the profile enough, in other words the decrease of divergence should be less then threshold value.

Figure 2. Anomaly detectors generation algorithm.

Anomaly detection is based on the set of detectors, recorded in the database. Fig. 3 shows a detector life cycle, called “maturing” while comparing it with an immune system. Figure 3. Anomaly detectors maturing process.

Figure 4. Block diagram of monitoring and response process. To increase accuracy of the blocking system and to queries to estimate perform several c network?”, “Js the Line (DUL) networ preserve a normal traffic we use “Whois” Database queries to learn an origin of IP address, location and reverse DNS the purpose of IP address usage. We hecks: “Is the IP address from our P address from our Country?”, “Js the P address from Digital Subscriber Line (DSL)/Dial Up k? ”. So, if the IP address is outside of a Cloud network and region, we propose that it probably could be the reason for an anomaly and we block it for an hour. We perform the same action if the IP address is from DSL/DUL networks.

equipment, which is connected to the Public switch and able to block outside IP addresses in case of receiving command from CSMS. Figure 5. CSMS deployment inside Eucalyptus Cloud infrastructure. IPFIX sensors deployed in the Cloud Infrastructure odes (component of the Cloud where runs Virtual Machines of the End User) and send information to the PFIX collector, which is also deployed on the Cloud Controller. In addition, IPFIX data is exporting from the border routers. CSMS module analyzes incoming data from the several sources (Nodes and Routers) and performs anomaly recognition actions — compare anomaly detectors patterns against observing network traffic data. In the case when anomaly discovered, CSMS performing IP address heck process to be sure that traffic not from own or trusted etworks and then sends command to Firewall equipment in rder to block malicious IP address. Advantage of this pproach lies in possibility to deploy IPFIX sensors in every operating system which supports traffic capturing. It means that no matter which kind of Cloud or Virtualization technology going to be used, the most important is the ability to export IPFIX data from network equipment or from virtual network interfaces of the Cloud nodes. mop a

CLUSTER I/O PERFORMANCE UNDER DIFFERENT SIZES (MB/S) Note that the read & write throughput of the cluster is evaluated by the Hadoop benchmark TestDFSIO. The throughput of 2,960, e.g., denotes that the cluster has a throughput of 2,960 MB/s for read.

MAPREDUCE PERFORMANCE UNDER DIFF. AMOUNT OF DATA Note that the job finish time is evaluated by the Hadoop benchmark Sort with different amount of data. The finish time of 2’42, e.g., denotes that the job was finished in 2 min 42 sec. The size of both clusters is fixed with 10 nodes. Every job is evaluated for three times.

Figure 1. Intermediate Results Network Transfer Optimization

Figure 2. Intermediate Results Localized Storage Optimization

Figure 3. The Performance Scalability of DFS and CS

Figure 4. Validation of Intermediate Results Localized Storage Optimiza- tion

Figure 5. Validation of Intermediate Results Network Transfer Optimiza- tion

Eucalyptus is an open source implementation of Cloud computing infrastructure that has a particular architecture. By using Eucalyptus, we can make public and private Clouds. The architecture of the Eucalyptus system is simple, flexible and modular with a hierarchical design, reflecting common resource environments found in many academic settings. In essence, the system allows users to start, control, access, and terminate entire virtual machines using an emulation of Amazon EC2’s SOAP and “Query” interfaces [7]. That is, users of Eucalyptus interact with the system using exactly the same tools and interfaces that they use to interact with Amazon EC2 [8]. The Eucalyptus is composed of five main components

Figure 4. Relationship between Source and Destination NCs for Migration Operation At this point, the destination NC updates instance’s information, which is running on it. Afterward, source NC removes instance’s name and information from the own list of running instances. Next, the CC updates its information and changes instance location. This change causes the following executive orders to be sent to the destination NC. These orders include terminate, reboot, attach and detach volumes to instance.

Figure 3. Relationship of CC and NC through stubs

Also, we have used LZO [10] compression algorithm in our disk transfer algorithm presented. The disk blocks in the source node are compressed before transmission. And then, they are sent to the destination node to be decompressed. This action causes optimal use of available bandwidth and also the data will be transferred in much less time than it is usually the case (without compression). Figure 5 shows the steps of our migration method.

Figure 7. The Throughput of the Network during Instance Migration In the first experiment, we evaluated the network bandwidth of instance during migration in terms of throughput. In this test, we have used Netperf benchmark, version 2.5.0 in order to measure the network bandwidth in normal conditions (not using migration technique) and when the instance is migrating. You see the test results in Figure 7. As one can see in the figure, when the instance is suspended and moved from origin to destination, throughput rate of the network is reduced by half.

Figure 6. The Cloud Implemented Environment and 8GB memory as NCs. Furthermore, we installed Xen 3.4 hypervisor on the NCs. Also, we have a machine with Intel Core2Duo 2.66GHz CPU, 320 GB disk capacity and 4 GB of memory as CLC and CC. These three machines are connected through a LAN network with 100 Mbps bandwidth. The migration operation is performed on the instance; it has one vCPU, 2GB disk space with 128 MB memory. On all components, the Linux Centos 5.6 OS is also installed. You see evaluation environment in Figure 6.

Figure 8. Response Time to Incoming Requests during Instance Migration The results of this test have been shown in Figure 8. At first, when the migration process is starting, disk blocks compress. Afterward, disk transfer starts in second 65 and end on second 156. Now, destination node decompresses received disk blocks and then sends a message based on preparing to receive memory pages to source node. Next, in second 220, the operation of transferring memory pages is started. After a few seconds, in second 237, the instance was entered in suspend state. Now, memory pages and CPU states are transferred to destination. After a few seconds, in second 242, instance will resume working on the destination node and synchronization operation of disk blocks between source and destination was began from second 243 to 280.

Figure 1: Business Service Innovation value roadmap of the proactive optimizer. Thus, the proactive optimization of cloud service serformance aspects provides several unique value oropositions.

Figure 2 — Proactive optimizer Business Solution Innovation implementation modules. composite application in which some of the supply-chain services are allowed to change. For every permutation possible, a relative aggregated SLA is presented to the Enterprise Architect, over time.

THE PRISONER’S DILEMMA RESCALED PAYOFF MATRIX Table II balance between the two aspects of load balancing scheme - communication and computation. For programs with a great deal of calculation compared to communication, jz should be relatively small, and vice versa. As js increases, the number of processors in use will decrease until eventually the communication is so costly that the entire calculation must be done on a single node. Score calculated according to [ is awarded to every node taking part in the load balancing scheme. Its magnitude is strictly dependent on agent’s action taken in the PD game as shown in Table II.

Figure 1. The issue of determining communication cost between source node (A) and destination node (B). Green route shows original communi- cation route according to the load balancing algorithm. Red route indicates an alternative (optimal) way back.

Figure 2. The gradient-based communication model. Computational nodes send results in the direction of the sender node (red) via the gradient map of proximity values. Cellular automata space comprises the von Neumann neighborhood - the four cells orthogonally surrounding a central cell on a two-dimensional square lattice. The resulting proximity map is later used used to perform the migration phase. Results are routed through the system in the direction of the sender node (Figure 2).

Figure 3. Strategy adaptation probability graph as a function of the payoff difference and variable K, characterizing the uncertainty related to the strategy imitation process. acquire higher scores in the PD game, which in turn will increase the probability of imitating that strategy by his less successful neighbors and propagating it in the system. This in turn should lead to an optimal load distribution in the cloud computing environment.

As per the NIST been explained in de and what kind of value framework, the cloud broker would provide three distinct services: Service Intermediation, Service Aggregation, and Service Arbitrage. These have tail in the ibid document and the distinction lies in the mode of provisioning of the services addition the broker would provide to the cloud consumer and reality, ie. the publi a business value to the cloud service provider. These require specific and binding agreements between the actors for the reference model to function as intended. Adding complexity to the cloud brokering framework are the varied deployment models that exist in c, private hybrid and community deployment models. The broker would require multiple SLAs with the associated stake holders based on the deployment model and the placement of actors in the model. Figure 1. Framework for SLA management and Cascading Effect Cloud service oriented SLAs, with the cloud broker as actor, represent a negotiated service contract between associated parties that specifies, in measurable terms, w cloud service will be provided to the consumer through cloud broker. This necessitates that key elements required cloud services including warranties, guarantees and rela’ an for ted performance metrics are not left out of the SLA. If left out, they often tend to make the SLA unenforceable. The bro would need to make the consumer understand and appreci the nuance of such elements and make sure that ker ate the agreement between the broker and the service provider also reflects the terms in an unambiguous manner. The aim is to make sure all parties understand and anticipate the course of action in provisioning of the service.

Figure 2. Modeling cloud components: a generic meta-model Implementation: This meta-model is intended to be specialized according to user’s needs, as its intrinsic sim- plicity makes it easy to introduce in user’s code. We provide a reference implementation of this approach using the Scala language, exposed as an internal domain-specific language to support the usage of this meta-model in JVM-based

Figure 1. Pim4Cloud DSL overview

Figure 3. WarContainer: component diagram representation As the language relies on Scala, the declaration of a scalar component is assimilated to the declaration of a class, that extends the concepts previously described. Thus, the user is completely free in such a class to write all the code he/she thinks necessary. The DSL is only used to support the user when dealing with its system from a deployment point of view. Internal DSLs immediately benefit from the

Figure 4. BankManager deployment variability

Listing 3. Multiple deployment topologies for BankManager Figure 5. Deploying the BankManager on a PaaS WarContainer component defined in Listing 1 to host the servlet container.

A set of tasks T are executed on a set of processing nodes A. Each processing node a has a resource capacity in terms Processing nodes A and storage nodes B are separated by a network containing a set of network routes R between any set of nodes. A set of virtual machines V containing algorithms are hosted on a set of physical processing nodes A. A set of virtual machines W containing data stores are hosted on a set of physical storage nodes B. Combined application (VM) and data placement taking CPU, memory, storage and network constraints into account has been investigated [10] and a solution using a penalty- based genetic algorithm described; however, the algorithm execution time does show an increase as the number of servers increases, causing a significant delay, which could render it unacceptable if used in a real time solution and may also lead to scalability problems. Hybrid evolutionary algorithms combining the best features of genetic algorithms with the best features of other evolutionary algorithms such as particle swarm optimisation (PSO) [11], ant colony optimisation (ACO) [12], and simulated annealing (SA) [13], have been shown to have a much shorter convergence time than purely genetic algorithm-based solutions [14]. Hybrid genetic algorithms such as the multi agent genetic algorithm 15] can offer superior performance over traditional genetic algorithms when very large scale and dynamic optimisation problems are concerned. Likewise, an improved genetic algorithm (IGA) [16] has been shown to be nearly twice as ast at finding optimised solutions as a purely genetic algorithm placement solution.

Figure 1. Architectural overview of the proposed system placing the image processing application CPU, memory, and network constraints need to be satisfied, likewise when placing data a certain amount of storage, adequate network bandwidth and an acceptable latency is required. The “Data Centre Monitor’ is responsible for monitoring the CPU and memory utilisation of hosts (e.g., HO, HI, H2) and the storage capacity of storage area network (SAN) nodes (e.g., SO, S1) within each Virtual Data Centre (VDC). Data centre node metrics are gathered by distributed agents along with network health metrics collected by the ‘WAN Monitor’, which uses a modified version of BWPing [17] to monitor the end to end bandwidth and latency between all VDCs and users. The node and network health metrics are normalised and form a combined fitness score for each node, which can satisfy the physical and logical constraints. A genetic algorithm is used to find an optimised solution within the pool of viable nodes.

The initial results in Figure 2 below show that a genetic algorithm solution (depicted as the lower solid line) produces placement decisions with a lower total processing cost than a random placement solution as depicted by the upper dashed line (initial fittest) in the graph. The costs for each solution are similar when the number of VMs requiring placement are small. Both solutions show a linear increase in cost as the number of VMs requiring placement increases, but the total image processing cost for the genetic algorithm is significantly lower than that of the random placement solution. With a maximum number of 75 VMs _ for placement the cost associated with random placement is 3229, whilst the genetic algorithm solution is 1294, which is just over 40% of the cost of the random placement solution. Figure 2. Performance comparison between initial fittest (random placement) and genetic algorithm placement solutions.

Fig. 1. (US-East), High-CPU Medium Instance’s inter-price time Amazon describes SIs purchasing system as a market-driven auction [3]. For example, if the provider has N free resources and it received K bids on the resources, then the provider accepts only the highest NV bids, where K is greater than N. The price will be the lowest bid value of the winning subset of the bids. However, by analyzing history traces of SIs’ price, Javadi et al. [1] showed sharp changes in the inter-price time (i.e., time between price changes) occurred on specific dates at different regions. Javadi et al. conclude that it is artificial (i.e., done by Amazon and not driven by customers demand). Ben- Yehuda et al. [10] went further by showing that the prices also are determined artificially by a random reserve price algorithm and do not represent real customers bids around 98% of the time. They expected that the aim of this random reserved price is to prevent customers from: 1- being complacent and force them to bid higher. 2-inferring the provider’s real capacity. Therefore, in case of low number of bids on specific instances type (i.e., K is lower than NV), the provider either accepts the lowest bid as the current price or generates a higher value (i.e., pretends less resources [9]) to sell the resources with a higher price. This behavior raises a question about the efficiency of approaches that model the SIs prices. However, we attribute the direct control of the provider on the price to the lack of demand for some instances’ type. Nevertheless, regardless of the aim of this random reserved price, our approach does not disclose any hidden information about provider’s capacity while it proposes changes to purchasing system rather than to pricing system of SIs.

At the beginning, the VM instance runs with its full capacity (i.e., 100%). As seen in Fig. 2, the throughput is 37.92 MOPs and the execution time is 56.6 seconds. The same workload is run many times but for different capacities of the VM’s CPU. In our experiment, we use Xen Credit Scheduler as an actuator for setting the CPU capacity limit of the VM. The Credit Scheduler has a non work-conserving mode, which prevents an overloaded VM from consuming the whole CPU capacity of the host and consequently degrading the other VMs performance. For each CPU capacity, we recorded both the MOPs number and the total execution times. Fig. 2. VM’s model against CPU-intensive workload

In the simulator, we describe the workload as the number of operations that can be done in 168 hours, which could be calculated by (1) as: 168 * 60 * 60 * 0.2415 « a!-9958 where x = 100. To cover many pricing patterns we chose different starting times from us-east-1.linux.cl.medium spot instance’s price history: 2010-01-02, 2010-09-09, and 2011-05-01. These days are selected to span different variations of inter-price Bands. However, we verified that running the job on other days, within the same epochs, behaves the same with a slight difference in the price and total run time. The bids range from 0.057 to 0.063 while probability density function, of the history prices of us-east-1.linux.cl.medium, shows that 99.64% of the prices fall within this range. Fig. 3 shows the following concepts: First, low bids lead to lower price but longer run time. Second, high bids lead to higher price but shorter run time. Moreover, the simulation of SI at 2010-09-09 shows a longer run time for most bid values compared with the other simulation dates. This is because of the short inter-price at epoch 2 (i.e., Band 3 is | to 2 hours). To study the influence of the inter-price time on the provider profit, we sum up the partial hour for each bid value. The result value is divided by the total run time to get the percentage of Unpaid running time. Results are illustrated in Fig. 4.

NORMALIZED Price x Time FOR EXECUTION ON MIN-BID, MEAN-BID, AND MAX-BID. THE REFERENCE IS A SI WITH OPTIMAL CHECKPOINTING STRATEGY SHOWN IN FIG. 3 If we compare the results in Table I with what obtained by [7], the lowest normalized Price x Time of the instance us- east.cl.medium with low bid (1.e., 0.058) was 1.266. However, with our approach, even for a lower bid value (i.e., 0.057), the normalized Price x Time values were 0.809, 0.833, and 0.749 for the simulation dates in consequence, which means 34% to 40% reduction in normalized Price x Time. Moreover, for the mean bid value (i.e., 0.060), the lowest normalized Price x Time of the same instance was 1.332. However, with our approach it is reduced to 0.969, 0.837, and 0.851 for the three simulation dates in consequence, which means 27% to 37% reduction in normalized Price x Time.

Fig. 4. Unpaid running time(%) - A Spot Instance running 168 hours job

Fig. 5. Running 168 hours job on ESI with different limit prices

Fig. 6. On-Demand instances utilization with variant number of ESIs

Permanent (~350cores/ 30TB) & On-Request (theoretically 3000+ cores) infrastructures Note: network links indicative only Some additional features implemented on the BonFIRE project are: Figure 1. Representation of the BonFIRE infrastructure. Image obtained from [1]. INRIA currently offers on-request compute resources in BonFIRE, allowing experimenters to reserve large quantities of physical hardware (162 nodes/1800 cores available). This gives experimenters flexibility to perform large-scale experimentation, as well as providing greater control of the experiment variables as exclusive access to the physical hosts is possible. Further control of network performance be- tween testbeds is anticipated through future interconnection with Federica and GEANT AutoBAHN. BonFIRE gives you control of your experiment, which is treated as a concrete entity in BonFIRE to manage your resources.

Figure 2. Workflow diagram of the experiment agent.

Figure 3. Workflow diagram of the error management implemented in the experiment agent.

Figure 5. Example of the distribution of 100 random experiments taking into account the histogram depicted in Figure 4. Figure 4. Experiment submission probability each 30 minutes of a day of the week.

STORAGE RESOURCES AVAILABLE ON EPCC AND INRIA BONFIRE SITES. A comparison between these results with the previous ones shown in Figure 6, highlights that the deployment time of VMs on INRIA is almost independent on the storage image and its dependence is higher with the instance type. This situation is remarkable for the DebSql0GV3 storage

Figure 6. Deployment time for each storage-instance type combination on EPCC BonFIRE site. The size rate of the storage images with respect to the DebSqV3 image (red line) is also depicted for comparison reasons.

Figure 7. Deployment time for each storage-instance type combination on INRIA BonFIRE site. The size rate of the storage images with respect to the DebSqV3 image (red line) is also depicted for comparison reasons.

SPARQL provides the possibility to formulate a subscription by associating several filter constraints to a quadruple (event), but also to a set of quadruples that belong to the same com- pound event. This means that several events that are published at different times and that belong to a same compound event may participate to the matching of a subscription by using their common constraints. Listing 1. Legal SPARQL subscription indicating that only events about users whose age is between 18 and 25 have to be notified.

Studies of distributed file systems specified for small files have become a key component of storage systems research as applications specific for small files like images and micro bloggings have been increasing rapidly [21, 31, 32]. FastDFS is designed to meet the requirement of the website whose service based on files such as photo sharing site and video sharing site. Facebook has designed Haystack to serve its Photos application where data is written once, read often, never modified, and rarely deleted.

As one part of the whole system, datanode plays a very important role. But so far there is hardly any optimization specifiedfordatanode, =

We believe _ that co-locating files based on the relationship inherent in application-specific knowledge can be exploited to successfully realize the performance potential of modem disks’ bandwidth.

Figure6. Read throughput under different mimbers of thread.

Figure7. Throughput improvement of different cache size.

Figure 8. Throughput under different numbers of thread.

Figure9. Throughput of different numbers of datanode.

PHYSICAL MACHINES CONFIGURATIONS

RELATION BETWEEN THE CPU USAGE AND THE AMOUNT OF PUS FOR EACH PHYSICAL MACHINE.

To demonstrate how ERHA works, this section presents an example of using the architecture to run the scenario described in the RDB shown in Figure 2. The environment creation and the application execution is performed in thirteen steps, as illustrated in Figure 3 and explained in sequence.

Fig. 6. ERHA Efficiency - Execution time with CPU limiting enabled: 2 PUs per VCPU

Fig. 7. Execution time using different loads in physical machines

Fig. 1: Cloud Computing layered architecture

Fig. 2: A dissemination architecture consisting of multiple EVE resources

Fig. 3: Components of an Elastic Video Endpoint The literature review above has shown that research in the area of content delivery is a popular topic, with developments taking place in all aspects of the concept. However, more recently, the realisation of cloud computing has created a platform that removes the need of content providers to either pay for their own hardware or expensive third party distri- bution platforms. Content producers can now utilise cloud resources to store and distribute their content in a pay as you go manner. While this has reduced the expense for providers, it still leaves the problem of over provisioning due to the lack of overload protection within these systems. In an attempt to dynamically provision content, while still maintaining a high quality of service we propose a new delivery endpoint, based on cloud resources, “EVE,” Elastic Video Endpoint. In Fig. 2, we can see an architectural overview of a distribution network consisting of multiple endpoints located in different geographical locations. A central content repository retains a copy of all the content that is available for dissemination.

Fig. 4: EVE processes and flow

Fig. 5: Network throughput against time

Figure 1. System Architecture of cocoBox CocoBox also provides service components in the format of REST and enables application developers make their own applications easily. We developed a mobile application for cocoBox by using these components.

Figure 2. Data model of cocoBox

Figure 3. cocoBox web application We can use cocoBox services through web browser and mobile internet devices.

Figure 5. Social data on the cocoBox app: score, tags, comments on the file Figure 5 shows the social data of the mobile cocoBox app. People can handle social data of a file using this interface. By providing these social data in file cloud service, people can discuss their sharing contents and express their thought or preference about it. We expect these social data of file cloud could help the collaboration and even communicating their knowledge with other people.

Figure 4. cocoBox mobile application Figure 4 shows the home display of mobile cocoBox app. This application was developed using the cocoBox service components shown in Table land runs on smart mobile devices the Oss of which are Android 2.2.