WAN Replication for Multi-Datacenter Deployment of NCache

Recorded webinar
By Ron Hussain and Zack Khan

This webinar will show you everything you need to know about the NCache Bridge feature for WAN replication of cache across data centers.

Here is what this webinar covers:

  • NCache's Bridge feature for WAN Replication
  • NCache Bridge Topology (Active-Active, Active-Passive, 3+ Active-Active Data Centers)
  • Advanced Bridge features:
    • Bridge high availability and fail-over
    • Dynamic conflict resolver
    • Parallel & Bulk Async Replication
    • Queue Optimization
  • Queue Multi-site sessions feature
  • Bridge performance/debugging monitoring options

Today's webinar topic is going to be WAN Replication for a Multi-Datacenter Deployment using NCache. In today's webinar, we're going to cover NCache's bridge feature. Which also includes NCache's bridge topology, the advanced bridge features NCache has, queueing multi-site sessions, as well as bridge performance and debugging monitoring options.

Today we have lined up a very important topic. Specifically, for applications which are deployed in multiple datacenters. These could be for various reasons. For example, you need a DR site, you need active-active multi-data center deployment or it could be east to west migration of data that you need.

So, we have a WAN replication feature available, with the help of our bridge topology and I’ll cover all the details. How to use object caching while you have WAN replication turned on. Use it for active-passive, active-active and multiple active-active, you know, datacenter deployments. So, we have a lot to cover. I believe everybody can see my screen and hear me fine. If I can get quick confirmations through GoTo Meeting questions and answer tab, that would be really good and then we'll quickly get started with the presentation. So, please confirm, if everybody can see our screen and here is fine without any issues.

Introduction to NCache

So, I'll get started with the very basic information about why you need a distributed caching system like NCache? So, typically, it is the application performance and scalability bottleneck that allows the issue, that limits your applications to perform in a faster and then more reliable manner.


Your application tier is very scalable. You can have a web application or a backend application. You can always create a web farm or application server farm, where your application can be deployed on multiple servers. Your load can be distributed. Multiple servers help serve all those application requests in parallel, in combination to one another but all of these applications need to talk to a backend database and that is usually a source of contention. Database becomes a performance, as well as, scalability bottleneck for your application because you cannot scale out database servers and its very expensive resource as well. So, you can always scale up but there's a limit to it how much you can scale up a database server? NoSQL is usually not the answer for it because you need to re-architecture your application. You need to stop using our relational database and start using a NoSQL data source in order to use that and we also have a product called NosDB which is a NoSQL database but we're projecting a different way to handle this and that is through distributed caching system.

So, first of all, solution to this scalability problem is very simple, that you start using an in-memory distributed caching system. It's super fast because it's in-memory, in comparison to disk. So, your performance of your application is going to be improved right away as soon as you plugin NCache.

Secondly, it's a team of servers. It's a cache cluster. It's not just a single source like database. You have multiple servers joined in a cache cluster. So, it's a logical, you know, storage which is pooled by many servers that you can choose to add. That makes it very scalable in comparison to your relational databases. You can start off with 2 servers and you can add more servers at runtime. So, it makes it more and more scalable and as a matter of fact linearly scalable, where you can add more servers and as a result you keep increasing your request handling capacity out of NCache. Nice thing about NCache is that you use it in addition to a back-end database, a relational database. There are a lot of features which complement you use of data that comes from a backend database. So, you can always use NCache in conjunction with your relational database. It's not a replacement of your relational data sources. Some scalability numbers.


NCache is very scalable, as you add more servers NCache allows you to handle more and more requests out of NCache cluster. We recently conducted these tests in our QA environment. We use our AWS lab, where we kept on increasing load and also kept on adding more servers and up to 5 NCache servers, which is a very regular configuration for our distributed cache. We were able to achieve 2 Million requests per second and that was an upward increasing trend where we, whenever we added more servers, we added more capacity to the cache cluster. With an average 1 Kilobyte object size, this is the kind of performance you can also expect out of NCache and with better hardware you can even stretch these numbers and get better performance throughput out of NCache. By the way these benchmarks, there's a whitepaper and a video demonstration published on our website as well. So, you can also take a look at that as well.

Some deployment details. How would a typical deployment of NCache is going to look like.


Here is a single-site deployment of NCache. As you can see, we have a single-site and in your case, what we talk about the WAN replication aspect of it, obviously we would have more than one deployment we would have a separate datacenter, where we would also have NCache and applications deployed.

