ESX iSCSI and Replication.

[To-M]

I do know many are using the Scheduled task with the Start and Stop time values for this but you will need a dedicated VPN (port 1723, GRE..) connection (need ports open 11000-14000as well) over a WAN. You can add many of the scheduled tasks as you need.

Function: Create schedule for volume replication task

Here you can create a schedule for the selected volume replication task.

Comment
You can enter a comment for the replication schedule.
Time select
You can start the volume replication immediately by selecting Now from the Time select drop-down list or schedule it for later.
Interval
Select the interval at which the replication will be executed.

Location
CONFIGURATION -> volume manager -> vol. replication -> Function: Create schedule for volume replication task.

[beng]

G'day Andy,
This is our desired scenario too.
ESX VMFS formatted iSCSI targets being constantly replicated (async is fine) to a DRP DSS (in this case on the GB LAN).
So I think it will be possible, but at this stage the great unknown for us is will it work in a production environment.
The last thing we want is for it to seem to work, but when we revert to the DRP DSS we find corrupted data

[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.