How are people keeping their VC databases replicated for DR?

[MR-T]

Simple question really, I'm interested to know how other people keep VirtualCenter SQL databases replicated for DR purposes.

So site A is live running SQL 2000 and Site B simply keeps the copy ready for a DR.

The methods I'm aware of are:

1) Log Shipping (but requires SQL enterprise)

2) Publisher\Distriutor method

3) SQL2005 mirroring

4) SAN replication technology (Mirrorview, CA etc)

Has anyone monitored the traffic between these instances to see what load they're seeing?

If anyone has experience with 3PAR storage I'd love to hear about it.

Thanks

[sbeaver]

1) Log Shipping (but requires SQL enterprise)

2) Publisher\Distriutor method

3) SQL2005 mirroring

4) SAN replication technology (Mirrorview, CA etc)

Of the 4 ways you have listed I will mention what we use. We have 2 DMX seperated by about 1000 miles. We use SDRF to replicate the SAN data and I just got back from a DR test and it worked flawless

Message was edited by:

Daryll

Had to split off and delete a message, so I changed the language of this posting to make sense.

[kix1979]

I agree with Steve, using database tools for this is far more efficient and reliably.

[MR-T]

Nice one Steve.

I'm being pushed to use the SAN replication method if possible, so it's nice to hear you've already tested this.

[TTCO]

If you have two sites you can run the SQL server on a MS Cluster that has one host in each site (req. a SAN as well that can replicate the data). Provides you with an almost transparent solution. If the SQL DB is down/restarted you might need to restart the VC services... (TT)

[MR-T]

Do you require the enterprise version of SQL to setup clustering?

[mattpound]

Well according to this http://msdn2.microsoft.com/en-us/library/ms143761.aspx

You can do two node clustering with Standard Edition. It also says you can do log shipping with Standard as well.

[mattpound]

And I think you need MSCS as well.

Microsoft Cluster Server (MSCS) must be configured on at least one node of your server cluster. MSCS is only supported if it is installed on a hardware configuration that has been tested for compatibility with the MSCS software. You must also run SQL Server 2005 Enterprise Edition or Standard Edition in conjunction with MSCS. SQL Server 2005 Enterprise Edition supports failover clusters with up to 8 nodes. SQL Server 2005 Standard Edition supports 2-node failover clusters.[/i]

MSCS requires Windows 2003 Enterprise.

[MR-T]

loads of money then.

I read the info about mixing the versions the other day, but it's cost.

[mattpound]

I would investigate Database Mirroring. Looks very promising from what I've read.

http://msdn2.microsoft.com/en-us/library/ms177412.aspx

[MR-T]

Yeah, I've had a look at this and it's just what I need.

If only I was allowed to install SQL2005!

[NeelR]

Why SQL 2005?

Also, can you DB mirror on 2 VM's? Or is this specifically about physical SQL Servers?

[bjd145-1]

A couple things come to mind.

1. You don't need Enterprise Edition with SQL Server 2005 to setup Log Shipping. All you need is log shipping\

2. If you have SQL Server 2000, then you can do a poor man's log shipping by backing up your transaction logs ever 15 minutes and using a tool like SyncBack (or a custom script) to sync those transaction logs to your DR site. You can even write a quick script to restore the files which infact I just blogged about here - http://www.bjd145.org/2007/11/restoring-database-with-transaction.html earlier today

[daniel_uk]

I am implementing neverfail across some of my companys SQL infrastructure...

Thing with Log shipping is the remote server for SQL isnt the same name etc so its going to increase recovery time, with neverfail it copys incremental data at byte level to the second node and also starts services in the event of faliure

www.neverfailgroup.com

Dan

PS I'm not a saleman

[NeelR]

Does the SQL Server need a 1 gb connection?

[bjd145-1]

No it doesn't require a Gig connection which is nice. Now it would be useful to have if your database is large but the VC database is typical less than a couple GB. With 20 esx servers and a couple hundred VMs, my database is only 1.5GB

[johnxon]

If you can get a 1GB connection, would be better in our experiance...

[bjd145-1]

Agreed, if you can get Gig - it would be nice and preferred. But Gig is hard to come by for true DR since most DRs are across a WAN link. For our site, we have only a T3 (45Mbps) between sites. But even with that, a nightly replication of the full 1.5GB bak file only takes 15 minutes. You can setup to replication the smaller transaction logs every fifteen minutes and that only takes about a minute to replicated those over. Once you have a single bak file restored on the DR SQL server, all you would need is the transactions to apply to maintain consistency. This is how SQL Server 2005 Log shipping is done. Once the databse is created over on DR, then it never sends over the full bak file. Only the transaction log backups. This saves alot on time and bandwidth.