February 10, 2009 at 8:35 am
Why companys r using clustering.when it is so colstly and when it has more dis advantages???
February 10, 2009 at 8:39 am
High availability, total server failover, hardware redundancy.
So what are all the disadvantages of clustering and what do you suggest as a replacement?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
February 10, 2009 at 8:47 am
Clustering does not guarantee a complete absence of downtime(Power failures)
Clustering requires expensive hardware and software
Clustering is designed to work within the confines of a data center, not over geographic distances
Wat could be a best alternative wen seeing these dis advantages.
can Database mirroring be an alternative.
Pls do share ur views on this
February 10, 2009 at 8:50 am
Mirroring is a great option, but for many shops (like mine) the extra SAN/Disk space is FAR more costly than having an additional server.
Couple that with the fact that you can actually use that additional server for performing a different task (could be another SQL Server for instance) and the fact that more times and not the issues that I have come across are things like processor fans dying out (cluster is perfect for this scenario).
Mirroring is a great option, but it is no where close to being a cheaper solution than clustering.
February 10, 2009 at 9:01 am
Clustering addresses specific requirements. It works well for some people, and one of the reasons it works well is the restrictions on hardware and setup.
It mirrors an instance. Database Mirroring only does a database, so if you have multiple databases, or perhaps jobs, packages, etc. that need to failover, it doesn't handle that. You can script something, but clustering handles it automatically.
February 10, 2009 at 9:08 am
amarbreddy21 (2/10/2009)
Clustering does not guarantee a complete absence of downtime(Power failures)
It can if there's a failover SAN and the nodes are in different server rooms (different buildings). Plus for complete uptime, the servers cannot be considered in isolation. There has to be backup power, redundant networks, switches, etc, etc
Clustering is designed to work within the confines of a data center, not over geographic distances
So's mirroring. It does not work well at all over slow (WAN) connections, especially synchronous mirroring on high usage servers.
Ever heard of geo-clustering?
can Database mirroring be an alternative.
Not a complete alternative. Mirroring is at a database level and requires that the clients are aware of the failover server. If there are multiple databases for an app, data files outside of SQL and/or other services (SSAS for example) then mirroring alone cannot replace clustering.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
February 10, 2009 at 9:09 am
Steve Jones - Editor (2/10/2009)
Clustering addresses specific requirements. It works well for some people, and one of the reasons it works well is the restrictions on hardware and setup.It mirrors an instance. Database Mirroring only does a database, so if you have multiple databases, or perhaps jobs, packages, etc. that need to failover, it doesn't handle that. You can script something, but clustering handles it automatically.
You can't mirror system databases, so things like logins (a big one) don't get automatically mirrored. Mirroring also has big limitations on work load. You can't mirror more than about 10 medium usage databases without getting into sync latency problems. Paul Randal covered this in TechNet last year. Clustering in Windows 2008 and with SQL 2008 is no longer the highly expensive option it used to be. You can now have heterogenous clusters so hardward dependencies aren't what they used to be. This also allows easy upgrading of cluster hardware as long as it is within the same family of processor (ie x86 has to be replaced by x86 and x64 by x64).
I've worked with both in the past, and I'd opt for Clustering over Mirroring for uptime purposes. For low cost HA where uptime doesn't have to be 99.999% or better, Mirroring can work, but expect to be down for any patching, rebooting, and unless your applications are configured correctly, expect to have downtime during failover while your reconfigure all of the apps to talk to a different servername, even if you shortcut it through a config Alias, you still have to touch every machine.
One other thing is that if your have Reporting Services, you can't do automatic failover with Mirrored Databases, its not supported, and not an option for Reporting Services. You have to go reconfigure your Reports Servers to talk to the new Server.
Jonathan Kehayias | Principal Consultant | MCM: SQL Server 2008
My Blog | Twitter | MVP Profile
Training | Consulting | Become a SQLskills Insider
Troubleshooting SQL Server: A Guide for Accidental DBAs[/url]
March 4, 2009 at 11:42 pm
The worst thing about clustering, in my opinion, is that it has a single point of failure; the shared database files. If you lose the database (disk failure) you lose the whole system. Ideally, I would advocate for using clustering as your primary failover with databse mirroring as your secondary failover.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply