ESX iSCSI and Replication.

[To-M]

Just make sure to take the defaults when setting up the LUN from the Targets and do not select the Write-back cache option for obvious reasons.

[beng]

G'day Todd,
I just re-read this reply and this is really going to sound stupid, but what are the "obvious" reasons?

I have (perhaps mistakenly) assumed that using the Writeback Cache was ok so long as I had the server under UPS protection and ran a redundant PSU.
Are there other dangers to using the WB option? and is this specific to replication or in general? (ie should I also have it off on the "Master"?)

With replication, does the ECC process only check to ensure it is written to the "slave". Not specifically written to the slave storage?

Since, (in my testing) WB cache made a big difference in smaller transfers we have left it on.
So should we now turn it off during replication, and then as part of the DR procedure turn it on before we make the server live?

Rgds Ben

[To-M]

The reasons are that we are not able to replicate the cache and not all applications will notice this small amount of data missing. We suggest not using the WB for this reason.
We will be updating notes on this topic in future release.

[budy]

Hi Todd,

this is hitting my as well. So there's a good chance that the data on the replicated volume will take damage, if wb is enabled on the source LV?

Thanks,
budy

[To-M]

Yes but not in all instances as some applications are aware of the data not being transferred and will resend what is missing but this will be a very small amount and in most cases to small. We will be looking into some feature to replicate the cache in the future. But this is a very $$$ feature even with our competitors it is extremly expensive.

[budy]

I see.

Just for completeness, does this then apply to normal, replicated iSCSI volumes as well, or is this ESX-specific.

E.g. if I have an iSCSI volume mounted on a CentOS box and thas volume has replication enabled, do I need to worry about this at all then?

Thanks,
budy

[To-M]

We did not test all scenarios only with the ESX environment when using the Auto Failover and enabling the Write Back option. When we disabled the Write Back option we did not see this issue. Though with this Write Back option disabled there is a small performance hit.