While participating in the GestaltIT Virtualization Field Day #2, I was asking Symantec about Application Aware Backups. In other words, could one backup an entire application, regardless of how the application was defined. This concept goes hand in hand with Application Aware Security measures. We can always backup VMs and their data to remote locations, but can we backup or maintain the application interactions within a multi-VM Application regardless of how it is defined. You can define applications within the virtual environment using several mechanisms:
- By Hand as a vApp (vSphere) or by Hand within the backup tool
- By determining all network dependencies (without the VM, similar to VMware AppInsight)
- By determining all network and non-network dependencies (within the VM, similar to Virtual Infrastructure Navigator)
- By Hand within a different non-backup tool such as VMware vCops Enterprise.
The question for Backup companies is whether such an application can be backed up as an application including all network and other virtual resource constructs in use. I.e. reproducing the virtual networking and other items automatically by the backup or replication tool. Symantec stated they could not do this, but would try to keep vApps together. ZeRTO on the other hand, treats all vApps as a virtual protection group of VMs. Even so, at the moment, there is no mechanism to define an application to backup save as a vApp (ZeRTO). Even so, this may not pick up all virtual environment dependencies.
At the moment we can define applications as a vApp, but backup tools still just backup VMs and not the application dependencies. So restorations are just of the VMs. Yet, such restorations also need to be application aware. Restoration should obey anti-affinity, network, and storage profiles rules so that when the application is restored, the application works just the way it did prior to backup. It is no longer ‘good enough’ to restore the VM and its immediate configuration. It is no longer ‘good enough’ to consider all applications as taking up exactly one VM. While each VM does contain what is considered an application such as a database or tomcat server, there are inter-dependencies within these VMs that are missing with current backup tools. Veeam has a start at this with its Surebackup mechanisms, but this is purely for restoration testing and requires a fair amount of script writing to implement. You can restore the VMs then test that the VMs can talk to each other, but misses the policies defined within the virtual environment on backup so they cannot be applied without complex scripting within the backup testing sandbox.
Application Awareness first stems from knowing what VMs make up the ultimate application which are really defined by the business. The business owners do not ask for a tomcat server, they instead ask for the business application which can be comprised of many different servers. It is time for the virtualization backup tools to step forward and become Application Aware and restore all dependencies not just single VMs. Which means they first need to backup based on those dependencies and policies. What dependencies are important? This is just a short list, but it is an ever growing list that is required first to restore an application but also perhaps to restore an entire environment:
- Network Configuration – what portgroup and VLAN the VMs reside as well as the network security constructs surrounding the application (such as firewalls, rules, etc.) Perhaps even from the ‘defined’ edge in. In a Cloud Environment, the edge is fairly well defined but not necessarily in a virtual environment.
- Introspective Security Configuration – what introspective firewall, SCSI filtering, and other rules that apply to the application such as those defined using vShield App, vShield Data Security, and vShield Endpoint as well as a way to remove such dependencies if restoration is to a set of hypervisors that do not have the support of introspective security tools.
- Edge network Configuration – what edge services are used by the application such as load balancing rules, firewall rules, VPN configurations, and other policies that define how this application is deployed within a hybrid and local cloud.
- Storage Profiles – restoration should restore to the defined storage levels if such exist in the target. It would be pretty bad if all restorations went to one set of datastores instead of being properly tiered across all levels. In a cloud environment this will become more important.
- Host Profiles – restoration should take into consideration those elements required to reconfigure a host as well, just in case we are working from a blank slate (in the case of a disaster)
- VM interactions – VMs should be rstored in the proper order and maintain not only their anti-affinity rules for CPUs, hosts, networking, but also maintain their boot order so that they can inter-operate properly. If there is a vApp defined within vSphere, some backup tools maintain such information, but not all.
- VM custom attributes – Customer attributes defined within the virtual machine configuration should also be maintained as some security tools make use of these attributes.
In other words, we need to be able to have an easy restore based on the entire application, its dependencies, security policy, and potential interactions as well as policies governing how the application interacts with cloud boundaries. Perhaps this is more about cloud awareness, but I see this type of policy driven backup applying to all cloud and virtual environments. It would also make restorations much easier if there is a true disaster.
Share this Article:
Latest posts by Edward Haletky (see all)
- Scale and Engineering - March 23, 2017
- SDS and Docker: The Beginnings of a Beautiful Friendship - March 21, 2017
- Security Operations Center: Not Just Visibility - March 14, 2017