Comparing VMware vSphere App HA with Symantec ApplicationHA

So before I jump into this post I want to put this disclaimer out there just to be clear.

The following post is a reflection on the views of myself and not that of Symantec Corp.

The reason why I wanted to create this post was that I was reading a whole stack of posts from other bloggers who were mentioning certain things that were just not true, comments such as App HA can protect Oracle, SAP or any application & App HA has been around since 5.0 are a couple of comments I have read on other sites and are just are not true. So what I wanted to do was to produce an honest account of both technologies and highlight gaps and strengths in both solution.

So here we go…..

Solution Functionality

VMware vSphere App HA

The vSphere App HA solution provides the administrator the ability to define high availability for applications running in the virtual environment, and it provides a level of visibility and control via the Web Client Interface for vSphere.  The App HA solution provides levels of remediation by restarting failed components on the application or using the Application Awareness API via VMware HA to reset the VM if the restarting of the application does not complete correctly. The vSphere App HA solution provides support for SQL, Tomcat, Apache, TC Server and IIS. It supports a limit of 400 deployed agents and each VM guest uses this Agent to monitor the applications.

Symantec ApplicationHA

The Symantec solution also provides the administrator the ability to define levels of high availability for applications running in the virtual environment, and employs management via a vCenter Plugin. The plugin provides visibility and control to the applications and also enables the operator to control the applications. The Symantec solution uses the heritage of Symantec Cluster Server, powered by Veritas agents to monitor and control the applications, and supports over 23 tier 1 applications such as SQL, Oracle, SAP, MQ, Exchange, Sharepoint and IIS to name a few, and supports homegrown applications that enterprises may be using to drive their businesses. There are 4 main levels of remediation, ApplicationHA can either restart an application’s failed components, and it can reboot the OS if the previous remediation step fails or restart the VM via the Application Awareness API. Finally it can even recover the last know good backup in case of corruption. The ApplicationHA solution has been performance tested to support 2000+ VMs and uses simple wizards for deployment and configuration. The Symantec solution can also leverage the Virtual Business Service from Veritas Operations Manager to control multiple tiers of applications in a start/stop process and employs fault remediation to resolve issues where ever in the stack a fault may occur.

Solution Functionality Comparison

Symantec ApplicationHA uses its knowledge of applications via its Symantec Cluster Server technology and supports those which are critical to enterprises today.  It has been further developed to simplify the installation, configuration and management of applications running in a virtual environment, and it scales to enterprise requirements.
On the other hand, VMware’s vSphere App HA is very much a 1.0 product and requires multiple points of management. The lack of any deployment automation can be a challenge for some environments and with limited support for key tier 1 applications or home grown applications; it could be viewed as not enterprise ready yet.

 Obtaining the Solutions

 VMware vSphere App HA

The VMware solution is available with vSphere Enterprise Plus edition or available as part of the vCloud Suite bundles which contain vSphere Enterprise Plus as part of the suite.

 

Product Features	Standard	Enterprise	Enterprise Plus
vMotion	•	•	•
Storage vMotion	•	•	•
High Availability	•	•	•
Data Protection	•	•	•
Fault Tolerance	•	•	•
vShield Endpoint	•	•	•
vSphere Replication	•	•	•
Hot Add	•	•	•
App HA			•

 Fig 1 – Compare editions for VMware vSphere App HA

Symantec ApplicationHA

Symantec ApplicationHA is licensed either by per VM or by CPU tier (physical ESX or vCPU) and can be installed against vSphere Standard, Enterprise and Enterprise Plus. Depending on the scale of deployment the average cost for ApplicationHA to vSphere App HA is around 20% of the additional cost of Enterprise Plus.  Obviously the Enterprise Plus edition contains other features beyond that of vSphere App HA, and ApplicationHA would be an additional cost but would bring enterprise application support which is missing in vSphere App HA.

Whilst App HA may be sufficient for some environments, there will be environments that need the scope of application support that ApplicationHA offers and the levels of resilience that it offers too. Understandably buying a solution that comes bundled with something like vSphere makes sense, but there are occasions when third party solutions make more sense as they have been developed to provide the functionality that customers need and they typically have the speciality knowledge in that field too. Symantec (Veritas) have been providing HA and DR solutions for over a decade and know how applications work.

Backend Infrastructure Requirements

VMware vSphere App HA

