Imagine, if you can, an application environment that needs to maintain 1,200 different scripts in order to protect it. That’s not a typo for 12 or 120. We mean one-thousand-two-hundred scripts. This is a real world example: it’s a big honkin’ UNIX-based application environment on which an entire business depends. And there’s one full-time person maintaining those 1,200 scripts and barely keeping up. Future growth – massive growth, in fact – was destined to overwhelm this entirely manual process. Enter IntelliSnap technology to save the day.
This environment happens to be running on Hitachi Data Systems (HDS) storage. Not at all uncommon — enterprise-class storage for an enterprise-class application environment. But it could be a different enterprise storage vendor. The challenges would remain the same. For this blog and a few to follow, we’re going to take a closer look at the challenges of manually managing snapshots, and how Commvault can help you. Along the way we’ll also take a look at specific HDS data protection technology and how it works together with Commvault.
Hitachi Snapshot Internals
This isn’t meant to be a comprehensive explanation, just an overview. If you’re familiar with HDS storage, feel free to jump to the next section.
In order to coordinate snapshot processes, HDS arrays use something called the Command Control Interface (CCI), which is software that enables data management and configuration tasks. CCI application files are also referred to as Hitachi Open Remote Copy Manager (HORCM) files, which require a configuration file to be created. This software and associated configuration files sit on every host that’s going to make use of the storage.
For operations, the CCI communicates with a Command Device, which is a logical volume on the storage system that functions as the interface to the storage system. The Command Device accepts read and write commands that are executed by the storage system. Got all that? Here’s a picture that might make it easier.
Now to make all this work across multiple hosts, you have to configure multiple HORCM configuration files. Like most configuration files, they require very precise management, meaning that something as minor as an extra space or carriage return can make the whole thing just not work. Troubleshooting can be challenging.
Here’s an example of part of a HORCM file taken from HDS documentation:
Having to maintain hundreds of these manually is no small task. As an example of what can go wrong, a thread in the HDS support forum noted that a user mistakenly typed,
which caused it to fail. You see, it’s case sensitive, and slash-slash-dot-slash, not dot-slash. That’s just how configuration files work. If it’s not 100% right, it’s wrong. User error is a continuing challenge because, face it, humans make mistakes.
And that’s why we have IntelliSnap technology – to do the hard stuff for you. Because when you deploy an IntelliSnap solution, that entire configuration file is built by the IntelliSnap software. To put it in Hitachi terms — IntelliSnap software creates the HORCM file for you. In fact, you don’t even have to know it’s happening. It just is. You can spend your time thinking about higher level issues, like how often you want to protect an application, how long you want to retain the snapshots and so on.
Configuring the Recovery Schedule: Hitachi Thin Image Integration
Hitachi storage has two main data protection approaches: Thin Image snapshots and ShadowImage clones, also referred as “in-system replication.” We’ll look at ShadowImage next time. Let’s focus on Thin Image for now.
Thin Image allows you take a whole lot of highly efficient snaps (1024 per volume, 32000 per array), giving you multiple point-in-time protection copies. Disk savings are up to 75% compared to using full- sized clones (still a very common thing at the enterprise app level).
To furnish more Hitachi-speak, the production disk volume is called a P-VOL. Snapshot space is taken from a defined pool of storage, called the HTI Pool (for Hitachi Thin Image), and each snapshot is referred to as a virtual volume, or V-VOL.
The trick here is to orchestrate the Thin Image snapshot with what’s happening on the host system. So let’s tie everything together. The following diagram lays out the steps. Follow the numbers, explained below.
At Step 1, the IntelliSnap iDataAgent (iDA) talks to the application running on the production host. It supports many of the biggest enterprise applications, including Oracle, Oracle RAC, DB2, SAP, MySQL and more. IntelliSnap technology utilizes application level APIs to ensure that the integration for proper protection is automatically performed; this is critical not only for protection but for recovery also.
When the app is properly quiesced, the host communicates to the storage array via the Command Device (Step 2). The snapshot request is then conveyed to the array, and the snapshot for the proper LUN is taken (Step 3), automatically creating a new V-VOL. As a final, optional step, the snapshot can be mounted to the IntelliSnap server (Step 4) for indexing and/or further processing. Snapshot indexing is a great feature which lets you find files/data within your snaps and provides granular recovery for them (of course, there are no native array capabilities for indexing snap contents).
And that’s how it works! The same process will repeat based on whatever recovery schedule you’ve configured. See what I did there? I didn’t call it a “backup schedule” or a “snapshot schedule.” No, it’s a recovery schedule. Because if you take snaps, say, every two hours, then you have two-hour recoverability for your application. It’s all about the recovery.
It all looks simple and, in fact, it’s very easy to configure a recovery policy. But under the covers, a ton of complicated things are happening. The difference is IntelliSnap is handling them all in a way that’s massively simpler and more reliable than trying to do this manually with scripts and batch jobs (and, one presumes, a lot of hair pulling, if you have any hair left that is). I started by talking about an application environment that needed to maintain 1,200 scripts. Now it has zero. Talk about a solution paying for itself! And as a reminder, you can deploy IntelliSnap technology alongside your current backup solution. It doesn’t replace your backup, it enhances it by providing managed, indexed, operational recovery from snapshots.
There’s a lot more to discuss with IntelliSnap. Next time we’ll look at ShadowImage. Then we’ll take a deeper dive into the application protection and recovery process.
Special thanks to Commvault’s Jonathan Howard for his excellent diagrams.
Hitachi Command Control Interface User and Reference Guide, page 2-13.