Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Using SAN replication for DR on a SQL server


Using SAN replication for DR on a SQL server

Author
Message
george sibbald
george sibbald
SSCertifiable
SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)

Group: General Forum Members
Points: 6334 Visits: 13687
In order to achieve quick failover (and failback) in the event of the loss of a data centre we are considering using SAN based replication (SRDF in this case). This is on physical SQL servers not virtual.

The OS and therefore some parts of SQL is installed on the local C drive, whilst the rest of the SQL installation is on SAN drives. SRDF only replicates the SAN drives so how do we keep the C drive in synch across the two servers.?

where I see this being a problem is when SQL upgrades are applied as this will make changes to the SAN drives and the C drives and so not all changes made will be replicated. This even applies to minor changes like how many error logs are kept, or default database directories, as these values are reflected in the registry.

Does anyone else out there do DR in this way and what procedures do you use to handle this situation?

thanks in advance

george

---------------------------------------------------------------------
george sibbald
george sibbald
SSCertifiable
SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)

Group: General Forum Members
Points: 6334 Visits: 13687
the disaster recovery forum is obviously hardly visited, so I am bumping this thread..................

any takers?

---------------------------------------------------------------------
alen teplitsky
alen teplitsky
SSCommitted
SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)

Group: General Forum Members
Points: 1595 Visits: 4621
we've been doing it on a cluster for years, one of EMC's first customers to do this. works great, downside is it's only on disk level.

if you're doing physical nodes and not clustered, why not just do the db files? just set up a recovery server at your DR site, recreate all logins and just attach the db's as a test every so often
Michael Valentine Jones
Michael Valentine Jones
Hall of Fame
Hall of Fame (3.3K reputation)Hall of Fame (3.3K reputation)Hall of Fame (3.3K reputation)Hall of Fame (3.3K reputation)Hall of Fame (3.3K reputation)Hall of Fame (3.3K reputation)Hall of Fame (3.3K reputation)Hall of Fame (3.3K reputation)

Group: General Forum Members
Points: 3258 Visits: 11771
Have you considered boot from SAN? Windows 200 and 2003 support it, so it is really just a matter of finding a SAN vendor that supports it at the hardware level.

Boot from SAN in Windows Server 2003 and Windows 2000 Server
http://www.microsoft.com/windowsserversystem/wss2003/techinfo/plandeploy/bootfromsaninwindows.mspx
george sibbald
george sibbald
SSCertifiable
SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)

Group: General Forum Members
Points: 6334 Visits: 13687
thanks for replying guys!

Mr(?) Noob, your way certainly gets round the upgrade problem.

Trouble is I am greedy and was really hoping to leverage SRDF to keep the failover in synch for me by replicating system databases as well. Because there are not just logins, but DTS\SSIS, agent jobs, linked servers as well. If they could just be kept in synch and just be there when we failover that would be so good and justify SRDF as more than a faster way to failover and back. Quite keen that the failover server ends up with the same name as the primary as well.

Michael, I like the boot from SAN idea, do you do that?. Our intel guys don't seem keen, saying there are performance problems. Seems to me it would give the slickest failover though.

I will be setting up a proof of concept and try all options I can think of, see how they compare.

Other option appears to be replicate system databases but not C, and split the disks being replicated when we do upgrades then re-establish SRDF.

---------------------------------------------------------------------
Stamey
Stamey
SSC Veteran
SSC Veteran (239 reputation)SSC Veteran (239 reputation)SSC Veteran (239 reputation)SSC Veteran (239 reputation)SSC Veteran (239 reputation)SSC Veteran (239 reputation)SSC Veteran (239 reputation)SSC Veteran (239 reputation)

Group: General Forum Members
Points: 239 Visits: 999
Here are a couple of possibilities.
1. Set up DB mirroring from primary to DR server. If there is a primary server failure, make the DR server the principal and rename it. This should only take a few minutes. As far as I can tell, SQL 2005 does not store the server name inside and will allow renaming of the server OS.
2. Make the server itself a VM, even if it is the only guest OS on that box, and stored the VM virtual disk files on the SAN, replicating them the same way as the SAN volumes the VM server uses for the data. What I am saying here is that the VM virtual disk is only for the C: drive. The SQL DB and transaction files will exist on their own SAN volumes, as you see fit.
This method should allow the VM to use the underlying host server resources as if their were no host in the middle, if the VM software will perform. I understand they have worked out the performance issues they had with SQL Server a few years ago.

Chris

Learning something new on every visit to SSC. Hoping to pass it on to someone else.
george sibbald
george sibbald
SSCertifiable
SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)

