Alachisoft.com

Contact Us

+1 (925) 236-3830 sales@alachisoft.com

support@alachisoft.com

Live Chat

Self-Healing Dynamic Clustering - TayzGrid

TayzGrid has a self-healing dynamic clustering capability based on a peer-to-peer cluster architecture. TayzGrid does not any OS-based clustering and instead creates its own TCP based dynamic cluster of cache servers. The purpose of this dynamic cluster is to provide you 100% uptime by allowing you to add or remove servers from the in-memory data grid cluster at runtime without stopping the dynamic cluster.

With dynamic clustering you can get the following capabilities:

  • 100% uptime for the cluster due to peer to peer architecture
  • Add or remove TayzGrid servers at runtime without stopping anything
  • Do load balancing for client connections to TayzGrid servers (at connection time)
  • Clients automatically reconnect to a different TayzGrid server if their server goes down

Peer to Peer Dynamic Cluster

TayzGrid provides a dynamic clustering capability with 100% uptime for the cluster. This is due to a peer to peer architecture of the cluster where there is no single point of failure.

An in-memory data grid cluster is a collection of one or more data grid servers with every server connected to every other server in the cluster. When an in-memory data grid cluster is formed, it contains a cluster coordinator that manages all membership to the cluster. The coordinator is the oldest server in the cluster (meaning the first server that started). If the coordinator ever goes down, this role passes on to the next senior-most server in the cluster. This removes any single point of failure in cluster membership management.

jvcache-peer-to-peer-cluster

Runtime Discovery within Cluster

The coordinator adds this new server to the cluster membership list at runtime and informs all the other servers in the cluster that a new server has joined the cluster. It also informs the new server about all the members of the cluster. Then, the new server establishes TCP connection with all the servers in the cluster. So, an in-memory data grid server joins the cluster without knowing all the servers in the cluster through this runtime discovery algorithm.

If the new server that has just started is unable to find any other server in the cluster running, it assumes that it is the first one and takes on the role of a coordinator.

Runtime Discovery by Clients

An in-memory data grid client (whether local or remote) does not need to know about all the data grid servers in the cluster upfront in order to connect to the data grid cluster. It only needs to know of one data grid server.

Once the client connects to any one data grid server, it receives a host of information from that server at runtime. The client uses this information to help determine which data grid servers to connect to and how to access the data. The client receives the following information from data grid servers at runtime:

  • Cluster membership information: This information is sent to the client when it connects to any one server and also if the cluster membership changes (meaning when you add or remove data grid servers from the cluster).
  • Caching topology information: This information is sent to the client when connection is established. The client uses this information to determine which cache server(s) to connect to. Please see more detail about this in data grid topologies page of this website.
  • Data distribution map: This information is provided only if the caching topology is Partitioned or Partition-Replica Cache. The client uses this information to determine which cache server has what data so it can directly go to that cache server and access it. This information is provided at connection time and also when partitioning map changes because you've added or removed a cache server from cluster.
ncache-dynamic-configuration

All of this means that you don't have to specify all data grid server names in the data grid client configuration file. You only need to specify one server (although you should specify as many servers as you know upfront for redundancy purpose). And, when the data grid client connects to any one server in the cluster, it immediately receives information about all the other servers in the cluster and can then decide whether to connect to all of them or some of them depending on data grid topology.

All the dynamic configuration propagation really simplifies your data grid client configuration as you're keeping most of the information either in the data grid server configuration or within the data grid cluster at runtime.

Failover Support: Add/Remove Servers at Runtime

The self-healing dynamic cluster of TayzGrid provides full failover support. There are two types of failovers that TayzGrid supports:

  • Failover support within cluster: This means that the in-memory data grid cluster is self-healing and automatically adjusts itself if a data grid server is added or removed from the cluster. This adjustment means that cluster membership information is updated and propagated to all the servers within cluster so each data grid server can update its connections to all other data grid servers.
  • Failover support for cache clients: This means that all the data grid clients also automatically adjust themselves if a data grid server is added or removed. If a data grid server is removed, all clients connected to it automatically move on to other data grid servers in the cluster. Similarly, if a data grid server is added to the cluster, the clients learn about it and can choose to connect to it.
dynamic-cluster

All of this allows you to add or remove data grid servers from the cluster at runtime without stopping the data grid cluster or your application. TayzGrid ensures that your application continues running without any interruptions and without any loss of data. The loss of data is prevented through various replication schemes that are discussed on the data grid topologies page.

Local and Remote Clients

TayzGrid supports both local and remote clients or a combination of the two. Remote clients access the data grid across the network whereas local clients access the data grid from one of the data grid servers but in a separate process.

ncache-local-clients

When you install a data grid server on a machine, local client libraries and assemblies are automatically included. But for a remote client scenario, you have to specially install remote client libraries on your web or application server machine where your application is running and wants to access the data grid remotely.

Hot Apply Configuration Changes

TayzGrid not only allows you to add or remove data grid servers at runtime but also allows you to change some of the data grid configuration information at runtime and Hot Apply these changes without stopping the data grid or your application. Hot Apply means apply the changes without stopping the data grid or the application.


What to Do Next?