• State Suggested Answer
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 28 subscribers
  • Views 6683 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Network Performance Issues

Corrigun
over 7 years ago

After a recent switch issue that caused my exported VM's to fail I have become aware of what seems to be a RR only problem with network speed.

While exporting base images (and I assume snapshots) I am experiencing what I would call "bursting". That is to say a data/pause/data/pause condition that is slowing the entire process down. This can be seen both visually in the status window as alternating between a progress bar and the

//////////////////////////////

bar that you see while it is preparing something to move. The overall transfer times also indicate about 1/2 the transfer rate of sample data moved including from other backup software run on the same network.

I have dropped the firewalls and killed the firewall service. I have added the machines and users to each other at full permissions. This is a dedicated fiber network and Windows 2012 servers with RAID6 arrays.

For reference it took me 12 hours to move a 1.17TB base using RR. About twice as long as similarly sized moves across the same network.

Parents
  • 0 over 7 years ago
    What you are describing is correct, and usually a common situation. Regardless of whether you are using VMware or HV, the data transfer rates into both hypervisors are not the types of speeds that you would expect to get through standard Windows traffic (also keep in mind writing directly into a VMware datastore from on outside "non-VMware" entity is not fast, that is something the entire industry has noted over the years). In fact this is why VMware has the transport methods of LAN-Free SAN and HotAdd to try and 'speed' things up if at all possible by reducing the amount of network hops, as this is something that overall has been noticed over time:

    support.quest.com/.../195634

    Having said that however, there are other things that affect your speed within RR that relate to the product specifically that you might not have to face when you do a standard network copy. Those are block size and dedupe. Unlike VMware which as a block size standard of 1 MB, or Windows that uses 64k, we use an 8k block size. While this helps with granularity, it will not help with performance when you are trying to copy out large amounts of data, it will in fact slow them down. I also mention dedupe as the solution is a compressed/deduped solution, so when you do a restore not only do you have to wait for files to un-compress, the core also has to re-hydrate the files as well from the dedupe cache.

    All of which comes down to yes, the restores will take, and are expected to take, a longer amount of time to restore than if you were to just copy the files via something like Windows. Though this isn't all that uncommon for DP solutions we may be unique in this situation as you hit all the factors that slow things down:

    1) writing into a Hypervisor
    2) dedupe
    3) compression
    4) block size

    I see your other posts regarding virtual standby, that is precisely why we recommend that customers have it created ahead of time, as restores take time, usually longer than you'd like them to when you're in dire need of them.
Reply
  • 0 over 7 years ago
    What you are describing is correct, and usually a common situation. Regardless of whether you are using VMware or HV, the data transfer rates into both hypervisors are not the types of speeds that you would expect to get through standard Windows traffic (also keep in mind writing directly into a VMware datastore from on outside "non-VMware" entity is not fast, that is something the entire industry has noted over the years). In fact this is why VMware has the transport methods of LAN-Free SAN and HotAdd to try and 'speed' things up if at all possible by reducing the amount of network hops, as this is something that overall has been noticed over time:

    support.quest.com/.../195634

    Having said that however, there are other things that affect your speed within RR that relate to the product specifically that you might not have to face when you do a standard network copy. Those are block size and dedupe. Unlike VMware which as a block size standard of 1 MB, or Windows that uses 64k, we use an 8k block size. While this helps with granularity, it will not help with performance when you are trying to copy out large amounts of data, it will in fact slow them down. I also mention dedupe as the solution is a compressed/deduped solution, so when you do a restore not only do you have to wait for files to un-compress, the core also has to re-hydrate the files as well from the dedupe cache.

    All of which comes down to yes, the restores will take, and are expected to take, a longer amount of time to restore than if you were to just copy the files via something like Windows. Though this isn't all that uncommon for DP solutions we may be unique in this situation as you hit all the factors that slow things down:

    1) writing into a Hypervisor
    2) dedupe
    3) compression
    4) block size

    I see your other posts regarding virtual standby, that is precisely why we recommend that customers have it created ahead of time, as restores take time, usually longer than you'd like them to when you're in dire need of them.
Children
No Data