So, with our distributed cache deployment, as shown in the diagram, let's talk about how a typical deployment looks like. So, we have a team of servers again. We have 4 to 5 servers showing in the diagram, that is where your cache cluster is hosted and as you can see, it sits in between your application and database. The idea here is that you use these sources in combination to one another, for object caching but for session caching, cache becomes your main source of data. So, all your sessions can be stored in NCache and you don't have to go anywhere else. A very flexible deployment model is available. NCache can be hosted on premise. It could be physical or virtual boxes. It could also be in cloud. It could be public or private cloud. It could also be on Azure AWS, because we have marketplace images available for both of these cloud vendors. But, in general, any server which has Windows or Linux and only prerequisite for NCache is .NET or .NET Core Framework. So, these are prereq. It's just .NET and .NET Core which NCache needs as a prereq. If that is available, NCache is very flexible to be deployed on Windows as well as on Linux environments and like I said it could be any environment as well, it could be, you can use Docker and you can also host NCache in Kubernetes cluster and that opens up a lot of other platforms. You can use it in OpenShift. You can use it in Azure Kubernetes service. You know, Elastic Kubernetes service as well. So, all those, you know, platforms are equipped and NCache is equipped to be deployed on all those platforms.

There are two deployment options. One is that you go with the dedicated cache tier, as shown in diagram and the second one is, and in dedicated your applications run on separate boxes and NCache runs on a separate dedicated tier. We also have a shared tier, approach available as well, where you can also run NCache alongside your application boxes. So, wherever your applications are hosted NCache can be hosted on top of it. So, I believe this is pretty straightforward. In a multi datacenter deployment you would have more than one datacenter’s and you would have same deployment for NCache on the other datacenter as well, which we'll cover in upcoming slides and by the way, if there are any questions, you can always post that question in our questions and answer tab and Zack and I will keep, you know, keep an eye out for all those questions which are going to be posted and we'll be very happy to answer all those questions for you. Speaking of questions, since you mentioned it just now, I have one that I’d like to bring out is, well it was very simple you were mentioning Kubernetes now. So, the question was, we're going to talk about bridges and this in general, are there any operating system requirements for all of this? Are you able to run this on Linux? Absolutely. NCache is very flexible. As you can see, even on our deployment diagram. You can see NCache is supported on Windows and Linux servers. So, on Linux servers, you just need .NET Core release of NCache and we have a server as well as client for these. So, if you want to run NCache servers on .NET on Linux using .NET Core that's possible and then your applications can always use our .NET Core release and be deployed on Windows as well as Linux, so, yes. Awesome. I'll let you actually go through the rest of it and I'll bring up the questions later.

Multi-Datacenter Deployment of NCache

So, next we'll talk about Multi-Datacenter deployment of NCache. Now, if your application is deployed on multiple datacenter’s, or it could be that you have one Active site and then we have a Passive site for DR scenarios. For example, the Active site goes down and your application requires that you should be always up and running, if it's a mission critical application, it’s important to your business. Having a downtime on a site level is something that would impact your business.

NCache cluster is designed in such a way that it's already equipped with high availability and data reliability features. So, on a single site level, if one or two servers go down, for example, if you lose a Server, NCache is equipped to handle that outage without any issues. But today we're talking about if we, what happens if we get a site level outage? Or, we need to bring site down for maintenance, entire site being down. So, all the servers are down. NCache is even equipped to handle that scenario and then that's what we're planning to cover today. So, let's talk about why do we need WAN Replication?


Typically, when your applications need high availability, single site can become a single point of failure. If your site goes down, you lose all the data and you can potentially get downtime on your application users and that could impact your business, we've already established that. Multi-Region Apps are slow, if they have to talk to one another across WAN. For example, you have one datacenter deployed, your application deployed in one datacenter which is in US region and then you have another application which is deployed in Europe or any other, for example Asian region. So, in that case, if your application databases are located on one of the datacenters the remote site has to go across network. So, your network speed would impact the latency for that other site. You know, in order to handle that scenario, you usually replicate your data sources across WAN as well and that's what we're recommending for NCache as well, that NCache should be replicated. But, considering that you're, you have a common data source the, remote site has to go across WAN and that could potentially give you a performance impact because data is not local for that site, distance between data centers would also impact your throughput. There is only so much of data that you can transmit between sites. So, that can limit your capacity of request handling.

So, these are two issues if you have multi-regional apps and if both apps are active. Data Replication at request level is expensive as well. For example, you don't replicate entire database and you have data source sitting on one datacenter. Now, a request which goes on our remote location, a geographical location which is remote, to your database. A request level replication for every data, you know, request unit which comes to our data source, that's going to be extremely expensive and that would eat up a lot of bandwidth and resources. So, you need an active mechanism, where you have data locally available and that's why you need WAN Replication of cache needed as a must. So, that your data from one datacenter is replicated across network to the other site.

Some use cases. Why, you know, where exactly you can use WAN Replication?


