Examine the Advantages of An Integrated Scalability Approach at Various Cloud Stack Layers

Introduction

The preferred method for providing IT services is moving toward the cloud [1]. The cloud paradigm offers its users (i.e., end users and service providers) a number of benefits, including the ability to outsource a portion of their operations to the cloud (for which strong IT skills are required), a decrease in the cost of owning, operating, and maintaining computational infrastructures, an in¬crease in flexibility, and access to a scalable infrastructure. The spread of cloud technologies and solutions, on the other hand, leads to the deployment of numerous heterogeneous multi-layer cloud stacks [2]. New methods for performance monitoring and automatic scaling that are independent of cloud configuration and operate at many layers are becoming more and more in de¬mand in this context.

In order to analyze the performance of several technologies of-fering functionality for a given cloud layer, existing performance evaluation and automatic scalability methodologies typically focus on a single cloud layer at a time [3,4]. As an illustration, various NoSQL databases are contrasted to assess their functionality and support for scalability in various scenarios [3,5,6]. The same holds true when comparing various cloud infrastructures (IaaS) [4]. In this way, even when multiple layers of the cloud stack compete for the same physical resources, inter-layer syn¬ergy and interference effects are not taken into account. Addi¬tionally, many current solutions presuppose an endless supply of resources that scale up on demand without any constraints (e.g., [4,7]). But as mentioned in, this is not always the case, particularly in situations where there are limited IT resources (as in a private cloud) or financial resources (as in a hybrid/public cloud) [8]. This situation prevents us from treating each layer of the cloud stack as an independent building block; instead, it forces us to prioritize which layer to grow first when resources are scarce and many levels (such the database and computing infrastructure layers) need to scale.

In this article, we address the aforementioned issue and propose an integrated approach to cloud scalability that centers on a sce¬nario in which the database and computational infrastructure layers are in competition for resources. Our contention is that blind scaling is inapplicable to the cloud settings of today, ne¬cessitating the definition of scalability solutions that take into account the possibility that the demands of the entire cloud stack cannot be met by the resources at hand. First, our method defines a set of indicators that can be assessed and quantified using com¬mercial and open-source software, as well as a set of guidelines for automatic scaling and performance monitoring that apply to both the database and computing infrastructure levels. Then, it is applied to three scalability scenarios: database only, computing infrastructure solely, and a mix of the two where database and computing infrastructure fight for resources. A private cloud ar¬chitecture is used to experimentally examine the three scenarios. The rest of this essay is structured as follows. Section II provides examples of our reference architecture and motivating scenario. The metrics and guidelines for automatic scalability are present-ed in Section III. Section IV details the results of our experiment. The relevant study is summarized in Section V, and our conclu-sions are presented in Section VI.

Motivating Scenario and Reference Architecture

A) Motivating Scenario

Our inspiring scenario and reference structure are presented in this section. A) Motivating Scenario Leading European telecommunications provider Telecom Italia offers its customers a range of mobile and cloud services. The Telecom Italia cloud computing offering known as Nuvola Italiana, or the "Italian Cloud," consists of a variety of services that assist businesses in the distribution of their applications and the implementation of their business processes. One of the most demanding needs in this situation is the ability to offer an auton¬omous scalability solution that targets the cloud stack at various stages. Since applications typically need resources for service execution and delivery as well as resources for database opera¬tions (such as the conventional NoSQL map- reduce operations), many of the provisioned services, in particular, require scalabili¬ty at least of the computing infrastructure and database [9].

Here, we focus on data-intensive applications (such as data-in-tensive websites developed in Ruby and deployed on the cloud1), which demand on two distinct pools of virtual machines because business logic and data layers are separated (VMs). First, we specifically concentrate on conventional cases where the business logic (i.e., computational infrastructure) and the data (i.e., database) layers are scaled independently depending on the loads of requests. Then, we concentrate on a scenario where the two levels compete with one another for resources. The research presented in this paper tries to address the following scalability requirements.

• Elasticity Scaling

The pay-as-you-go paradigm must be taken into consideration when discussing cloud scalability, and elastic approaches that scale up, out, and down based on the real load must also be supported.

• Reactivity vs Proactivity

Scalability must accommodate both proactive and reactive strategies. By using appropriate metrics (such as CPU and memo¬ry use), a reactive method to scalability assesses the status and configuration of the cloud and scales as necessary in accordance with rules concerning those metrics. In order to decrease the likelihood of situations when the stack is overloaded or under-loaded and a reactive approach is required, a proactive method monitors the status and configuration of the cloud and preemp-tively scales.

• Multi-Layer

Clouds are inherently multi-layered and diverse. A cloud scal-ability strategy must address the heterogeneity of the cloud and support various methods that enable scaling at various layers of the cloud architecture.

• Resource Limitations

A scalable infrastructure with boundless resources that are accessible on demand is frequently how the cloud is viewed. This isn't always the case, though [8], and as a result, a scalability strategy that optimally assigns/revokes resources when and when needed is required.

B) Typical Architecture

The layers in our reference architecture's cloud stack are as follows: the management of infrastructure resources (such as compute, network, and storage) through the deployment of com¬ponents providing IaaS functionalities; the management of ap¬plication lifecycle and scaling rules through the deployment of components providing PaaS functionalities; and the implemen¬tation and management of databases through the provision of da¬tabase infrastructure. Our approach is based on Telecom Italia's cloud offering, which covers the following group of products.

• OpenStack

IaaS open source software that enables management and mon¬itoring of infrastructure resources It establishes infrastructure templates for VM provisioning, controls network and storage operations, and provides a number of APIs that expose moni¬tored data to the architecture's higher layers.

• Cloudify

A PaaS system that is open source and allows management of the application lifetime. In order to offer scalability at the in¬frastructure layer, it implements a collection of recipes that are mapped on OpenStack templates. It offers a list of supported ap¬plication architectures, supports metrics definition, and scaling rules (i.e., Apache, Tomcat, and MongoDB in our scenario).

• MongoDB

A document-oriented, NoSQL database with no schema. It is made up of three basic parts: a router service that receives and distributes requests to shards; shard servers that store data; configuration servers that store database configurations.

• KVM

It is the hypervisor that OpenStack uses to operate within the computing node.

We observe that OpenStack has been set up in a multi-node configuration, with three virtual machines serving as the controller, network, and computing nodes, respectively. We should also mention that VMWare ESXi 5.5 is the hypervisor used to deploy the entire system.

II- Performance Metrics and Scalability Rules

A strategy for automated scaling must first define a set of metrics tracking the condition of various cloud stack levels (Section III-A). Following that, a set of rules that can support automatic scaling at various layers can be implemented using these metrics (Section III-B). Database layers and computer infrastructure are the main topics of this section.

A. Performance Indicators

Performance metrics are numerical indicators of a certain cloud stack's health and can be tracked to inform various scalability strategies according to the scenario under consideration. We make a distinction between reactive and aggressive scaling. First, metrics for reactive scalability provide a quick snapshot of the current state of a particular computing infrastructure and/or database, enabling prompt responses to situations where an event may have an impact on the performance and availability of a certain configuration. We take into account the subsequent indicators for reactive scalability:

• CPU Load (CL): It gauges the actual CPU usage of a group of virtual machines that are assigned to a system. For instance, high levels of CL can indicate that a system is having trouble address¬ing a certain set of requests. Memory Occupancy (MO) is a measurement of how much memory a pool of virtual machines given to a system actually uses. For instance, high values of MO can indicate that a system is having trouble handling situations when applications need to manage large amounts of data.

• Network Utilization (NU): This metric assesses how well network bandwidth is being used. High NU values, for instance, may indicate situations where the distribution of data in a data¬base is not ideal, necessitating numerous data exchanges (such as for map-reduce processes), or they may indicate the need to reallocate resources from outside the system to handle a spike in demand.

• Host Availability (HA): This measure determines how many VMs are available and reachable via the network.

• Response Time (RT): the period of time between the dispatch of a request and the client's receipt of the appropriate response

. • Execution Time (ET): This metric gauges how long it takes for a service to respond to a request after receiving it.

• Request Ratio (RR): This metric compares the proportion of requests that are directed at various cloud stack layers.

• Metrics for proactive scalability must also be established.

These metrics analyze the performance trend and system evolution over a predetermined time window with a size of t seconds in order to predict and deduce potential demands for extra resources. Preemptive scaling minimizes potential service performance degradations and enables long-term maintenance of a constant performance level. If recurring patterns of computing infrastructure/database usage are present, these metrics are more useful. For proactive scalability, we take the following metrics into account:

• Request Rate (ReqR): This metric counts how many requests have come in within the specified time period. It can be used to recognize a specific pattern and subsequently estimate future resource scalability needs.

• Request Faults (RF): This metric evaluates the proportion of requests that were not fulfilled within a given time frame, allow¬ing for the detection of systemic issues.

• Request Type (ReqT): It calculates the frequency of each type of request over a specified time period. As an illustration, we can keep track of the rate of MongoDB queries per type (such as read, insert, and update) and respond appropriately. The measure Value can also be affected by the complexity of incoming re¬quests, which can be assessed using the service description [10] or professional recommendations.

• CPU Load Pattern (CLT): It tracks the trend of CPU usage throughout the selected time period. It can be used to monitor the system's evolution and respond appropriately. Similar to CLT, but for memory occupancy, is the Memory Oc¬cupancy Trend (MOT).

• Network Utilization Trend (NUT): similar to CLT but for network usage

The state of the database layer and the computing infrastructure can both be assessed using the aforementioned metrics. Additionally, they can be combined to provide more in-depth information, such as the current CPU Load with a rising or falling trend.

B) Scalability Rules

To track the performance of cloud-based systems and choose the best strategy for automated scaling, we created an architecture based on the metrics in Section III-A. When specific events are detected that may have an impact on the system's performance and availability, our monitoring infrastructure will set off one or more scaling rules. These rules simulate situations in which a single met¬ric (or a combination of them) surpasses predetermined thresholds and causes the execution of specified scalability actions. To extract data from the underlying system and calculate performance metrics, our monitoring infrastructure I builds on specific APIs, in this case those provided by OpenStack and MongoDB through JMX, and ii) is based on Cloudify. Scalability rules are implemented as Cloudify recipes, which manage the scale out and scale down of the application.

We should point out that scaling up is not an option here because it is less successful than a scale out strategy [8].

Table I shows a set of rules that, when certain high/low thresholds are crossed, initiate scaling actions at the infrastructure and database layers by monitoring and evaluating performance metrics. Expert users can define thresholds based on prior tests and the domain un¬der consideration. Table I lists the metrics to be combined for each rule (Formula) and describes the scalability steps (Action). We ob¬serve that a single metric's value is normalized from 0 to 1 using either the highest value it is capable of reaching or the highest value already recorded.

Details are provided in Table I(a), where metrics are used to assess the state of resources that are either assigned to the database layer (poolI) or the computing infrastructure layer (poolI) (poolDB). When the system encounters a major change in infrastructure per¬formance, or, to put it another way, when pertinent formulas assume values above/below the high/low thresholds, an infrastructure-level rule is activated. Similar to this, when pertinent formulas indicate the requirement for scaling database resources, a database- level rule is activated for the database layer. Table I(b), instead, presents composite rules that monitor metrics referred to both poolI and poolDB. The table's scalability rules can then be applied as Cloudify recipes (see for example the excerpt in Figure 1).

1. 1. Basic Rules

1. 2. Composite Rules

There is a complexity to take into account when many recipes apply, request more resources, and must be processed simulta-neously. These recipes may insist on various cloud layers. As was mentioned in Section II, there may be situations in which all triggered rules are competing for the same set of resources and cannot be implemented simultaneously owing to resource and/or financial limits. In this case, we suggest augmenting our scalability solution with a priority-based strategy that gives each rule a priority. If further rules demanding a scale out activity are present, they are applied in accordance with the priority until no more resources are available or all rules have been applied. It is significant to highlight that Cloudify's monitoring infrastructure must be expanded to handle this situation because the existing implementation does not provide the selective execution of distinct recipes based on priority. We experimentally evaluated a 

situation in Section IV-D where Rule 1 and Rule 2 are both trig¬gered and require an additional VM to be assigned to poolI and poolDB, but there is only one VM that is accessible. This anal¬ysis was done to demonstrate the possibilities of our technique. Our tests demonstrate which option provides the greatest perfor¬mance advantages to establish Rule 1's precedence over Rule 2. Finally, Figure 1 depicts a Cloudify recipe that implements Rule 1 from Table I. CLI is first assessed using script statistics. a CLInfr that calculates the value of relevant data after retrieval. If the ratio surpasses the high threshold, the system then adds one VM outfitted with a Tomcat instance to poolI (instancesIncrease) (0.75). Conversely, if the ratio falls below the low threshold, it removes one instance (decreaseInstance) (0.25). Every 20 seconds, CLI is assessed (movingTimeRangeInSeconds).

s e r v i c e {

name ” tomcat ”

. . .

e l a s t i c t rue numInstances 1

minAllowedInstances 1

maxAllowedInstances 2

scaleCooldownInSeconds 20

samplingPeriodInSeconds 1 s c a l i n g R u l e s ( [

s c a l i n g R u l e {

s e r v i c e S t a t i s t i c s { m e t r i c ”RULE 1”

movingTimeRangeInSeconds 20

s t a t i s t i c s S t a t i s t i c s . CLInfr

}

highThreshold { value 0.75

i n s t a n c e s I n c r e a s e 1

}

lowThreshold { value 0.25

i n s t a n c e s D e c r e a s e 1

}

}

] )

Figure 1: An example of Cloudify recipe for Rule 1 in Table I.

Experimental Evaluation

To test the viability of our strategy, we created the following proof-of-concept private cloud architecture, focusing solely on reactive scalability. First, we studied a case in which the data-base (Section IV-C) or computational infrastructure (Section IV-B) requires greater resources. Then, we looked at a variety of the prior scenarios in which the database and computational infrastructure both had to scale up and compete for scarce re¬sources (Section IV-D). We made the assumption that data-intensive apps would use separate pools of virtual machines for infrastructure and databases.

A) Experimental setting

Two physical servers were used in a cluster for testing. The first server (Server 1) is a Dell Precision T1650 with an Intel Xeon Quad Core 2.6 GHz processor, 32 GB of RAM, a 1 TB hard drive spinning at 7200 RPM, and two 1 Gb/s Ethernet NICs. The second server (Server 2) is an Acer Veriton M6620G with an Intel Core- i7 3770 3.40 GHz processor, 16 GB of RAM, a 1 TB hard drive spinning at 7200 R On two different pools of virtual machines, one for the database and the other for the computing infrastructure, the components of our reference architecture (see Section II-B) have been installed and set up as follows.

Regarding the computing infrastructure, OpenStack has been set up and tested using three virtual machines (VMs): two of the machines house the control and network nodes and are deployed on Server 2, while the third computer houses the compute node and is installed on Server 1. The compute node controls a collection of virtual machines (VMs), each of which has a Tomcat instance and 1 vCPU and 1GB of RAM. Regarding the database, we considered MongoDB (in a multi-shard configuration) made up of three component types (i.e., shard servers, configuration servers, and router servers), each of which was installed on a single virtual CPU and one gigabyte of RAM.

These hybrid MongoDB configurations are typical of Ru-by-based data-intensive services and websites. We installed Cloudify and connected its shell to OpenStack for IaaS admin¬istration to finish our proof-of- concept cloud stack. Then, using Cloudify, we made a virtual machine (VM) for managing Open-Stack and one for every Tomcat server and MongoDB shard.

Then, we recreated a real-world scenario with multiple clients making requests simultaneously (i.e., threads). Using Apache JMeter, an open-source functional testing solution for services, the demand on the computing infrastructure has been generated and supplied to two different web apps, deployed on the Tom¬cat server. The first program is a straightforward hello world (hw). Following the Gregory-Leibniz series, the second applica¬tion (hw) expands hw to calculate the value with a precision of 70,000 digits; hw allows us to primarily stress the CPU of our physical infrastructure. Using the Yahoo! Cloud Serving Bench¬mark (YCSB) (https://github.com/brianfrankcooper/YCSB/ wiki/), a framework and a set of workloads frequently used for evaluating and benchmarking the performance of various NoSQL databases, the load on the database has been generated and sent to the MongoDB cluster connected to our applications. In each experiment, the average Transactions Per Second were measured (TPS).

B) Computing Infrastructure Scaling

