• Products
  • Solutions
  • Customers
  • Resources
  • Company
  • Pricing
  • Download
Try Playground
  • NCache Architecture
  • Dynamic Clustering
Show / Hide Table of Contents
  • Administrator's Guide
  • NCache Architecture
    • Cache Topologies
      • Partitioned Topologies
      • Replicated Topology
      • Mirrored Topology
      • Scalability in Topologies
    • Dynamic Clustering
    • Local Cache
    • Cache Client
    • Client Cache
    • Bridge for WAN Replication
    • Connectivity with Load Balancer
    • Serialization Format
    • Data Encryption
    • Data Compression
    • Data Load Balancing
    • Pipelining
    • Cache Server Backward Compatibility
    • Client Backward Compatibility
    • Eviction
    • Indexing
    • Split-Brain
    • Maintenance Mode
    • Runtime Data Sharing
    • Portable Data Types
    • Class Versioning
    • IP Binding with Multiple NICs
    • Graceful Node Down
    • Separate Cache Host Process
    • Self Healing Dynamic Clustering
    • Distributed Cache with Persistence
  • NCache Management Center
  • Configure Caches
    • Create a Cache
      • Local Cache Overview
        • Local Cache
        • Local Cache with Persistence
        • Pub/Sub Messaging Cache
        • Add Existing Cache
      • Clustered Cache Overview
        • Distributed Cache
        • Persistent Distributed Cache
        • Pub/Sub Messaging Cache
        • Add Existing Clustered Cache
        • Troubleshooting
    • Remove Cache
    • Clear Cache
    • Add Server Node
    • Remove Server Node
    • Add Test Data
    • Configure Query Indexes
    • Configure JSON Query Indexes
    • Compact Serialization
      • Non-Generic Registration
      • Non-Generic Unregistration
      • Generic Registration
      • Using Type Handler
    • Deploy Providers
    • Configure Custom Dependency
    • Add Data Source Providers
      • Read-Through Provider
      • Write-Through Provider
      • Write-Behind Provider
    • Loader and Refresher
    • Configure Maintenance Mode
      • Stop for Maintenance Mode
      • Exit Maintenance Mode
    • Configure LINQPad
      • Configure LinqPad for NCache
      • Querying Data in LinqPad
  • Configure Clients
    • Add Client Node
    • Remove Client Node
  • Configure Client Cache
    • Create Client Cache
    • Create Client Cache with NuGet
    • Enable Client Cache on Client Nodes
    • Disable Client Cache on Client Nodes
    • Remove Client Cache
  • Management Operations
    • Start Cache
    • Stop Cache
    • Restart Cache
    • Manage Cache Service on a Server Node
    • Memory Dumps
    • Data Load Balancing
    • Invoke Refresher Dataset
    • Import/Export Cache Data
    • Import Lucene Indexes
    • Suspend/Resume NCache Data Persistence
    • Backup and Restore NCache Persisted Data
  • Cache Settings
    • General Cache Settings
      • Cache Size
      • Cache Isolation Levels
      • Cache Serialization Format
      • Cache Data Expiration
    • Cache Cluster Settings
      • Ports
      • Operation Timeout
      • Configure Pipelining
      • Static Replication Interval
      • Connection Retries
      • Retry Interval
      • Split-Brain Auto Recovery
    • NCache Persistence Settings
      • Store Information
      • Persistence Interval
    • Error Logging
    • Cache Level Events
    • Client Activity Events
    • Eviction Policy
    • MapReduce
    • Register Classes for Portable Data Sharing
    • Compression
    • Email Notifications
    • Bind IP with Multiple NICs
      • Bind Cluster with a Dedicated IP
      • Bind Client/Server with a Dedicated IP
    • Heartbeat
    • Keep Alive
    • Client Death Detection
    • Communication Reliability
    • Auto Start Cache on Boot
    • Nagle's Algorithm
    • Dual Socket
    • Configuration Files
      • Client Side Configurations
        • Client Config
        • EFCaching Config
      • Server Side Configurations
        • Cache Config
        • Bridge Config
        • Modules Config
        • Security Config
        • TLS Config
        • Monitoring Config
        • Emails Template
  • Cache Server Settings
    • Server Connectivity
    • Bind to Multiple NICs
    • Server Ports
    • Memory
    • Custom Dependency
    • Request Inquiry
    • Windows Events
    • Message Events
    • Expiration & Eviction
    • SQL Server
    • Logging
    • Monitoring
    • Persistence Data Loading Retries
    • Miscellaneous Configurations
  • Bridge Server Settings
  • Cache Client Settings
  • Client Cache Settings
  • Configure Security
    • Configure Authentication and Authorization
    • Configure Encryption for Cache
    • Configure TLS Encryption
    • Configure HTTPS for NCache Management Center
  • Configure Bridge for WAN Replication
    • Create Bridge
    • Add Clustered Caches to Bridge
    • Configure Bridge Settings
    • Change Cache Synchronization Modes
    • Bridge Management
    • Synchronize Caches in Bridge
    • Leave Bridge
    • Remove Cache from Bridge
    • Configure Conflict Resolver
  • Setup Database for Cache Synchronization
    • Setup SQL Server Environment
    • Setup Oracle Database Environment
    • Setup OleDb Environment
    • Setup SQL Server for CLR Procedures
  • Simulate NCache Usage
  • Monitor Caches
    • Counters
      • Distributed Cache Counters
      • Distributed Cache with Persistence Counters
      • Pub/Sub Messaging Cache Counters
      • Distributed Lucene Cache Counters
      • Cache Client Counters
      • Bridge Counters
    • Monitor NCache using the NCache Management Center
      • Using Tabular Statistics
        • Configure Counters to Display Caching Statistics
        • Configure Counters to Display Pub/Sub Statistics
        • Configure Counters to Display Lucene Statistics
        • Configure Counters to Display Bridge Statistics
        • Browse Cache Statistics
        • Monitor Bridge
      • Using Monitoring Dashboards
        • Configure Monitor Settings
        • Configure Event Logging
        • Configure API Logging
        • Monitor with a Built-In NCache Monitor Dashboard
        • Monitor with the NCache Monitor Custom Dashboard
        • Monitor Cluster Connectivity
        • Monitor Cache Clusters using NCache Email Alerts
    • Monitor Cache Using Command Line Tools
      • Monitor Cache Server Statistics with Command Line Tools
      • Monitor Cache Client Statistics with Command Line Tools
    • Monitor NCache Using Windows PerfMon Tool
      • Monitoring Cache Server Counters using PerfMon
      • Monitoring Cache Client Counters using PerfMon
      • Monitor Bridge Counters Using PerfMon Tool
    • Monitor NCache using Prometheus
    • Monitor NCache using Grafana
    • Monitor NCache Using SNMP Counters
    • Monitor NCache Using JMX Counters
    • Logging
      • NCache Log Viewer
      • Performance Counters Logging
      • Windows Event Logging
      • Cache Health Alerts
      • Email Notifications on NCache Events
      • Cache Server Logging
      • Client Side API Logging
      • Cache Event IDs
      • Feature Usage Logging
    • Troubleshooting NCache Monitoring
      • Computer Name Not Found
      • Diskperf Not Installed
      • No READ Access to Perflib Subkeys
      • Unable to Connect to Remote Server
    • IPV6 Support

