WAN acc. ext. disk for cache?

[janezk]

Hi,

I have a phisical server for WAN accelerrator ( and proxy role at the same time) It turned out, that I have a HDD too small for the requirements for WAN acceleration global cache or. more exactly for Digests...
Since I can't buy a new HDD right now (I don't want to discuss this) , I've been looking at alternative options:

I would present a LUN on EMC VNX ( that is attached directly via FC) and map a VeeamWAN folder (or. some subfolders if possible) to it. Would this work? What about speed?

Sub question:
Can I have a GlobalCache on different drive than Digests?
Let me explain: If a add a second disk ( either phisical or LUN ) I would still like to keep the GlobalCache on the existing drive to use the available space (would increase from 100Gb's to 300GB's) - as I can set a size of a global cache. And use the new drive only for Digests.

BR

Janez

[PTide]

Hi,

Yes, you can have global cache anywhere until the place where you have it is accessible on a block level (shared folders won't work). Regarding speed - since v8 wan accelerator algorithms have improved so they do not require fast drives.

Thanks

[janezk]

Great, thanks for a super very lightning speedy answer ( me like it very much...)

What about different locations for global cache and Digests? In WAN acc. settings you can only choose the path for main folder VeeamWAN!
Is there a registry key or something?

BR

Janez

[PTide]

What about different locations for global cache and Digests?

Sorry, I misunderstood your question at the first time a read it. Digest are kept on the source acceerator, and cache is kept on the target accelerator, so cache and digests are always kept separately:

On each WAN accelerator Veeam Backup & Replication creates the VeeamWAN folder containing the following data:

The VeeamWAN folder on the source WAN accelerator stores files with digests required for global deduplication. For more information, see How WAN Acceleration Works.
The VeeamWAN folder on the target WAN accelerator stores global cache data.

[janezk]

Hi,

Sorry, maybe I didn't gave enough data before, but I wrote, what I thought was essential. In fact I have multiple WAN accelerators on both sites, but that doesn't make a difference...

... Digest are kept on the source acceerator, and cache is kept on the target accelerator, so cache and digests are always kept separately:

Correct me if I'm wrong, on this: Not always... This is true only if a WAN acc has a single role... If it is at the same time used as a source and a target, both folders GlobalCache and Digests are used.

So I'm aware of that configuration notes you referenced, but I have a case that I use the same WAN accelerator as a source and as a target, because I move BC jobs and replicas in both directions.
This is the reason why I want to "split" folders into different locations in context of what I have written before.

So the question remains still unanswered...

BR

Janez

[PTide]

Unfortunatley there is no way to "split" locations for cache and digests.

[janezk]

Hi,

that's a pitty... When I "studied" the topic I found a lot of questions and topics regarding WAN acc. cache limit problems. A lot cases when people size their HDD by mistakenly taking in account their cache size limit, thinking that the limit applies to all cache (including the digests... ) And then they ran out of space...
or simply as in my case a drastic growth of data in backups and BC jobs, that can't be really predicted (unless you are a fortune teller... )

I think if there would be a simple possibility to point the cache and digests to different locations this would be a nice and very useful feature, that would help to use the available resources in most economic way.
Now I will have to have a 350GB's of available disk space unused just sitting there waisted... as worse x4 times as I have 4 WAN acc. servers in that same configuration... And on the other hand provide on a new disk additional space for cache... ( at least 100Gb/server )=400Gb... ( I'd better not tell this to my boss... )

The only think that I can do is to suggest that this is added as a FEATURE REQUEST...

BR

Janez

[PTide]

Got your request, thanks! I think that you might be intersted in this workaround.

Thanks

[janezk]

Hi,

thanks for the reference. I think this should do well in my case.

btw. i don't know how I missed this topic, while extensively searching trough forum... oh, maybe because the forum is too good ( and thus quite big...)
Thanks, very much appreciated the quick feedback, that we are getting here... Keep up the good practice.

BR

Janez