GigaSpaces Common Clustering Architecture

{color:orange}*Clustering Technologies for High Availability and Scalability *{color}

A GigaSpaces Enterprise Edition cluster is a collection of two or more GigaSpaces space instances that are logically grouped, and collaborate in order to present unified service functionality for the user. Each member in the cluster may reside in a different container on a different host. Each member has a separate identity, but still collaborate "behind the scenes."

The cluster as a whole is policy-based. Each cluster has an XML configuration file specifying the policies that define the cluster behavior. The space members, along with their proxies, collaborate according to these policies.

The two main advantages that clusters offer are high availability and scalability:

High availability - A non-clustered space represents a single point of failure in the architecture. The space runs on a single server, and is often a critical part of the application. If the server is unavailable for any reason (e.g. maintenance or crash), the application cannot function. In a mission-critical-system, this is unacceptable. While high availability is a codename for a wide range of availability requirements, the minimum requirement is independence from a single server machine. Combining replication and failover, a cluster offers a high-availability solution that is both simple and powerful.

Scalability - In a non-clustered setup, the single space often becomes a bottleneck, because it is required to serve requests made by all clients, and maintain connections to all clients. In large, real-time data processing systems, this is often infeasible: The connections and requests must be handled by several servers, each of them serving only a fraction of the clients and requests. GigaSpaces Enterprise Edition offers numerous built-in load balancing policies, which allow users and requests to be spread across a number of spaces in different ways. You can also write your own policies to load-balance between cluster members.

The GigaSpaces cluster supports three main mechanisms:

*1. Replication *

A GigaSpaces cluster can contain replication groups and assign members to any of these groups. The replication mechanism synchronizes between all replication group members, and both full replication and partial replication are supported.

*2. Fail-Over *

A GigaSpaces cluster can also contain fail-over groups. A proxy of a clustered space is fail-over aware. In the event of space member unavailability, the proxy can fail to another space member and continue the user operation, according to the fail-over policy.

*3. Load-Balancing *

A GigaSpaces cluster can contain load-balancing groups. A proxy of a clustered space is load-balancing aware. It can balance the load on the space members in a group, according to the load-balancing policy.

The user can mix and match replication, fail-over and load balancing, tailoring the cluster to his/her specific requirements. This results in a very flexible solution that is suitable to a wide variety of applications.

*The GigaSpaces??? Clustering Architecture *

Two main components ??? the clustered proxy and the replicator ??? were added to the GigaSpaces platform for clustering purposes. Many core components of GigaSpaces have been enhanced to support clustering, among them are the GigaSpaces engine, processor, cache manager, storage adapter, lease manager and proxy.

The following figure depicts the architecture of the clustered GigaSpaces platform:


there are two different spaces, space ???a??? and space ???b,??? and each space belongs to a different container, labeled ???A??? and ???B.??? Space members in a cluster may reside in one or more containers. The ability to run a clustered space inside a single container is especially convenient during development and debugging. Production environments typically run clusters on several physical machines, so in our example containers ???A??? and ???B??? run on two separate machines.

Spaces in a cluster, like any spaces, can be persistent or transient. It is possible to build mixed clusters where some space members are persistent and some are transient. In the case of a clustered persistent space, each space member has its own database tables (and as necessary even its own database server) and it is possible to use different types of databases.

In a clustered space environment, each space member retains its unique identity, each registering its proxies in lookup services and/or JNDI name space. This results in heightened flexibility, since space members can be found and accessed distinctively, despite the fact they are linked in replication groups, for example.

A clustered space member creates and advertises a clustered proxy instead of a regular proxy. The clustered proxy has the following clustering capabilities:

  • Automatic Fail-Over ??? in case of an operation failure of on one space member in the cluster, the clustered proxy can fail-over to another live space member and invoke the operation on the other space member.
  • Load Balancing ??? the clustered proxy is able to distribute operations over a group of space members in the cluster.

In addition, inside the space engine of a replicated space there is a replicator component, which is in charge of sending space updates to other members in the replication group, and handling space updates sent from members in the group.

The replicator components cooperate to synchronize the spaces in the replication group.

Each cluster has an XML configuration file that is accessible from one or more URLs. The cluster configuration file can specify:

  • The cluster name, which is unique in the environment.
  • Space members and their location ??? each space member is identified as a container:space pair, for example: ???A:a??? and ???B:b??? are the space members in the example above. For each space member, location may be provided in a logical or physical format.
  • Groups and policies ??? space members may be grouped and groups may have policies that determine the semantics of the space. Policies exist for replication, fail-over and load balancing.

This thread was imported from the previous forum.
For your reference, the original is available here

asked 2006-02-25 16:35:03 -0500

admin gravatar image

updated 2013-08-08 09:52:00 -0500

jaissefsfex gravatar image
edit retag flag offensive close merge delete