Visit Open-E website
Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: ESX iSCSI and Replication.

  1. #1
    Join Date
    Jan 2008
    Posts
    86

    Default 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

  2. #2

    Default

    Hi!

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

    --> both working fine...

    Pril

  3. #3
    Join Date
    Jan 2008
    Posts
    86

    Default

    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

  4. #4

    Default

    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

  5. #5
    Join Date
    Apr 2008
    Location
    LONDON
    Posts
    4

    Default

    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

  6. #6

    Default

    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.
    All the best,

    Todd Maxwell


    Follow the red "E"
    Facebook | Twitter | YouTube

  7. #7
    Join Date
    Jan 2008
    Posts
    86

    Default

    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

  8. #8

    Default

    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.
    All the best,

    Todd Maxwell


    Follow the red "E"
    Facebook | Twitter | YouTube

  9. #9
    Join Date
    Jan 2008
    Posts
    86

    Default

    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

  10. #10

    Default

    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.
    All the best,

    Todd Maxwell


    Follow the red "E"
    Facebook | Twitter | YouTube

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •