Disaster Recovery using SAN Replication
-
Does anyone have experience setting up a DR system using SAN replication and specifically using MirrorView/A for managing the asynchronous replication? We are planning to implement this in a few weeks, but so far, I have not had success getting our failover server to use the replicated database files. Any help/insight would be appreciated.
Gordon Pollokoff
"Wile E. is my reality, Bugs Bunny is my goal" - Chuck Jones
-
Hi,
What kind of error SQL reports, when you said that failover server fails to use the replicated database files? Does failover SQL see MV target disks?
So far, I have two MirrorView/A installations with SQL2000 cluster on primary side and one SQL2000 on secondary, and it's working well, if it's properly configured. Post little bit more info pls - are the san and mv set up corectly - fc connections, zoning, storage groups, cache, lun pool, source, target....?
rgds
-
We store all our critical data on HDS SANs, one in GB and one in US, and these use async replication and are fully integrated into our DR plan.
On our SQL Server machines, we have some drive letters reserved to hold active/passive databases, while others are reserved for active/active databases. The A/P databases get replicated via the SAN, while the A/A databases do not need replicating as the relevant applications keep both copies consistant.
For our A/P databases, we have the databases online at the active site, and offline at the passive site. The A/P disks mounted in Windows on the active site, and dismounted in Windows on the passive site. The databases SAN replication keeps the passive site data up-to-date.
At failover time (say from GB to US), we:
1) Stop all affected applications (This disconnects the users)
2) Put the A/P databases offline on the GB (Active) site
3) Dismount the A/P disks from the GB site
4) Stop SAN replication for the A/P disks
5) Switch the SAN PVOL to the passive site (This make it the new Active site)
6) Update DNS to set the Alias for the failover instance from GB to US
7) Mount the A/P disks on the US (old Passive) site
8) Wait about 15 seconds for Windows to build its file caches
9) Put the A/P databases online at the US site
10) Start the relevant applications (applications connect using the instance DNS Alias)
11) Perform sanity checks on the failed over applications
12) Allow users to log on to failed over applications
13) If all is well, start replication from US to GB
This process needs careful scripting if it is to run smoothly and meet predictable targets. We have a failover SLA of 30 minutes, and normally can complete a failover (from disconnecting users to allowing users back on) in about 20 minutes. We treat our GB and US sites as peers, but because most of our staff are in GB there is a preference to run from GB. However, we always run a few days each month from US.
We have multiple systems, and a major selling point for HDS at the time of purchase is it allows individual LUN pairs to be replicated individually. This means we often have our Test servers active in US and Prod in GB, all on the same SAN. I know HDS is a different vendor to your SAN, but almost all we do is vendor-independant.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
-
Perhaps I posted too soon ( or maybe my post removed the curse
). Our most recent test, completed this morning, worked successfully. I guess we finally got all the stars aligned properly.Thanks for your responses.
Gordon
Some days you are the windshield, some days you are the bug.
Gordon Pollokoff
"Wile E. is my reality, Bugs Bunny is my goal" - Chuck Jones
-
that is that matters
cheers
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply