Nowadays different Cloud services enable enterprises to migrate applications to the Cloud. An application can be partially migrated by replacing some of its components with Cloud services, or by migrating one or multiple of its layers to the Cloud. As a result, accessing application data stored off-premise requires mechanisms to mitigate the negative impact on Quality of Service (QoS), e.g. due to network latency. In this work, we propose and realize an approach for transparently accessing data migrated to the Cloud using a multi-tenant open source Enterprise Service Bus (ESB) as the basis. Furthermore, we enhance the ESB with QoS awareness by integrating it with an open source caching solution. For evaluation purposes we generate a representative application workload using data from the TPC-H benchmark. Based on this workload, we then evaluate the optimal caching strategy among multiple eviction algorithms when accessing relational databases located at different Cloud providers.
%in Stilfontein+277-882-255-28 abortion pills for sale in Stilfontein
Evaluating Caching Strategies for Cloud Data Access using an Enterprise Service Bus
1. University of Stuttgart
Universitätsstr. 38
70569 Stuttgart
Germany
Phone +49-711-685 88337
Fax +49-711-685 88472
Research
Santiago Gómez Sáez, Vasilios Andrikopoulos, Frank Leymann, and Steve Strauch
Institute of Architecture of Application Systems
{gomez-saez, andrikopoulos, leymann, strauch}@iaas.uni-stuttgart.de
Evaluating Caching Strategies
for Cloud Data Access using an
Enterprise Service Bus
IEEE IC2E 2014
1- In the last years Cloud computing has become popular among IT organizations aiming to reduce its operational costs
2- Applications can be designed to run in the Cloud, or can be partially or completely migrated to the Cloud.
3- Focusing on the three layered application pattern, in other works we have focused on migrating the application data to the Cloud. Migrating the application data to the Cloud requires adaptations, e.g. rewiring to access the migrated to the Cloud databases.
4- In this work we target how to mitigate the performance degradation due to accessing the migrated to the Cloud data through CDASMix
Contributions of this work:
The design and realization of CDASMix, a multi-tenant aware ESB solution with caching support that enables transparent data access to databases both on-premise and off-premise.Design and realization of CDASMix, a multi-tenant aware ESB solution that enables transparent access to databases hosted on or off-premise
A performance evaluation of our proposal, with the dual purpose of showing the impact of introducing CDASMix to the performance of the application, and identifying the optimal caching strategy for CDASMix for different deployment options across Cloud service providers.
A set of initial findings stemming from this evaluation, that can be valuable for related efforts
1- Focus on the three layered application pattern proposed by Fowler
2- Data layer is subdivided into the data access layer and the database layer
3.1- Consider an application whose stack is completely hosted on-premise.
3.2- Data is partially or completely migrated to the Cloud, e.g. to Amazon RDS
3.3- The data Access layer must be adapted and rewired in order to access the migrated to the Cloud database
3.4- If we assume 3 different scenarios, e.g. data partially hosted between on-premise, and DBaaS or IaaS solutions, the data access layer must be aware of such locations towards retrieving the data from the different backend data sources.
3.5- Therefore, there is a need of a Cloud enabled data access layer able to redirect the data storage and retrieval requests to the different databases.
3.6- For example, being able to redirect SQL requests to data migrated to AWS RDS.
Presentation layer: Extended to provide a larger amount of operations not only for multi-tenant aware administration and management, but also to enable the registration of the necessary information for routing requests between multiple backend data sources.
Business Logic Layer: encapsulates the business logic of the ESBmt administration and management. Have extended to incorporate cloud data access awareness.
Access layer: based on role based access control. Tenant and users access the system with an unique tenant id and user id.
Tenant Registry Manager, Configuration Registry Manager, and Service Registry Manager: wrap the interaction functionalities with the persistent resources, tenant registry, configuration registry, and service registry.
JBI Container Manager and Service Assembly Managers contain the necessary functionalities to interact with the JBI Container Cluster for deployment and undeployment of message adapters and transformers.
Resources Layer: encapsulates the persistancy resources, and the resources which are managed and administered through the upper layers.
ESB Instance Cluster: multiple ESB instaces which perform the tasks associated with ESB solutions, e.g. message routing and transformation. Each ESB instances can be seen as three main components: Message adapters, message processors, and a normalized message router.
Tenant Registry: contains information related to the tenants and users, e.g. id, email, etc.
Configuration Registry: contains information related to the configuration of each tenant, e.g. tenant operator permissions, used jbi clusters, quota for message adapters, etc.
Service Registry: tenant’s services in the ESB cluster, as well as the configuration of each message adapter deployed to the ESB instance.
Message broker is an intermediate component for communicating with the ESB instances based on topic subscription.
- MySQL Proxy: OSGi and JBI compliant version of Java MySQL Proxy implementing native MySQL communication protocol, providing one endpoint
- Caching: EhCache realizing Least Recently Used (LRU) caching policy and deleting cach records when SQL statements involve data modifications
- NMR: enables integration of OSGi Proxy and NMR
- SMX-Camel-mt: multi-tenancy, integration between JBI and Enterprise Integration Patterns provided by Apache Camel
CamelcdasmixJDBC: dynamically connecting to backend data stores via corresponding database communication protocol
JNDI: to register database connections in order to reduce latency when creating a database connection per user
SMX-Camel: enables loading CamelcedasmixJDBC packages at runtime, e.g. updates for supporting a new backend data store or data service
MySQL query cache uses the an improved LRU eviction algorithm incorporating a midpoint insertion strategy. Following a temporal storage based on lists, the list is divided into the most recently accessed and the oldest values which are less recently used. With this approach, the list contains blocks which are the most recently used.
TPC-H benchmark is a database decision support benchmar which comprises a set of queries with a high degree of complexity that run over a large volume of data.
9 Adapted queries which are distributed among a workload constituted by 100 queries distributed with probability 1/9
Average of 10 Rounds per scenario
RDS and EC2 m1.xlarge EC2 and a db.m1.xlarge instances
Amazon instances in the EU zone.
Refer the RDS results in the paper
First comparison is based on the performance degradation
Second comparison is based on how the degraded performance is mitigated by introducing the cache.
In previous papers we identified the network latency as approx 3 % of the total throughput.
Refer the RDS results in the paper
First comparison is based on the performance degradation
Second comparison is based on how the degraded performance is mitigated by introducing the cache.
Performs better in Tandem with the Optimized LRU caching strategy implemented in MySQL, as it relies on the LRU. The combination of both provide better performance results.