The most common one, that we come across, is disaster recovery site. You have an active site, that is serving your main business use case. That's where your traffic is being generated and being handled. What if the entire site goes down? You need a fallback option, right. So, that DR site should have data made available already. Otherwise, it would not have that data requirements handled if it has to go back to the site which is already down, right. So, you need data to be made available on the DR site, so, that it's already up and running. You just need to shift your traffic to that DR site. You should not do anything else, just route your traffic to the disaster recovery site and it should work with the same performance value, same performance matrices that you had with the active site. So, 100% data recovery in case of failure is possible, with the help of NCache WAN Replication.

Multi Regional Applications can share data as well as load. Now, with Active-Active sites, if you have one region in US and one in another part of the world, for example, Europe or Asia. If you want that, you know, request from, you know, a datacenter should be handled based on the location affinity, you can achieve that. Now, user from Asia could connect to a site within that region, nearest to that region and they can use the cache over there as well and that cache is in sync with the other cache which is in US region. So, any user which bounces off. For example, you need to manage overflow or you need to distribute capacity. Some of the users need, now need to bounce to US region because Asia region is fully choked, so, you can always do that. So, on a site level, you can load balance your request, based on the capacity that site is handling at that time and at that point in time. Since, cache data is already replicated across datacenters and we'll talk about how to achieve that, so, your multi-regional applications are efficiently able to share their application data and also share the request load and they can have equal load sharing as well. No redundant data migration is done. It's just based on the request bouncing from one datacenter to the other and you can always get that data from the cache which is already connected there.

East to West application data migration is another use case. For example, Asian markets start earlier, than, you know, the Western markets, right. So, your data trend, usually follows from East to West. So, your Eastern site can have our cache set up and with time zone, data moves between datacenter to the Western region and it reaches to the West. So, if you have data replicated across datacenters, the cache data, the Western region would be able to take advantage of all the data, that is made available from the Eastern region. So, you can have East to West data migration made available and the maintenance use case is the third one.

Fourth one, where we can deploy upgrade and maintain without any downtime. That's becoming a very pressing use case, with NCache as well. That, if you're planning to upgrade, you can have upgrades between older and newer versions, using our bridge topology. Where older data, version data can be transmitted to the newer version with live upgrades feature. It could be between sites, for example, you can use one site and replicate data actively to the passive site and you can upgrade, deploy a new code, maintain performance, maintenance on the active site and you have all the data made available and your traffic can be routed to the passive site for that matter. So, both sites can always be up and running without zero downtime and any application data loss.

NCache Bridge for WAN Replication

So, let's talk about how to handle that? The name of the feature is NCache bridge. It's part of the same product. You don't need any separate installation for it. NCache Enterprise is equipped with NCache bridge topology and let's talk about it.

So, our cache, NCache bridge feature allows you to replicate cache across datacenter’s.


It's based on async replication model. It does not incur any performance degradation on the application side. Your cache applications are connected in active to the cache on one datacenter. For example, you have clients here and then you can create a bridge which is also an active-passive queue and that would transmit data to the other sites asynchronously.


So, it's based on async replication, so, there is no performance degradation in replication of data. It's very reliable. It's fault tolerant. It automatically detects connection failures. It automatically reconnects. There are automatic retry options available, so and bridge is also backed up on active-passive queue.

So, there is an Active Bridge server and then there's a Passive Bridge server as well. If Active Bridge server goes down, the Passive would pick up and start all the replication operations without any delays. It's very easy to set up, you don't need any code changes, you don't need any extra installations. It's part of the same product, the Enterprise and it gives its own monitoring and management support, which is integrated into the same NCache Enterprise product and it supports multiple topologies which I’m going to cover next.

So, we have three major topologies.


We have Active-Passive. Where we have an active site and then we have passive site. Passive site is also taking client requests but the data flow is from active to passive. So, if you have DR site requirements, you can use one site to be active, connected to bridge and then you can have other site passive. The active site transmits data to the passive site. So, it's a one-way transmission. The term passive essentially means that passive site is not transmitting data back to active. It is still running and you have client applications take advantage of it. So, it's not something which is stopped by any means. East to west migration can be achieved with active passive. Your maintenance and an upgrade use case can be handled with the help of active-passive.

The active-active topology is, when you have one application deployed on two different geographic locations and you want data from site 1 to be made available on site 2 and site 2’s data made available on site 1. If your application needs data sharing requirements between geographical sites, you can target active-active where you have users active on both datacenters. Clients are connected to both datacenter’s and there is a two-way replication going on between two different sites and then we have 3, 2+ or 3+ active-active topology, where we have one primary bid server, but it's transmitting data to all sites and those sites are also transmitting data back to every other site. So, one update has to be applied on all of the datacenter’s and vice-versa.

So, here is our active-passive.