The infrastructure requirements for vSphere App HA are provided by deploying the App HA appliance; this is a dedicated VM which is configured with 2 vCPUs and 4GB RAM. The scale limitation of App HA is 400 agents which take the form as Hyperic Agents. For App HA to operate in the environment it must contain the Hyperic Server along with its database, thus requiring another two virtual appliances. So that’s 3 separate VMs required for the solution to operate. The application monitoring framework is provided via the VMware vFabric Hyperic appliance, which for a small environment (50 Agents) requires around 4 vCPUs and 4GB RAM; the recommendation to support the limit of 400 agents would require 4 vCPUs and 8Gb Ram.  The Hyperic Server also requires a Postgres database which is packaged as an OVA supplied by VMware along with the Hyperic Server. This database appliance typically requires 4 vCPUs and 4GB RAM but recommendation is to increase the RAM to 6GB. In all, the vSphere App HA solution will require at least 10 vCPUs and 18GB RAM.

Once the Appliances are deployed the administrator would then configure “VM and Application monitoring” within VMware HA on the clusters where the virtual machines are residing to enable protection with vSphere App HA.

 Fig 2 – VMware vSphere App HA Architecture

Symantec ApplicationHA

For the centralized management of availability protected VMs, Symantec ApplicationHA utilizes the Symantec HA Console, this is installed on a Microsoft Windows virtual or physical machine. The HA Console provides management via a vCenter plugin which is registered during the install process. An installation wizard provides the process to deploy the HA Console Server. ApplicationHA can also protect the HA Console Server by providing an agent to make the HA Console Server highly available. Once deployed the administrator would configure “VM and Application monitoring” within VMware HA for the clusters so that ApplicationHA can utilize the Application awareness API for application heart-beating with VMware HA.

The requirements for the HA Console Server is to have a minimum of 2 vCPUs and 2GB RAM for a 1000 VM deployment and 4 vCPU and 4GB RAM for a 2000 VM deployment; this is well under a third of the resources required by App HA and only uses a single VM to be built and maintained.

Fig 3 – Symantec ApplicationHA Management vCenter Plugin

Backend Infrastructure Requirements Comparison

The infrastructure resource requirements for VMware vSphere App HA is more than triple  that of Symantec ApplicationHA, and with multiple VMs required for the appliances it does consume a large amount of resources and has more touch points to manage to provide the functionality. One of the benefits of the vSphere  App HA solution is the ability to be managed via the Web Client; where as  at the moment ApplicationHA only uses the vCenter Plugin for similar management interaction.

Application Agent deployment inside the Virtual Machines

VMware vSphere App HA

The vSphere App HA solution does not provide any VM agent deployment mechanism and relies on the administrator to provide it. The Hyperic Agent packages are supplied as “RPM” or “EXE” binaries for their relevant platforms.

Once the Hyperic Agents have been deployed to the VMs the administrator would then need to start the configuration of the agents.  The configuration of the agents does require some modifications to the agents configuration file “agent.properties” to enable the vSphere App HA alarms in vCenter. The administrator would have to stop the Hyperic agent if it was running, then make changes to the config file and restart the agent. Note this would have to be completed for each agent running on each VM.

With the agent started the updated configuration is the sent to the Hyperic server.

Fig 4 – Modifying the VM agent.properties in Hyperic

Symantec ApplicationHA

The deployment process for the ApplicationHA VMs is provided via functionality from the HA Console Server. The Plugin provides a mechanism by which the administrator can select any powered on VMs and deploy the agent “Guest Components” to Windows or Linux VMs.  The status of the deployment is tracked via the task panel in the vSphere UI.

 

Fig 5 – Symantec ApplicationHA guest deployment via vCenter

  

Fig 6 – Symantec ApplicationHA guest installation task status via vCenter

 Application Agent deployment inside the Virtual Machines Comparison

Whilst modification of the App HA configuration is a simple process to carry out, be aware that this must be done for each agent that is deployed and it can be time consuming and error prone especially when carried out manually. The Symantec solution requires no configuration changes with respect to its agents that get deployed, and the Symantec solution is able to push out the agents centrally for both Windows and Linux VMs directly from the vSphere UI.  Also note that the alarm functions are setup automatically with its deployment.

Configuration of Remediation Policies

VMware vSphere App HA

With the VMs Hyperic agents configured and information sent to the Hyperic Server, the administrator does need to configure the remediation actions for the application via a Policy in the Web Client.  If alerting is required for audit tracking then this needs to be configured from within the Hyperic Server UI.

