sql cluster and sharepoint

We're installing an SQL Cluster in the next couple of days.  Are there any gotchas as far as SP goes when installing a SQL cluster?  

We've already got the SAN space configured for tempdb, tlog, content dbs, as well as MSDTC and Quorum.  

I'm basically going over this item which seems to be an amazing resource, but if any other thoughts particularly as it relates to SP, please chime in...


Who is Participating?
mccarthybriConnect With a Mentor Commented:
any gotcha's if there are I havent seen them.  As you know a Sharepoint farm is based on redundency. extra front ends, index servers, all in the name of ensure that no one server or service would bring it down if it died.  Sql cluster is no differant, designed based on if one sql dies there is another to keep in going.  The one thing we did in our shop was to test this cluster from time to time to force the fail-over to occur to ensure it does actually work.  we also setup our two sql servers in the bios so if both servers crashed our primary would reboot and our alternate would not until we manually rebooted it, this way there would be a fit for which one would be the primary.  that was one fail safe we put in place.  only because our setup was prone to power loss at that time.  Otherwise, its a pretty sound deal.  of course also the cluster allow running updates and then rebooting without disruption of service to customers, which is always nice.  So inclosing I hadnt seen any short comings from sharepoint on doing a sql cluster.
MsShadowConnect With a Mentor Commented:
The only extra advise I can give on top of mccarthybri's excellent explanation is to make sure that the SQL Cluster setup is done by a SQL Pro. In many cases SQL Clusters are setup so poorly that the goal (less risk, more uptime) isn't reached at all, on the contrary.
crmsharepointAuthor Commented:
thanks...no real gotchas came up as they relate to sp...just some hiccups in the actual SQL install and configuration.....if you don't mind, for my own records and perhaps to someone elses benefit someday, here are some lessons learned...

1) Make sure that you are logged out of Node B when you are installing on NODE A
2) We needed domain admin privileges to do the sql install, even though the things we read told us we didn't need domain admin privileges (it consistently failed until we did it with domain admin.
3) when problems arise look at bootstrap logs, logs in logged in users temp directory, and of course system event viewer
4) Test failing over of MSDTC, do the SQL cluster install...test failing over of SQL cluster....THEN do SP install
5) When moving tempdb to a new drive make sure that it is a dependency of the sqlserver instance.  This mistake hosed us when the dba accidentally did this.
6) if something like #5 happens, you may need to remove all the disks as cluster resources, as well as delete the cluster resource group, then re-add the resource group, and re-add the disks.

crmsharepointAuthor Commented:
done.  thanks, and yes having our dba actually do it was helpful.  
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.