Dynamic Clustering in In-Memory Distributed Cache

The NCache in-memory distributed cache cluster is self-healing, dynamic, and highly scalable. You can add or remove cache servers at runtime, without application downtime. The NCache cluster provides linear scalability in terms of handling application request processing and data. When your cache cluster reaches its peak limits you can add more servers to redistribute the requests and data loads.

If a cache server goes down, the cache cluster automatically detects the server failure and adjusts accordingly. Let's consider a case when a cache server goes down in the Partition-Replica Topology, the cache cluster automatically rearranges the partitions and the data. The remaining cache servers copy the leftover data of the server that went down from its backup server.

Every clustered cache has a dedicated TCP-based cluster. The applications talk to the cache cluster over TCP. So, if the application process goes down, it does not affect the cache cluster. Every cache cluster requires a separate TCP port at the time of configuring a clustered cache. The Partition-Replica Topology occupies one extra TCP port for the replica.

The Peer-to-Peer architecture allows every cache server to establish a TCP connection with every other cache server. This enables cache servers to either directly talk to each other whenever necessary or broadcast the requests at other times. The cache cluster, multi-threaded architecture allows executing operations in parallel, thus, reaping the benefits of today's powerful hardware.

You can configure the request timeout for the cache cluster at the time of configuring the cache cluster. The default request timeout is 60 seconds.

