Category Archives: vRetreat

RTO With Cohesity @ vRetreat

How Cohesity’s Approach to VM Backup Affects the Recovery Time Objective

This week I attended another vRetreat online, this time featuring data vendor Cohesity who I saw presenting at the (in-person) event last year. These are great events, and the small panel of delegates works well in the virtual format.

One thing that stood out to me in their presentation was the focus on the Recovery Time Objective (RTO)- in essence how long it takes to recover from an incident. In this post I will briefly discuss how I understand the definition of RTO before looking at how the Cohesity products work to keep this time down when working with Virtual Machines.

Recovery Time Objective

There’s plenty of material out on the interwebs which will explain RTO in great detail, but I’m taking the definition to be:

the expected length of time between an incident occurring and users being able to work normally again

As this diagram shows, the Time can be split into a number of notable sections, I’ve chosen the following three:

RTO

  1. Discovering the Incident. How long is it before we notice something is broken? Do we have to wait for a user to contact the service desk, or do we have responsive monitoring and alerting in place?
  2. Starting the Restore. How long does it take to actually start the restore operation? Is there a clear process to be followed? There might be internal decisions to be made as to whether to kick off a backup restore or attempt an in-place repair. Does somebody need to physically power on some equipment or find and load some tapes before a backup restore can commence?
  3. The Restore Operation. How long does it take between “Go” being pushed on the restore console and the service being usable again?

You’ll notice there’s also a fourth section on the diagram- the “Tidy Up”. This is all those processes that need to happen after the user is working again to get the system back into a normal state. This might include things like tidying up the original (broken) copies of the VM, returning a backup tape to the library, or investigation of the root cause. In any of these cases, I’ve put this step outside of the RTO as by the definition above, the Users are working normally again.

Ransomware Detection

imageRecovery from ransomware attacks seem to be the current favoured feature pushed by backup vendors, and Cohesity are no exception. Their take here is that because the Cohesity Data Platform handles all the backups, it sees all the data and this position in the data flow gives the rest of the Cohesity stack an opportunity to spot both when an unusual number of files have been changed and also when files suddenly can’t be indexed because they’ve been encrypted.

Tied with an alerting mechanism, this helps address our question in point 1 above- “Can we discover the incident quickly?”. The sooner someone in IT is aware that a ransomware infection has happened, the quicker a response can be started.

Additionally, Regular point-in-time snapshot backups make it easier to spot the time the infection started (or if not the point of infection, at least when the malware started acting) and the more granular the timestamps the less data is potentially lost between a backup and the incident. But we’re straying into RPO, not RTO, there.

Starting Restore

Most of the time when responding to a major incident and orchestrating a restore operation the user interface will be key to assessing the situation and bringing services back online. Cohesity offers a clean and tidy web-based UI, complete with the now-obligatory Dark Mode.

2020-07-09_21-58-27

Whilst the platform isn’t going to make those go/no-go decisions on kicking off a restore- it can influence that decision. Because the restores are so quick (as we’ll see shortly) the discussion on whether to repair or restore might favour the latter. It’s also possible to bring up the VMs in a network-disconnected state without touching the production systems so that once any discussions are complete the restore is even quicker (or if the repair option is chosen then that restore can just be cancelled)

Restoring User Service

Once recovery is started in Cohesity Data Protect an NFS datastore is created on the Data Platform- the VMDK is already here so there is no need to spend time at this point moving blocks across the network. The NFS datastore is mounted within vCenter and the VM registered and at this point the VM can be powered on and the users can get working again.

Once service has been restored, the longer process of putting the VM files back where they belong is achieved with the hypervisors own Storage vMotion technology (the fourth step above). Applications are available throughout this, and once the Cohesity datastore has been cleared, it is unmounted from vCenter.

As this slide extract from the Cohesity presentation shows, one of their big selling points is this quick recovery process. Notice how the “Recover data to target storage device” is positioned after the User access is restored.

image

