IBM at VMworld 2013: Making heroes of VMware admins and SQL Server DBAs

In the modern datacenter, there’s a lot of shifting going on when it comes to traditional storage management responsibilities. What used to be the domain of a central storage and backup administration team has been thrown up for grabs as server virtualization and software defined everything have entered the scene. I hinted at this a bit in my post Do IT managers really “manage” storage anymore? But let’s consider a practical example that’s quite common with clients I speak to. If you are going to VMworld 2013, plan on attending the IBM TSM for VE hands-on lab to get more details.

Microsoft SQL Server is the foundation for a lot of applications that are critical to business operation – meaning CIO’s and IT managers are interested in its recoverability. Those same CIO’s and IT managers are also interested in the recoverability of their VMware estates, the software defined compute (SDC) platform that houses those databases. For many clients, the problem is that these two domains are tightly guarded by two independent superheroes, and neither is specifically trained in storage.

Superhero #1: The database administrator (DBA)

VMware and SQL Server superheroMost DBAs that I’ve known have an almost personal connection with their databases. They care for them as they would their own children. The thought of leaving one unprotected (without a backup) equates to dereliction of duty. Ignoring the idea that it takes a village to raise a child (or in this case that there may be other members of the IT administration village like VMware admins and backup admins), SQL Server DBAs will often work alone with the backup tools Microsoft provides to ensure their databases are protected. Good for the SQL Server, but not so much for the surrounding infrastructure.  For databases running on VMware, routine full backups even with periodic differential backups can consume a LOT of disk space and virtual compute resources, and also contribute to the I/O blender effect.

Superhero #2: The VMware administrator

TSM for VE in VMware vSphere web client

TSM for VE in VMware vSphere web client

VMware administrators can be just as focused on their domain as DBAs are. Their attention is on being able to recover persistent or critical virtual machine (VM) images, regardless of what app happens to be riding along. VMware has done a nice job of creating and supporting an industry of tightly integrated backup providers. These tools can get at the VMware data through a set of vStorage API’s for Data Protection (VADP) and VMware administrators can manage them through vCenter plug-ins. But few VMware admins are completely aware of all the workloads that run on their VMs and even less aware of the unique recovery needs of all those workloads. It’s just hard to keep up.

Common ground exists

One tool that bridges the gap is IBM Tivoli Storage Manager for Virtual Environments (TSM for VE). Nicely integrated with both VADP and SQL Server, TSM for VE can bring together VMware administrators and the DBAs in ways that would make any IT manager smile. Here are two of the more common approaches.

We can each do our own thing – together

As noted above, SQL Server DBAs take full backups sprinkled with differentials. Even though this approach can tax server and storage resources, and contribute to the I/O blender effect, it is in the DBA comfort zone. When the app is running on a VMware virtual machine, the DBA has the option of storing those backups on disk storage associated with the VM. It’s a nice thing to do because it allows the VMware admin to stay within his comfort zone too. Using vCenter to drive a VADP integrated snapshot tool like TSM for VE, the VMware admin can capture a complete copy of the virtual machine, along with the SQL Server backups the DBA created. Since the likely use of such a snapshot would be to recover the VM and then recover the database from its backup, there’s really not a reason to include the source SQL Server database or logs in the snapshot. With TSM for VE, the VMware admin can exclude the source SQL Server database from being redundantly backed up adding to an already formidable set of built-in efficiency techniques (with TSM for VE, snapshots are taken incrementally – forever, and can be deduplicated and compressed).  It’s a good compromise solution letting each admin stay in his or her comfort zone. But it can be better.

We can join forces and do something really great

VMware and SQL Server superhero togetherWith TSM for VE, VMware admins and SQL Server DBAs can put their heads together and choose to do something really great. For the DBA, it’s an exercise in less-is-more. The DBA stops doing her own backups. No more full or differential copies of the database. No more taxing resource usage on the VM. No more I/O blender effect. Just, no more. How? Well, with a VMware VADP integrated backup tool like TSM for VE, the snapshot of the VM is accompanied by a freeze and thaw of the SQL Server database (techno-speak for putting the database in a consistent state), just like what happens when a backup is independently initiated by a DBA. And with TSM for VE, as soon as the TSM server confirms that it has successfully stored the consistent snapshot in a safe, physically separate place, it will connect back with the SQL Server to truncate the database logs.

In addition to the less-is-more benefits above, think about the differences in restore with these two scenarios. When the DBA and VMware admin simply coexist, each doing their own thing, restoring the SQL Server database includes steps for restoring:

  • The VM snapshot to get the database backups in place
  • The full database backup
  • The subsequent differential backups

By comparison, when the DBA and the VMware admin join forces with TSM for VE, the steps are dramatically simplified. Restoring the snapshot equates to restoring a consistent copy of the database.  And remember, because these snapshots are highly efficient, they can be taken quite frequently.

Superhero indeed!

Going to VMworld 2013? Come visit IBM on the Solutions Exchange floor at booth #1545.


About Ron Riffe

IBM Manager, Software Defined Portfolio. Adoring husband, proud daddy, imperfect but redeemed. I have a thirty year background in the storage industry having held positions as both a consumer and a peddler and in roles spanning from administrator, to thought leader, to strategic planner, to senior manager. I’m also a passionate leader, speaker and author. My perspectives are my own.
This entry was posted in Backup and Recovery, VMware and storage and tagged , , . Bookmark the permalink.

4 Responses to IBM at VMworld 2013: Making heroes of VMware admins and SQL Server DBAs

  1. Len Clark says:

    Given the “freeze and thaw”, how would I recover a backup from, say, three days ago? Do I,
    a) copy the data files out to the relevant V Server
    b) attach them to a database (with, presumably a new name)?

    Since I will need both a .mdb and a .ldb, how do I ensure that they are consistent when they are on different drives and may be imaged at significantly different times?

  2. Del Hoobler says:

    The snapshot is federated, i.e. it works in conjunction with the SQL Server and the disk subsystem through the VSS infrastructure. Therefore, if your SQL Server database files were on one drive and your database log files were on another, they will be quiesced and snapped at the same time in a synchronized fashion. This article explains more details about how the VSS infrastructure works if you are interested:

    As far as restore, you have a few options, Yes, you could mount the snapshots and copy the files off, followed by a SQL Server attach. You can also access the snapshots using TSM Data Protection for SQL and let it automatically handle the mount and restore of the files from the snapshot and interface with the SQL Server to run the recovery.

  3. Falk says:

    What about point-in-time recovery? If the logs are just truncated there is no way to restore to a specific point-in-time. My comfort zone is lost for a lot of databases I have to take care. In the documents (TSM4VE) and your article there is nothing written about that. At least a warning for all the TSM and VMware admins that are impressed by your solution should be found here, that there is mor than full- or differencial backup!

  4. Del Hoobler says:

    If you want the ability for specific point in time recovery of your SQL Server databases, you can configure TSM for Virtual Environments to not truncate the logs at VM-level backup time and then perform log backups using Data Protection for SQL (or other tool of your choice). At restore time, the database is restored from the TSM for VE backup and then the log backups can be applied before recovery is run.

Join the conversation!

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s