service availability guarantees on virtual economy

service availability guarantees on virtual economy

Abstract:

Service-oriented architecture (SOA) paradigm for Orchestrating large-scale distributed applications offers significant cost savings by reusing existing services. However, the high irregularity of client requests and the distributed nature of the approach may deteriorate service response time and
availability. Static replication of components in datacenters for accommodating load spikes requires proper resource planning and underutilizes the cloud infrastructure. Moreover, no service availability guarantees are offered in case of datacenter failures. In this paper, we propose a cost-efficient approach for dynamic and geographically-diverse replication of components in a cloud computing infrastructure that effectively adapts to load variations and offers service availability guarantees. In our virtual economy, components rent server resources and replicate, migrate or delete themselves according to self optimizing strategies. We experimentally prove that such an approach outperforms in response time even full replication of the components in all servers, while offering service availability guarantees under failures.

Existing System:

successful online application should be able to handle traffic spikes and flash crowds efficiently. Moreover, the service provided by the application needs to be resilient to all kinds of failures (e.g. software stales, hardware, rack or even datacenter failures, etc.). A naive solution against load variations would be static over-provisioning of resources; this would result into resource underutilization for most of the time. Resource redundancy should be employed to increase service reliability and availability, yet in a cost-effective way. Most importantly, as the size of the cloud increases its administrative overhead becomes unmanageable. The cloud resources for an application should be self managed and adaptive to load variations or failures.

Proposed system:

Building an application that both provide robust guarantees against failures (hardware, network, etc.) and handles dynamically a load spike is a non-trivial task. we have developed a simple web application for selling e-tickets (print@home).Composed by 4 independent components :
(i.e.) web front-end, user manager, ticket manager, e-ticket generator.
Each component can be regarded as a stateless, standalone and self-contained web service. Figure 1 depicts the application architecture. A token (or a session ID) is assigned to each customer’s browser by the web front-end and is passed to each component along with the requests. This token is used as a key in the key-value database to store the details of the client’s shopping cart, such as the number of tickets ordered. Note that even if the application uses the concepts of sessions, the components themselves are stateless (i.e. they do not need to keep an internal state between two requests).

Algorithm:

The number of replicas of a service and their placement are handled by a distributed optimization algorithm autonomously executed by the agents. In an untrustworthy environment, where a server agent may be malicious, the functionality of decision making could be implemented directly in the component itself. While being robust to strategic behaviors of server agents, this approach tends to waste resources, as every component would have to perform the tasks of a server agent.
Instead of using a centralized repository for locating services, each server keeps locally a mapping between components and servers. It is maintained by a gossiping algorithm where each agent contacts a random subset (log (N) where N is the total number of servers) of remote
agents and exchanges information about the services running on their respective server. Contrary to usual web services architectures, there is no central repository for locating a service, but each agent maintains its own local registry.

Modules:

o A web front-end, which is the entry point of the application and serves the HTML pages to the end user.
o A user manager for managing the profiles of the customers. The profiles are stored in a highly scalable, eventually consistent, distributed, structured key-value store.
o A ticket manager for managing the amount of available tickets of an event. This component uses a relational database management system.
o An e-ticket generator that produces e-tickets in PDF format (print@home).

Server agent

The server agent is a special component that resides at each server and is responsible for managing the resources of the server according to our economic-based approach.

Routing table

A component may be hosted by several servers; therefore we consider 4 different policies that a server s may use for choosing the replica of a component:
_ a proximity-based policy: thanks to the labels attached to each server, the geographically nearest replica is chosen;
_ a rent-based policy: the least loaded server is chosen; this decision is based on the rent price of the servers.
_ a random-based policy: a random replica is chosen.
_ a net benefit-based policy: the geographically closest and least loaded replica. For every replica of the component residing at server j, we compute a weight.

Hardware Required:

System : Pentium IV 2.4 GHz
Hard Disk : 40 GB
Floppy Drive : 1.44 MB
Monitor : 15 VGA color
Mouse : Logitech.
Keyboard : 110 keys enhanced
RAM : 256 MB

Software Required:

O/S : Windows XP.
Language : Asp.Net, c#.
Data Base : Sql Server 2005.

Comments are closed.