Migration complete –

We did it.   Migrated the hosts/data.   Production is now running in Kansas, DR in Georgia, and the old datacenters in NY/NJ are one step closer to being shut down.

Interesting couple of things I learned today.

SRDF/A is a great technology for replicating over long distances while maintaining what they call a “dependent-write-consistent” state.  It means that even though the replication is being taken care of asynchronously, with minimal performance impact to the host, that in the event of a failure you’re going to lose a minimal amount of data.  (In our case, when it was running the R2 disks were about 45-60 seconds behind the R1.)

We also performed a “failure” (disconnected both Gig-E ports to simulate the Kansas site dropping out) and brought the DR hardware up as primary, then reconnecting, unmounting, and restarting the SRDF/A session.

The only downside I’ve found with SRDF/A is that it’s a royal pain to stop and restart the replication.  In cases like this one, where once a week they take the R2’s offline to run a 20-hour backup off them, they are putting themselves at unneeded risk.  It’s a situation where TimeFinder/SNAP would be a great benefit.  You snap the R2’s at midnight and back them up, thereby leaving your R2’s in sync with your R1’s for the duration.  You can also then mount the SNAP volumes to a separate media server thereby avoiding having to re-configure the DR server as a temporary media server.

It’s just a thought.

It’s always a great feeling when you hit the deadline dead-on, especially when you’re dealing with a situation where the requirements keptchanging throughout the project, even to the point of having to add new devices at the last minute.

Oh well, on to the next.  At least the next is going to keep me closer to home.   Small-scale data migration from DMX2 to DMX2 within the same room, this should be a cake-walk. 🙂


Skip to comment form

    • on November 26, 2007 at 10:33 am
    • Reply

    For ~3years now I’ve been asking for snaps off the R2. Everytime they say, we do allow it you can take a snap of a R2, I then respond with a did you miss the async part or has something changed? They then look at the ground and say… oh ASYNC SRDF, no not *yet* but soon, and look we do sync snaps today. I think their definition of the word “soon” and mine are vastly different. The only thing they tell me why it’s not supported is due to “performance” concerns, not a technical limitation (like # of mirror positions with BCV’s), which makes me ask what is the performance concern and all they can do is stammer and say corporate says no snaps off R2, but maybe soon.

  1. I believe that if you PEND-DROP the SRDF/A session long enough to split the BCV’s/SNAP’s, ir can be accomplished.

    This is akin to bringing an Adaptive-Copy/Disk session into Sync mode long enough to split the BCV’s.

    Using conventional SRDF that would be the standard practice and unless your latency is horrible, users won’t notice more than a slight slow-down during the synchronization.

    SRDF/A users wouldn’t even notice that. Because the PEND-DROP waits for the current deltaset to be applied and then drops the session, the R2 side would then be “write consistent” and would support the TimeFinder operation.

    I’m trying to find the whitepaper I read that supports this, but I’m having powerlink issues today.

    • on November 26, 2007 at 4:22 pm
    • Reply

    “this should be a cake-walk. 🙂 ”

    I trust it was Murphy laughing at the end of that sentence.

  2. My ego talking. 😉

Leave a Reply

Your email address will not be published.