Thanks to Patrick Redknap and the Cohesity team for hosting this informative event, and I look forward to the next one. For more information about Cohesity, check out their website: https://www.cohesity.com/

Please read my standard Declaration/Disclaimer and before rushing out to buy anything bear in mind that this article is based on a sales discussion at a sponsored event rather than a POC or production installation. I wasn’t paid to write this article or offered any payment, although Cohesity did sponsor a prize draw for delegates at the event.

Datrium @ vRetreat May 2020

Last week I received an invitation to the latest in the vRetreat series of events. These events bring together IT vendors and a selected group of tech bloggers- usually in venues like football clubs and racetracks, but in the current circumstances we were forced online. The second of the two briefings at the May 2020 event came from Datrium.

To paraphrase their own words, Datrium was founded to take the complicated world of Disaster Recovery and make it simpler and more reliable, they call this DR-as-a-service. The focus of this vRetreat presentation was around their ability to protect an on-premises VMware virtual environment using a VMware Cloud on AWS Software-Defined-Data-Centre as the DR target.

These days the idea of backing up VMs to a cloud storage provider and then being able to quickly restore them is fairly commonplace in the market. Datrium, however, take this a step further and integrate the VMware-on-AWS model to reduce RTO but also ensure reliability by enabling easy, and automated, test restores.

When Disaster Strikes

In the event of a disaster Datrium promises a 1-click failover to the DR site through it’s ControlShift SaaS portal. One of the great benefits here is the DR site2020-05-19 (44)– or at least the compute side of it- doesn’t exist until that failover is initiated. This means the business isn’t paying for hardware to sit idly by just in case there’s a disaster.

The backup data is pushed up to “cheap” AWS storage and at the point the failover runbook is activated a vSphere cluster is spun up and the storage is mounted directly as an NFS datastore. VMs can then start to be powered on as soon as the hosts come online – with Datrium handling any required changes in IP addresses etc.

Whilst the system is running in this DR state, changes are monitored so that when the on-premises environment is restored failback only requires the delta change to be synchronised back from the cloud. And at this point the VMware environment on AWS is removed until the next time one is required.

2020-05-19_15-09-20

Testing – Practice Makes Perfect

This ability to spin-up and decommission the entire DR site on demand enables realistic testing to be performed without risk to the production workloads. Test restores can be run, and workload-specific tests run on the test environment, but the SDDC built on AWS only exists for the duration of the test.

The Datrium platform contains runbooks, and these are not just restricted to disaster events, but can be used to automate testing. The system will, on a schedule, spin up some or all of the VMware environment in a temporary SDDC then run some specified tests and shutdown and destroy the test infrastructure when complete. The results of this testing are compiled into an audit report.

Conclusion

As I’ve alluded to at the top of this post, there are plenty of “Backup” and “DR” products out there servicing Enterprise IT and leveraging the public cloud to do so. Of those, I think Datrium is worth considering particularly if you are focussed on protecting a vSphere environment with a short RTO, and are interested in using VMware on AWS as a DR solution but not that keen on the not-insubstantial costs of running that DR SDDC 24/7.

Please read my standard Declaration/Disclaimer and before rushing out to buy anything bear in mind that this article is based on a sales discussion at a sponsored event rather than a POC or production installation. I wasn’t paid to write this article or offered any payment, aside from being entered in a  prize draw of delegates to win a chair (I was not a winner).

Snapt @ vRetreat May 2020

Last week I received an invitation to the latest in the vRetreat series of events. These events bring together IT vendors and a selected group of tech bloggers- usually in venues like football clubs and racetracks, but in the current circumstances we were forced online. The first of the two briefings at the May 2020 event came from Snapt.

Established in 2012, Snapt is built on a product range they refer to as “Load Balancing Plus” – taking in Load Balancing, Web Acceleration and Firewall. They have a recent flagship release named “Nova” which enables the deployment and scaling of these load balancers across multiple environments.

