Alachisoft.com
Videos | Webinars | Blogs
Download NCache Now!

Contact Us

NCache: Self Healing Dynamic Clustering

NCache has a self-healing dynamic clustering capability based on a peer-to-peer cluster architecture. NCache does not use Windows Clustering or any other OS-based clustering but 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 cache servers from the 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 cache servers at runtime without stopping the cache
  • Do load balancing for client connections to cache servers (at connection time)
  • Clients automatically reconnect to a different cache server if their server goes down

Peer to Peer Dynamic Cluster

NCache 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.

A cache cluster is a collection of one or more cache servers with every server connected to every other server in the cluster. When a cache 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.

ncache-peer-to-peer-cluster

Runtime Discovery within Cluster

When a server starts, it must know of at least one other server in the cluster but not all of them. Normally, it has names of multiple cache servers in its configuration file. It tries to connect to any one of these servers. Once it connects to any one of them, it asks that server about the identity of the cluster coordinator. Once it finds the cluster coordinator, it asks the coordinator to add it to the membership list of the 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, a cache 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

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

Once the client connects to any one cache server, it receives a host of information from that server at runtime. The client uses this information to help determine which cache servers to connect to and how to access the cache. The client receives the following information from cache 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 cache 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 caching 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 cache server names in the cache 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 cache 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 caching topology.

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

Failover Support: Add/Remove Servers at Runtime

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

  • Failover support within cluster: This means that the cache cluster is self-healing and automatically adjusts itself if a cache 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 cache server can update its connections to all other cache servers.
  • Failover support for cache clients: This means that all the cache clients also automatically adjust themselves if a cache server is added or removed. If a cache server is removed, all clients connected to it automatically move on to other cache servers in the cluster. Similarly, if a cache 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 cache servers from the cluster at runtime without either stopping the cache or your application. NCache 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 caching topologies page.

Local and Remote Clients

NCache supports both local and remote clients or a combination of the two. Remote clients access the cache across the network whereas local clients access the cache on the same machine but in a separate process.

ncache-local-clients

When you install a cache 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 cache remotely.

Hot Apply Configuration Changes

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