SAN Replication as DR strategy(SRDF)

Question

SAN Replication as DR strategy(SRDF)

sree-226516

SSCrazy

Points: 2590
More actions
June 12, 2007 at 12:21 pm

#119409

I am quite new to SRDF technology.Here we use SRDF(SAN replication as DR startegy).I just need to bring the database part(SRDF split and disk demount or mount is done by SA and other team).Could anybody please provide any documnetation or step by step guide to bring DR database online after SRDF split.Its a cluster enviroment.
Any help is appreciated.

Thanks,
SR

Thanks,
SR

Viewing 12 posts - 1 through 11 (of 11 total)

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

Rob-406527 SSC Eights! Points: 907 More actions · Answer 1

Hello, I know this is an older posting but wondered how the SRDF - SQL server combo worked for you. We are considering the same architecture for a DR solution.

Carl Federl One Orange Chip Points: 25384 More actions · Answer 2

"Could anybody please provide any documnetation or step by step guide to bring DR database online after SRDF split.Its a cluster enviroment."

I have done about 50 SQL Server DR tests using SAN Replication and assumming that everything is being replicated, bringing the DR database online is no different than for a non-DR clustered server, just bring the SQL Server resource group on-line. If there are any SAN resources that are needed but not being replication, then the start-up will fail.

Some cautions:

Make sure that all system databases (except tempdb) are also replicated.

SQL Server start-up parameters need to be manually syncronized between the live and DR servers such as any additional start-up trace flags.

In order to install SQL Server or apply Service Packs or patch, the DR server will need to have all resources in the SQL Server resource group available. If the DR server is not at an identical version to the live, then the start-up will fail.

SQL = Scarcely Qualifies as a Language

Rob-406527 SSC Eights! Points: 907 More actions · Answer 3

Thanks for the info Carl. A few questions for you when you have a second.

1. Is the SAN replication configured as an incremental snapshot or a complete copy?

2. Does the DB have to shutdown or "freeze" somehow before the replication runs?

I'm trying to figure if and how the DB makes it to the DR site in a consistent state if it wasn't shutdown or frozen somehow so a consistent copy can be taken.

Thanks in advance.

Carl Federl One Orange Chip Points: 25384 More actions · Answer 4

"Is the SAN replication configured as an incremental snapshot or a complete copy?"

Neither - SAN Replication is configured as synchronous meaning that all writes on the production SAN partition are replicated to the DR SAN without any delay.

"Does the DB have to shutdown or "freeze" somehow before the replication runs?"

No - not with synchronous replication.

SQL = Scarcely Qualifies as a Language

Vivien Xing SSChampion Points: 12297 More actions · Answer 5

DBA just needs to bring database online when your SA says go ahead. This means bring SQL services online from cluster administrator tool. Of course, make sure all SQL group dependencies are available on the node it should be.

Are you using EMC SRDF? Ask for documentation from the vendor or responsible person from your side. I have searched for the documentation last year very hard, and finally found out the help files on the server as part of the installation! : )

Search whether you can find something like this. It is pretty straightforward and neat.

emc_srdf_ce_config_util.chm

emc_srdf_ce_config_wizard.chm

BTW, my case is SRDF/Cluster Enabler for MSCS v2.0, plus VSFW (VERITAS Storage Foundation for Windows).

Rob-406527 SSC Eights! Points: 907 More actions · Answer 6

Great thanks for the info everyone. Some additional details i've uncovered.

The consistency of the DB was always my concern. It looks like the backup/SAN vendors have a couple of different APIs/techniques to help out.

1. For zero dataloss

It looks like synchronous SAN replication is the way to go. However the replication solution must follow the original write order and account for writes to the primary SAN cache.

2. For some data loss

It looks like the SAN snapshot software can tap into the SQL Virtual Device Interface (VDI) to freeze - copy - thaw the DB. The amount of data loss depends on how often you run the freeze - copy - thaw process.

I see performance implications for all SAN approaches i've researched but it still has to be more efficient than SQL Server's DB mirroring. My focus here is only on VLDBs (multi TB, 50,000+ user systems).

julie gordon SSC Enthusiast Points: 106 More actions · Answer 7

Thanks for sharing the additional details you uncovered. Our team is currently trying to design a DR method, and I am in the same quandary as you and wondering how or if SAN-to-SAN replication can account for cache contents during the replication process and at the time of a disastrous shutdown of the primary machine.

I am investigating the ramifications of setting the recovery interval lower to increase checkpointing thus decreasing the amount of dirty pages left in buffer, but that does not appear to be a good solution for performance reasons, and it may not even be possible to set the recovery interval < 0.

Since your last posting, have you uncovered any additional information about whether the replication software can be configured to force primary cache contents to be replicated real-time?

Lucy Shi Valued Member Points: 74 More actions · Answer 8

We are planning to roll out our SRDF DR solution very soon. The reason we chose SRDF instead of log shipping is that we have many databases within one instance. During the SRDF test, I experienced the "suspect" database status on msdb and some of the application databases. After I did resync, everything came back clean. Unfortunately, I can not recreate the error again. We are using SRDF sync mode.

Carl Federl One Orange Chip Points: 25384 More actions · Answer 9

"SAN-to-SAN replication can account for cache contents during the replication process and at the time of a disastrous shutdown of the primary machine."

You do not need to worry about the cached dirty data, which is data that has been updated in memory but not yet written to disk. The transaction log is always written to disk at commit time and recovery of data is done from the transaction log. At SQL Server startup, a check for data written to the transaction log but not to the data disk is performed and the same startup recovery is also performed on the DR server.

SQL = Scarcely Qualifies as a Language

julie gordon SSC Enthusiast Points: 106 More actions · Answer 10

Thanks for spending your time to provide this clear explanation. You've saved me many more hours of research.

george sibbald SSC Guru Points: 104210 More actions · Answer 11

We are thinking of using SRDF as a DR process for our Non-clustered consolidated SQL servers. My question is how you apply SQL patches\upgrades when the local drives (ie C drive) are not replicated by SRDF.

To avoid cross posting can I ask you post answers to this thread:

http://www.sqlservercentral.com/Forums/Topic665105-384-1.aspx#bm665712

sorry to do this but I am not getting any replies....................

---------------------------------------------------------------------