It’s an interesting approach for anyone working in a multi-cloud environment, for example with workloads in vSphere, AWS, and Azure, who wants a consistent method of deploying, securing, and maintaining their load balancers in all of these clouds from one SaaS platform.

snapt1-crop

Snapt achieve this by separating their control and data planes – The SaaS control plane is managed by a clean web-based dashboard or API calls, and from there the nodes are deployed to the target infrastructures as VMs, containers, or cloud devices depending on the platform.

This separation of the nodes from the control adds potential for scaling, helped by their stateless nature. Logs are streamed directly out of the node and the parameters are pulled down from the control plane. Nodes also expose interfaces to allow direct monitoring from third-party applications as well as that provided by the Nova dashboard.

image

Down on the node, the load balancing features are supported by a wide set of security tools. Traditional blacklists and whitelists are supported by more advanced features such as geofencing and anomaly detection. Activity here is reported back up to the dashboard to give admins a clear, global, view of load and threats across their environments.

Whilst there are plenty of other load balancing solutions on the marketplace, based on this briefing I’d say that Snapt are well worth a look and particularly if the requirement is for a multi-cloud type environment.

There is a Community Edition of Nova available which allows up to 5 nodes free of charge- check out https://nova.snapt.net/pricing for details.

Please read my standard Declaration/Disclaimer and before rushing out to buy anything bear in mind that this article is based on a sales discussion at a sponsored event rather than a POC or production installation. I wasn’t paid to write this article or offered any payment, aside from being entered in a  prize draw of delegates to win a chair (I was not a winner).

vRetreat February 2019- Secondary Storage with Cohesity

Last week I had the pleasure of attending the latest #vRetreat blogger event. This edition featured a day of presentations and labs from enterprise storage vendor Cohesity held at Chelsea Football Club in London. In my first blog post from the event I look at what Cohesity are doing to distinguish “Secondary Storage” from “Backup Storage”.IMG_20190222_105103399_sm

There’s a number of vendors on the market who can provide enterprises with a backup appliance and support for public cloud storage. Cohesity have looked at this and asked what other business operations can leverage this (comparatively) cheap storage media? I’ve heard their message of “we’re not backup, but secondary storage” before, but at this event the distinction really clicked with me.

IMG_20190222_110747824_smWhilst front-line production services often demand the best-performing storage possible, storage for backups doesn’t (hopefully) need to be accessed regularly and doesn’t require the speed of access that front line production systems might. Where possible organisations will purchase cheap(er) storage for this task, and this can lead to a separate backup storage silo.

If nearly 80 percent of stored data goes unused after 90 days then the majority of data on NAS/SAN filers also fits these access and performance characteristics, so why not combine the two and reduce the silo count? The Cohesity platform offers SMB and NFS, and can also function as an object store. This also helps justify the outlay on the storage for backup which, like an insurance policy, you hope to never actually need.

CohesitySimilarly test and development workloads can often (but not always) be run on lower performance storage than their production counterparts. Again these functions are looking for similar attributes to backup when it comes to storage- keep the cost/GB low and don’t impact on the performance of our primary production storage.

Cohesity’s DataPlatform consolidates the traditional backup storage platform along with the ability to spin out test and dev workloads directly from this data, whilst also providing host file and object storage. For example, when the primary storage is upgraded to all flash, the NAS or test workloads that don’t need this level of performance can use the Cohesity platform.1550869582007_sm

This was an interesting briefing, and for me this part definitely showed the potential for not thinking of your backup infrastructure solely as an insurance policy but continuing to find new ways to leverage that investment elsewhere in the IT function.

Please read my standard Declaration/Disclaimer and before rushing out to buy anything bear in mind that this article is based on a sales discussion at a sponsored event rather than a POC or production installation. I wasn’t paid to write this article or offered any payment, although Cohesity did sponsor the lunch, T-shirt, and stadium tour at the event. Attendees were also given a pair of bright green socks and matching branded shoelaces so you should be able to spot them.