From within the vCenter Web Client the administrator would connect the App HA appliance to the Hyperic Server via a configuration section in the plugin panel. Once communication is made the administrator can then create a policy for the application.  The policy can be created for a specific application or it can be created for a collection of the same type of applications, ie:- create a policy for all SQL 2008 R2 applications or create a separate policy for a specific SQL 2008 R2 application. Note that different applications require separate policies.

   

Fig 7 – Creating an application remediation policy & specify failure policies

Symantec ApplicationHA

The deployment process for the virtual machines also configures the connection of the VMs to the Console Server via its own Single Sign On process using the credentials supplied during the install process and requiring no user configuration. There are no policies to define with ApplicationHA during the installation process. Remediation settings can be specified if required once the application has been configured.

Configuration of Remediation Polices Comparison

Symantec ApplicationHA reduces the management overhead in configuration by removing the need to have to create policies up front for the applications. The configuration process for the applications contains the remediation policies and often will require no changes to its underlying policy.

Configuring Application Availability

VMware vSphere App HA

To configure applications with vSphere App HA the administrator first needs to add the server to the Hyperic inventory from within the Hyperic web management page. Once the server has been added to the inventory the administrator creates an alert service for the virtual machine so that it will alert vCenter Server if the application elements fault or have issues.

The administrator then would switch back to the vCenter Web UI and assign the remediation policies against the VM based on the application being monitored.

 

Fig 8 – Adding the VM into Hyperic Inventory

Symantec ApplicationHA

From within the Symantec High availability tab within vCenter the administrator would click on the link to configure the application for high availability. An Application configuration wizard is displayed and the administrator selects which application to configure.  Once selected, the wizard auto discovers the components of the application and displays those for the administrator to select. The wizard then would configure the application for high availability and would display the status of the application for the VM in the Symantec HA plugin tab. Remediation policies are set on a per VM basis from the settings link on the application status view. Some of the ApplicationHA agents utilize detailed monitoring so that the actual health state of the application is monitored.  For example, if a database stopped responding or becomes un-mounted, the agent would react to this and report the application state as faulted.

 Fig 9 – Symantec ApplicationHA application configuration wizard

Configuring Application Availability Comparison

Symantec ApplicationHA removes the need for the user to truly understand the application to be able to configure it. Operations teams with basic application information given from the application owners are able to configure the application quickly and efficiently from a single console. The VMware Solution requires the user to switch to the Hyperic Server UI to add the server to the inventory and then switch back to the Web Client to apply the policy which could mean that different teams handle different jobs based on their access control.

Operating and Managing the Application Availability

VMware vSphere App HA

Operating the vSphere App HA solution is done with the vCenter Web Client. The application status is viewed via the “Application Availability” tab from within “Monitor” at either the Datacenter or Custer level. There is no ability to view the application status at the virtual machine level.  During normal operations the Hyperic agent running on the virtual machine monitors the application state and reacts to failures that may occur within the application. Based on the policy set for the application certain remediation would happen if a fault was to occur. The Hyperic agent carries out service level monitoring of the application and restarts the failed service based on the policy setting. If the failed service does not restart then the remediation policy is run and vSphere App HA solution simply resets the virtual machine. There is no graceful shutdown of the operating system, this is not ideal as possible file-system corruption could occur in such circumstances. Once the virtual machine is reset the monitoring cycle is resumed. Alerting is visible in the Web Client describing the fault and action taken by vSphere App HA.

 Fig 10 – VMware vSphere App HA display

Symantec ApplicationHA

Operating the ApplicationHA solution is done with the Symantec HA tab within vSphere management UI. For environments that limit the user access to the vSphere UI it is also possible to manage the applications directly from a secure webpage, CLI or using the Veritas Operations Manager (VOM) interface which also employs various levels for granularity for access control.

The application status can be viewed at the virtual machine level, Cluster and Datacenter level. The application view also displays the application components in a dependency view so that the administrator can review the hierarchy of the application components. From within all views the administrator can start and stop the application as well as enter maintenance mode for application patching purposes. ApplicationHA provides differing levels of remediation for faulted applications. It can restart failed components of the application a number of times before advancing to the next level of remediation. It can also instruct the VM to carry out an operating system reboot so that the virtual machine is shut down cleanly in an attempt to clear the fault. Finally, ApplicationHA can pass control to VMware HA to reset the virtual machine, or it can also be integrated into Symantec BackupExec to recover from the last known good backup image and restore that as the last step in remediation.

 Fig 11 – Symantec ApplicationHA Management (VM View)

