02-25-2009 05:05 AM
I do see advantages using a cluster for e.g. mailbox archiving ('automatic failover'), but also for using Building Blocks/USL ('easy setup').
On the other hand I do see disadvantages for using a cluster ('more complex setup') and for using Building Blocks/USL ('manual failover', which requires different type of monitoring).
If I have a requirement of 98% uptime a cluster seems a bit of an overkill.
Could anybody indicate if they had to deal with the same question, and if so which solution was used under which circumstances; or is it a typically 'you're mileage may vary'...?
Solved! Go to Solution.
02-25-2009 09:32 PM
02-25-2009 06:06 AM
Since your uptime is so high I recommend Clustering. With a 98% up time unless you have someone on site 24 * 7 * 365 who has been trianed on how to do this it will be a streach to maintain that requirements
At least with clustering if it fails the other device will take over the operations within seconds, this way you exceed your uptime.
In my opinion building blocks is good if your devices are spread accross two physical locations. In that case building blocks is ideal so when you get the call you can make a few small changes and the DR server comes online but if it will be all in one Computer Room / Data Center then full clustering is the way to go
02-25-2009 06:33 AM
I didn't mention that the active/passive servers will be lcated in the primary and remote site of a Twin datacenter. Storage will be a full redundant MetroCluster.
Could this process of 1. monitoring is an EV server is down, 2. make changes to DNS and 3. run the USL be scripted? However, monitoring will be 24x7x365 anyway...
02-25-2009 07:00 AM
Since full clustering requires a shared resource for Quorum and data storage then having the servers physically seperated may be an issue unless you are using iSCSI or some other form of remote storage to perform these tasks in a full Cluster
If you do not have this available then i think Building Blocks is the way you should go
I think you can get very creative regarding writing a script ot Make the DNS Changes and stuff. But i dont believe this can be fully automated because the USL cant be run via a script and i never recommend scripting a DNS change for a failover like this. If something goes wrong with it you can mess up your DNS and make a bad situation worse.
As for monitoring...there are many products out there to monitor your environment, stull like SMS and Nagios to name two.
Nagios can be configured to perform tasks after an event is registered but since the USL cant be scripted i dont think everything can be completed automatically if you go with the building blocks option
02-25-2009 07:02 AM
02-25-2009 07:23 AM
Building Blocks costs less mut the manual side of it will add to the downtime
Physical clustering is faster and failover is automatic but there are costs involved
It all boils down to the dirty 4 letter word....COST
02-25-2009 09:32 PM
02-27-2009 02:20 AM
Both solutions (Cluster / Building Blocks) use (at least) one second server: in both cases there may be a chance they're never used (this is the black and white assumption; they will be used).
However, if the second server would be a bare-metal one, so that it can be used for other purposes also, and assuming that the 98% availability allows for a rebuild of the server as part of the failover when required...
1. Would a restore of the server system state backup be enough? If not, what's more to think of?
2. Would large Vault Stores / Partitions cause a problem when starting the server after the restore.
PS. This is a theoretical question, but may give additional insight in our decision process.