Out: Clustering. In: Application Management

[Eric_Hennessey1]

I've been blogging over the past couple of weeks under the theme "Everything you think you know about clustering is wrong". It's sort of a tongue-in-cheek theme, but the misconceptions I was trying to dispel are real and held by enough people that I felt they were worth addressing. But now I want to shift gears a little bit.

In my last post, I mentioned how a lot of people can't seem to break out of the late-1990s mindset of 2-node active/passive failover HA:

While large clusters meant we no longer needed two nodes for every critical application, many people's mindsets were still stuck in 1997 and they continued to view HA clustering in a 2-node, active/passive context.

To be sure, that's definitely not the case with all of our customers, especially those who've been using Veritas Cluster Server for a long time. Take, for example, one innovative customer who decided to install VCS on nearly every server in the data center, whether that system was part of a cluster or not. The reason? It turns out the customer discovered that VCS made a great application management tool. With the application under control of VCS - even on a single node - they were able to achieve:

• Automated application start & stop
• Application restart in the event of a failure
• Push-button application start & stop via the cluster interface by operations staff

It was a use case for VCS which I'd never thought of at the time, but one which made a great deal of sense, and I have to admit to being embarrassed over not at first grasping the value of making it easy for operations staff to start and stop apps.

This same customer was a big fan of using VCS as an operations tool. Almost none of their VCS clusters were less than four nodes, and not just because they knew larger clusters were more economical. Having a "roaming spare" in an N+1 cluster configuration permitted them to perform maintenance on the idle node, quickly and easily move an app to that node after the work was done, then repeat the maintenance on the new idle node.

Meanwhile, of course, data center technologies continued to evolve, and VCS was no exception. We introduced Veritas Operations Manager (VOM) to provide a single pane of glass to manage VCS and Storage Foundation across all platforms and multiple sites, and we applied the notion of single-node VCS clusters to our Applicaton HA product to deliver application-level HA to VMware, KVM, Solaris LDOM and IBM DLPAR virtual environments. Last December, we released VOM 4.1 and VCS 6.0 which introduced Virtual Business Services (VBS), allowing users to link together the multiple layers of a multi-tiered application stack across multiple OS and virtualization platforms.

All of which brings us to a sort of tipping point where the word "clustering" becomes less and less relevant to what we're doing and "application management" becomes a more appropriate term. Sure, we still have "tight" clusters in the traditional sense, but now we're including in the mix "loose" nodes - single physical and virtual nodes whose apps are being managed externally through VOM and VBS. The boundaries of a single cluster are becoming blurred as complex, multi-tier applications may have its components spread across a mix of tight clusters and loose nodes. The Virtual Business Service construct will ensure that the multi-tier app is started up and shut down in a proper, coordinated fashion, as well as failed over locally or remotely as needed. While VCS today allows users to define static application load and server capacity attributes to assist VCS in making informed application placement decisions, future capability may make real-time decisions based on dynamic load and capacity values.

The look and feel of high availability and disaster recovery is changing, and is becoming something we deliver more as a by-product of effective application management than through isolated HA clusters. In future posts, I'll be drilling down into the various aspects of this.