In this, we have bridge, which is a queue, which is also active-passive. We have cache cluster on site 1, which is just, you know, handling client requests. We have 3 servers here. It's connected to bridge. Bridge also resides on one of the sites. Or in some cases, you can have active bridge on site 1 and passive bridge server on site 2. That’s also possible but we typically recommend that you move bridge on one of the, one of the sites in your deployment architecture. The second site is passive site and again by passive it's still running. It's just that the passive site does not replicate data back to the active. It's one way transmission of data and that's all it means when we say this is a passive site. You can essentially run client applications here and it's fully functional even in this state. So, it's a replication of data, active passive, so, if this server goes down, the passive becomes activated and it's automatic. No code changes are needed. I'll show you how to configure bridge, once we progress to our hands-on portion. So, it's pretty simple.

A question came in and it has to do with this active-passive, it's, primarily if you have an active and a passive site how do you make the passive site activated? Is it a manual process? Is the site stopped? How do you do that? Okay, so, if I’ve understood this question correctly, the passive site in terms of how we activate it? It's already activated. It's running and if we bring this site down or we want to move traffic here, it's your application traffic load that you need to move to this site. So, you have application servers here, you have application servers here, whatever data that you have is going to be transmitted here and this site users can have the data made available from the cache itself. Now, you can always route your traffic to the passive site and you can get all the data made available. So, there are no steps needed in order to make it activated. However, if you want this site to start transmitting data back to the active site as well, you can make it active by using our GUI tools. So, in terms of replication, if you want this to be replicating data back to the active, so, you can always make this active and this is a runtime process. So, you can just with one line of, with one click in the GUI tool you can achieve that or you can use our PowerShell tool to make that happen. But if your question is in regards to making the passive node active. If there is a manual step in order to have client applications connect to it and be able to use data, it's already running. Your applications start using it by if you start routing traffic to this cache cluster. So, within your load balancer. You switch this site off and route all your traffic to the available site, which is up and running already and you can get/take advantage of all the data which is being replicated.

So, active-active, it's again based on same principle. Where we have bridges running on one of the sites.


We have cache 1, cache 2. Both sites are active and even the passive topology can be turned into active, by right clicking and making it active and in this case data from site 1 cache is transmitted to site 2, asynchronously from cache to bridge and from bridge to cache and then similarly, site 2 is also transferring data back to site 1.


3+ active-active datacenter’s, where we have three or plus active-active, where we have one of the sites as bridge server. We can also have a fallback site for bridge. We can have a backup bridge site as well. But, in general we would have one of the sites which would hosting, which would be hosting bridge and then that site is transmitting data to other sites and similarly site 2 is transferring data to site 1 through bridge and to site 3. And for active-active, we have conflict resolution which is time based, so, last update wins. All the data structures that we use are conflict free. These are conflict-free data types. There are no race conditions or any you know data consistency issues because last update is going to be, be applied on the cache cluster across the board. So, NCache manages if there are two updates for the same key come in, NCache would evaluate that and would also allow you to build your own conflict resolution, if that's a requirement. So, it's managed as part of NCache topologies.

So, here's a quick peek into our bridge configurations.


We have NCache bridge config. NCache Bridge is the name and then we have LondonCache environment 1, so, that you can have multiple caches with the same name as well. NewYorkCache and these are connected.

Hands-on Demo NCache

So, let me actually show you all of this in action, how to configure a bridge? How to get started with it and then we'll actually show you object caching and session caching applications. Before you get into that Ron, I had a question come up just on the previous slide with the code and the question is what are the code changes that are involved in order to set up the bridge? Do they need to write any code in order to have the data replicated through the bridge? Not at all. We don't need any code. It's just a configuration. So, you have cache 1 on datacenter 1 and cache 2 on datacenter 2. You simply configure bridge and whatever data that's already being added by your applications in into NCache, is going to be replicated through bridge automatically. So, it's bridge’s responsibility to take charge of all the replication. You don't need to write any code explicitly to have data replicated across datacenter’s and when we say the data types, the conflict resolution, that is something which is also implemented by default, which is time based but if you want to implement your own conflict resolution, if your business requirements are that you evaluate objects, in case multiple updates come in, in that case you can implement that interface. But as far as replication of data is concerned, it's bridge’s responsibility. You don't have to write any code for that.

Create Caches

So, let me quickly get started, I’m going to create a cache.


Let's say, I’m going to name site1cache or let me actually use this right here SiteOneCache. This is just to give you an idea how to quickly get started and be able to create the bridge. I'll keep everything default, because NCache architecture covers all these details.


So, I’m going to quickly go through them. Partition of Replica cache, any cluster. Topology async replication. I'm going to choose 101 and let's see if I can pick 102, if that's available. These are my two servers, to host the bridge. I’ll keep all of this default. Start this and auto start as well. Finish. So, my cache one is on 101 and 102, which is going to be created. Let's see how it goes and then I’ll go ahead and create another cache which would be on separate set of servers and then I’ll host the bridge and show you how this would all work out. Right. So, we have SiteOneCache fully configured. As you can see, it started as well.


