• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

MS SQL server clustering

ManateeMatt

Limp Gawd
Joined
May 27, 2009
Messages
145
My office is investigating moving the the 10 (BES, ACCPAC, SharePoint, vSphere and a few other small apps )or so small on the machine sql instances to a more powerful sql Custer for easier management, backups and better reliability.

Does anyone have any suggested ways creating this sql Cluster? I have read the different ways and I'm not 100% sure what way to pick.
 
If you have to ask, you're probably in way over your head. You're putting all you companies databases in one place. Do YOU want to be responsible for making sure that SQL cluster works reliably? At the very least, you'd want to setup a proof of concept environment to prove you can do it and that you're not introducing more problems than you're solving.

You'll probably be better off hiring someone for this
 
How many servers are you going to cluster? We currently run two Dell R710 systems for SQL clustering.

If you have a storage array that uses parallel scsi connections, you cannot cluster with Windows Server 2008 because they dropped support for it. You can however still use Windows Server 2003 R2 with parallel scsi connections.

If you are going to use shared storage through FCoE, FC, iSCSI, you're all set then to setup clustering.

If you have two servers, each will have it's own IP address in the cluster and then you will have a "cluster" IP address. All desktops,etc that want to connect will connect to the cluster IP address so that if one server fails, the cluster IP automatically redirects to the server IP and no one will be the wiser that something happened. Each server will also have a heartbeat IP address (completely private from anything else) and that's how the servers will communicate between each other.

All you have left to do is create a LUN or slice or whatever you have on your SAN and point the cluster to the quorum drive. The quorum drive is responsible to telling the cluster which server is doing what basically. There is very, very little data written to this, so you could easily get away with a 200mb partition for the quorum.

After that, when you install SQL 2008, it will ask if you're installing a clustered instance of it. Select that on each server in the cluster and the software takes care of the rest. Move your SQL data into the stores you create on your SAN and tell SQL where to link the database and voila.
 
You will need 2008 R2 EE to do this right, you need to create a server cluster and then an SQL cluster on top of that. When I last did this it could only be a n Active passive cluster but things may have changed since then.
 
My first goal was a proof of concept in a lab, then a butload of testing then possibly depending on how confident i feel proposing it. We have the infrastructure to do it. I understand how to do it, I was wondering if anyone had any "oh i ran into this" or "dont cluster, do XYZ" I guess i could have been a bit more clear in my original post. Fail-over clustering seems to be a bit of a hog for resources as just one server sits there and does nothing until the server fail over.

I guess I'm used to more of a load balancing type system than a Fail-over type system.
 
vSphere isn't an app, it's a platform. Things run on top of it. If you're a VMware vSphere shop virtualize the SQL servers and skip Microsoft Clustering. Use VMware HA and maybe VMware FT to protect them. Simple and easy.
 
vSphere isn't an app, it's a platform. Things run on top of it. If you're a VMware vSphere shop virtualize the SQL servers and skip Microsoft Clustering. Use VMware HA and maybe VMware FT to protect them. Simple and easy.

I was taking about the DB that you need for vSphere management server thing (cant remember the name right now)

I did think of that, and I'm more than likely going to go that way, but I am still going to try clustering anyways as it will give me more knowledge when I say no lets do it this way.
 
Back
Top