Note

This feature is also available in NCache Professional.

Note

Cluster port(s) assigned to the cache cluster should be available on all configured cache servers. Similarly, the firewall should be configured to allow communication between cache servers on given cluster ports. The default cluster port range starts from 7800.

Cluster Coordinator in an In-Memory Distributed Cache

In a distributed environment, the coordination of different tasks is inevitable. In the cache cluster, the coordinator server plays this vital role. Every cache cluster has one coordinator cache server.

The selection of the coordinator server in NCache is simple. The senior-most cache server assumes the role of the coordinator server. So, the cache server which has joined the cluster first becomes the coordinator server. If a coordinator cache server leaves the cache cluster gracefully or abruptly, the next senior-most cache server becomes the coordinator.

The coordinator cache server is responsible for the following:

  • Cluster Membership: The coordinator server is responsible for accepting membership requests of new cache servers. It also broadcasts the updated membership list to the rest of the servers. Similarly, when a server leaves the cluster, the coordinator server notifies the other servers about the change in membership.

  • Distribution Map Generation: The coordinator server generates the distribution map and manages the replicas whenever a server joins or leaves the cache cluster in the Partitioned and Partition-Replica topologies.

  • Request Ordering: Adding and updating of data in the Replicated Topology requires that the operations on all the cache servers are executed in the same order to achieve data consistency. These operations take sequence tokens from the coordinator server, and execution of the operations takes place according to these sequence tokens. This mechanism guarantees that the same updates against a given CacheItem are applied across the entire cluster.

  • Cache Data Loader and Refresher Management: Cache Startup Loader and Refresher tasks are executed on the coordinator server. When multiple distribution hints are specified for the Cache Startup Loader or Refresher, the coordinator assigns these hints to different cluster members for parallel loading and refreshing.

  • Data Invalidation and Eviction: Every cache server in Replicated and Mirror topologies contains the same set of data. Therefore, the coordinator server is responsible for data invalidation (Expirations and Dependencies) across the entire cluster. The coordinator server determines which items are to be expired or evicted from the cache, and it removes those items from the entire cluster through a cluster call.

How Servers Join and Leave the Cache Cluster in an In-Memory Distributed Cache

The following is the process by which server nodes join and leave the cache cluster:

Member Discovery and Server Joining

When you start the cache on the first cache server, it forms the cache cluster. A member discovery process runs on every cache server upon cache start. In the discovery process, the cache server tries to establish a TCP connection with the other cache members on the configured cluster port.

When the first cache server starts up, and it can not establish a connection with the other cache servers in the cache cluster, it concludes that no other cache server is up. This server then becomes the first member and the coordinator server of the cache cluster. As soon as the other servers start, they go through the same discovery process and establish connections with the running cache servers.

These cache servers seek information about the coordinator server of the cache cluster from already running cache servers. Once the discovery process has concluded and the coordinator server is determined, the newly joining cache servers send join requests to the coordinator.

The coordinator accepts the join requests, generates the distribution map (only in the Partitioned and Partition-Replica topologies), and broadcasts the new membership list to the entire cache cluster.

Graceful Leaving of Server

When you stop the cache on a cache server through the NCache Management Center or PowerShell tools, the leaving cache server informs the coordinator by sending a leave request. The coordinator immediately processes the leave request and generates distribution maps, and broadcasts the new membership list to the entire cluster. Hence, the cluster quickly adjusts according to the new distribution maps.

Abrupt Server Failure