Now, I’m going to go ahead and create actually, I’m going to create another cache, which is SiteTwoCache. I think, I can use that. I was playing around with it earlier on. Keep everything simple and this time I’m going to give separate set of servers, so that we represent this as a separate site altogether. Keep everything default and by the way our bridge allows you to have remote management of all sites, from the management & monetary tools allow you to actually manage all the sites along with bridge, from one central location. So, if you have network access. If there's a WAN link available between your SiteOne and SiteTwo, you can essentially manage everything. So, we have SiteTwoCache right here. SiteOneCache right here. 101 102 representing SiteOneCache. 107 and 108 representing SiteTwoCache. Now, and these are started as well.


If I click on statistics you can see there are no objects added here as yet. Data is not added in SiteOneCache or SiteTwoCache, so, we're good. I would simply run this. I think, I have permissions issue to review this counter. I think, I can, okay. So, you can see there are no items available as yet. I'm now going to link these two caches with the help of a bridge, which I will configure next.

Create a Bridge

So, here we're going to create a bridge.


So, I will just say NCacheDemoBridge.


You can come up with any name and bridge can be on any servers. For example, on 107. Let me just give my box, there you go. So, let me just create bridge on 101 and 102. I have permissions issues. So, let me just see if I can add 107, otherwise, I'll just use one server for the bridge. This requires certain ports to be opened. So, I think my machine has all those ports open. So, let me just use 101 for now. One server is good enough. The backup server is not there but we can always add it and I’ll keep everything default and choose Finish. Auto start the bridge, when it starts up, that's also a possibility and then if I click on View Details on the bridge, for example, if I click right here, that would open all the bridge settings that we have. Here you can specify, you can add more Nodes to the bridge, if needed and you can also add more caches, which would act as active or passive. So, if I click on Add, for some reason it's not letting me actually add. Please bear with me. I can sneak in a question while we wait. Sure, please go ahead. Sure, yeah, one just came up. It's a pretty straightforward one, it's has to do with how do you ensure secure data transmission? We have encryption features available. So, if you have cache level encryption or security turned on, bridge will obey that. So, whatever transmitting being transmitted between CacheOne and CacheTwo is going to be encrypted, if you have encryption and security turned off, turned on. So, we have, AES, DES, FIPS compliant encryption providers as well. We have TLS 1.2 supported as well. So, we have Transport Level Security, as well as Payload Level Security encryption features. So, you can take advantage of those features.

Add Caches to the Bridge

All right, so, I'm going to select one of the caches, SiteOneCache right here, right. So, I can choose it to be Active or Passive. I'm going to go with Active and choose Finish.


So, SiteOneCache is added under the bridge. Now I'm going to add the second cache, which is from 107 box. I hope that I’m able to open the service control manager. I am. Select it, SiteTwoCache. Let's make it again Active. If you choose Passive, it's going to be site one to site two cache but if you choose active, it's between site one to site two and site two to site one replication of data. Let's choose finish.

Monitor Bridge Statistics

So, you can also review bridge counters. For example, if I come right here and open statistics of bridge from here, I can always see the counters of the bridge as well. Let me actually start this first. For some reason it's, the system is not very responsive, so, please bear with me and let me open the statistics window. So, here is our bridge. Nothing is being replicated as yet because we don't have any load at all.


So, I’m just going to simulate some load by running a stress test tool, siteonecache.


Since we have counters available so, we would have a client connected and would start simulating. Although we've run this only for SiteOneCache, as soon as it connects. So, please bear with me. So, let me actually open monitor to review if it's indeed being connected to the cache or not. I think, it is. So, bridge has some activity, so, which suggests that bridge is now taking requests. Environment is a little sluggish today. I apologize for that but let's review how it goes. Okay, so, since bridge is showing activity. Bridge cache size is growing, operations received and then received per second are showing activity. So, that essentially means that it's replicating data across sites. There you go. So, we have SiteOneCache right here.


If we go open the, let me actually log into our demo environment, so that, we see the correct view of counters from there. I think that should help us review any permission related issues as well because it's taking awfully long time to actually load this and I’m not able to see counter activity as well. All right. So, let me launch this web manager here. There you go. So, although it was not showing counters earlier on, on the local screen but when I logged into SiteTwoCache from that server, the web manager is fully able to see all the counters. So, we have count actively being replicated. I never ran any stresses tool inside two cache but it's actively getting data here. Now, if I stop that or even if I keep that running, I can now run a stresses tool for SiteTwoCache as well and that would replicate data back to my SiteOneCache as well. So, that completes our testing. I think, I should stick to having remote in on this environment as well, so that, we can see activity separately on both environments. So, I'll just use siteonecache from here, bridge from here and sitetwocache from over there.

