Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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 can say create a simple Hello world app, and cluster that but they wouldnt be something you could see interms of the UI or anything, so they would effectively need to be developed as a Windows Service perhaps or even as a standard Console app which runs and not wait for user input but you wouldnt see any output from it (unless you redirect output to somewhere else)

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

For example we have the cloud service - fundamentally its built on clustering - if there is an outage, another node takes place and service is resumed as normal but we dont really see much of that downtime.

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

1 Answer 1

up vote 3 down vote accepted

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.

share|improve this answer
    
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 –  Ahmed ilyas Nov 22 '12 at 3:12
    
[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. –  Ahmed ilyas Nov 22 '12 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 '12 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). –  Ahmed ilyas Nov 23 '12 at 6:25

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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