SDLT 110/220 and Maximum Throughput.

[Graham Mitchell]

I have an 1850R which is being used as a central backup server. I have two Wide Ultra 3 SCSI controllers and four 110/220 SDLT tape devices (two tape devices connected to each controller), and a SMART 3200 that the internal disks connect to.

I'm not getting the expected data throughput to each tape device, and I believe this may be related to the way the controllers are connected internally to the PCI BUS. The internal connections are as follows:

Wide Ultra 3 (card 1) Slot 1 Bus 1
Wide Ultra 3 (card 2) Slot 1 Bus 2
SMART 3200 (disks) Slot 4 Bus 0

Please could you reply detailing the optimum PCI slot configuration to give maximum throughput.

Many Thanks

Graham.

[Leif Halvarsson_2]

Hi,
Some questions.
What throughput do you get ?
What kind of data do you back up (small files , large files, databases etc. ) ?
Is the data you back up local or do you backup over LAN, FC, etc. ?
Is all four drives running simoultaneous ?
Is there any difference when backing up using only one drive ?

[Graham Mitchell]

In Reply to the questions posted.

The majority of the backup is completed over the LAN, (100MB) The data is pushed using backup client agents.
The data is a mixture of system files and word documents, so no large databases or applications.

The average throughput differs from (slowest) 1.65MB/Sec to (quickest) 4.05MB/Sec, across the LAN. While a local backup throughput is 4.81MB/Sec

The tape devices are running job simultaneously. I will need to perform a test using only one drive to be sure of the outcome.

I understand that the network may be providing a bottleneck to the LAN backups, but I would still expect the local backup to be quicker than 4.81MB/sec as the tape device max throughput is 11MB/Sec.

Hence why I think it may be something to do with local Bus configuration.

[Leif Halvarsson_2]

Hi,
I don't know which backup software you use but, if it is possible, try to back up a local filesystem to a null device (NUL) and check what performance you get.

[Brian M Rawlings]

Graham: what you are seeing is probably the common problem of 'disk speed'. What is that, exactly?

Well, disks are fast. Now we put files on them, with file system overhead. Then we fill them up and end up with fragmentation. Then we do backups while apps are using the disks, causing lots of seeking. Or, the internal drives are ATA, not SCSI, and aren't quite as fast (5400RPM spindles, etc). And, all of a sudden, a disk isn't quite as fast as we thought.

These tape drives are voracious. They (each) want 11MB/s, native. If you send it a data stream that compresses at 2:1, it will want 22MB/s. Compression actually varies from file to file, from none to 3:1 or higher, with spikes of highly compressable data wanting 40MB/s (briefly), or even more.

So, how on earth do you keep even one of these monster tape drives satisfied, when a disk can't even send it more than 4-5MB/s?

The trick is in the backup software you are using, and in using really fast disks.

If you run, say, Veritas Netbackup, or HP Omniback ("Data Protector", now), they have a "concurrency" setting, which allows one or more backup agents on the local host or network hosts to all send data from multiple disks, at the same time. The BU SW then amalgamates (multiplexes) all these data streams together, and sends them to the tape drive as one massive feed. The tape is happy, the backups are scalding fast, and life is good.

To do this over the network, you need to back up several servers at once (if they are all on 100baseT). Gigabit ethernet is needed for this kind of throughput, between at least your backup server and the network switch(es). The switches will allow many 100baseT links to run simultaneously through a Gig-E (1000baseT, or fiber). Or, ideally, big servers are all on Gig-E. Even more ideally, you have a seperate Gig-E backup network. But I digress into fantasyland...

Another great scheme is that all modern external disk arrays have Fibre Channel (very fast) connections, and enough performance (from parallelism at the drive level) to provide hundreds of megabytes per second. They also have some sort of "snapshot" capability, to make an instant copy of a volume (or some logical data group), which you can then mount up to your backup server. This will provide you with a data stream that is WAY fast enough for your tapes, even all four of them, simultaneously.

One caution: if you don't provide these drives with a faster data stream, you end up actually harming them. This is due to their motion: when they have data, they cruise along. If they run out of data, they have to stop, slowly. Then rewind past the stopping point. By now (2-3 seconds), they have data, so they start up again, only to repeat the above every few seconds. You end up putting 100 miles on your drive and your media for a 2 mile backup. It can literally be 50-100 times as much wear and tear as they would normally see, if they could just keep running. This is known as the "shoe-shine" effect, and will prematurely wear out both tapes and drives. This issue is common to all "streaming" tape technology (DLT, LTO, 8mm, etc).

So, figure out some way of sending these drives more data at once, or you risk reliability issues down the road, both of drives and (worse) of your media.

Regards, --bmr