I am going to cover some application related use cases next. So, please let me know if there are any questions? It's just a pretty basic question but it was mostly just what environments do we support? Again, I know you mentioned a couple earlier but I figured you could just list them all down. Like I said, the only prerequisite for NCache is .NET or .NET Core. You can use NCache on Windows and Linux environments, wherever they are available. It could be on-premise, it could be cloud environment, it could be Azure, AWS, Google Cloud or any other. It could be a hosted environment as well. It's available in Docker, through Docker Container and you can use Docker Images to host your cache and your applications. Kubernetes are also supported. OpenShift, Kubernetes Service, mentioned Azure Kubernetes Service, Elastic Kubernetes Service. So, wherever you can use Docker, you can use NCache over there and it just boils down to one simple fact that if you have .NET Core or .NET installed, that's the only prerequisite for NCache and NCache can essentially run on all those platforms, on all those servers.

Run Sample Application

So, let me actually run, although I am using this bridge right here, I have another bridge which is available. So, let me run another application, which is right here. It’s a load balanced web application. We have designed it in such a way that we can route one request on one datacenter and if that datacenter is down, the subsequent request would go to the other datacenter. So, that would essentially give you a view of how to manage disaster recovery, if you have NCache bridge turned on and you get to have all your data made available.

So, first of all, I would run this from here, where we have, let me just open this from this window, right here. So, let me just get started with the object caching sample. Right, so, let me just run this LondonCache sample and then let me also open the other sample which is available. So, I’m going to get started with Visual Studio. Running the samples. So, as soon as, these samples would run, I would show you that you can essentially use object caching and route request between datacenters as needed.

So, that would give you a visual representation of data being added from one datacenter and retrieved from other and vice versa through our bridge. All right, so, this is using a LondonCache which I have configured right here. If I show you real quick. So, we have a LondonCache and we have NewYorkCache. So, two caches representing two datacenters and then we have a bridge which is NCache bridge. It has LondonCache as CacheOne active and NYCache as second. So, I’m going to stop the bridge for now. Show you these two caches separately and then I’m going to simulate some data and show you how this works in the cache. So, let it run and as soon as it loads up and this is using NYKCache, so, let me just spin this up as well. Now that you know how to configure the bridge, so, it's very simple in terms of connecting these two caches together by running the management tool on any box and be able to configure that bridge. So, please bear with me. It would spin up some instances. It’s awfully slow today, I apologize for that. So, its built event has been completed, so, it would simulate that shortly. Right, so, this is our Main.aspx and within this I’m just loading some objects in the cache. That's all I’m doing. For example, within the, right, so, if I show you the Main.aspx it's actually loading some of the objects in the cache. So, idea here is that we would hit London region site and then we would hit New York region and then I’ll show you how to sync data added from London region to New York and vice versa and a visual representation would make everything a lot more clear in comparison. So, we have both sides up and running we have. Let me just open one right here and the other right here. Now, if I add let's say 10 items, which it allows. 10 items are added. If I retrieve from the same cache, it's showing that this data is added from UK region and UK customers are shown right here.


Similarly, if I add data from the London, US portal it adds 10 items and then you see all those 10 items but what if the, if the user bounces and it needs data from both regions to be made available, simultaneously? So, that's not possible as yet. Let me just add 5 more items here, so, that this is different in terms of numbers. So, we have about 15 items here and 10 items here. So, with just one click away, if I just turn this bridge on, right, and open statistics the first thing that bridge, you know, does is actually replicates all the data that's already in the caches.


So, caches are already connected, as soon as, we started the bridge. We have bridge replicated, replicating 25 items. So, that's exactly what we added. So, if I open the counters of, let me open the LondonCache, as well as, NewYorkCache & open statistics. For some reason this is taking time but eventually it will open. Now, we have statistics right here.


We have clients connected and we have the count value showing right here. So, it's showing about 25 items and that's what you're seeing on the NewYorkCache as well. Now coming back to my application, I would keep the same application running but this time I would just fetch data from here and I expect to see all the items in the cache. So, all 25 items, London, as well as, US items retrieved here because bridge replicated data from CacheOne to CacheTwo and CacheTwo to CacheOne. So, 15 items here are now added with 10 more items to 25 items together and if I fetch data from the cache, the USCache, I see all the items in the US region as well. So, again it's a two-way transmission. It could be more than two. It could be active-passive. Where one-way transmission can be done or active-active as shown in the sample application.

Now, any new item being added, let's say, 20 more items added, let's say and you fetch from here, you get 45 items and if I fetch those items from here you would see 45 items here. So, it's in instantaneous. Any items here added here, let's say, add data on the, that would increase the count from 45 to 68 but if I fetch data from here, I get same items made available from here. So, see how fast it is in replicating data between different sites. So, these two caches are, and these caches are also running on multiple servers as we speak. So, that completes our object caching demonstration.

ASP.NET Sessions Replication Across Data Centers

