I've read some articles about the andvantages of failover clustering for MS
SQL Server. I wonder if this is really an important point for environments
with web servers accessing a database and with a limeted budget.
As I remember you need the enterprise edition of MS SQL Server to setup a
failover cluster (which is not really cheap). Also with webservers running
custom business logic, you have a much higher risk in crashing the web
application than crashing a single node of an SQL-Server-Cluster. And there
is no performence benefit (I think clustering will cause a lower performance
because of the overhead).
With all this in mind: Who was ever glad to have failover clustering because
of a hardware crash on an SQL server? Are there any studies about the
effective benefit in "uptime" using a failover cluster?
Lets assume :
- 1 internet connection
- 2-node firewall
- 4 web servers
- 2 switches involved
- 1 SQL-Server
Dell publishes a paper these "facts" (are they "facts" or "whishes"?):
- Win2k & SQL-Server => 99% UpTime
- Win2k & SQL-Server & RAID => 99,9% UpTime
- Win2k & SQL-Server & RAID & Cluster => 99,99% UpTime
Is this realistic? If "yes" - what would you assume to be a realistic UpTime
for the configuration above without the SQL-Server - Would you invest in a
Backup Internet Connection, additional firewall nodes, additional web
servers?
Thanks for yout opinion,
SvenFrom the tone of your question it sounds like you don't need it.
It depends on how much down time the business can afford, how
experienced the staff are and what the support coverage is as to whether
it is advisable.
Nigel Rivett
www.nigelrivett.net
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Friday, March 23, 2012
is there a a real need for failover clustering or should we invest in other redundancies?
Labels:
andvantages,
articles,
clustering,
database,
failover,
important,
invest,
microsoft,
mysql,
oracle,
point,
real,
redundancies,
server,
sql
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment