Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
The issue you noted, very much might be mitigated by QoS. Something like replication traffic can often work fine deprioritized relative to most other traffic, including "normal" default traffic. Additionally, using relative prioritizations, rather than some artificial shaping or policing, generally allows some bandwidth heavy traffic, such as replication, to fully leverage all your available bandwidth; again without being adverse to other traffic.
Regarding Etherchannel load balancing, source/destination hash combos normally do well, using source/destination IP, when supported, often the best option.
Of course, traffic between two hosts will have the same IP, so all traffic will flow across the same path. Some switches, also allow port (UDP/TCP) numbers to be included in the hash, but this often doesn't help when there's just one very busy flow. If the switches do support port hashing, you might work with your server folk to determine if huge replication transfers might be split into multiple flows.