Let me also show you how to handle this through if you're using ASP.NET sessions. In multi-sites, you know, you can also have ASP.NET sessions. So, for example, if this is through a load balancer, I would just add some items, that's a separate application. We have two web servers, site one web server and site two web server, hosting the same application across datacenters. So, I’ll just add some items. So, as soon as it adds and let me actually stop the bridge one more time. If I view cart. So, we have one item added. Let’s say add some more items. So, we have some items made available. Now if I go to IIS, you know, the London Site. Let me just actually start this as well, right. Bring back here, you got, I really hope that it hits London Site as a priority. We don't have any items over there, so, let's see where it ends up and then we'll connect the bridge and show you that whatever data that you add from Site One is made available on Site Two and vice versa. First request is usually slow. I just started the application, there you go. So, if we got here, we get 0 items returned. So, these two sites are out of sync, although your user session is bouncing from one site to the other, whenever we start or stop the site.

Now, I would simply turn on the bridge, on the same lines, as we've done earlier on. Right. So, it would run and it's going to start. Again, I'm going to see statistics. So, 69 items are there, you know, these are from the previous test. But now, if I come back to my site right here. Right. Let's start over. We've added some items. Let’s keep doing that. Now coincidentally, if this or if it goes down due to power failure or you bring it down, if I bring London site down, the only site is the, you know, the New York site is still up and running, so, if I simply hit view cart, same data items are made available from the US portal and it has data added from the UK site. So, you can see data being bounced from one site to the other and your user still gets the data back. Now, if even the site becomes back, you know, comes back online, it would again be able to fetch all the session data from the cache.

Multi-Site ASP.NET Sessions

Similarly, we have multi-sites ASP.NET sessions. That's a separate feature. So, we recommend bridge for your object caching scenarios, where we have a lot of data transmission happening behind the scenes between two caches and we've seen that for object caching as well as for session caching.


But for session caching, we also have Multi-Sites ASP.NET session caching use case as well. So, if I don't use the bridge. I still can link these two sites together and that is through a separate feature which is available and for that I will just stop the bridge. As soon as it stops, I'm going to come back here. Let me just clear contents, so that we start over and that's actually a better way of synchronizing your cache for session caching. Reasons for that, session is a very transactional data. So, you don't want your session data being replicated, although your user is not bouncing from one site to the other, right. So, if your user is mostly on one site and because it's a human user having ASP.NET sessions. So, in that case it's a transactional data which is transient in nature, it would not be needed on the other site. It's only based on the user which is there and if you end up changing your user from one site to the other, that could be managed with on-demand replication of data. You don't need to replicate all session data. For example, overflow happens where one site is being more, hitting more capacity than other and you want overflow users to go to the other site and they already had a session object created here. So, you don't need all sessions there. You just need sessions of that particular user. So, in order to cater for that scenario, we don't recommend that you turn on bridge.

So, for that we have another feature called NCache Multi Site session. So Multi-Region ASP.NET sessions State Provider allows you to actually achieve all of that, without using bridge.


So, you have site one cache, which has sessions and we have site two cache and site one has primary cache address and then the backup cache address across region and similarly site two cache has primary and backup concept. So, if a user bounces from one site to other, your cache clients which are your Application servers, would go to the other site on demand and they would get the session data made available from there and all it needs is information to other site cache, for example, we have primary cache and secondary cache, London, New York and you can have multiple of backup caches. So, in case London user bounces to New York site, it would go back to LondonCache and would fetch the data and keep it there and in order to demonstrate that I would again get started with a cache application. For example, I add some data here, again this is using LondonCache. Add items here. Remember I've cleared the contents in the cache, so, we don't have any items here and similarly let me just open the LondonCache statistics. So, we don't have any items here, until the first request comes in. Let's say, add. So, we have two items, with the same name of course. So, one session is created here. It's not replicated on New York site as yet but we have Multi-Site session feature enabled. We don't need bridge for this, because we want on-demand session replication to be done. We've done these configurations, where we have primary cache and secondary cache and then we have session state provider plugged in.

So, it's just based on session state provider settings, NCache is able to handle Multi-Site session use case without using bridge and it's on demand, so, it's much more efficient as far as session data is concerned. So, what I would do now is, I would bounce the session request back to other site by going to IIS and I would stop the London site completely. I would keep the cache up and running of course and if I now fetch this. First of all, it would get the data from the US site. Same items would be made available from there and as soon as it completes, I would add some more item and bring the LondonCache back up online. So, it's an on-demand replication, which I’m trying to demonstrate. So, let's see how it goes. Let's say, let me add some items. So, let me turn this site back online. Since it's sticky to the London site. So, now that I've brought the US user back to London site, let's see how it goes. So, same items are made available from the London site as well and the data elements were added from the US region. If I add some more item here, I would be able to add those items here as well. Let me simulate this failure one more time by stopping this site and let's see if it bounces to the other side as well. I think there's some configuration related issues previously but now that this site is stopped. Let me just view cart. I expect, there you go. So, the same session is now made available from the US site and remember I don't have any bridge configured here for this feature, it's just the Multi-Site session. Bridge is stopped. It’s still replicating data but it's on demand. So, that actually completes it.