We evaluated our strategy under various load fluctuations to de¬termine whether performance would increase as the computing infrastructure scaled out (i.e., a single VM is added to poolI ). We used the recipe implementing Rule 1 (Figure 1) to manage infrastructure scalability when either hw or hw is taken into ac- count in order to keep things simple without sacrificing general-ity. Each test case: I took into account 20 active clients (threads) sending requests; ii) simulated different loads, varying the re-quest per second (rps) in 500rps, 1000rps, 1500rps, 2000rps, 2500rps, 3000rps, 3500rps, 4000rps (3500rps and 4000rps for hw only), and iii) produced a total number of 100,000 requests.
Figure 2 illustrates the changes in TPS depending on whether hw or hw is taken into account. In both cases, we started with a fun¬damental architecturea single system running Tomcatand scaled it up to four virtual machines. Figure 2(a) demonstrates that when 4 VMs are deployed with application hardware, the system can handle a maximum load of 1896 TPS for 4000rps. With compared to configurations with 1 VM, 2 VMs, and 3 VMs, respectively, we saw improvements of 39.5%, 28.7%, and 7.1% in this case. However, a configuration with 1 or 2 VMs yields the best performance for situations with 1500, 2000, and 2500 RPS.                                              This is mostly caused by the complexity added by managing several VMs and by the properties of hardware that responds after very little computation. Figure 2(b) demonstrates that when 4 VMs are deployed with application hardware, the system can handle a maximum load of 1650 TPS for 2000rps. With compared to configurations with 1 VM, 2 VMs, and 3 VMs, respec¬tively, we were able to boost performance in this case by 53.6%, 27.2%, and 12.2%, respectively, following a similar pattern to the one seen for the hardware.

Figure 2: Performance evaluation (TPS) 

Additionally, we observe that the findings demonstrate a more pronounced correlation between the number of VMs and the supported TPS due to the fact that hardware needs more work on the Tomcat server to compute. For example, the system responds to (nearly) every request received up to 1500RPS for 3 and 4 VMs, 1000RPS for 2 VMs, and 500RPS for 1 VM.

Figure 3: Performance analysis after database pool scale up.   

C) Database Scaling

We examined our strategy under various loads to evaluate per-formance gains as the database layer scales out. We used a single recipe (implementing Rule 2 in Table I), which adds a VM to poolDB when a decline in performance is noticed, same to in¬frastructure scaling. Each test case generated 100,000 requests while simulating various loads with rps of 50, 100, 200, and 400. Three scenarios with different database request types were examined for each load: 5% read, 95% update; 95% read, 50% update; and 50% read, 50% update (RU0595). In each case, we expanded up to 4 shares from the initial basic MongoDB config¬uration with 1 shard (i.e., 1 VM) (i.e., 4 VMs) [26].

Figure 3 depicts the changes in TPS that occur when poolDB scales out in situations I through iii). First, we should point out that poolDB can support more TPS the more VMs are provided for it. The database was able to handle a load of 50 rps in all cas¬es, we then note. Additionally, in scenario I as shown in Figure 3(a), the system could handle a load of no more than 90 TPS when configured with just two VMs, and this number increased to 131 TPS when four VMs were used. In case ii), as depicted in Figure 3, (b), In the configuration with two VMs, the system could handle a maximum load of 212 TPS; this number rose to 399 TPS with four VMs. In this instance, when 400 rps are put into the database, MongoDB is able to handle all the queries thanks to 4 VMs. The outcomes of cases I and ii) demonstrate MongoDB's capacity to significantly boost performance when read operations outnumber update operations. In scenario iii), where we pressured the DB infrastructure sending primarily update queries, this point is made more obvious. MongoDB could handle a maximum of 79 TPS with just 2 VMs and 121 TPS with 4 VMs, as shown in Figure 3(c). In conclusion, we observed increases of 46% in scenario I, 88% in scenario II, and 53% in scenario III when we increased our poolDB from 2 VMs to 4 VMs [26].

