The Backup Blog

The Next Step Forward For Mainframe Virtual Tape: DLm6000

Mainframe tape is a funny thing. Or at least it can look funny to a person that doesn't work with mainframes.

Funny because mainframe tape does a bunch of things. In the open systems world, life is simple by comparison. Tape does (or did!) basically one thing: backup. Yes, you could argue that it was used for archiving too, but that argument largely depends on the notion that backup and archive tend to be the same thing for open systems folks. Which isn't necessarily a good thing, but it is certainly the case more often than not.

In the mainframe world however, tape does at least four things: backup, archive, batch processing, and migration (for DFHSM). Now some of these, it could be argued, are sort of suited to tape. And some are not. In fact, as time has moved on, the value of tape to each of these has degraded.

And as innovation has occurred, that value has degraded even further. Because mainframe tape is very much like open system tape in one key respect: it isn't very much fun. It is unreliable (relative to other IT systems), it is insecure, it is slow, and it is an operational nightmare. And on top of it all, it makes disaster recovery planning, testing, and execution really really difficult.

Killing Me Softly

Early this week an IBM blogger mentioned that IBM had increased the density of storage on tape by some impressive factor of 40x or thereabouts that would result in tape cartridges of 35 TB. As a research exercise or proof of concept or some such thing.

Consider me unimpressed. Well, no, not quite. I am impressed in the same way that I might be if I took a trip to the Ripley's Believe It Or Not exhibit at the circus. Weird. Bizarre. Freaky. But not terribly useful to the real world.

I also had two more rational reactions.

The first of these was that the "announcement" reminded me a lot of a briefing that I attended many years ago. The briefing was given by Sun, and it was all about their new multi-core, multi-threaded processors.This was a big thing at the time: Sun had been selling some really really big systems (E10000s and E15000s for those of you with long memories). And they were really really expensive. Yes they occasionally went out the door at 90% discounts. But often these systems were $10,000,000 or so. Just for the system. No storage. No apps. No database. Which seems pretty absurd by today's standards, doesn't it?

TSM and the Elephant

OK, fair notice here, but much of what follows is only tangentially related to backup, at best. But there is a point, I think, to my rambling.

First, let me start by reacting to Tony Pearson's continued defence of TSM as a backup application that offers economies of scale. And before I really get going, let me emphasize again the definition of economies of scale: economies of scale offer a declining marginal cost per unit. It is what makes many industries go around: automotive (to the degree that it is actually going around these days!) and chip manufacturing to name just two. It is what makes Intel so successful: the 1,000,000 chip of a given architecture costs pennies (although the first chip might have cost them $2bn or so!).

I have a belief that is somebody can figure out how to achieve real economies of scale in backup and recovery, they are going to achieve two things: they are going to get rich, and they are going to get significant (dominant?) market share. Although I think that EMC has gone further than anybody else in achieving economies of scale with backup, I think there is still a great deal more that we can do. We as an industry, or we as EMC, however you wish to read that.

TSM, Virtual Tape, Deduplication and Reclamation

Well that is kind of a mouthful.

Quick technical tip for TSM users. When TSM is finished with a tape volume (virtual or physical) the default behaviour is to not relabel it, but instead to reuse it with the existing label (volume ID).

This happens to be not a very good thing if you are using a virtual tape library with deduplication. Why? Because virtual tape libraries don't reclaim space--at the block or segment level that is no longer referenced by valid backup data--on a volume that is still in use. Even if "in use" in this case means sitting in the (virtual) scratch pool doing nothing.

So, the good folks over at IBM figured this out, and have a way to force TSM relabel a volume when it is returned to the scratch pool. In terms, the VTL now sees that the data referenced by this volume is no longer valid, and can be freed up for reclamation, which will free up physical space on your deduplicated VTL. Good stuff.

In order to take advantage of this, you need to set "relabelscratch=yes" in your library definition. You can find additional detail here: http://www-01.ibm.com/support/docview.wss?uid=swg21330242. Note that if you are at TSM 5.5.1.0 you will need to apply a patch for this to work, if you are at 5.5.2.x and higher, it should work without further patching.

Virtual Tape Revisionist History

It seems that Tony Pearson over at IBM is up to it. Again. Once again (and just about one year later) he has failed to acknowledge the difference between Open Systems virtual tape and mainframe oriented virtual tape. His claim: "Today, IBM is the leader in storage virtualization, both for disk and tape."

Really, Tony?

I don't think so. It has been a while since we looked at the topic, but to refresh: mainframe and open systems virtual tape are two very different beasts. They have different use cases, attach to different platforms, have different performance objectives, and so on. And while it is true that IBM has done admirably well in the area of mainframe virtual tape (although EMC's MDL continues to gain market share), it is also true that IBM has been a virtual no-show in the area of open systems virtual tape. To claim leadership would be a massive distortion of the facts.

Unequivocally, EMC has shipped more Open Systems virtual tape than any other vendor. And when compared to any other single vendor, like IBM, the disparity is usually about 10:1 in EMC's favor.

Of course, Tony is also claiming a "resurgence" in interest in tape. In the same year that IBM reported a 31% year over year decrease in tape sales revenue. Hmmm.

Disk Library for Mainframe Update

The good folks over in marketing made a sneak announcement on December 29th regarding the Disk Library for mainframe (DLm). Sneak because, lets be honest, how many of us had reading press releases as a high priority on December 29th?

In any event, there is some good stuff here. To revisit the core differentiator of the EMC DLm: this is a virtual tape library for mainframes that is not a disk cache. That is a significantly different architecture from either competitive offering from Sun or IBM--both of which are "merely" a small to medium size disk cache in front of a bunch of physical tape. Expensive disk. Expensive tape.

So EMC's approach is a little different: take the tape out of the equation. And a good chunk of the cost too. The DLm is far more than "just" a disk cache: by virtue of capacity and capability it enables you to store data more or less permanently on disk. Not to say that you will have no tape at the end of the day, but you will have a lot less than with other approaches.

Tape Drives and TSM

A while back, after reading this post, a reader asked: so how do other backup applications compare to TSM? If TSM runs tape drives at 80% to 90% utilization on average, how busy are tape drives with other applications?

Good question.

Not only is it a good question, it is also one of the primary differences in practice between TSM and everybody else. (And I say everybody else because, for arguments sake, "everybody" else does a traditional grandfather, father, son backup rotation which involves full backups on weekends, and incremental backups throughout the week. Except, as I never tire of pointing out, for databases and email which are probably backed up full everyday by most people anyway. And yes there are a couple other backup applications which do a progressive incremental like TSM, but their market share is so tiny as to render them insignificant.)

I Want A Red Ferrari

Unfortunately, wanting something, and having reality conform to my desires, are two totally different things. So it should come as no surprise that I do not, in fact, have a red Ferrari. Or a Ferrari of any color. Nor is it likely to be the case that I will have one in the future.

And I am OK with that.

When Tony Pearson talks about virtual tape and TSM in his latest post, I get the impression that not only does he want a red Ferrari, he thinks that desire alone is sufficient to ensure that one appears in his driveway.

IBM Really Does Love Diligent

After waiting so long for the news, I was beginning to fear that IBM had gotten cold feet, or that maybe they were just too hung over after celebrating the XiV purchase to go ahead and consummate things with Diligent. But not so! No, they have forged fearlessly ahead, procuring for themselves one data deduplication company, courtesy of their new BFF (best friend forever), Moshe Yanai. All for a cool $200m. Nice. I wonder if they know that it doesn't replicate? The Diligent deduplication solution, that is. Well, no matter. Who needs replication when you have tape? Or something like that. I am sure they will figure it out by the time they release TSM with deduplication and hopelessly confuse their customer base. Again. You go girl!

And (tongue firmly in cheek) I suppose this means that IBM now has a technology EMC didn't want, and DataDomain has 100 plus sales people EMC didn't want.

Peace, Love and Revolution

Barry Burke may want to riff on Britney Spears in his latest post, but I think I will channel Lucinda Williams instead. Besides being two or three decades older than Ms. Spears, Lucinda is also gifted with wisdom and passion, qualities sadly lacking in little Miss Train-Wreck-In-Slow-Motion-Spears. So, it is Lucinda's words that title this post.

And, I like to think that it is time for a little Peace, Love and Revolution in the world of backup and recovery. Mostly revolution though. The peace and love can come as we, as an industry, work to make things better.

The revolution we need is a re-think of our backup applications.