Group: General Forum Members
Points: 6334 Visits: 13687
This is just like buses, nothing for a month, then 3 at once:-)

Stamey (3/25/2009)
Here are a couple of possibilities.
1. Set up DB mirroring from primary to DR server. If there is a primary server failure, make the DR server the principal and rename it. This should only take a few minutes. As far as I can tell, SQL 2005 does not store the server name inside and will allow renaming of the server OS.


Got to be SRDF I am afraid, for quick failover AND failback. No time for reinitialising from full database backup\restores

2. Make the server itself a VM, even if it is the only guest OS on that box, and stored the VM virtual disk files on the SAN, replicating them the same way as the SAN volumes the VM server uses for the data. What I am saying here is that the VM virtual disk is only for the C: drive. The SQL DB and transaction files will exist on their own SAN volumes, as you see fit.
This method should allow the VM to use the underlying host server resources as if their were no host in the middle, if the VM software will perform. I understand they have worked out the performance issues they had with SQL Server a few years ago.

Chris


We have some SQL on vmware, and SRDF in place for these, they are fine. Most of our apps don't perform on vmware though and this requirement is to get SRDF up and running on the physical boxes, some of which support multiple applications.

---------------------------------------------------------------------
alen teplitsky
alen teplitsky
SSCommitted
SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)

Group: General Forum Members
Points: 1595 Visits: 4621
george sibbald (3/25/2009)
thanks for replying guys!

Mr(?) Noob, your way certainly gets round the upgrade problem.

Trouble is I am greedy and was really hoping to leverage SRDF to keep the failover in synch for me by replicating system databases as well. Because there are not just logins, but DTS\SSIS, agent jobs, linked servers as well. If they could just be kept in synch and just be there when we failover that would be so good and justify SRDF as more than a faster way to failover and back. Quite keen that the failover server ends up with the same name as the primary as well.

Michael, I like the boot from SAN idea, do you do that?. Our intel guys don't seem keen, saying there are performance problems. Seems to me it would give the slickest failover though.

I will be setting up a proof of concept and try all options I can think of, see how they compare.

Other option appears to be replicate system databases but not C, and split the disks being replicated when we do upgrades then re-establish SRDF.



you can do it. somewhere in BOL i think there are instructions to move system databases to another drive. for the domain name the failover server is different unless you drop the old one and rename the DR server.

if you can wait 6-12 months Intel is about to ship it's new CPU's in a week or so and the hardware will be so powerful you can run SQL in VMWare and just ship the virtual machine file to your DR site.

next week Intel releases their new Nehalem CPU's that Apple and Cisco already announced a few weeks ago. this one is a dead end since they skipping this current generation and will release a new generation in less than 12 months unlike 2-3 year time as before. I think next week's release is 45nm and they are going to 32nm later this year. from what i read a 2U server with this CPU should support up to 192GB of RAM. and these machines will come with PCI Express v2 which is twice as fast as the current I/O system


we used to run log shipping here years ago before srdf and before i became a dba. from what i heard there were always problems and they had to always reinitialize it with a new full backup/restore. mirroring is almost the same thing and subject to the same problems
Michael Valentine Jones
Michael Valentine Jones
Hall of Fame
Hall of Fame (3.3K reputation)Hall of Fame (3.3K reputation)Hall of Fame (3.3K reputation)Hall of Fame (3.3K reputation)Hall of Fame (3.3K reputation)Hall of Fame (3.3K reputation)Hall of Fame (3.3K reputation)Hall of Fame (3.3K reputation)

Group: General Forum Members
Points: 3258 Visits: 11771
george sibbald (3/25/2009)


...Michael, I like the boot from SAN idea, do you do that?. Our intel guys don't seem keen, saying there are performance problems. Seems to me it would give the slickest failover though...



Never used it myself.

I would ask whoever said there are performance problems for more info about why they are saying that. Did they actually try it themselves? Or did they just hear it somewhere, and are repeating an old wives tale based on some problems with early versions, etc.? Also, even if they did try it themselves, did they really know what they were doing?

Doesn't hurt to be a little skeptical. Of course, that also includes the promises made by SAN vendors with visions of of multimillion dollar sales.
Steve Jones
Steve Jones
SSC-Dedicated
SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)

Group: Administrators
Points: 36172 Visits: 18751
We've had plenty of servers booting off SANs since 2001 with no issues. It gets a little harder to configure for some hardware to get the boot, but it should be no performance issue.

What is on the C drive you're worried about? Should be a base instance, which should be minimal to recover for you.

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search