There are cases when a cache server may go down abruptly without informing the coordinator i.e., a power failure. When a cache server goes down abruptly, the TCP connections break between the leaving server and other cache servers. They try to re-establish the TCP connection for a configurable number of retries with the leaving server. This mechanism helps recover from temporary connection failures and prevent the wrong death declaration of a server.

Once connection retries are over, the given cache server concludes the death of the abrupt leaving server. Upon the death conclusion, cache servers inform the coordinator. Although the coordinator may have already discovered the death of a cache server, the information provided by other cache servers results in quick membership adjustment in case the coordinator discovers the death of the server.

Whatever the case is, the coordinator generates the new distribution maps and broadcasts the new membership list across existing cache servers.

Heartbeat

Detection of a broken TCP connection depends on the traffic going through the connection. For example, If the cache cluster is busy and sending requests across different cache servers, then connection breakage is detected early on. However, if the cache cluster has very low activity, detection of TCP connection breakage may take more time.

To avoid this problem, the NCache cluster has a built-in heartbeat mechanism that can be enabled. When the cluster is in an idle state, heartbeat messages are periodically exchanged across servers. Thus, the heartbeat mechanism generates traffic between cache servers and helps early death detection of abruptly leaving servers.

Nagling

NCache cluster supports the parallel execution of multiple requests. The term nagling refers to combining multiple requests into a single one before sending them over the TCP connection. This increases the throughput of the cluster. You can configure nagling and its threshold through the service configuration file.

Cluster Membership Change Alerts

Change in cluster membership is an important activity. So, NCache provides multiple mechanisms to notify the cache administrators and applications about membership changes.

  • Cache logs: Cache logs are the first place to look for membership changes for cache administrators.

  • Event Viewer: Member join and leave notifications are logged into the event viewer on Windows.

  • Email Alerts: You can configure email alerts of servers joining and leaving events for a given cache. Whenever a membership change takes place, an email is generated and sent to the registered email recipients.

  • Application-level Notifications: Client applications can also register notifications callback about cluster membership changes. These callbacks are called whenever any change in cluster membership change occurs.

See Also

Cache Topologies
Local Cache
Cache Client
Client Cache
Bridge for WAN Replication

In This Article
  • Cluster Coordinator in an In-Memory Distributed Cache
  • How Servers Join and Leave the Cache Cluster in an In-Memory Distributed Cache
    • Member Discovery and Server Joining
    • Graceful Leaving of Server
    • Abrupt Server Failure
  • Heartbeat
  • Nagling
  • Cluster Membership Change Alerts
  • See Also

Contact Us

PHONE

+1 (214) 764-6933   (US)

+44 20 7993 8327   (UK)

 
EMAIL

sales@alachisoft.com

support@alachisoft.com

NCache
  • NCache Enterprise
  • NCache Professional
  • Edition Comparison
  • NCache Architecture
  • Benchmarks
Download
Pricing
Try Playground

Deployments
  • Cloud (SaaS & Software)
  • On-Premises
  • Kubernetes
  • Docker
Technical Use Cases
  • ASP.NET Sessions
  • ASP.NET Core Sessions
  • Pub/Sub Messaging
  • Real-Time ASP.NET SignalR
  • Internet of Things (IoT)
  • NoSQL Database
  • Stream Processing
  • Microservices
Resources
  • Magazine Articles
  • Third-Party Articles
  • Articles
  • Videos
  • Whitepapers
  • Shows
  • Talks
  • Blogs
  • Docs
Customer Case Studies
  • Testimonials
  • Customers
Support
  • Schedule a Demo
  • Forum (Google Groups)
  • Tips
Company
  • Leadership
  • Partners
  • News
  • Events
  • Careers
Contact Us

  • EnglishChinese (Simplified)FrenchGermanItalianJapaneseKoreanPortugueseSpanish

  • Contact Us
  •  
  • Sitemap
  •  
  • Terms of Use
  •  
  • Privacy Policy
© Copyright Alachisoft 2002 - 2025. All rights reserved. NCache is a registered trademark of Diyatech Corp.
Back to top