I recently wrote a number of posts covering HYCU, a data protection software solution from HYCU Inc.  During the testing I was curious to understand how easy it would be to automate the build of a dedicated backup environment.  Here’s what I found.

HYCU Recap

HYCU is a software product that was written specifically for backing up HCI (Nutanix in particular) platforms.  The integration of HYCU into the Nutanix platform allows data to be backed up efficiently by using existing APIs that expose access to virtual machines and snapshot data.  What makes HYCU interesting in this instance is the installation process.  With either Nutanix AHV or vSphere, the HYCU image can be installed and customised within a few minutes, after which backups can be taken.

Backup on Demand

What happens if you want to build a backup environment per customer, team or group?  There are reasons why this might make sense to do.  For example, individual development teams working on a project could be given dedicated backup and restore to their own data.  This allows them to re-build environments at will, then package up the data at the end of development work for subsequent archive.  Any cost associated with running the backup can be directly attributed to individual teams.  The backup also becomes self-contained and so could be deleted in the future without risking other backup content (obviously there are existing ways this could be done too).

Having a separate “tenant” backup environment offers flexibility and segments control, but it might not be ideal in all circumstances.  Search may not be possible across all backup images, for example.  Savings from de-duplication may not be possible unless the back-end data can de-dupe across multiple tenants.  So I’m not suggesting this is a configuration suitable for everyone, but it could have its uses.

Automation

How does HYCU score in the automation stakes?

OVF Deployment

1. Image Build

This part is easy on either platform.  In my example, I built out a HYCU 3.0 environment using an OVF template, specifying target image name and network settings.  In this instance I didn’t use automation, but I could have done it with ovftool for example.  To be fair, I really need to try this part out and be 100% sure it’s possible.  Similarly for AHV, most of the steps should be easy to automate.

2. Initial Login

Here’s where things get more tricky.  The standard process for building a HYCU deployment is to log into the GUI and change the default admin password to a more secure one.  I wanted to use the API at this point, in order to do further configuration.  The API itself is quite easy to use.  Within the GUI there’s an API explorer to show the syntax of commands and expected outputs.  it’s also possible to try out code first.

Unfortunately it appears that due to security restrictions, I can’t log in with the default admin userid/password combination.  I see the sense in this; if someone forgets to change the default then a user can still log in and the system isn’t exposed to hackers.  Unfortunately for me, it introduces a manual step of changing the password.

3. Platform Configuration

HYCU API Explorer

With a valid userid, the remainder of platform configuration can all be done through the API.  This means mapping to a Nutanix cluster, creating a backup data target, adding virtual machines and policies.  How much of this can I do with API?  Pretty much all of it.  These are the REST API calls:

  • /administration/clusters – adds a Nutanix cluster to a configuration.
  • /administration/license – license the cluster.
  • /policies – create a backup policy
  • /targets – create a target
  • /vm – get VM list
  • /vm/{vmUuid}/backup – run a manual backup

And so the list goes on.  The API is comprehensive enough to list backup objects, restore from them, as well as all the other expected management tasks.

4. Ongoing Management

As already discussed, the API has all of the options to manage the backup tasks available via the GUI.  But once the VM is running HYCU, the API isn’t really necessary.  Ongoing management can simply happen with the GUI itself.  So by this point, we’re done.

The Architect’s View

Automation is 99% there, but for good reason, HYCU restricts API access until a non-default password is set.  Although irritating for my test, it highlights that with an exposed API, the HYCU team have thought about security.  I guess if there was demand for completely automated builds of the HYCU environment, then the way forward would be to allow a password to be specified at the time the VM is built from the OVF.

There was also one other small hiccup.  I could see no obvious way to partition my Nutanix environment for multi-tenancy.  I could do this with vCloud Director, which is great, however I was testing with the Nutanix Community Edition, so perhaps that has restrictions.

As we move closer to truly hybrid data centres, one of the challenges will definitely be how we separate infrastructure from services.  More and more companies are moving to SaaS models, so being able to offer multi-tenant backup will surely be a requirement.  Let’s hope we see this in HYCU soon.

Comments are always welcome; please read our Comments Policy. If you have any related links of interest, please feel free to add them as a comment for consideration.

Copyright (c) 2007-2018 – Post #ADB0 – Brookend Ltd, first published on https://blog.architecting.it, do not reproduce without permission. Photo credit iStock.

Written by Chris Evans

With 30+ years in IT, Chris has worked on everything from mainframe to open platforms, Windows and more. During that time, he has focused on storage, developed software and even co-founded a music company in the late 1990s. These days it's all about analysis, advice and consultancy.