TSM Target Deduplication: You Get What You Pay For

I was recently pondering TSM’s implementation of target deduplication and decided to review ESG’s Lab Validation report on IBM TSM 6.1. There is quite a bit of good information in the paper, and some really interesting data about TSM’s target deduplication.

Before discussing the results, it is important to understand the testing methodology. Enterprise Strategy Group clearly states that the article was based on “hands-on testing [in IBM’s Tucson, AZ labs], audits of IBM test environments, and detailed discussions with IBM TSM experts.” (page 5) This means that IBM installed and configured the environment and allowed ESG to test the systems and review the results. Clearly, IBM engineers are experts in TSM and so you would assume that any systems provided would be optimally configured for performance and deduplication. The results experienced by ESG are likely the best case scenario since the average customer may not have the flexibility (or knowledge) to configure a similar system. This is not a problem, per se, but readers should keep this in mind.


TSM and Deduplication: 4 Reasons Why TSM Deduplication Ratios Suffer

TSM presents unique deduplication challenges due to its progressive incremental backup strategy and architectural design. This contrasts with the traditional full/incremental model used by competing backup software vendors. The result is that TSM users will see smaller deduplication ratios than their counterparts using NetBackup, NetWorker or Data Protector. This post explores four key reasons why TSM is difficult to deduplicate.

Backup Deduplication Virtual Tape

War Stories: Diligent

As I have posted before, IBM/Diligent requires Fibre Channel drives due to the highly I/O intensive nature of their deduplication algorithm. I recently came across a situation that provides an interesting lesson and an important data point for anyone considering IBM/Diligent technology.

A customer was backing up about 25 TB nightly and was searching for a deduplication solution. Most vendors, including IBM/Diligent, initially specified systems in the 40 – 80 TB range using SATA disk drives.

Initial pricing from all vendors was around $500k. However as discussions continued and final performance and capacity metrics were defined, the IBM/Diligent configuration changed dramatically. The system went from 64TB to 400TB resulting in a price increase of over 2x and capacity increase of 6x. The added disk capacity was not due to increased storage requirements (none of the other vendors had changed their configs) but was due to performance requirements. In short, they could not deliver the required performance with 64TB of SATA disk and were forced to include more.

The key takeaway is that if considering IBM/Diligent you must be cognizant of disk configuration. The I/O intensive nature of ProtectTier means that it is highly sensitive to disk technology and so Fibre Channel drives are the standard requirement for Diligent solutions. End users should always request Fibre Channel disk systems for the best performance and SATA configurations must be scrutinized. Appliance-based solutions can help avoid this situation by providing known disk solutions and performance guarantees.


TSM Deduplication

IBM recently announced the addition of deduplication technology to their Tivoli Storage Manager (ITSM) backup application. ITSM is a powerful application that uses a progressive incremental approach to data protection that is completely different from most other backup applications. The addition of deduplication to ITSM provides a benefit in disk space utilization, but also creates some new challenges.

The first challenge for many TSM environments is that administrators are already over-burdened with having to manage numerous discrete processes to ensure that backup operations are meeting their business requirements. The deduplication functionality within ITSM adds another process to an already complex backup environment. In addition to scheduling and managing processes such as reclamation, migration and expiration as part of daily operations, administrators now have to manage deduplication as well. This management may involve activities as disparate as capacity planning, fine-tuning, and system optimization. The alternative is to use a VTL-based deduplication solution like a SEPATON® S2100®-ES2 VTL with DeltaStor® software, which will provide deduplication benefits without having to create and manage a new process.


IBM Deduplication Appliances

I have been on hiatus as of late and apologize for my tardiness in blogging.

IBM released their new deduplication applications based on the technology they acquired from Diligent. At first glance, it might appear that this could be a competitive alternative to SEPATON, but when you look at it, it quickly becomes apparent that this is not the case.

IBM previously sold one product, TS7650G gateway which they now target at the enterprise. The new appliance products use similar server hardware and a de-featured version of the DS4700 disk array. As with all Diligent installations, the solution uses Fibre Channel drives that reduce density and add cost. They will never be price leaders. The configurations are as follows:

Capacity Nodes
7 TB One
18 TB One
36 TB One
36 TB Two

You can’t move beyond the configurations listed above. If you want to grow the system beyond 36 TB, you are out of luck. Your only choice is a forklift upgrade to the TS7650G gateway. What if you want dual nodes and less than 36TB? Same answer. How about replication? Same answer. (That is, if you can consider the array-based approach in the TS7650G a realistic replication option.)

The ultimate irony is that by creating appliance VTLs, IBM has actually made their customers’ lives more difficult. Customers now have to choose whether to purchase a gateway (which adds complexity and cost) or a simple bounded appliance (which has limited configurations). Why should a customer have to make this trade-off? Why not offer an appliance that is simple, cost-effective AND scalable? Well, the simple answer to the question is to get a SEPATON S2100-ES2!


TS7650G and Fibre Channel Drives

IBM/Diligent TS7650G uses a pattern matching approach to deduplication, which is different from the hash-based solutions used by many vendors or the ContentAwareTM approach pioneered by SEPATON.

Diligent’s technology requires Fibre Channel (FC) drives for the best performance because pattern matching is highly I/O intensive and needs the additional I/O from FC drives. FC drives in turn, negatively affect disk density, require more power and dramatically increase the price of the system.

The pattern matching technology used in the TS7650G is an inline process. Therefore, all duplicate data has to be identified before data is committed to disk. Pattern matching only provides an approximate match on redundant data and requires a byte-level compare to verify the redundancy. All byte-level compares must be completed before any data is written to disk and the next piece of data accepted. FC drives are required because they provide the random I/O performance needed to handle inline byte-level comparisons. Diligent specified a 110 disk FC array for the ESG performance whitepaper that they sponsored back in July of 2006. (Local copy of the ESG whitepaper.)  This is not to say that the algorithm will not work with SATA, but these drives will dramatically reduce performance.

If you are considering the TS7650G, you must carefully consider the associated disk sub-system. It is not clear what disk system and capacity was used when IBM/Diligent generated their performance specifications. As part of the evaluation you should also test single stream and aggregate backup performance because as previously mentioned single stream performance may be a challenge.

Deduplication Virtual Tape

Falconstor, SIR and OEMs

This article on highlights enhancements to FalconStor’s SIR deduplication platform, but I have to wonder whether anyone cares. FalconStor was a big player in providing VTL software to OEMs; but their deduplication software has been largely ignored.

FalconStor had their heyday in VTL. They aggressively pursued OEM deals with large vendors including EMC, IBM, and Sun. EMC was the most successful with their EDL family of products. As the market moved to deduplication, you would think that FalconStor would be the default OEM supplier of deduplication software as well. You would be wrong.

Ironically, FalconStor’s VTL success was their downfall in deduplication. Their OEMs realized that they were all selling the same VTL software and did not want to repeat the situation with deduplication.  EMC and IBM, have already announced that they are using alternative deduplication providers.

Backup Deduplication

IBM Storage Announcement

As previously posted, I was confused about the muted launch of IBM’s XIV disk platform. Well, the formal launch finally occurred at IBM Storage Symposium in Montpelier, France. Congratulations to IBM, although I am still left scratching my head why they informally announced the product a month ago!

Another part of the announcement was the TS7650G which is Diligent’s software running on an IBM server. Surprisingly, there is not much new; it appears that they are banking on the IBM brand and salesforce to jumpstart Diligent’s sales. Judging by the lack of success in selling the TS75xx series, it will be interesting to see whether they will have any more success with this platform.

From a VTL perspective, IBM has backed themselves into a box. Like EMC, they have a historic relationship with FalconStor and have chosen a different supplier for deduplication. This creates an interesting dichotomy. Let’s look at the specs of their existing FalconStor-based VTL and newly announced technology.


A little bit off topic – IBM XIV

I traditionally stay focused on data protection in this blog, but wanted to make a quick digression. Specifically, I wanted to comment briefly on some weirdness around IBM and their XIV product line. IBM has recently been positioning XIV storage inside their new deduplication enabled VTL. Anyone considering these solutions should spend some time trying to understand XIV.

IBM bought XIV about 8 months ago. XIV was an Israeli company founded by industry guru Moshe Yanai. Yanai is clearly a smart guy having developed EMC’s Symmetric Storage system. He is experienced and talented, and his company, XIV, was developing next generation clustered storage. When IBM bought XIV, they said that it “could mark the end to RAID5 and mark the beginnings of a new disk storage architecture” (Quote courtesy of Tony Pearson, IBM employee and author of Inside Systems Blog).

All of the above sounds great, the problem is IBM just announced the first XIV product in Europe only with very little fanfare. It is quite odd, if the product is as revolutionary as they had previously suggested, wouldn’t you expect them to make a big deal out of it? Where are the analyst quotes? Where is the evangelizing? The short answer is that there has been none! What gives?

There have been numerous posts in the blogosphere about this. One of the earliest folks was Barry Burke from EMC on his StorageAnarchist blog. Blocks and Files, NetworkWorld and eWeek have also chimed in. Everyone is confused by this, Network World notes that the features are very limited in the product and eWeek goes so far as to suggest that the entire XIV acquisition was a failure!

The noteworthy point of the announced XIV solution is that its feature set is unimpressive and it only comes in one configuration, RAID 1 and 180 TB raw/80 TB usable. If you want any more storage that means a second XIV; if you want less, that means you get a fully populated XIV and you will only be licensed for the amount you are using. This makes for completely weird economics. No matter how much storage you want, you get 180 TB raw. You want 20 TB, no problem, you get 180 disks. Want 5 TB, they can meet that requirement as well although it requires 180 disks!

I have no idea what IBM is doing with this launch, but in my opinion, IBM has made a big blunder. When announcing a product, you either have to be fully committed with all resources behind or hold off. This half-baked launch where they only announced it in EMEA only is just plain odd and it leaves everyone, myself included, wondering what is really going on. From a product standpoint, I think that they probably encountered more challenges than originally expected and so were forced to delay the launch of the fully functional XIV. Why they launched the half-baked version in Europe is beyond me…