During the early development of Neverfail Continuity Engine, our engineering team built the continuous availability solution based on a cloned-based architecture. Here's why we did a cloned-based approach.The standard technique for other recovery products is to first build up a completely separate server, then replicate the primary (production) server application and system state configuration to another server that has a separate identity. However, at the time of failover, these recovery processes require that the application data be restored, server configuration be modified, and in some cases a reboot is required. This not only adds to the Recovery Time Objective (RTO), but there can be gaps in the way users and other applications connect and use this data post-failover. This can lead to a failed failover automation, or at least some breakage in connectivity or application configuration, and at a minimum a post failover cleanup is not ideal.
Solving Clone-based Architecture
Because of these issues, Neverfail adopted a “true” cloned-based architecture to overcome these limitations. In simple terms, Continuity Engine uses copies of the production server as its passive node. Continuity Engine replicates application data sets and its configuration over to passive nodes, and these passive nodes are hidden from the production network.
At the time of failover, Continuity Engine simply reveals the same server to the network. This ensures that the users and applications have the same resources available (at the time of failover) that was configured on the production server. This technique has been the cornerstone of Neverfail Continuity Engine’s value proposition for almost two decades.
Understanding that there are pros and cons to every recovery technique, the cloned-based architecture had a few areas for improvement. In our experience, customers wanted to have management control over the passive nodes. So years ago, we added the ability to add a management IP address to these passive nodes for users to remotely access them via RDP. Our customers also asked for processes to patch the passive nodes. We began adding these manual processes to Continuity Engine.
These manual processes worked; however, the processes varied from application to application. More recently, users simply wanted a single process that allowed operational control by 3rd party applications over the passive nodes while maintaining the benefits of the cloned-based architecture for continuous availability.
Typically, 3rd party instrumentation uses unique identities to keep accurate configuration information of patches that were pushed to the endpoints. With a cloned-based architecture, these products will update the production server. Then it moves to the management IP address on a passive node; it will see the same identity as the production server. Therefore it will simply move on without patching the server.
Thus, the patching software sees that it already patched the server and unless there was a deliberate push of these patches, the passive nodes would be overlooked.
Cozen Passive Node Management
We wanted to innovate a new, out-of-the-box approach to give our customers the best of both worlds. The result was Cozen Passive Node Management.
What is Cozen? Cozen is a Latin term that literally means to trick. So from a Continuity Engine perspective, there is a new and automated process to trick 3rd party instrumentation into thinking every node in the cluster has a unique identity.
How so? We present a “Cozen” name on each node in the cluster that is mapped to a management IP address separate from the public address used by user and applications. Continuity Engine registers this Cozen name in DNS and creates a NETBIOS name associated with the management IP address. When a patching technology connects to this management IP address, the Cozen name is presented and stored in its configuration database.
The result is a method that provides a unique identity to 3rd party instrumentation while preserving the underlying namespace, which is critical to achieving the benefits of the cloned-based architecture. It’s a truly reliable and innovative solution.
Neverfail currently has validated the following technologies with Cozen:
- Quest KACE Appliance
Other technologies that will be validated in the near future are:
- Kaysa VSA
- Tivoli – Endpoint Manager
- GFI LanGaurd
- Solarwinds Patch Manager
- ConnectWise Automate
- Patch Manager – CloudManagementSuite.com
Today, Cozen provides peace of mind in a computing world the continues to be more and more security conscious while lowering the administrative burden of patching passive nodes in the cluster. Neverfail Continuity Engine provides users with all the benefits of this mature continuity technology and ensures that protected applications are replicated real-time with intelligent application aware failover.
The new Cozen approach delivers superior protection architecture with Continuity Engine and allows customers to manage passive nodes in the same manner as their production servers.
Your next steps are:
- Read about the Neverfail Business Continuity Engine 8.5 Update 3 Release
- Learn about the new Mitel and Ipswitch plug-ins
If you have questions or need a quote, our team can help you. Simply send an email to firstname.lastname@example.org, and a member of our experts team will reach out to you. If you are in a business crisis situation and you need help, contact us at +1-512-600-4300.