george sibbald (5/3/2009)
cmille19 (7/20/2007)
That's correct at the DR site there is an identical server where all volumes are replicated at the disk level from one SAN to another SAN over two OC3 pipes using SRDF/A. The DR server does not have the disks mounted, they are unmounted and a series EMC commands are run to mount the volumes. The DR SQL Server is configured as follows:
One time setup -- Use a temporary volume to install SQL Server service using same instance name and path as primary site. Set SQL Server service to manual at DR site, remove temporary volume, setup SRDF/A to replicate all volumes except the OS this includes the system databases (master...). The repliated volumes remain unmounted. In event of disaster or during several annual tests run EMC scripts to mount the volumes, start SQL Server service and swing DNS entry. When SQL Server comes online its a mirror image of primary site SQL Server. The actual time it takes to mount the volumes is almost instaneous. The disk replication is within one minute of the primary site and setup to be consistent across a set of disks. The particular setup we are running is nothing speical in that you can have EMC design a identical solution. Here's one more cool thing about using SAN based replication. Since its a SAN based solution we use the same technique for all of servers including Unix, Windows, web, app and of course SQL Server. On the Web and App servers we maintain dark servers and replicate teh boot partition i.e. the C drive. Because of MS cluster setup at the primary site and the lame setup of storing IP Addresses as part of the cluster configuration we cannot replicate the boot partitions of the SQL Servers. Although we have replicated boot partitions for non-clustered SQL Servers in the past, however as I now longer have non-clustered SQL Servers.
cmille19, hope you see this! I will be setting up SRDF for our DR to replace log shipping, (non-clustered servers) and am looking for the best design to achieve fastest failover and failback. So your set up above sounds good to me as I wish if possible to replicate the system databases as well.
A few questions, if you installed on SQL DR as the same instance name the server name must have been the same, so how do you get round having two servers of the same name active? Is the DR server renamed after initial install and again at failover time?
How do you apply patches to SQL on the DR server, by replicating the C drive as well or splitting SRDF whilst you do it? Are you booting from SAN?
cheers
george
I SRDF/A the system databases also. That way I don't have to attach databases just mount the EMC LUNs and start the SQL Server. To SAN replicate the system databases you'll need to install the DR SQL installation with the same path as the primary server.
As far as server name. The server name is different on the DR server. I use strictly named instances for example Z002\SQL1, so just the instance name is the same. To avoid changing connection string the developers are instructed to use fully qualified DNS names for example Z002.acme.com. If the server is named instance the connection string would be the hostname followed by comma and the port number: Z002.acme.com,2507. In a DR scenario the DNS servers are sent a updated hostname to IP list which points to the DR IP with the original primary site DNS name.
Before adoption clustering as an HA solution for my primary site, I replicated the boot partition. All of our Web and App servers use boot partition replication. Although I no longer replicate boot partition on SQL Servers, I'm still using boot from SAN.
For patching, I'll have a second set of LUNs mounted on the DR server. These LUNs are used for QA environment. The system databases are the path as the DR and primary servers. A secondary benefit to this setup is that patches can be applied to both OS and SQL to keep in sync with primary server. In a DR scenario the QA LUNs are unmounted and the DR LUNs mounted.