Video Screencast Help

storage foundation 6.1 new feature??

Created: 06 Jan 2014 | 4 comments

VVR I / O throughput improvements using batched writes
Do you know about the features of the above ?

Operating Systems:

Comments 4 CommentsJump to latest comment

Gaurav Sangamnerkar's picture

Hello,

From 6.1 release notes for SF

VVR I/O throughput improvements using batched writes

Batched writing of multiple application writes to the SRL increases application I/O
throughput and lowers VVR CPU utilization. This is achieved by allocating a log
location for a set of application writes, and then batching the writes together to form
a single write to the SRL, and therefore replacing the multiple writes to the SRL at
the primary RVG.

Additional enhancement

VVR replication performance improvements using bulk transfer

To effectively use network bandwidth for replication, data is replicated to a disaster
recovery (DR) site in bulk at 256 KB. This bulk data transfer reduces Volume
Replicator (VVR) CPU overhead and increases the overall replication throughput.
With compression enabled, bulk data transfer improves the compression ratio and
reduces the primary side CPU usage. Bulk data transfer is not supported with bunker
replication, and in cross-platform replication

Link to document

https://sort.symantec.com/documents/doc_details/sf...

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.
 

smileagain's picture

VVR I/O throughput improvements using batched writes

Batched writing of multiple application writes to the SRL increases application I/O
throughput and lowers VVR CPU utilization. This is achieved by allocating a log
location for a set of application writes, and then batching the writes together to form
a single write to the SRL, and therefore replacing the multiple writes to the SRL at
the primary RVG.

I do not understand the contents .
How to use this?

Gaurav Sangamnerkar's picture

Hi,

This looks to be an performance enhancement in the way writes use to happen to SRL log. What I understand from above is writes will be grouped before writing to SRL log which reduces the number of writes & hence increasing the throughput.

This should be now default behaviour of VVR in 6.1 & you won't need to do anything specific.

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

I agree, there is not much information on how these new VVR features work - below is my understanding with some queries - perhaps someone from Symantec can clarify:

Batched writes

Regarding "This is achieved by allocating a log location" - I don't see any requirements to set up any storage so I assume that unlike Storage Replicator Log (SRL), this is not a log on disk, so I assume this is a log in memory, but I also don't see any extra memory parameters, so does this use an existing memory pool and if so which one and much space does it use.

Regarding "batching the writes together to form a single write to the SRL" - how does this work.  In 6.0 and earlier my understanding is that a write is acknowledged to the application when:

Async mode: Write is completed to SRL (writes dont have to be completed for data volumes at primary)
Sync Mode: Write is written to SRL and network ack from secondary (writes dont have to be completed for data volumes at primary or secondary)

So if this is correct, if writes are batched together, wouldn't this delay ack to application in both sync and async - so please clarify how this works and whether it applies to both sync and async. 

I assume the idea of batching writes is that is quicker to write one 32k block than say 4 8k blocks, so if this is the case, how much are the writes batched - is there a figure like in bulk transfer of 256k

Can this feature be turned off?

Bulk transfer

The admin guide explains this is for async only and so it sounds like that instead of sending writes as they come through, that they are batched together until they total 256KB, but if this is the case, what happens if there isn't 256KB, is there a fixed or tunable timeout for how long VVR waits for 256KB?
My understanding is that by combining writes in bulk, that it is quicker and less CPU intensive to send one 256k write as oppose to say 32 8k writes and also that you get better compression ratios compressing 256k, rather than 8k.
Also although this feature is enabled automatically if secondary logging is enabled and bunker replication, or cross-platform replication are not being used, can you turn this feature off if you want to?
 

Secondary logging

This feature was actually introduced in 6.0 for async mode, but as with above 2 features, can this be turned off.
My understanding is that this does not effect the time for the secondary network ack, but improves the time for the secondary data ack because the data ack happens after data is written to secondary SRL so VVR does not have to split the writes up into the volumes they need to be written to and write in order (which happens after data ack with Secondary logging), but I don't understand how this improves Replication performance.  I can only see this helps, if you have an issue where the secondary uses a slower array than the primary, so can't keep up, as withOUT seconday logging, this would mean the rlink is detached if the memory pool gets full at the primary due to unacknowledged secondary data writes, but this issue should be fixed, because if you circumvent it, then the secondary could end up with a big back log of writes in the SRL that are not written to data volumes.
 
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