April 14, 2009 at 11:19 am
Hello
we are putting together a stategy for upgrading from sql server 2005 ( currently in a clustered enviornment on server 2003) to new dedicated hardware for our sql server 2008 installation. So far we have determined we will be using server 2008 64bit to host ssms,ssas, ssis, ssrs ( specific sql server version is 2008 enterprise also 64 bit). My question is on our high availablity strategy in case this box goes down. Can I get some ideas how this is currently being done in the sql server community? Is sql server clustering a possibility? Best case scenario is if this box goes down we can go to our second box-- are there other strategies outside of clustering? our cluster enviornment for sql server 2005 used a software app called "Never Fail" which gave us a lot of problems when we went from node A to Node B. Are there significant improvements with server 2008 clustering and it's effects on SQL Server 2008?
thanks in advance
kam
April 14, 2009 at 4:07 pm
Hi Debbie not to sure what "Never Fail" is...
I have used clustering on both SQL Server 2000 and SQL Server 2005 and on test cluster with SQL Server 2008, all using windows clustering and MSCS and i have never had any problems...I have used veritas clustering too...that also worked well enough.
Other high availablity options include Database mirrorring and Log shipping...
Hope this helps
Gethyn Elliswww.gethynellis.com
April 15, 2009 at 12:29 pm
We have a similar problem with ARSystem as you do with NeverFail. When a failover happened the connection would obviously be lost, and ARSystem isn't smart enough to try and reconnect.
To get around this we put in place a stored procedure that would execute on startup and failover the cluster on which ARSystem resides (ARSystem is not cluster aware but we are running it as a clustered service sitting in the resource group with the Quorum). There's no reason that you couldn't force a restart of any service associated with NeverFail which would help it reconnect.
If you are just looking to resolve a potential hardware failure then clustering is the best way to go. Mirroring and log shipping probably wouldn't suit your needs as you described them.
April 15, 2009 at 1:08 pm
thanks for response -- we will do some testing and see what will work best for us
April 15, 2009 at 10:21 pm
Your final solution will also depend on what you are trying to protect against, what downtime tolerance you have, and where the backup server(s) will be located. There is nothing to stop you from combining clustering, mirroring, replication and log shipping if you want to; they each have their own advantages and disadvantages and you would benefit from investigating each of them before making any final decisions.
I'm not sure if SSIS, SSRS, SSAS are cluster-aware and that may also impact your decision.
April 16, 2009 at 7:09 am
matt stockham (4/15/2009)
Your final solution will also depend on what you are trying to protect against, what downtime tolerance you have, and where the backup server(s) will be located. There is nothing to stop you from combining clustering, mirroring, replication and log shipping if you want to; they each have their own advantages and disadvantages and you would benefit from investigating each of them before making any final decisions.I'm not sure if SSIS, SSRS, SSAS are cluster-aware and that may also impact your decision.
We've been able to get SSIS running in a cluster, it's a little cludgey but works, no issues with SSAS either. SSRS is another story, we're not running it clustered, so can't help with that one (it is awesome that you don't need IIS for it any longer)
Viewing 6 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply