April 14, 2014 at 9:25 pm
Comments posted to this topic are about the item Why every SQL Server installation should be a cluster
Francis
-----------------
SQLRanger.com
April 15, 2014 at 1:36 am
"lessoning" of hardware failure.
Love it 🙂
April 15, 2014 at 2:10 am
So, the companies I work with are the only ones not running Windows Server Enterprise edition? Ok.
April 15, 2014 at 3:08 am
I like this article a lot and you make the case very well. It would be interesting to see the balance of arguments if you look at the alternative options for HA, particularly when you consider the potential cost savings (hardware at least) that could be achieved if you plum for AlwaysOn AG over clustering. As ever it boils down to requirements, and I've recently gone for a mix of clustering for HA and AlwaysOn AG for DR in a design I've just done. So I'm very much looking forward to your next article which will hopefully vindicate my design! 🙂
April 15, 2014 at 5:53 am
An excellent and well thought out article, especially relevant now that Microsoft have changed the Enterprise licensing model to make the use of AGs that much more costly and difficult to justify.
It is just such a shame that clustering still requires a storage medium that can be passed between the nodes, whereas networking has moved on to allow for multisubnet failovers. It makes clustering difficult for any that are in a traditional separate data centre design and cannot have floating storage between them
April 15, 2014 at 6:37 am
Clustering can be a very nice convenience, however, there is still the cost of ownership for the hardware to properly backup that type of HA solution. I'm not 100% sold on the TCO for the particular environment that our team supports. We do use mirroring though and that for us has a much lower TCO for how our environment is built. I have worked with a clustered environment before though and I can attest to the benefits. I also think your article does make a very good case for using it. I think it would be good to do a follow up post where you delve into the infrastructure requirements that clustering requires for the databases to perform well. Maybe a best practices type of posting to get people started on clustering if they want to go that route based on your own experiences with clustering and not just from various BOL articles and white papers.
April 15, 2014 at 6:43 am
This is a good start to an article, but it's more of an advertisement than a convincing argument. Why? It's all upside.
You don't acknowledge the costs of clustering: hardware, licensing, implementation and administration time.
A full rational argument sets out the costs and the benefits and shows (in a positive case) that the benefits outweigh the costs.
I would love to see a part two to this article which fully covers the costs of clustering, as enthusiastically as this one covered the benefits.
April 15, 2014 at 6:55 am
IMHO the decision if to cluster or not should be entirely business driven. Do you really need the potential higher availability and are you willing to pay the additional cost. How does increased availability of SQL Server measure up compared to application failure (IMHO the most significant source of service downtime).
To my experience, the added complexity of clustering at the SQL Server level can in practice lead to less uptime than a simple straight forward single node installation (especially in a vm on a vm cluster). Today, in a computing centre you already have many other means to guard you from hardware failure or at least allow rather quick recovery. (High available, redundant storage in a SAN, VM clusters etc.)
April 15, 2014 at 7:32 am
I found the article very interesting. As the sole DBA I am currently supporting 2 clustered environments in 2 domains. The headache I am going to be facing next summer is the replacement of the 2 servers in one of the clusters. When we replace hardware, we also upgrade OS. We do not upgrade the OS on existing hardware. The reasons for this can be the subject of another post. This particular cluster is running Windows server 2008 R2 Enterprise. When we replace the hardware these servers will move up to Windows Server 2012 R2. Can Win 2008R2 and Win 2012R2 be clustered together?
Bill Soranno
MCP, MCTS, MCITP DBA
Database Administrator
Winona State University
Maxwell 143
"Quality, like Success, is a Journey, not a Destination" - William Soranno '92
April 15, 2014 at 7:38 am
Clustering SQL Server first requires a clustered OS. And that has IMHO, been the missing element to setting up a clustered SQL Server. either limitations in windows or the IT staff just would not, or could not setup and maintain a cluster.
But lately, ease and IT skill in setting up an OS cluster have improved. That combined with mirroring being phased out will lead more and more DBA's to cluster. It makes sense to cluster, but you need the infrastructure.
The more you are prepared, the less you need it.
April 15, 2014 at 7:44 am
As a "DBA in Diapers" I found this article to be very useful. Thanks for sharing your knowledge, looking forward to your next article.
April 15, 2014 at 7:48 am
I disagree strongly. This goes against the keep it simple stupid rule of thumb. I will say that if you cluster your production servers, you should cluster your test and QA even if it is a cluster of 1. This way you know what you are up against when it comes time to windows updates and software updates. But clustering everything makes the servers that don't need to be clustered that much more difficult to manage. If you need HA, look for the best HA solution for you need and budget. If you don't need HA, why invest the time and money on it.
April 15, 2014 at 8:10 am
I found the article very interesting. As the sole DBA I am currently supporting 2 clustered environments in 2 domains. The headache I am going to be facing next summer is the replacement of the 2 servers in one of the clusters. When we replace hardware, we also upgrade OS. We do not upgrade the OS on existing hardware. The reasons for this can be the subject of another post. This particular cluster is running Windows server 2008 R2 Enterprise. When we replace the hardware these servers will move up to Windows Server 2012 R2. Can Win 2008R2 and Win 2012R2 be clustered together?
If you have the two boxes sitting there you might consider these steps instead.
1) Build the second cluster.
2) Install SQL and restore master. (upgrade SQL if needed).
3) Restore MSDB, Model, and set up anything else you need.
4) Mirror over to the new cluster.
5) Make sure everything that needs to reach the new cluster can, make sure all the packages, web servers, app servers, anything can reach and talk to the database.
6) Double check #5 about 3 more times. Have someone else test it.
7) Fail the mirror over safely to the new cluster. After it's run there a few hours/days/week.... break the mirroring and shut down the old cluster.
8) Find something cold and put your feet up for a bit.
This is a personal approach as long as you have the hardware / licensing / time to support it. There may be other ways, even better ways.
.
April 15, 2014 at 8:13 am
On the KISS thing. I do agree. Clustering has some pretty heavy negatives for it. You have to be on a domain, you have to have share storage, you now have an additional layer of things that can break.... I like clustering where it's needed, but it's not needed everywhere. There are plenty of places that just cant afford this and the data isn't worth the price of the hardware and people that can maintain it.
.
April 15, 2014 at 8:14 am
Interesting article and you make some good points. However, we are going to migrating away from our Clusters that we have as we upgrade in the coming years. We are virtualizing everything and snap cloning everything to our disaster site as well as replicating our current backups to our disaster site as well.
The added costs of extra hardware for the Prod as well as NonProd environments are quite high. (I had to do a hard sell to my boss as to why we need a Cluster in NonProd) I want to be able to simulate all Windows updates, SQLServer patches, migrations to new SAN etc in Nonprod before we just do it for the first time in Prod.
As far as downtime I have found we have more downtime with Clusters than standalone systems. Reason I say that is a unplanned failover of SQL Server from one node to another happens once in a while OR someone is doing something on what they think is the NonActive server when it is really the active one. Some software isn't cluster aware either which causes problems.
Viewing 15 posts - 1 through 15 (of 80 total)
You must be logged in to reply to this topic. Login to reply