ESX iSCSI and Replication.

G'day,
Hopefully this is a simple question.
The iSCSI replication documents all seem to refer to iSCSI in Block I/O mode.
As ESX requires iSCSI in File I/O mode, does this mean that it is not possible to replicate an ESX VMFS store? (Asynchronous would be fine)
If this is not possible, you may wish to remove the VMware icon and/or state it in the docs... I couldn't find it there?

BTW, kudos on the documents, they are really good, but on pg 30, the arrow moves but the text is the same as pg 29....

Rgds Ben

Hi!

I tried replication and failover/failback on file I/O volumes:

--> both working fine...

Pril

G'day Pril,
Thanks for the reply.
Is this in a production scenario or just in your testing?
Also, just to confirm, was this with ESX 3.5 and it's software iSCSI initiator?

Rgds Ben

Hi!

It was just a testing szenario and I used virtualiron, but it was file I/O.

The client does not recognize, if replication is on or not...

Pril

Quote:

---

Originally Posted by Pril

Hi!

I tried replication and failover/failback on file I/O volumes:

--> both working fine...

Pril

---

I'd love to see some walkthrough documentation on how to set this up.

My ideal would be to have a regular (async) replication task duplicating a whole vmfs formatted iSCSI volume from my production site to my DR site (Open-E at both locations) but I've not mananged anything close.....

If anyone can say that its (a) Possible and (b) they are doing it sucessfully it would give me great hope !!!


Thanks,

Andy

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.

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

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.

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

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

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.

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

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.

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

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.