Comprehensive data protection for all workloads
Post Reply
fmt1962
Influencer
Posts: 12
Liked: 3 times
Joined: Jul 31, 2012 9:04 am
Full Name: Daryl W
Contact:

WAN Accelerator - Concurrent jobs

Post by fmt1962 »

It appears that the WAN accelerator does not support concurrent jobs, if I create a second job, it reports it is waiting for resources to become available.

If I use direct mode or replication, I can run concurrent jobs....

Whilst the WAN Accelerator pushes far less traffic over the WAN, much of the time is source side processing and very little data moving over the WAN, using concurrent jobs on direct mode or replication with concurrent jobs, whilst pushing more data over the WAN, completes in a fraction of the time.... ie the backup window is HUGE with WAN accelerator as it is single threaded. This rather defeats much of the purpose.... increasing the backup window rather than reducing it.

As an example... I used to use 4 concurrent replica jobs, WAN was saturated for around 2 hours (after hours = OK), now with WAN accelerator, single job takes 16-18 hours! (with much less data - but running into work hours)

I hope there are plans to make the WAN accelerator multi threaded??? Please....
foggy
Veeam Software
Posts: 21069
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: WAN Accelerator - Concurrent jobs

Post by foggy »

Daryl, you're probably talking about the source WAN accelerator, which indeed can process a single task at a time only, putting all other tasks in the queue. You can utilize additional servers as WAN accelerators to be able to perform tasks concurrently (but keep in mind space requirements for the global cache), if your WAN link allows.

That said, keep in mind that the primary purpose of WAN accelerators is to minimize traffic, not the time required to transfer data. Job duration depends on the the available connection bandwidth and WAN accelerators performance. On a fast link WAN accelerated job can take significantly longer comparing to direct mode job. However the fact that WAN accelerated job transfers 10x and more less traffic allows it to complete much faster on a slow or busy link with little bandwidth available (when network is the real bottleneck).

Also, while I assume there could be reasons for limiting backup copy job activity by some time period, it is usually not that critical since this activity is performed outside the main backup window, without touching the production VMs at all.
Gostev
Chief Product Officer
Posts: 31459
Liked: 6648 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: WAN Accelerator - Concurrent jobs

Post by Gostev »

WAN accelerator cannot process data any faster than it does for you right now with a single thread, so making it multi-threaded will not help. To improve performance, you should speed up data processing on your WAN accelerators. The biggest speed increase can be achieved by using SSD for cache storage.
fmt1962
Influencer
Posts: 12
Liked: 3 times
Joined: Jul 31, 2012 9:04 am
Full Name: Daryl W
Contact:

Re: WAN Accelerator - Concurrent jobs

Post by fmt1962 »

Thanks for the reply foggy and Gostev.

As to reason for keeping the backup copy window out of production time, it is exactly due to the fact the WAN link is the bottleneck. Direct impact of backups on production VMs would be insignificant in comparison, obviously a backup copy job has no impact on production VM, however it does load up the WAN and unless throttled (which it is during business hours) has a huge impact on production as WAN bandwidth, which is our biggest issue. So yes there is a VERY significan reason to limit WAN usage to non business hours, contention for WAN bandwidth is much more of a concern than load on the server VMs.

Thanks for the suggestion to look into the performance of the cache using SSD option... Just checking are you talking about the target global cache or the source digest? I would not have expected the target cache to have high I/O, but I would expect the source digest would have high I/O.

Just a suggestion on the sizing of the global cache...... I do have multiple sources (from various WAN's we have multiple remote sites archiving data back to H.O.). At present the WAN accellerator sizing is set once only for the WAN accelerator target, per source accelerator..... the suggestion is, can this be considered for the size to be allocated discretely for each source in future release maybe????

The reason is, we have one remote site with over 3TB of source data, whilst one of the small sites only have 150Gb..... However the WAN accelerator allocates the same size cache for each!!!! So if I use 100Gb cache then the small site has a huge cache relative to the source whereas the large site has a tiny cache....

Can this maybe be suggested for consideration...... :)
Gostev
Chief Product Officer
Posts: 31459
Liked: 6648 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: WAN Accelerator - Concurrent jobs

Post by Gostev »

Most important is to have SSD on the target WAN accelerator's cache side. Basically, until you have SSD there, any other optimizations are meaningless, as target cache speed will be by far your biggest bottleneck.

I will check on WAN accelerator cache sizing. I believe it makes sense to pick the smallest cache size for each pair, instead of largest - unless it already works this way.
Post Reply

Who is online

Users browsing this forum: Google [Bot], ybarrap2003 and 310 guests