Forum Discussion

Viktor_Tanin's avatar
13 years ago

Low perfomance of SAN using BE 2010 R3

Hi.
We are using BE 2010 R3 with latest updates.
BE is running on blade server which connected with other segments of SAN through 8-gbit FC-swithes.
Also, here is HP StorageWorks MSA P2000 G3 with SAS and SATA disks, and HP MSL 4048 LTO5 tape library connected through FC-swithes.
LAN is a management network.

Speed of backing up data from P2000 to tape library is about 2600 MB/min, speed of verify operation is 13000 MB/min.

What do you think, why is not achieved full network speed (8Gb), especially when backing up?

10 Replies

  • We used an MSA for many years.  Not exactly a fast box, but a very reliable one! 

     

    When I set it up, I had to go back through a variety of configurations with the hard drive to get the best possible through put.  Look at HP's web site and see if you can find a white paper on it.  If I remember correctly, we had to create our arrays within the expansion cabinet as opposed to using stripping.

     

    Another thing I found frustrating is that it gets very fragmented very easy.  We used Diskeeper to try and keep it running as fast as it could.

    Disk is always going to be your slowest device, so you have to work to make the best of it.

  • > Disk is always going to be your slowest device, so you have to work to make the best of it. Yeah, but SAS interface supports speed up to 6Gbit, but the actual speed of reading the disk can reach 9000 mb / min and more! We see in 3 times less speed. In addition, speed of verifying is much higher than the writing speed to tape (although to its limits too far). Our HP MSA P2000 connected to SAN through 8-Gb Fiber-channel switches.
  • Hi Viktor,

     

    It depends on what you're backing up, and if the servers you are backing up from are also attached to the SAN. If not, you're looking at SAN performance. If you're backing up a lot of small files compared to large flat files or applications like Exchange, this also affects the throughput.

    The Symantec TN below explains why theoretical throughput could be lower than expected:

    http://www.symantec.com/business/support/index?page=content&id=TECH8326

    So, what are you backing up? If any servers are connected to the SAN and you want to use the speed of your SAN, you need to load the license key for SAN SSO (Shared Storage Option). This makes your current server the main SAN SSO server, and this shares the SAN-attached tape library with other servers.

    If the servers are all LAN-based, then you can look at tuning your drives a bit to see if you can wring out more performance. Also make sure that your NIC speed and switch port speeds are hard-coded to the maximum speed of the NIC.

    You can read th Symantec TN below on how to tune your hardware:

    http://www.symantec.com/business/support/index?page=content&id=DOC3276

     

    Thanks!

  • I agree there are lots of factors that could be causing this. 2,600MB/min is around the speed we get from our LTO3 drive so I assume LTO5 should be faster? But then again, you've stuck it across the fibre channel so introduced another layer into the equation compared to locally attached.

    I assume that this is "normal" backups as it's tape based so none of the deduplication performance factors come into play.

    Is there a way in BE to determine how much shoe-shining (is that the right term?) is going on whereby because the data stream gets interrupted, the tape overshoots and has to rewind. I understand this is a very costly operation which would explain the difference between backup and verify. With verify, BE is simply re-reading the tape to ensure it can be read. This runs at almost full-tilt.

    Cheers, Rob.

     

  • Yeah, but SAS interface supports speed up to 6Gbit, but the actual speed of reading the disk can reach 9000 mb / min and more! We see in 3 times less speed.

    Didn't you only give times for tape backup? What kind of backup are you doing to disk? Backup-to-disk or deduplication? With the later, my tests have indicated that the hash algorithm could be the bottleneck, not the backup media or network. Hashing is a CPU intensive operation and might only be able to run at 1000MB/min anyway.

    Cheers, Rob.

  • We are backing up the whole disks of virtual machine (vShpere 5) with its snapshot. Size of that disks is 40GB and 1TB. These disks is stored on P2000. The backup job is configured to write all data to one tape (1,5TB). Mappings in MSA P2000 is configured for tape library, for backup server and for VM hosts. >2,600MB/min is around the speed we get from our LTO3 drive so I assume LTO5 should be faster? Yes, it should be. >Hashing is a CPU intensive operation and might only be able to run at 1000MB/min anyway. Our backup server has two six-core Intel X5650 CPU and 36GB of RAM :)
  • LTO5 faster? - not neccessarily compared to LTO4, but likely compared to LTO3

    do a search in this forum for

    lto5 speed

    YMMV

    Our LT04 drive does 6500MB/sec via AVVI off an IBM SAN duplicating a B2D job

  • >We are backing up the whole disks of virtual machine (vShpere 5) with its snapshot. Size of that disks is 40GB and 1TB. These disks is stored on P2000.

    Okay so the problem with many little files isn't the problem here. It's a sustained read from disk across the network.

    >Our backup server has two six-core Intel X5650 CPU and 36GB of RAM :)

    And I think you'll find that it's sat twiddling it's thumbs mailing during the backup?

    Cheers, Rob.

  • BTW - have you done a backup of a similar VM image directly from the hard drive of the local media server? As a speed test?

    Cheers, Rob.

  • Backing up one file (11GB) from MSA P2000 to local disk:
    Write speed: 4993 MB/min
    Verify speed: 5190 MB/min

    Backing up from local disk to tape:
    Write speed: 5992 MB/min
    Verify speed: 11985 MB/min