• Facebook
  • Twitter
  • Youtube
  • LinedIn
  • RSS
  • Docs
  • Comparisons
  • Blogs
  • Download
  • Contact Us
Download
Show / Hide Table of Contents

Connectivity with Load Balancer

Many enterprise application deployments utilize Load Balancers to distribute traffic and secure internal server IP addresses. In such environments, NCache ensures seamless connectivity through an efficient Load Balancer Connection Logic.

Cluster Connectivity

Such connectivity is critical for distributed cache topologies (Partitioned and Partition-Replica), where the client has to maintain a direct connection to every individual node in the cluster to access the correct data partitions.

Note

This configuration is for Load Balancers using a Round-Robin approach.

Important

Ensure that Sticky Sessions are not enabled and that the Load Balancer allows bidirectional traffic on TCP ports 9800 (Client/Server) and 8250 (Management).

In such circumstances, to ensure that your client connects to all the machines in the cluster (which is necessary for both the Partitioned and Partition-Replica topologies), NCache offers the is-load-balancer configuration.

This configuration works by using multiple requests to establish connections with all the desired servers connected to the Load Balancer. For example, imagine you have a Load Balancer connected to three servers where NCache is already connected to server 1 and needs to be connected to the other servers, it will then send repeated requests until it is connected to server 2 and server 3 sequentially. After the first connection is established, the Load Balancer sends the second request to server 2, NCache will receive the server ID and agree to establish a connection before moving on, as demonstrated below.

Connection Accepted

However, if the Load Balancer sends the request to server 3, NCache will reject the connection and try again, as shown below. This process will continue until it is connected to all the servers or until the specified number of retries has been reached (load-balancer-connection-retries).

Note

The default number of load-balancer-connection-retries is 15 and the minimum number of retries is 2.

Important

The load-balancer-connection-retries tag signifies how often the Load Balancer is prompted per regular connection retry (i.e., connection-retries). Therefore, if connection-retries= 3 and load-balancer-connection-retries= 15, the Load Balancer will be prompted 15 times per retry, totaling 45 prompts to the Load Balancer to get the client connected to the correct machine.

Note

All connection attempts are logged.

Connection Rejected

To enable this flag, you can edit the client.ncconf file (available at %NCHOME%\config in Windows or opt/ncache/config in Linux) by setting is-load-balancer to True.

Note

You can also do this programmatically using the CacheConnectionOptions API.

Bridge Connectivity

NCache also supports Bridge connectivity through a Load Balancer. This is useful in environments where the bridge service or a remote cache cluster is exposed through a single external endpoint instead of direct server IP addresses.

This is especially important in Kubernetes environments, where cache and bridge services are usually abstracted inside the cluster. External access is commonly provided through a Load Balancer, as it provides a single stable endpoint for communication between sites.

In a WAN replication setup, the source cache sends replication operations to the bridge, and the bridge forwards those operations to the target cache. For example, consider two Kubernetes sites: Site A and Site B. Each site has its own cache cluster, and the bridge is deployed as part of one of the sites. When the source cache receives an operation from the client, it sends the operation to the bridge. The bridge then replicates that operation to the target cache.

If the source cache needs to reach the bridge through a Load Balancer, the Load Balancer acts as the external entry point for bridge communication. Similarly, if the bridge needs to reach a remote cache through a Load Balancer, the Load Balancer acts as the external entry point for that cache site.

Important

In Kubernetes or other abstracted environments, bridge-cache connectivity is typically established through an externally accessible Load Balancer endpoint.

To enable this feature, using the Add-BridgeCache cmdlet. Alternatively, you can edit the cache.ncconf and bridge.ncconf (available at %NCHOME%\config in Windows or opt/ncache/config in Linux).

See Also

Cache Topologies
Cache Cluster
Cache Client
Client Cache
Bridge for WAN Replication

Contact Us

PHONE

+1 214-619-2601   (US)

+44 20 7993 8327   (UK)

 
EMAIL

sales@alachisoft.com

support@alachisoft.com

NCache
  • 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 - . All rights reserved. NCache is a registered trademark of Diyatech Corp.
Back to top