D) Competitive Scaling

We took into account a situation where poolI and poolDB needed to grow out simultaneously but had a finite amount of re¬sources. To do this, the following three web applications were deployed: I) the hardware used in earlier experiments; II) an extension of the hardware called hw,r that makes it possible to send read requests to MongoDB for each request received; and III) an extension of the hardware called hw,u that makes it possible to send update requests to MongoDB for each request received. Then, under various rates of rps generated as follows, we eval¬uated the performance benefits when the extra VM is either as¬signed to poolI or poolDB. A rate rd=•ri of rps is generated and sent to hw,r (95%) and hw,u (5%), given a rate ri of rps deliv¬ered to hw. In particular, we first altered rd in 100rps and 400rps while fixing ri to 1000rps. Then, we varied ri between 1500, 2000, and 2500 rps while fixing rd to 200 rps.

Figure 4 illustrates the rise in TPS that results from adding a single VM to poolI or poolDB after choosing the appropriate ri, rd, and corresponding. The graph takes into account the combined TPS of the three services and exhibits a noticeable performance improvement in both scalability scenarios, with a greater improvement when the VM is added to poolI. Particularly, the system demonstrated good responsiveness and a consistent upward trend as demands on the computing infrastructure rose. Generally speaking, these experiments can be utilized to create a best practice strategy for a competitive situation with limited resources, allowing scaling in an ideal manner based on the environment under consideration (see Section IV-E for more details).

E) Discussion

The first outcome of our tests is one that would seem to be obvi¬ous: the more resources devoted to a single layer, the better the performance. This incremental behavior is noticeable at both the infrastructure and database layers, where the best TPS performance is frequently attained by deploying 4 virtual machines, each of which installs a Tomcat server or a MongoDB shard, as appropriate. The database scalability test results also demon¬strate MongoDB's capacity to perform better when read opera-tions predominate over update operations. Operations outnum¬ber updates in terms of importance. Additionally, based on the earlier findings, it can be assumed that situations in which the infrastructure and database layers both demand on the same pool of resources will result in the same performance improvement. Here, we suppose that as the design scales out, a single VM will be added to the pool of resources, containing the resources of one VM with a Tomcat server and one VM with a MongoDB shard. Furthermore, we note that the best performance boost is seen when a competitive scaling is involved. higher priority should be given to the relevant rules when the VM is added to pool I.

                                              Figure 4; Competitive scaling performance.

To sum up, we first note that neither our solution's primary goal was to increase the architecture's overall performance nor was it designed to offer yet another performance assessment in a cloud environment. Instead, we wanted to research how scalability af¬fected different cloud stack levels in a competitive environment with limited resources. Our findings may therefore be viewed as a practice run that will enable the development of a performance lookup table that will direct the operations of a probe that imple¬ments a scalability manager. The probe can then employ an ideal scaling method that takes into account the unique characteristics of each user's environment (e.g., application types).

This is based on how the user's applications are distributed in relation to the request load. The probe can also boost the trans-parency of the cloud by enabling the cloud provider to define precise and efficient scalability techniques while also providing a clear picture of how a scalability process is controlled by the cloud provider and tailored to the needs of the user.                                                                                                         

Related work

Different layers can be established for scalability approaches for distributed systems and environments, which often rely on met-ric-based regulations [11,12].

Traditional methods of scalability and elasticity compare the performance of various technologies that provide functionality for each cloud layer, taking into account only one cloud layer and one scenario at a time [3], [4,13]. For instance, several strategies have concentrated on the scalability of IaaS, PaaS, and SaaS. Salah and Boutaba offer a model for evaluating elastic cloud ap¬plications by predicting service response time, whereas Iosup et al. analyze the performance of cloud computing services for sci¬entific computing workloads [14,15]. Espadas et al [16]. 'S strat¬egy based on resource allocation for SaaS to establish a cost-effective scalable environment offers a systematic measurement for under and over provisioning of cloud resources. Other works have analyzed the process of adaptive resource expansion and contraction, provided strategies for their performance evalua¬tion, and controlled the flexibility of NoSQL databases and stor- age [3,5, 6,17,18]. Copil et al. provide a multi-layer solution for the management of elasticity and scalability on the cloud, which is very similar to the work in this paper [19]. While we focus on the issue of competing requests for resources, they define a mechanism for managing conflicting elasticity requirements.

