Big Blue stuffs data into backup at GIGABYTES/sec IBM's TSM backup product goes super-fast when backing up to the Elastic Storage parallel file system, according to company trials. TSM stands for Tivoli Storage Manager, with Elastic Storage being the re-branded GPFS. Servers running TSM were linked to an Elastic Storage array in a proof-of-concept test by IBM engineers in …
Great results for TSM server. But absolutely no measurment of the client performance or end-to-end backup performance because, according to IBM, this "eliminated TSM client system bottlenecks caused by limited disk and network performance". So absolutely no use as an indication of what you will get in real world scenarios. Also no indication of how much "disk and network" would be required on the client to get anywhere near the results here.
Benchmarketing or benchmarking?
"A previous PoC used 56Gbit/s InfiniBand to link TSM and GPFS servers and also produced outstanding results:
Peak backup performance using multiple sessions for a single TSM server is 5.4GB/sec.
Peak backup performance using multiple sessions for two TSM servers is 9 GB/sec in total.
Peak restore performance using multiple sessions for a single TSM server is 6.5 GB/sec.
Peak backup performance using a single session for a single TSM server is 2.5 GB/sec."
9 GB/s over a 56Gbit/s (7GB/s) link is very impressive, some might say impossible. Looking at the linked blog post shows that the TSM servers connect to the switch each with a single 56Gbit/s link, but that the GPFS Storage Server is hooked up to the switch with 2 x 56Gbit/s connections per server. So unless I am mistaken, they are sending the data to and from the same storage, albeit through the switch. This sounds more like marketing than a genuine PoC to me.
"9 GB/s over a 56Gbit/s (7GB/s) link is very impressive, some might say impossible." This is the bandwidth achieved by 2 TSM servers, each attached using one 56Gb/s link, so is eminently possible given the way the tests were run.
They installed a TSM client on each of the TSM servers and connected the client to its local server via an in memory pipe. For both proofs of concept the client DID NOT READ any data. It generated the data to be backed up and then sent it to the TSM server to back it up. The "TSM client workload was artificially generated in memory".
This is a test of TSM server performance and tells you nothing about TSM client or end to end performance. Hence my comment about Benchmarketing vs Benchmarking.
(Disclaimer: I work for Quantum and sell StorNext)
Nothing to see here... As the previous commenter mentioned StorNext has been doing this for years. For those that don't know StorNext is a cross-platform (Mac OS X, Linux, Windows and a variety of UNIX platforms) SAN or LAN attached high performance clustered filesystem with an integrated HSM policing based tiering engine called Storage Manager that can archive at whatever performance you require to what ever storage you require whether disk, tape, object storage (like Quantum Lattus), etc... meanwhile supporting up to 5 billion files in a single namespace.
Sorry for the sales pitch but we are conspicuously absent from this article.
I always thought it was an acronym for "Tivoli Storage Manager".
What do you suggest it's an abbreviation of, Richard1?
There are those who feel an acronym must be pronounced phonetically; presumably when spoken aloud, "TSM" is typically pronounced "tee-ess-em" rather than, say, "təsm". Often they prefer "initialism" for a term constructed like an acronym but read as individual letters. This is false, or at best dubious, pedantry: the term "acronym" is not a grammatical or linguistic term of art, and etymologically (and it's of recent coinage) is just a portmanteau of "across" and "nym" (name). Even prescriptivists don't really have a leg to stand on with this one.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
