Last time around, we looked at how Simpana® IntelliSnap® technology works with Hitachi Data Systems (HDS) storage, both generally speaking and in terms of Hitachi Thin Image technology. You can start there if you’d like to review those topics.
This time we’re discussing Hitachi ShadowImage. There are two big differences between ShadowImage and Thin Image: space consumption and performance considerations. We’ll get to those. First, let’s look at ShadowImage and the associated HDS terminology.
A ShadowImage volume (S-VOL) is an equal-sized, real-time copy of a production volume (P-VOL). Sometimes this is referred to as mirroring or, in HDS terms, “in-system replication.” I prefer the term “clone,” so I’ll use that. You can keep up to three primary clones.
The first thing to note is that compared to Thin Image snapshots, which maintain only changed data, an S-VOL is a 100% copy of the primary. So if you’ve got 10 TB of primary, you’ve got 10 or 20 or 30 TBs worth of clones. Space consumption is a major consideration, but the smart folks at HDS have optimized ShadowImage clones to make good use of space. If the P-VOL is provisioned using thin provisioning, the ShadowImage clone can also be provisioned that way. In that case, if a 10 TB LUN was created but only used 2TB of blocks, the ShadowImage clone would be provisioned as 10 TB but only take up 2TB of space. IntelliSnap technology can ensure that the provisioning aspect is correct when utilizing ShadowImage. Also, unlike snaps, with clones you really can’t have a lot of recovery points, because each clone equals only one recovery point. Snaps can easily give you dozens or even hundreds of recovery points; clones cannot. Keep in mind also that the initial synch of a large volume can take some time, unlike snaps which are more or less instantaneous.
The other consideration is performance. The good news about clones is that they are physically separate LUNs in different pools. A different pool will reside on separate spindles. If you decide you want to use the clone for some high-impact operation – like copying it, running intensive reporting against it, using it for active test/dev – then you aren’t creating impact on your P-VOL. With snapshots, all the read I/O is coming off your primary spindles, so you can see some production impact depending on how hard you hit it. Snaps are great for recovery use cases because you can have lots of recovery points with limited space consumption, but if you want to use them more actively, make sure you aren’t pushing the I/O beyond what it can handle.
IntelliSnap technology automates synching up your ShadowImage clones with applications. Look at the diagram and follow the numbers.
At Step 1, the IntelliSnap software agent (the 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. Using application APIs, IntelliSnap software will put the app into a proper backup mode.
When the app is properly quiesced, the host communicates to the storage array via the array Command Device (Step 2). At this point, IntelliSnap technology will split the clone off so the data in the clone is application consistent and ready for use (Step 3). Meanwhile, the array continues to track data changes that occur after the clone is split off, meaning that when you re-synch it, you don’t have to re-synch all the data, just the deltas since the split occurred. Clones are also non-accessible before they are split. Post-split you can mount them to a server, which is what happens in Step 4 when the IntelliSnap software mounts the clone for indexing (optional). Indexing lets you find things quickly and gives you granular recovery capabilities, though indexing is more important with snaps than with clones. With snaps, you can have dozens or hundreds, so finding a particular file or many versions of a file is vastly easier with an index.
As a final step, when you are done using the clone, the P-VOL is re-synched with the S-VOL so the S-VOL is once again current, ready for you to split it again when needed.
Cascaded Snapshots: The Best of Both Worlds
Right about now you’re thinking, “Wouldn’t it be great if you could combine the performance of clones with the space efficiency of snapshots?” Well thanks to the smart folks at HDS, you can! That’s called a “cascaded snapshot,” meaning a snapshot that uses an S-VOL clone as the source rather than a P-VOL. Looks like this conceptually:
And yes, IntelliSnap technology supports cascaded snapshots! Here’s the sequence of events.
You need to have a ShadowImage relationship in place to start (Step 1). We recently added the ability to import existing ShadowImage pairs into the IntelliSnap solution, so no worries about needing to re-synch an existing clone. If you don’t have a clone in place, you can set one up with IntelliSnap software (as a separate process prior to configuring the snap schedule, and then convert it to a cascaded snapshot configuration).
Before we take snapshots, we make sure the P-VOL and S-VOL are in synch (Step 2). In Step 3, after quiescing the application, we split the clone off. And then IntelliSnap software takes a snap off the S-VOL (Step 4). You can then use this clone-snap for indexing purposes (Step 5) or you can mount it to another server (Step 6) for value-added tasks: test/dev, reporting, etc. And remember, you’re running these off the S-VOL spindles, so there’s no impact on the P-VOL.
IntelliSnap software makes this multi-step process very simple to set up and run, automating a number of steps that you would need to do manually, subject to all the human error that comes with that. You can even schedule procedures like mounting the snap. An example use case would be a test/dev workstation that needs a copy of Oracle every morning. You could schedule the snap to mount each morning at 8:00 a.m. so when the developer shows up for work, the Oracle image is already mounted to the workstation. Nice! You can even hand off the management of this to the developer because IntelliSnap software provides plenty of detailed user rights and security, meaning you can restrict a user to a very narrow set of operations (e.g., let them do what they need to do, but don’t hand them the keys to the kingdom).
You might be thinking that software as cool and valuable as IntelliSnap software would be an expensive proposition. But you’d be surprised at how reasonable it is to purchase and deploy. If you’re a Hitachi user today, you can talk to your Hitachi sales rep because HDS re-sells Simpana technology under the name Hitachi Data Protection Suite.
That concludes our topic for today. In the next installment, we’re going to pull it all together and explain just what IntelliSnap technology can do for you when it comes to protecting and recovering critical applications.
Special thanks to CommVault’s Jonathan Howard for his excellent diagrams and for key technical details.