One aspect of SDDC that does not get a lot of attention is Data Protection, instead we are concentrating on SDN and automation. Yet, this leads me to Data Protection. There is a clear marriage between Data Protection and SDDC that needs to be added to any architecture. As with all things, we start with the architecture. Our SDDC architecture should also include data protection, but what data are we really protecting? Within SDDC there are three forms of data: tenant, configuration, and automation. Without one or the other, we may not be able to reload our SDDC during a disaster. What is required to get these three types of data, what really are these types of data? and how can we add data protection into SDDC cleanly?
These are just some of the questions I have been asking myself over the last few years and looking for products that not only backup the data, which all do, but backup my tenant configuration, and any automation information required to recreate my environment whether created by me or by the cloud provider. In essence, a full backup of data, configuration, and automation recipes.

SDDC Data Protection: Configuration Data

Very few backup tools today will backup more than a given virtual machine configuration file which is a VM-centric not Application-centric view of backup and is the bare minimum required. However, I would like to backup my applications. But this means we need a consistent method to define an application and that consistent method does not exist outside of VMware’s product suite: the vApp. While not all tools within VMware’s product line agree that the vApp is the ultimate definition of an application, it is the starting point for vSphere, vCloud Suite, etc. When you pull in tools like HotLink, the vApp concept extends into other hypervisor and cloud suites.
So if the vApp concept is used to define applications, then we should provide Data Protection for the vApp and all its configuration data which include inter-vApp networking and security configurations. What is at the ‘edge’ of my vApp is just as important as what is in it. Currently, very few companies backup vApp’s: Zerto and Vision Solutions Double-Take (which is limited). There is a rumor that a third vendor will enter this arena with the launch of their next product.
However, there is still a list of items missing from such vApp backups:

  • Full Tenant Network links (not just what is in the vApp but leading to the vApp)
  • Network Configuration (not just IP info, but DNS, and all bits necessary to recreate DNS, AD, etc as necessary)
  • vCNS Edge Security Configuration (outside the vApp but crucial)
  • vCNS App Security Configuration (inside the vApp but often overlooked and crucial)
  • Endpoint Security Configuration (inside each VM of the vApp)

We need all the configuration necessary to reproduce the vApp in full with no hands on requirement. Which includes registration within DNS, a directory service, all the ports in use (and the links between ports), and most important all security measures.

SDDC Data Protection: Automation Data

In addition to all the configuration data, we need the automation scripts, recipes, and tool configurations to reproduce the environment. Having a software defined data center, also implies that data protection is software defined and the restoration should be a push of a button. Let the software figure it out. However, in order for us to let the software ‘figure it out’, we need to give the software just a little help by providing within any backup or replication the tools we used to configure the environment in the first place. These tools must be multi-tenant or generic enough that our software defined data center can determine where everything goes on restoration.

SDDC Data Protection: Restoration Testing

This also leads us to another very important aspect of data protection: Restoration Testing. The backup tools must do this as a matter of course. I feel this is table stakes as we enter the realm of SDDC. We need to be able to take our application data, configuration, and automation data and restore it within a sandbox to ensure that our applications and tenancy restores properly. A tenant generally has more than one application defined, and if so, we need to understand the relationship between each of these applications and restore it during our automated restoration testing. What good is a backup if you have no idea if it works. Veeam is the only company that currently does automated restoration testing and for a small subset of applications can ensure your applications work.

Closing Thoughts

SDDC provides many capabilities but is based in automation. Data Protection needs to not only backup the tenant data, but application configuration data, and any automation data associated with the tenant as well as be able to test the restoration of everything, not using proprietary backup-company mechanisms but using the inherent tools of the cloud or virtual environment. In a disaster, the ultimate recovery location may not have all the bells and whistles but just enough to get going. So what does the SDDC Data Protection tool need to provide to make restoration in such disasters easier, besides ongoing backup restoration testing?
What are your thoughts?

3 replies on “SDDC Data Protection”

  1. Pingback: Automation Weaknesses | IBM Watson Cloud Computing

Comments are closed.