Finally, numerous concerns have been discussed in literature in relation to cloud performance optimization. The issue of re¬source and data allocation has been the focus of some methodologies [20,21]. Yi et al [21] 's alternative perspective on the SaaS scalability issue includes a heuristic that, given a fixed number of nodes, distributes tenants so as to maximize the sum of their numbers. DejaVu is a framework presented by Vasic et al. [20] that enhances and accelerates resource allocation in virtualized environments and can adjust to changing workloads [20]. The capacity of a cloud framework to adapt to various circumstances has also been intensively studied in the literature, with measure¬ments and benchmarks defined [22-24]. Additionally, Ali-Eldin et al. describe an adaptive controller for cloud infrastructures allowing horizontal elasticity that is both proactive and reactive [25].

Conclusions

One significant possibility provided by cloud platforms is in-tegrated, multi-layer scalability. In this article, we discussed a method for automatic scaling in a multi-layer scenario where various cloud stack levels compete for resources that are inherently scarce. In particular, the suggested solution takes into account scalability at the database and computing infrastructure layers and is based on performance indicators and scalability criteria. In a data-intensive environment where the database and computational infrastructure layers each have a separate pool of virtual machines (VMs) and may compete for a finite number of resources, we also experimentally examined scalability criteria.

References

2. Mell, P., & Grance, T. (2011). The NIST definition of cloud computing. National Institute of Standards and Technology (NIST). Vers, 15, 800-145.
3. Cooper, B. F., Silberstein, A., Tam, E., Ramakrishnan, R., & Sears, R. (2010, June). Benchmarking cloud serving sys­tems with YCSB. In Proceedings of the 1st ACM sympo­sium on Cloud computing (pp. 143-154)..
4. CloudSpectator, Cloud Computing Performance a Compar­ative Analysis of 5 Large Cloud IaaS Providers, 2013.
5. Tsoumakos, D., Konstantinou, I., Boumpouka, C., Sioutas, S., & Koziris, N. (2013, May). Automated, elastic resource provisioning for nosql clusters using tiramola. In 2013 13th IEEE/ACM International Symposium on Cluster, Cloud, and Grid Computing (pp. 34-41). IEEE.
6. Dory, T., Mejías, B., Van Roy, P., & Tran, N. L. (2011, Oc­tober). Comparative elasticity and scalability measurements of cloud databases. In Proc of the 2nd ACM symposium on cloud computing (SoCC) (Vol. 11).
7. Li, A., Yang, X., Kandula, S., & Zhang, M. (2010, Novem­ber). CloudCmp: comparing public cloud providers. In Pro­ceedings of the 10th ACM SIGCOMM conference on Inter­net measurement (pp. 1-14).
8. Ardagna, C. A., Damiani, E., Frati, F., Rebeccani, D., & Ughetti, M. (2012, June). Scalability patterns for platform-as-a-service. In 2012 IEEE Fifth International Conference on Cloud Computing (pp. 718-725). IEEE.
9. J. Ekanayake, S. Pallickara, and G. Fox. (2008). Mapreduce for data intensive scientific analyses,â?? in Proc. of IEEE In­ternational Conference on eScience, Indianapolis.
10. Ardagna, C. A., Damiani, E., Sagbo, K. A., & Frati, F. (2014, January). Zero-knowledge evaluation of service per­formance based on simulation. In 2014 IEEE 15th Interna­tional Symposium on High-Assurance Systems Engineer­ing (pp. 254-258). IEEE.
11. Cáceres, J., Vaquero, L. M., Rodero-Merino, L., Polo, A., & Hierro, J. J. (2010). Service scalability over the cloud. Handbook of Cloud Computing, 357-377.
12. Jimenez-Peris, R., Patiño-Martinez, M., Kemme, B., Pe-rez-Sorrosal, F., & Serrano, D. (2009). A system of archi­tectural patterns for scalable, consistent and highly avail­able multi-tier service-oriented infrastructures. Architecting Dependable Systems VI, 1-23.
13. Vaquero, L. M., Rodero-Merino, L., & Buyya, R. (2011). Dynamically scaling applications in the cloud. ACM SIG-COMM Computer Communication Review, 41(1), 45-52.
14. Iosup, A., Ostermann, S., Yigitbasi, M. N., Prodan, R., Fahringer, T., & Epema, D. (2011). Performance analysis of cloud computing services for many-tasks scientific comput­ing. IEEE Transactions on Parallel and Distributed systems, 22(6), 931-945.
15. Salah, K., & Boutaba, R. (2012, November). Estimating service response time for elastic cloud applications. In 2012 IEEE 1st International Conference on Cloud Networking (CLOUDNET) (pp. 12-16). IEEE.
16. Espadas, J., Molina, A., Jiménez, G., Molina, M., Ramírez, R., & Concha, D. (2013). A tenant-based resource allocationmodel for scaling Software-as-a-Service applications over cloud computing infrastructures. Future Generation Com­puter Systems, 29(1), 273-286.
17. Li, Y., & Manoharan, S. (2013, August). A performance comparison of SQL and NoSQL databases. In 2013 IEEE Pacific Rim conference on communications, computers and signal processing (PACRIM) (pp. 15-19). IEEE.
18. Konstantinou, I., Angelou, E., Boumpouka, C., Tsouma­kos, D., & Koziris, N. (2011, October). On the elasticity of NoSQL databases over cloud management platforms. In Proceedings of the 20th ACM international conference on Information and knowledge management (pp. 2385-2388).
19. Copil, G., Moldovan, D., Truong, H. L., & Dustdar, S. (2013). Multi-level elasticity control of cloud services. In Service-Oriented Computing: 11th International Confer­ence, ICSOC 2013, Berlin, Germany, December 2-5, 2013, Proceedings 11 (pp. 429-436). Springer Berlin Heidelberg.
20. VasiÄ?, N., NovakoviÄ?, D., Miučin, S., KostiÄ?, D., & Bi-anchini, R. (2012, March). Dejavu: accelerating resource allocation in virtualized environments. In Proceedings of the seventeenth international conference on Architectural Support for Programming Languages and Operating Sys­tems (pp. 423-436).
21. Zhang, Y., Wang, Z., Gao, B., Guo, C., Sun, W., & Li, X. (2010, July). An effective heuristic for on-line tenant place­ment problem in SaaS. In 2010 IEEE International Confer­ence on Web Services (pp. 425-432). IEEE.
22. Krebs, R., Wert, A., & Kounev, S. (2013). Multi-tenancy performance benchmark for web application platforms. In Web Engineering: 13th International Conference, ICWE 2013, Aalborg, Denmark, July 8-12, 2013. Proceedings 13 (pp. 424-438). Springer Berlin Heidelberg.
23. Li, Z., O'brien, L., Zhang, H., & Cai, R. (2012, September). On a catalogue of metrics for evaluating commercial cloud services. In 2012 ACM/IEEE 13th International Conference on Grid Computing (pp. 164-173). IEEE.
24. Islam, S., Lee, K., Fekete, A., & Liu, A. (2012, April). How a consumer can measure elasticity for cloud platforms. In Proceedings of the 3rd ACM/SPEC International Confer­ence on Performance Engineering (pp. 85-96).
25. Ali-Eldin, A., Tordsson, J., & Elmroth, E. (2012, April). An adaptive hybrid elasticity controller for cloud infrastruc­tures. In 2012 IEEE Network Operations and Management Symposium (pp. 204-212). IEEE.
26. Ardagna, C. A., Damiani, E., Frati, F., Montalbano, G., Rebeccani, D., & Ughetti, M. (2014, June). A competitive scalability approach for cloud architectures. In 2014 IEEE 7th International Conference on Cloud Computing (pp. 610-617). IEEE.