Dynamic Clustering
NCache has a dynamic clustering capability based on a peer-to-peer architecture. NCache does not use Windows Clustering but instead creates its own TCP based 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 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 cluster
- 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
- Access cache in InProc or OutProc modes
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.
When a server starts, it looks for other servers in the cluster that are running. If it finds any of them, it asks 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.
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.
Cache Server
A cache server is a process on a machine that hosts your cache. A cache server can be stand-alone in case of a Local Cache or clustered with other cache servers in case of clustered caches.
OutProc Mode
An OutProc cache server is the NCache service process (Alachisoft.NCache.Server.exe located in NCache\bin\service folder) and it can host multiple caches in the same process. All OutProc caches on the same machine are always hosted in the same NCache service process.
OutProc is the most popular mode. It is also the recommended mode for ASP.NET applications, web services, and other N-tier applications running in worker processes. The reason for this is that an OutProc cache is unaffected when your worker processes recycle. Additionally, if your application recycles its processes for any reason, then you should use the cache in OutProc mode.
InProc Mode
An InProc cache server on the other hand is your application process that has started the cache in InProc mode. In this case, all the cache and cluster management exists within your application process. You can start multiple InProc cache servers on the same machine. And, these cache servers can be hosting the same cache clustered together with other instances locally or on other machines, or it can be multiple separate cache either clustered or local.
InProc mode is not recommended for ASP.NET applications, web services, and other N-Tier applications running in worker processes. Since InProc mode means that your application process is itself a cache server, a worker process recycling has the same effect as a cache server leaving and joining the cache cluster. That is the main reason for not recommending InProc mode for these applications.
InProc mode is most popular for Client Cache topology or if your application is running as a service process that does not recycle. Since the Client Cache is usually a small subset of the clustered cache and hosts the most frequently needed data for read-intensive applications, keeping it InProc gives performance boost by avoiding inter-process communication between your application and the cache server. And, since it is not part of the cache cluster, worker process recycling does not affect the cluster performance.
Cache Client
A cache client is your application process connected to a cache server for a specific cache. A cache client can be local or remote and in both cases uses TCP based sockets for connecting to the cache server. NCache uses its own socket based protocol for client to server n.
Some of the main capabilities of client to server communications are as follows:
- Clients can be local or remote
- Clients can be .NET or Java applications
- Clients can use load-balancing info to connect to the most appropriate server
- Clients automatically connect to a different server if current server goes down
- If new cache servers are added to cluster at runtime, this information is propagated to all clients
A cache client connects to a cache server based on cache-id and a cache server machine name. Your application typically provides only the cache-name and the client.ncconf in NCache\config folder keeps a list of servers associated with this cache-id. Here is a sample client.ncconf:
<cache id="myReplicatedCache" node-balance="true"> <server name="192.168.1.60" priority="1"> <server name="192.168.1.61" priority="2"> <cache>
Please note node-balance property. If this is set to "true", then your application connects to the first cache server in the list and asks it to recommend the most appropriate cache server based on how many clients are connected to each cache server. Then, it connects to that recommended cache server. If this property is set to "false", then your client connects to the first cache server in the list specified above.
Either way, a cache client connects to one cache server in the cluster. And, if that server ever goes down, the cache client connects to the next cache server in the server list provided in client.ncconf. Additionally, when a client connects to a cache server, it gets an updated list of all cache servers in the cluster. And anytime the cluster membership changes because new nodes joined or some node left the cluster, the updated membership is sent to all clients. This allows the client to know about all cache servers and addresses the situation where you've added new servers at runtime which are not mentioned in client.ncconf.
Your application connects to a cache by calling InitializeCache() and passing it a cache name. In case of ASP.NET Session State storage, the NCache sessions module makes this call for you based on the cache name that you have specified in your web.config. In case of your application making NCache API calls, you have to call InitializeCache() yourself. Here is sample code that does this in an ASP.NET application:
using Alachisoft.NCache.Web.Caching; public class Global : HttpApplication { public void Application_Start() { Cache cache = NCache.InitializeCache("myReplicatedCache"); } }
When you call InitializeCache(), you're essentially connecting to a running cache server in case of OutProc mode. In case of InProc mode, your application process now becomes a cache server itself (as described earlier in this document).