| W. Chris Shank on 14 May 2008 07:50:29 -0700 |
|
Thanks for the insight. right now i'm planning to have all the data live on the SAN - including OSs, File Shares, Databases, etc. The secondary site is for DR if the primary is clobbered. We will have identical server hardware in each location HBA booting from the SAN. So the theoritical plan will be to replicate the entire SAN to the other side. If/when a failure occurs we will power-on the dormant servers from their SAN HBA image. I am also considering doing the whole thing with virtual machines if the performance is there. I've worked through my IO issues with VMware, so i think it may work for my need. I think replication will be more straight forward at that point. ----- Original Message ----- From: "Darin Strait" <darin.strait@ashdar-partners.com> To: "Philadelphia Linux User's Group Discussion List" <plug@lists.phillylinux.org> Sent: Wednesday, May 14, 2008 10:00:15 AM (GMT-0500) America/New_York Subject: Re: [PLUG] real-time data replication over highspeed WAN link Hi. I''ve spent a lot of time working with SQL Server running on big EMC hardware, and I've got some understanding of how their SAN-based replication tech (SRDF) works with SQL Server. As long as whatever SAN you settle on looks just like any other disk to windows, SQL should be happy enough. Either iSCSI or a "real" SAN" shouldn't matter, at least from a getting-it-to-work perspective. A well-peforming system is a different question. "Network drives", the kind that you get off of NAS units and are available through UNC-style paths, are usually a bad way to go. The final arbiter of a high-performance SQL Server system is I/O latency, particular for SQL Server's tempdb files and the transaction log files for the user databases. SQL Servers are particularly sensitve to disk latency. This sensitivity can kill performance inside of a VMWare VM, for example. If your database is low-stress, it might not matter much, or even noticeably, but when organizations place their databases files on SANs, performance often drops. Many people are surprised by this because marketting teaches us that SANs are faster. One thing, from your note, it's not clear what purpose you intend to use the 'other' copy for. SQL Server doesn't support two instances running off of a SAN-based replication system. There is no Oracle RAC-like feature and "clustering" is often not what people are looking for, either. People who aren't "SQL Server guys" don't always realize this. I don't know what your background is, so I'm just sayin'. The other copy would be only for failover/disaster recovery purposes. (Of course, you'd want to test the way your system works, as implemented, by knocking down one server and bringing up the DR server.) At the SQL Server level, your choices for data "replication" (by which I mean a copy of the data) are "log shipping", "database mirroring" and SQL Server's internal replication features. All of these have trade offs, which may or may not be important to you, depending on exactly what you need. -- d On Tue, May 13, 2008 at 9:40 PM, W. Chris Shank <shankwc@acetechgroup.com> wrote:
-- -- W. Chris Shank ACE Technology Group www.myRemoteITdept.com ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
|
|