WAN Acceleration bug with Linux VMs?

[dmitri-va]

I've been testing Veeam Backup & Replication (I pronounce it VeeamB by the way ) and noticed that when I deployed WAN Acceleration, it worked nicely overall but with the exception that it does not do anything to the RHEL 6.6 disks formatted with ext4 over LVM (the first disk with ext4 without LVM on the same VMs is accelerated fine).

https://onedrive.live.com/redir?resid=B ... hoto%2cjpg

[foggy]

Dmitri, is the second disk just a common data disk? Global cache contains data that is more likely to be deduped - OS system disks blocks, blocks with common applications data (Exchange, for example). As you can see, deduplication worked for that disk too, even without it being placed in cache (only 4,5 GB transferred from 20,4 GB).

[dmitri-va]

this one in particular is an IBM MQ server, so yes it can be considered as common data disk. The other VMs in the screenshot were of different roles but all with the second disk being lvm/ext4. I was thinking that after the backup copy job against same VMs run multiple times, at some point it would cache something from those disk, even if a small percent. However, consistently showing 0% cached for those disks lead me to believe it may just not be working with lvm/ext4 disks at all...

[foggy]

WAN accelerator does not care about disk partition actually, so this is not the case.

[PTide]

Hi Dmitri,

What kind of data does your 100Gb-LVM-Ext4 contain? Is it database, website, fileserver or something else?

Thank you.

[dmitri-va]

With the exception of the one running IBM DB2 database, all the other 4-5 linux VMs I've tested with, running IBM Websphere application server, IBM MQ server, and other applications. Overall, all of them have some static application/configuration data that should have been cached.
I wonder if someone at Veeam could stage it in a lab to confirm my findings?

[PTide]

Dmitri,

In case nothing's been found in global cache WAN-accelerator queries the storage in attempt to find datablocks to deduplicate. That is exactly what has happened in your case - the second drive had not been cached due to its not-OS nature , so the system found duplicate data on your target storage. That's why only 4,5 gigs have been transferred though been never shown in job stats.

However, if you want to have it in your cache, I've come up with a solution which I think can do the trick:

Instead of using two .vmdks you can use a single one and split it into two physical volumes ("OS" and "software") from inside of your OS. In that case the whole VMDK will be considered as an OS drive, therefore everything will be cached including non-OS stuff.

Keeping OS and software drives separate could be important if it was a physical machine (the possibility of drive failure) and/or Windows OS (takes a lot of space --> longer restoration). Since you use virtualized Linux you can easily afford keeping everything in a single VMDK.


Hope this helps.

Please correct me if I'm wrong.


Thank you!

[dmitri-va]

that's a good suggestion and also helped me realize that WAN Acceleration only works with OS disks, which I missed before. What are the reasons to only cache OS disks, and not all vmdks?

[Vitaliy S.]

The reason is simple, in the system disk there is a lot more chance to find similar blocks across all VMs. This should also help in keeping cache size reasonably small and make it more manageable.

[Gostev]

While it's still possible to enable caching for non-OS disks via a registry edit - aside of corner cases, the benefit just does not worth all the extra processing overhead introduced. In fact, in some cases this may even reduce data reduction ratio, because of cache being stuffed with data that is much less likely to dedupe comparing to the OS disks data.

[dmitri-va]

thanks for the clarification.
it turns out our current practice on the linux side of the house is to build RHEL VMs with two disks, first has boot and swap partitions, and second holds OS and applications. Reason being they can add up to three more partitions to the second disk in case there is a request for more disk space later on. As you can see, disk1s in this case is really the 'os' disk.
So maybe a mentioned registry edit will work for our case?

[Gostev]

Yep, most people do create their VMs this way anyway, so you are definitely not unique here. You will only get the benefit if all the application data in the second disk is completely identical between multiple VMs (such as mirrored databases etc.)

[dmitri-va]

well, all OS files are there on the second disk, as well as application files that are identical between multiple servers of the same role, so I believe we could benefit from enabling WAN acceleration for these disks.

The mentioned registry edit - is this supported? If so, where could I find the details on this?

The other question: is WAN acceleration looking for identical blocks across the VMs in a given backup-copy job, or across all the VMs from all backup-copy jobs utilizing same WAN acceleration instances?

[Gostev]

Oh, I missed that part about OS being on the second disk in your post, sorry about that.

I will send you the registry value directly to try, just need to find it.

Cache is global for all jobs.

[dmitri-va]

appreciate it