Fig 12 – Symantec ApplicationHA Dashboard (Cluster/Datacenter View)

 Quick Comparison:  vSphere App HA vs Symantec ApplicationHA

	vSphere App HA	Symantec Application HA
Architecture Requirements
Management Appliance	Multiple, including App HA Appliance, along with the Hyperic Server Appliance and its database.	Provided via HA Console Server running inside Windows VM
Management Appliance required for function to operate.	Yes, loss of either appliance = loss of protection	No, ApplicationHA continues to operate with VMwareHA
Management foot print	10 vCPU 18Gb RAM	1-2 vCPU 2-4Gb RAM
Management UI	vSphere Web Client	vCenter Plugin
Platform Support	vSphere 5.5	vSphere 4.x & 5.x
Installation & Configuration
Push install of Agent/Guest components	No	Yes via vSphere UI
Management interface points	Multiple points of management between Hyperic server and Web Client	Single management tab provided via vCenter Plugin
Configuration of Agents	Some configuration file modification required	Simple wizard to configure application monitoring
Support for custom or generic applications	No	Yes
Applications Supported	SQL, Tomcat, Apache, IIS, vFabric tc	SQL, Oracle, SAP, MQ, Weblogic, Siebel, DB2, Exchange, Sharepoint, IIS, Fileshare, Printshare
Number of applications supported	5 with 14 application versions ie IIS 6/7/8	24 with 63 total application versions ie IIS 6/7/8
Management and Operations
Levels of remediation	2 – App restart & VM reset	4 – App restart, OS reboot, VM reset & Backup image recovery via BackupExec
Application Policy	Yes, defined per application type or specific application	Yes, defined after application configuration.
Application alarms	Defined on per VM basis from with Hyperic Server	Enabled as default under “Tasks and Events”.
Application control	None	Yes, Start/Stop
Multiple Application Control	None	Yes, Virtual Business Service
Maintenance Mode	Yes	Yes
SRM support	No	Yes
Backup integration for recovery	None	Yes

Conclusion

Although on the face of it looks like VMware is providing a solution with similar reputation as VMware HA, their vSphere App HA product is lacking many enterprise features. Two gaping holes are that there is very limited support for any tier 1 applications, and there is no support for custom or generic applications.  Only Microsoft SQL is a real tier one app on their supported list, and there are many major tier 1 applications missing such as SAP, MQ and of course Oracle.

The ease of use capability which VMware often promotes is also missing in this solution. The installation process of the agents is very manual in its approach and requires some type of automation to be provided by the customer. After installation, some amendments need to be made to the configuration along with vCenter alarm configurations which have to be created on a per VM basis before you’ve even configured App HA.  This all adds up to a very lengthy and error prone deployment process, especially if no automation is available.

The levels of remediation are basic, in that App HA can only restart a failed application service and then performs a hard reset against the virtual machine, which is not ideal as it can cause file system or VM corruption, compounding the application downtime even more. ApplicationHA provides OS reboots to safely shutdown the file system and along with integrating with Symantec BackupExec to provide VM image recovery if all goes really wrong. Symantec ApplicationHA works autonomously from its management console and still provides protection via the application awareness API within VMwareHA, ApplicationHA also contains an agent to protect the HA Console server if required too.  The same can’t be said for the App HA solution if the Hyperic Server or App HA appliance were to fail.

VMware does provide management via the Web Client but they do omit any management functions such as starting or stopping the applications. Visibility is only provided at the cluster or datacenter view with no singular VM view or application dependency view. The “Application Availability” view provides very limited information on the application configuration and allows no customization. In a large environment with multiple applications of the same type it will be very easy to become confused with only the virtual machine name to distinguish between application types. Also having to use two management UIs for administration is not ideal and some operational workflow would need to be in place to operate efficiently.

Overall it seems that VMware has hastily put together a solution which seems to be integrated to a point but it is missing some vital operational workflow as well as support for critical tier 1 applications.

Reference Information

Comparing the Editions

http://www.vmware.com/products/vsphere/compare.html

vSphere App HA Overview

http://www.vmware.com/products/vsphere/features/application-HA.html

vSphere App HA Release Notes

http://www.vmware.com/support/appha/doc/releasenotes-appha10.html

vSphere App HA Documentation

http://www.vmware.com/support/pubs/appha-pubs.html

Hyperic Server Configuration requirements

https://www.vmware.com/pdf/vFabric-Hyperic-Supported-Configurations-and-System-Requirements-57.pdf