For object caching and less transactional data, reference data and static data, we recommend that you turn on bridge and take advantage of active replication between datacenters but session is a transactional use case which has read and write request, you know, combination. So, it's very heavy while you're updating data from one datacenter to the other data has already changed on the primary datacenter and session user does not bounce from one datacenter to the other. It would be only on one site at any given point in time. So, you don't need active data replication. You can have on demand replication. When it bounces from region one to region two, you should be able to get the session data from there and if it bounces back to region one, you should again be able to get the session data made available and for that we recommend that you use our Multi-Site session feature without bridge.

There are some advanced features which I would quickly discuss.


Bridge is highly available. Failover support is built into it, any bridge server going down will not incur any downtime. Bridge queue is very optimized. It's fast. Additionally, you can enable some queue optimization features, which would make it further optimum.


Conflict resolution is built into it. Last update wins but if you want to implement your own conflict resolution, so, you can use a handler and register with NCache. So, this interface can be called, in case there is a conflict of two keys, where two updates happen to occur at the same time. So, NCache would give you control and you can verify version of that item and take decision which one wins.

Handling disaster at Runtime. Zack initially asked how to make the Passive site Active, you just need to route traffic to the Passive.


If Active site ever goes down and there is no downtime and automatic resync happens if the Active comes back up. In Active-Active traffic is routed to both sites. Any site going down would not have an impact you just need to route traffic back to the active and if the active the other active comes back online the resyncing is done automatically. There is no delays, no manual intervention needed. In two plus or three or more Active-Active cases, if non-bridge active site goes down, you just need to use the traffic to the any other site and there would be no downtime or data loss. In case, the bridge active site goes down, for example, if we have one bridge site right here.


If this goes down, we have an option of backup bridge site as well. So, you can turn that bridge site enabled and for that you can specify the backup bridge to pick up replication. So, replication would stop, if the entire bridge site goes down but we have option of backup bridge site as well.

So, I want to cover these aspects real quick. I think that should be enough for now. Any questions so far? Zack you can pick it up from here. Sure, I know, we're running on the last minute or two here so, I’ll just toss in one question that came in on what you revised just now. It had to do with conflict resolution and I believe the question is what are the examples of conflict resolution where we would need to implement it? Okay. Typically, most of your conflict resolution would be handled by default, where you don't need to implement anything. The time-based conflict resolution is all what you need. With an expectation that you're running Active-Active sites and you need data from one datacenter to the other you need updates from one datacenter to the other. So, last update wins. But, in case where data is more specific and you want to have value of the data and that would determine what object should be kept in the bridge. For example, there is certain version or certain information or certain sequence number within the object definition, for example, there is a version attribute of an object. So, if there is a conflict you don't want that object to be missed. So, you check that object through the code, verify the version, which one is needed to be kept, so, based on the last version or the latest version in comparison to time it could be version based. It could be even based on the value of the object. For example, there is a database record and you have an object which represents that database and that has a modified time. So, that's not the update on the cache, it's an update on the database but that update time happens to be part of that object and if that object was added first and then another object overwrites, it you don't want that last update on the database to be lost, right? So, if there is anything inside the object and you need to take a decision based on the attribute values, you need to implement the conflict resolution yourself for that. But like I said, most of the conflict resolution is going to be handled by default through our time base default option. So, whichever update comes last, is going to be applied as the latest update on the item and this only happens remember that this conflict resolution logic would only come into play, if there are two updates simultaneously added in the queue on the bridge. Right, so, bridge gets two updates at the same time. So, which one to pick? Site one added or updated an item and site two also added or updated the same item. So, bridge now has to decide which one to keep in the cache or in the queue and that's what gets replicated to site one and site two as well. Because one has to win over other. So, time-based conflict resolution is implemented by default and that would get you through most of your cases.

I leave it to you, is there anything else that we're going over? I think we're good. As far as content is concerned. Okay. The demonstration is completed. All right, we're running right at the last minute here, so, thank you to everybody that's come out. If you have any questions, pertaining to this specific webinar, feel free to just email us at support@alachisoft.com Definitely, head over to our website and download a free 2-month trial NCache Enterprise and use it in your environment. If you'd like help onboarding it, you can reach out to support@alachisoft.com and if you have any more questions about if you want to buy NCache or to get licensing information, feel free to reach out to sales@alachisoft.com.

What to Do Next?

© Copyright Alachisoft 2002 - . All rights reserved. NCache is a registered trademark of Diyatech Corp.