Over a million developers have joined DZone.

Zero Downtime of Coherence Infrastructure with 24/7 Availability as Part of Planned Deployment Strategy

Rather than relying on a clean restart of the Coherence Cluster, optimize the availability of your data grid layer with these three deployment scenarios.

· Database Zone

Build fast, scale big with MongoDB Atlas, a hosted service for the leading NoSQL database. Try it now! Brought to you in partnership with MongoDB.

Coherence is a reliable in-memory data grid product offering OOTB failover & continuous availability with extreme scalability. But we at times face challenges during Coherence deployment and tend to lean towards clean restart of entire Coherence Cluster. This defeats the purpose of 24/7 availability of data grid layer and eventually the availability of dependent applications as well.

I came across this discussion with several people and hence sharing my thoughts on the entire Coherence Deployment Strategy, which does not require any downtime ensuring continuous availability.

In my opinion, there are particularly three high-level scenarios with respect to Coherence deployment:

Scenario 1 - Deployment of Application, Which is Using Coherence Data Grid Layer

  • Problem Statement: Typically, this is the case when there are multiple web or native applications backed-up by Coherence data grid layer. Often, infrastructure team tends to restart Coherence Cluster during the process of deployment causing downtime to cache layer & eventually the entire application. This causes extended downtime of entire application (even hours) as clean restart of Coherence usually takes time.
  • Solution Approach: 
    • As a best practice, Coherence Cluster shutdown & restart should be avoided wherever possible. Coherence does not require to be cleanly restarted unless there are changes in libraries (which is second scenario below).
    • If there is requirement to clean-up existing Cache entries and replace them with new cache entries, then it is more of a change in application version maintenance of cache items than cache system. Typically, each cache item can have version information (getter method like getVersion()) attached to it and post deployment, previous version entries can be discarded by the application. 
    • You can also refer to Cache Invalidation Strategies, which comes as an OOTB feature in Coherence.

Scenario 2 - Deployment of Application with Updated Coherence Application Libraries, Which is Using Coherence Data Grid Layer

  • Problem Statement: This scenario is applicable in cases where there is usage of Coherence Application Cache particularly where read-through or write-through patterns are implemented. In this case, application specific JAR files or libraries need to be updated on Coherence Nodes & hence infrastructure team tends to shutdown entire Coherence Cluster with clean restart.
  • Solution Approach: 
    • As a best practice, Coherence Cluster shutdown & restart should be avoided wherever possible.
    • A cyclic restart (or rolling restart) can help in this case along with version based maintenance & cache invalidation strategies of cache items (as explained in scenario 1).
    • Note that invalidation or cache item clean-up plays critical role as even if Coherence Nodes get restarted, data will get automatically backed-up in data grid layer (by other nodes). In essence, failover feature is acting against clean deployment in this case and hence need to be careful in clean-up approach in this case.

Scenario 3 - Coherence Configuration Change as Part of Deployment

  • Problem Statement: This scenario is applicable in cases where there are changes in Coherence Configuration (Cluster Configuration or otherwise). Note that even if there is any difference (even minor) in configuration of any Coherence Node, it will get rejected by Coherence Cluster. For example, if there is change in Security Configuration (using override file) or TTL change or Coherence Edition Change.
  • Solution Approach: 
    • The easiest approach is to shutdown entire Coherence Cluster (JMX monitoring can help to make sure all Coherence Nodes are down) and post configuration change, restart all nodes. But it defeats our purpose of ZERO DOWNTIME.
    • If Zero downtime is needed, then we need to:
      • Setup an entirely new Coherence Cluster (e.g. by assigning a new multicast IP address or change of mutlicast port)
      • Make Configuration Changes &  do fresh deployment on new cluster
      • Do cyclic restart of dependent application servers using new Coherence Cluster setup
      • Discard Old Coherence Cluster post migration of old applications to new Coherence Cluster

There can be multiple other deployment scenarios possible but they can be variation of scenarios described above (at least in my mind).

Hope it helps to all those people who are seeking Zero Downtime Deployment without paying extra for other products like Oracle GoldenGate to achieve the same.

Now it's easier than ever to get started with MongoDB, the database that allows startups and enterprises alike to rapidly build planet-scale apps. Introducing MongoDB Atlas, the official hosted service for the database on AWS. Try it now! Brought to you in partnership with MongoDB.

java,high-perf,database,oracle,tutorial,performance,tips and tricks,oracle coherence

Published at DZone with permission of Ankur Kumar, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}