So for a clustered environment - how would this work with your apps?

What about your own custom .NET apps? Would there be a special way to develop them? I know that you could create a simple Hello world app, and cluster that, but that wouldn't be something you could see in terms of the UI or anything. So they would effectively need to be developed as a Windows Service, or even, perhaps, as a standard Console app, which runs and does not wait for user input. But you wouldn't see any output from it (unless you redirect output to somewhere else).

What I'm getting at here is... for those who have experience or developed a cluster application in .NET, how did you do it? What are the things to be aware of?

For example, we have the cloud service, which is fundamentally built on clustering. If there is an outage, another node takes its place, and the service resumes as normal. However, we don't really see much of that downtime.

  • Would this be for an Active/Passive cluster or Active/Active?
    – Walter
    Nov 21, 2012 at 23:36
  • Both I guess. I'm trying to gain more knowledge on this subject matter which also stimulates me :) Nov 22, 2012 at 0:07

1 Answer 1


I've written a lot of .NET clustered applications over the years (exclusively for Active/Passive clusters) and can share what I've learned.

I've always written my apps as Windows Services and include them as clustered resources in the Windows Cluster Administrator. When the cluster fails over from Node1 to Node2, the Cluster Administrator shuts down the service on Node1 and starts it up on Node2. That's the simple part and Windows takes care of the heavy lifting.

Aside - There is no technical reason why you couldn't write a console app and have it kicked off by the Scheduled Tasks service (which can also be setup as a clustered resource) or some other means. When I first started writing clustered apps the requirements often required the process to be kicked off by the arrival of a file and that seemed to be a better fit for a service than for a console app. For consistency sake, we just continued to write them as services.

The design of your app is going to depend quite a bit on what exactly its task is. But conceptually, you'll need some way to keep track of what unit of work your app is executing so that if the cluster fails over, your app on Node2 knows where to pick up where the app on Node1 left off.

If your app is file based, meaning it is performing some work on files or the data contained in one or more files, those files will need to be on a drive that either fails over or is visible to both nodes. Your app will need to keep track of what file it was working on and potentially what record within the file as well. How it stores this progress is really up to you and what resources are available, but the important thing is that this progress is stored in a manner that will survive the failover (ie, in a DB table or a file on a drive). Storing this progress on a local drive of Node1 will do you no good when the app starts up on Node2, if Node1 is dead.

While you're designing/coding, keep asking yourself - if the cluster failed over at this exact point in the process,

  • What data would be lost? (and would it matter?)
  • Where would the other node deteremine it should start from? (and is it correct?)

There's no magic to it really, just a lot of thought in the details. Should your app do all of the work in transaction (DB or COM+)? That depends on the complexity of the task and requirements. Can you just tag records in a DB as your app completes them and have the other node work on untagged records? Sure, again it depends on the requirements.

  • Walter - great response. Thank you. + 1 to that. OK so here is the thing: If your app "dies" because of the node rebooting or hardware error then Node y kicks in. Fine but then I guess you are right that your app needs to know what it was working on so it can resume where it left off. It makes sense - I just thought there would be another special way of doing this but guess not. For a solution I proposed, which works, is to have n instances of a console app run across the nodes for scalability and HA which is bound to MSMQ. Works like a treat Nov 22, 2012 at 3:12
  • 1
    [cont]... Because, in this specific solution, it is WCF and Transactional MSMQ processing msgs from the queue. If a node, or app, goes down then the others kick in and MSMQ/WCF co-ordinates who/which app gets that msg to process without duplicate processing (WCF config for setting ExactlyOnce=true). So that works fine. But for other custom apps, you are right - you need to know at what point was the app doing what and if it needs to be processed FROM That point onwards, or all over again when the node fails over. Nov 22, 2012 at 3:14
  • @Ahmedilyas - MQ technologies (MS or IBM) add another layer of complexity, as you've stated. There aren't a lot of great choices other than using Transactions with them.
    – Walter
    Nov 22, 2012 at 12:41
  • exactly. that is what I am using, always transactional...and also durable (on disk in case of failure of power or whatever). Nov 23, 2012 at 6:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.