Need DR Strategy Design Help

  • I need some assistance on a DR strategy. I am currently looking at setting up a DR where essentially the sky is the limit as far as hardware, network, etc.

    The requirements indicate that critical databases (all if possible) be available at the DR almost immediately with little to no data loss. Automatic failover is prefered

    I have virtually zero SAN knowledge. So this is my primary are of questions.

    I wanted to know if I can setup a DR solution as follows:

    * Setup SQL cluster and have it geographically spaced. So Node A is at primary location and Node B is at DR site.

    * There is a SAN at the primary and secondary locations. Can I have "SAN Replication" run to keep them in sync?

    * Can I have both Nodes point to the SAN at the primary location and if the SAN fails, they will switch to the DR site?

    Basically I am looking to figure out the best DR scenario I can create. I have a network with no bandwidth concerns between the primary and dr site and have the possibility of SAN replication (whatever that exactly gets me I am not sure). My thought is a geographical cluster of windows and sql if they can point to a "geographical san cluster" then all points could fail and switch over. Does anyone have articles, documents, etc to provide information on a DR strategy like this?

    In my scenario will that allow for machine, san, or both to fail and allow the other site to pick up and run? Should I use a different strategy?

  • DMC,

    As far as I am aware, and I have little knowledge of SANs, is that SAN replication is preformed by the filers, so the servers etc. are not aware the data is being replicated. A Windows Cluster requires a shared storage, so the DR SQL server would still be using the same data source as the primary SQL server (the primary SAN).

    You can buy 3rd party apps (like Double Take GeoCluster) to perform the replication for you so that each server has a local copy of the data (by local it could mean both to the respective SANs). We used to use GeoCluster, but had issues with it so removed it.

    The good thing about Clustering is that all DBs failover at the same time, as it is a virtual instance of SQL server.

    Have you considered Mirroring in ‘High Availability’ mode with a witness server (‘High Safety with automatic failover’ post SP1)? The thing to keep in mind is that if the witness server fails then there will be no automatic failover (but if you have ample budget maybe you could even cluster the witness server?). I’m not too sure if the failover in this case is piecemeal or all together from a DB perspective, something you would have to look into. With the new MDAC connectivity it will automatically direct the apps to connect to the mirror on failover (if your apps use MDAC).

    It maybe worth talking to your SAN provider to see what experience they have with this, I doubt that you’re the first person to want/need this kind of availability!

    Regards,

    Phil

  • Phillip,

    I think I will need to talk to the SAN provider and see what options they have as they are probably a great source. I was looking at other options then mirroring for two reasons.

    1. Reduce administrative overhead. Mirroring always seemed like a lot of overhead to maintain.

    2. I don't believe any of the applications we have running are mirror/failover aware. So automatic failover will not function.

  • have you looked at db mirroring (i'm assuming you're running sql05+)? we looked at clustering here but decided against it because there's still a single point of failure: the sql server instance itself. with db mirroring, if the instance goes down (for whatever reason), the mirrored server becomes the primary within seconds... it's using its own set of hardware, storage, network, etc. pretty much everything is redundant.

    just a thought...

  • DMC,

    If you using a "good" SAN then some form of SAN mirroring should be possible, but may not be possible when SQL Server is active. You're likely to run into a problem caused by the fact the SQL Server does not like to permit any other process to read, or write to, it's files. That means that the SAN mirroring will likely have a problem reading the source files and writing to the destination files, unless the replication tool has a way around the problem.

    SQL Server replication is probably a better approach than SAN mirroring.

    P.S. I've been told that "good" SAN mirroring tools should be able to accomplish this.



    Alvin Ramard
    Memphis PASS Chapter[/url]

    All my SSC forum answers come with a money back guarantee. If you didn't like the answer then I'll gladly refund what you paid for it.

    For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]

  • Alvin Ramard (8/6/2008)


    DMC,

    P.S. I've been told that "good" SAN mirroring tools should be able to accomplish this.

    We use a NetApp solution to mirror data from the primary to a DR site, as it is the SAN filers doing the mirroring, it appears that SQL is not aware of any of it happening 😉

    Regards,

    Phil

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply