Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

What is the compression ratio or algorithm used in VVR replication

Created: 11 Dec 2013 • Updated: 18 Dec 2013 | 5 comments
Zahid.Haseeb's picture
This issue has been solved. See solution.

Environment

SFHA/DR = 6.0.2

OS = Win2008R2

Operating Systems:

Comments 5 CommentsJump to latest comment

Gaurav Sangamnerkar's picture

Hi Zahid,

Compression ratio is as such not defined as what exact ratio is being used. I am assuming it would be hard coded.

From Admin guide

Compression feature enables VVR to send data in a compressed form from a
PrimarytoaSecondaryhost.ItreducesnetworkbandwidthconsumptionbyVVR.
This feature is particularly useful in scenarios where there is low availability of
bandwidth or where the bandwidth is shared among several applications.
Purchasing an external compression software or hardware for data transfer can
prove costly. Hence, compression feature in VVR is a cost-effective alternative in such scenarios.
 
Compression option can be enabled on a per RLINK basis either through the CLI
or GUI. If both sides have compression enabled, the Primary site generates the
compresseddataduringsendingofanyupdates.Atanytime,theusercandisable
or enable the compression feature without stopping replication.
GeneralfunctionalityconstraintsforVVRcompressionareasshown.Datashould
not be send in compressed form in the following cases:
If either the Primary or Secondary RLINK does not have compression enabled
If the compressed data size is greater than the uncompressed data size
If the memory for keeping the compressed data could not be allocated on the
Primary side
 
 
G

 

PS: If you are happy with the answer provided, please mark the post as solution. You can do so by clicking link "Mark as Solution" below the answer provided.
 

Zahid.Haseeb's picture

Thanks Gaurav for your words.

If the memory for keeping the compressed data could not be allocated on the
Primary side

I never see the memory allocation when configuring the replication (via VEA) between primary and DR site.

=============

So, when the compress replication data reaches at DR site it first uncompress replication data and then it writes to DR site volume. Correct ?

Any comment will be appreciated. Mark as Solution if your query is resolved
__________________
Thanks in Advance
Zahid Haseeb

zahidhaseeb.wordpress.com

Gaurav Sangamnerkar's picture

Yes, that is correct, data is compressed only to save the bandwidth, it will be uncompressed again before getting written to the volumes on DR site.

About, memory, I don't believe you would be able to see any specific memory allocation happening for compression, rather the memory used by VVR itself will be shared.

 

G

PS: If you are happy with the answer provided, please mark the post as solution. You can do so by clicking link "Mark as Solution" below the answer provided.
 

mikebounds's picture

See extract from VVR admin guide:

VVR uses the zlib library for performing compression and decompression. For
more information on the zlib compression library, see http://www.zlib.net

zlib uses the "Deflate" algorithm see http://www.zlib.net/feldspar.html  for more information.

Memory is allocated from the VVR NMCOM memory pool 

Mike

UK Symantec Consultant in VCS, GCO, SF, VVR, VxAT on Solaris, AIX, HP-ux, Linux & Windows

If this post has answered your question then please click on "Mark as solution" link below

SOLUTION
Wally_Heim's picture

Hi Zahid,

The VVR compression ratio is dependent on the data being compressed.  VVR uses the NMCom memory pool on the primary to compress the packet being sent.  It then compares the compressed packet in NMCom memory to uncompressed packet in the RDBack pool memory and sends the one that is smaller or the one in the RDBack pool if they are the same size.

You can use the "rlink -e -i 5 stats <rlink_name>" command on the primary to details on compression that is being done live on the server.

"vxtune" command output also shows some of the tunables that can be done with compression. 

I have adjusted the number of threads with a few customers but not many.  The more threads that you allocate to compression the more load it puts on the servers.  It does not change compression ratios.

If you adjust any tunables alway check your vxmemstat output to see how your memory is doing.  If you are hitting max memory then you should think about increasing memory to NMCom or RDBack pool as needed on the primary and secondary.

Thank you,

Wally

 

SOLUTION