June 4, 2009 at 2:25 am
Hi,
I have to get involved into SQL2K5 Failover Clustering. I've read-up on the subject and miss some specific info on how things actually work. I don't need an installation manual or best practices, I can find those topics easily; I need questions answered on situations which seem contradictory.
For instance, I've read trhis article: Failover Clustering for Microsoft SQL Server 2005 and SQL Server 2005 Analysis Services from Microsoft and read, that on W2003 EE for SQL2K5 EE maximum 8 CPU's are supported. In some of our clustered servers I see 16 CPU's. Another thing is the recommendation, that identical hardware is used; so differences in CPU and memory would be a no-no, yet I see some clustered servers with exactly those differences. So would this document be outdated(2007)?
Another thing I am curious about, how Failover actually work? We have several clustered servers, yet I see different databases on different clustered servers; this is good practice?. The datafiles are placed on an advanced HP Diskcabinet, but what actually happens when an availibility check fails for a node? As I read it another node takes over(which one?) and a recovery process is started for the databases on the failed node. A recoveryprocess can be a lengthy process with some databases. I would think another node with instantly pickup the load from the failed node, or else why install a failover solution?
So, are there som docs/sites out there, which can give me some more insight on this?
Greetz,
Hans Brouwer
June 4, 2009 at 9:20 am
I too need some information on SQL2K5 Failover Clustering. I would prefer some more detailed information than what was provided by the mentioned article. ANY information is welcomed and appreciated.
June 4, 2009 at 2:58 pm
You should check out Allan Hirts Pro SQL Server 2005 high Availability, he beautifully explains Clustering
http://www.amazon.com/Pro-Server-2005-High-Availability/dp/159059780X
June 5, 2009 at 6:11 am
I know, I have ordered his book?
Manager:'Why do we need it?'
DBA: 'Because we lack the knowledge'
M:'But...isn't that why we hired you?'
DBA:'As you recall you hired me for these specified tasks & targets:' list as long as my arm.
M:'Yes? And?'
DBA:'Do you see anything mentioned about redesigning our Cluster?'
Silence.
M:'OK, I'll order it'
Greetz,
Hans Brouwer
June 5, 2009 at 7:56 am
FreeHansje (6/4/2009)
Hi,I have to get involved into SQL2K5 Failover Clustering. I've read-up on the subject and miss some specific info on how things actually work. I don't need an installation manual or best practices, I can find those topics easily; I need questions answered on situations which seem contradictory.
For instance, I've read trhis article: Failover Clustering for Microsoft SQL Server 2005 and SQL Server 2005 Analysis Services from Microsoft and read, that on W2003 EE for SQL2K5 EE maximum 8 CPU's are supported. In some of our clustered servers I see 16 CPU's. Another thing is the recommendation, that identical hardware is used; so differences in CPU and memory would be a no-no, yet I see some clustered servers with exactly those differences. So would this document be outdated(2007)?
Clusters should by nature have the same hardware within their cabinets. This means that when a clustered resource fails over to a different node that the performance of that instance will not change because the hardware running it is the same. That said, if you can get a cluster to run on differing hardware, I'm sure that it's still better than not having one at all.
As for the 16 CPUs...are they hyperthreaded Intel procs? Those tend to show up as double processors, similar with dual core procs.
FreeHansje (6/4/2009)
Hi,Another thing I am curious about, how Failover actually work? We have several clustered servers, yet I see different databases on different clustered servers; this is good practice?. The datafiles are placed on an advanced HP Diskcabinet, but what actually happens when an availibility check fails for a node? As I read it another node takes over(which one?) and a recovery process is started for the databases on the failed node. A recoveryprocess can be a lengthy process with some databases. I would think another node with instantly pickup the load from the failed node, or else why install a failover solution?
So, are there som docs/sites out there, which can give me some more insight on this?
Depending on how you have it configured, when a node fails, either the SQL service starts up on another node, or it must be manually started. In the case of hardware failure, the short period of time (and it's less than a minute when I fail my 1000 database instances over from one node to another) is still shorter than waiting for the hardware to be serviced to bring the sql instance back up.
I'm not sure I understand your question about different databases on different clustered servers. Each clustered instance can fail within its cluster group from node to node. If more than one instance is on the cluster group then different databases can be on each running clustered instance.
June 5, 2009 at 8:21 am
I am personally working on learning Clustering with SQL 2008 by building my own cluster using ESXi and 4 virtual machines. I am slowly blogging about it on my blog, but you can follow the information on the reference URLs on my first blog post in the series on building a testing cluster for free:
I wouldn't recommend learning on your first implementation. You'll learn a whole lot building a few clusters in a VM environment before actually rolling one for production, and you'll make your mistakes in an environment that isn't important.
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]
June 5, 2009 at 8:23 am
BTW, the same type of setup can be used with SQL 2005 for learning.
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]
June 5, 2009 at 9:05 am
June 6, 2009 at 9:07 am
Tnx for answering all, this is instructive.
Nilmov, this doc was the first I downloaded, it left a lot of questions with me...;-)
Jonathan, I will follow your BLog with interest; the virtual environment is good advice, see if I can arrange that.
Mtassin, I had a different(wrong) idea about clustering, so the latter part of my question is based on a wrong assumption. Apologies.
Greetz,
Hans Brouwer
June 7, 2009 at 2:52 pm
If you can go straight to SQL 2008 and Windows 2008. I wrote the entire steps by following Dell threads they have the entire instructions layed out. It appears a lot of this now GUI Wizards when setting up the clustering.
June 9, 2009 at 1:11 pm
I've noticed the book 'Pro SQL Server 2005 High Availability' has been recommended in this thread. Looks like I'm going to have to purchase this one on my own. Before I do, anyone with knowledge of this book, how is it on explaining in DETAIL how to set up a clustered SQL Server 2005 environment. I've seen a couple of articles (incl. Microsoft white pages) and they still do not explain in a lot of detail how to set it up.
So please, let me know your thoughts, suggestions, recommendations on purchasing this book - Pro SQL Server 2005 High Availability.
thanks...
June 9, 2009 at 3:48 pm
peggy.gaines (6/9/2009)
I've noticed the book 'Pro SQL Server 2005 High Availability' has been recommended in this thread. Looks like I'm going to have to purchase this one on my own. Before I do, anyone with knowledge of this book, how is it on explaining in DETAIL how to set up a clustered SQL Server 2005 environment. I've seen a couple of articles (incl. Microsoft white pages) and they still do not explain in a lot of detail how to set it up.So please, let me know your thoughts, suggestions, recommendations on purchasing this book - Pro SQL Server 2005 High Availability.
thanks...
I'll agree that the white papers leave something to be desired. As for the book I haven't read it.
The most important tip I can give is to not install the clustered SQL instance while on an RDP session. This might work better in 2008, but in 2005 it won't work, and the errors you'll get won't make sense. Even RDP with /console won't cut it, either a VNC or Dell ERA type connection to the console, or walk up to the thing and do the install up close and personal like. The reason this doesn't work is SQL 2005 uses RDP to install itself to the cluster nodes and needs all the RDP sessions (2) that a typical non-application centered Windows Server has.
June 10, 2009 at 7:17 am
I don't think there is any issue with running different SQL Server instances on each node of the cluster. For example, at my company we have several clusters and most of them have databases on node A and node B. The only issue that I know of is when failover occurs the node running all the databases will slow down some. I'm assuming that depends on how hard the databases are used. In my testing of failover, the recovery process doesn't take that long, a few seconds and the database was backup on the second node. This database was only about 200 GBs though. One thing of importance though, make sure that the dependencies are set correctly. By that, I mean make sure the disks are set to start backup and then the SQL Server instances or SQL Server won't be able to start because it can't find the disk.
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply