Ever increasing tape speeds are technical suicide

Column

Ever increasing tape speeds are technical suicide

Hywel Matthews
Have you got the network, SAN and server infrastructure to support the latest and greatest? What will be the impact to your restore times? Not forgetting LTO5, LTO6, DLT-S5, DLT-S6 and DLT-S7 are on the road map.

Here are some interesting native throughputs to keep in mind. IBM TS1120 and DLT-S5 ≈ 100 MB/sec, LTO4 and STK T10000 = 120MB/sec. LTO5 and DLT-S6 weigh in around 180 - 200MB/sec; LTO6 should be a whopping 270MB/sec with DLT-S7 projected to be a staggering 400MB/sec. Clearly this is fulfilling a need for speed. The question is how are we going to get at it?

Your reaction to these figures could be: (A) a raised eye brow and a perplexed look, as you know you will be facing these challenges in the near future; (B) an indifferent response as it does not affect you, since you have just performed a tape refresh; or (C) a smile - you're about to retire. Well, you need to think about the figures in the event of drive replacements, growth etc. Personally, I had reaction A (right now, C is too far away).

This is not so much of a problem for the DLT mid-range storage market as the DLT-V value range can be chosen over the DLT-S performance range. Someone is applying common sense to the mix at last, except for the naming convention.

How will single stream backup applications cope? A single file/print server running at 2MB/sec will crucify the drive and tape. No doubt, you've all got one of "those" servers where the backup window approaches or extends beyond 24 hours, and a throughput of 2MB/sec is probably wishful thinking.

How will applications capable of sending multiple streams writing to one drive need to be architected? Even in such an architecture, 60 backup streams of 2MB/sec would be required to keep an LTO4 running at its native speed of 120MB/sec. Can the backup application support up to 60 backup streams per drive? If so, how will this affect your RPO's and RTO's?

One of the reasons for backup stream separation is to ensure separation of media, but ever-increasing drive throughputs will challenge this backup practice, which up until now is widely followed. Make way for virtual tape libraries, which look like a suitable proposition or disk-to-disk-to-tape (D2D2T) (with the disk being SAN disk or VTL) for those of you who have a media offsite requirement, to overcome these constraints.

Consider the native speed of an LTO6 of 270MB/sec., which could be 135 streams of 2MB/sec! Or, if the application can only manage, say, 30 simultaneous streams, it equates to 9MB/sec per stream. Remember, all are native speeds, a 2:1 compression doubles the problems, and DLT-S7 is projected to be 50% faster than an LTO6.

The next issue is the specification of a server capable of delivering the throughput - the first challenge coping with that 270MB/sec network throughput – which is going to need a few NIC's. Then enough CPU and memory to cope with the: (1) data mover server workload; (2) number of NIC's; (3) the number of HBA's required (depending on the number of attached drives, which I envisage as not many), plus the required SAN infrastructure and careful design to eliminate bottlenecks. By then, 10GB SAN's should come to the rescue.

In the months and years to come, we backup types must somehow be integrated into application or system deployments, as the data layout will become key to the ability to backup and protect the data. An architect's idea of data layout is not necessarily the best from a backup point of view.

About the author: Hywel Matthews is an Senior Consultant at GlassHouse Technologies (UK), an independent consulting firm with an emphasis on IT infrastructure.


Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
 

COMMENTS powered by Disqus  //  Commenting policy