Neverfail Announces IT Continuity Architect for BCP / DR Planning

Breaking away from a long streak of backup solutions discussed at Tech Field Day 9, Neverfail delivered a presentation focused on the often sticky subject of disaster recovery and business continuity side of operations. The idea of having Neverfail present on a new product was exciting for me, as I have long been familiar with their core Heartbeat bits that sit inside of the VMware vCenter Heartbeat product, which allows you to protect a multitude of VMware product databases. However, don’t confuse the VMware product with Neverfail’s Heartbeat Failover Engine, which is available for a large variety of workloads and consumed by thousands of organizations.

Nick Harmer, Senior VP of Corporate Development, kicked things off by stating that their up and coming new product, IT Continuity Architect, fills in a lot of gaps and solves many challenges that we are all entirely too familiar with in just about any IT shop. Neverfail’s mission is to protect customer applications from downtown, regardless of the cause. Their DNA comprises of over a decade of experience operating as a business continuity software company focused on mission critical applications. The next big leap for Neverfail is aimed at IT continuity management. Fancy term!

Nick Harmer goes into details on Neverfail
Nick Harmer goes into details on Neverfail

The idea is to provide a system that can understand the relationship of your disaster protection strategies and the objects that are within. If a workload somehow egresses from the protection environment, perhaps via a vMotion or a storage vMotion, Neverfail will provide assistance. So why the new push into territory behind Heartbeat Engine? The plumbing has become commoditized, forcing Neverfail to push into new areas outside of their niche in the protection game. This includes areas like planning, assurance, and optimization of the continuity management cycle.

Note: All travel and incidentals were paid for by Gestalt IT to attend Tech Field Day 9. No other compensation was given.

IT Continuity Architect

It took a bit of coaxing and delegate tongue lashing to get the heart of Architect’s focus out of the Neverfail team, but ultimately we learned that it is a environment discovery engine. The process is to discover the entities on your network, define services, assign them into SLAs, and then identify and mitigate risks that are shown in the results. This process is rather logical and, in reality, what we do today in a very manual, labor intensive way.

Architect has defined and analyzed a number of entities on the network
Architect has defined and analyzed a number of entities on the network

Architect allows you to define four different business tiers. Each tier can be tuned by the admin to define things like RTO, RPO, site protection, application protection, server protection, data protection, physical and virtual workloads, hypervisor, or even custom additions to the protection technology to define use cases not covered by the product out of the box. You can then easily mirror your business defined tiers, such as bronze, silver, and gold, to actual check boxes within the Architect SLA – such as silver needing an RPO of 1 hour but gold needing an RPO of 5 minutes.

Dependency Mapping

Architect is able to understand the relationship between objects in a number of different ways. The most obvious are network flow relationships, such as who is talking to what, but also include layers like virtualization tiers. For example, obviously all of the virtual machines on a vSphere datastore depend on that datastore to function, and so ultimately the storage array’s LUN is part of the relationship.

Some of the very complex relationships that Architect has discovered for a business service
Some of the very complex relationships that Architect has discovered for a business service

If that isn’t neat enough, the tool is also analyzing the dependencies in real time. Workloads are migratory and tend to shift around by things like DRS or maintenance activities. Even further than that, new workloads are introduced and decommissioned all the time. Architect keeps tabs on these activities and has the ability to dynamically add workloads into a business service or SLA tier. This is really the hard part about a proper DR plan – the moment a manual plan is created it is already out of date. This is often masked by smoke tests and table top tests, which are based on the existing DR plan, but painfully discovered during a live cut over or real disaster.

Risk Identification and Heat Mapping

Another facet of the tool that I felt was spot on was the ability to see your compliance level for any of the business services or tiers. This heat map gives an idea of how within the defined SLA you are. Imagine you are asked to provide an RPO of 5 minutes but the replication tool is lagging behind and actually only keeping up in 10 minute intervals. This would be a great way to provide proof that additional funding is required, or to offer a warm and fuzzy to the executive team that their DR statement to stakeholders is in fact being supplied by the current IT environment.

A heat map of compliance
A heat map of compliance

Want to model protection beyond just what you currently have? No sweat for Architect. It can examine current state traffic on your workloads and get an idea for how much bandwidth will be needed to replicate at the schedule defined by the SLA. It even offers a fancy graph with color coated jobs. This can be awesome for determining how much bandwidth to buy from your Internet provider or Co-location host.

Architect can do some really amazing protection modeling
Architect can do some really amazing protection modeling

Thoughts

Kudos to Neverfail for really breaking out of the box and coming up with such a nifty tool. I know that myself and others are extremely keen to see this break into the market beyond its current beta phase. At this time they are also quite interested in working with folks who want early access to the product for feedback on the software to find out what is functional, non-functional, and discuss the business value based on their use case(s). I would highly suggest taking a look if you are involved with DR planning or modeling for your organization.