| T O P I C R E V I E W |
| Endaar |
Posted - 06/01/2012 : 1:24:56 PM
Hi All,
I've had two, two-node file & print clusters running for around 4-5 years. One pair of servers is HP (2003 R2 x64), the other Dell (2003 R2 x86). Shared storage was originally on an HP SAN and is now on a Falconstor SAN, both via fibre-channel. Everything was on the Microsoft cluster HCL at the time.
The Dell cluster has largely been reliable. The HP one has been a thorn in my side since day one. The basic problem has always been the cluster resources become unavailable but do not go offline. Since both nodes are 'live' and the resources are not offline or failed, the cluster does not automatically fail over. Most of the time the only way to fix this is to power off the node that had the resources, at which point the remaining node realizes it needs to take over and brings everything back up.
I blamed this on the HP SAN for some time, and admittedly it's gotten better since moving over to the Falconstor unit, but it's still a problem. The HP servers have been rebuilt from scratch, following to the letter every Microsoft best-practice document I could find. Etc...
Without making this longer than it needs to be, I've come to the conclusion that I've had more downtime as a result of this being a cluster than I've avoided because it is.
The HP servers are due to be replaced, and two new Dell servers have already been purchased. But having just gone through yet another (admittedly brief) outage, I'm wondering if it's worth clustering the new servers or just using one of them and skipping the cluster entirely.
We do image-based backups of everything, so I can restore a corrupted OS pretty quickly. If hardware goes I can mount that image to a VM and map the SAN volumes with user data to that VM. Our DR situation is pretty solid.
This is K-12 so we're a little less sensitive to downtime than other environments. I already own the new hardware, so cost does not come into this decision. I just want the most reliable setup, and my experience has unfortunately been that clustering is less reliable.
Thoughts?
James |
| 5 L A T E S T R E P L I E S (Newest First) |
| Rastor728 |
Posted - 06/05/2012 : 09:57:12 AM
quote:
Originally posted by Endaar
quote:
Adian Finn's documentation
Got a link handy?
Thanks,
James
http://www.aidanfinn.com/?p=10311
"Rough Guide to setting up a HyperV Cluster"
Use the links to download the relevant documents.
I printed them out, wrote out my network specific settings as I went along and built and tested as a "test lab", then once I knew everything was working well, I moved it to live use.
His book "Mastering Hyper V Deployment" is very useful as well! |
| Jazzy |
Posted - 06/05/2012 : 08:17:45 AM
I agree that for many customers failover clustering adds complexity, increases the administrative burden and leads to more downtime and increased costs. I see this with my customers too.
Usually you can achieve acceptable availability with virtualization and good procedures. I mean, a bad sysadmin will brake any server whether it's a cluster or a VM. |
| Endaar |
Posted - 06/05/2012 : 08:04:45 AM
quote:
Adian Finn's documentation
Got a link handy?
Thanks,
James |
| Rastor728 |
Posted - 06/04/2012 : 1:18:32 PM
My two node HyperV 2008 R2 Cluster (Dell R610) with a Dell NX3100 SAN (with several free drive slots still unused) and connected using iSCSI have worked great for the past six months. Was a very affordable system to use for my first cluster/hyperv build, and has been very easy to monitor and maintain.
From there I have a SQL 2008 R2 Server (with three different DB instances), Backup DC, Windows 2008 Print server plus many other specific application and file servers (small rural critical access hospital) that have had great (for us and what we used to have) uptime and performance numbers.
I used Adian Finn's documentation on setting up the two node system in a test with very few changes for production from his details. |
| wkasdo |
Posted - 06/01/2012 : 2:52:42 PM
> Thoughts?
Just some small ones.
- Clustering in Windows 2008R2 is a completely different animal from 2003.
- a solid virtualization stack is good for uptime. |
|
|
