Clustered .NET Applications

Clustered .NET Applications

• Jeff-B

  RMD,
  
  I hear you and yes, it might be that BTS might not be the tool of choice for your scenario (though there are very big biztalk installations that handle very big loads, they are expensive).
  
  I see you're talking about sockets here and not MSMQ, and a lot will depend on what your fault tolerance requirements. For example, if you can't afford to loose messages, then you need to make sure you get rid of messages as soon as possible, and keeping everything socket based won't get you there without a lot of work on both client and server sides (that's the kind of thing messaging systems were built to do). Also, what's your requirements for handling messages whose "routing" failed That will need to be taken into account.
  
  Note that both using SQL as a temporary store or MSMQ will incurr some overhead, precisely because the only way to avoid loosing in-flight messages is to saved them to disk during that time (MSMQ always does this with transactional queues precisely to deal with this). So if this is a requirement, you're gonna have to pay that price one way or the other, but there are certainly ways you can minimize that hit (quite a few SQL optimizations would be possible, for example).
  
  This is actually the reason BizTalk uses a backend, shared SQL store to share state among servers and ensure transactionality of operations, btw :)
  
  I wouldn't worry that much about configuration data, as you said it can be cached to improve performance; my main concern and focus would be in-flight messages.
  
  There are BTW some pretty big systems based on MSMQ that follow an architecture similar to yours. One article on this I found very enlightening is this:
  http://msdn.microsoft.com/library/default.asp url=/library/en-us/dnmaj/html/benchmarkingTED.asp
  perhaps you might find it useful to get some ideas.
  
  
  

• Drksrvnt

  Thanks for the article.
  
  As far as my system, my initial design had the MSMQ messages being created by .NET services listening on those sockets. A message would arrive via the socket, it would be transformed into an .NET class that would then be placed inside an MSMQ message body. This message would then be sent to various queues depending on the routing needs. These queues would have .NET Services reading from them and then finally sending the messages out another socket connection.
  
  While this was happening I would need to do various logging and auditing tasks, none of which need to be synchronous.
  
  As mentioned before, in order to make sure there is no single point of failure I'll need to make sure the servers hosting the MSMQ infrastructure are clustered.
  
  If the SQL Server Service Broker can handle the kind of message volume I'm planning for then it might be a cool alternative to MSMQ. I'll obviously also have to have a clustered SQL DB backend, so that could cut costs.
  
  

• manick312938

  My 2 cents. Here goes. MSMQ can handle tremendous load. There are a few things to really consider when using MSMQ.

  1. Use the correct format path for faster performance connection to the QUEUE.
  2. Store Binary queues if possible. If other than tag objects to be serialized.
  3. Avoid Transactional Queues. In your case you may nees it though.
  4. Store Queue on Server. If servers goes offline, Queues are recoverable.
  5. Avoid Dependent MSMQ.
  

  Don't make the architecture more complex than it already is. Install the C# service on the MSMQ Server to avoid trips to MSMQ and to Database.

  Consider Grid Techonology for C# application, like Digipade or go cluster.

  There are other simpler alternatives. I have worked on similar projects and MSMQ did a great job. If you need additional info just drop me a word.

  Thanks

  
  

• Fille

  Tomas,
  
  Thanks for the reply, it was very helpful.
  
  I have looked into both BizTalk and the Service Broker for SQL2k5. I have concerns with both of these approaches.
  
  My application will be routing many hundreds of thousands (and eventually millions) of messages per day. These message are very small (< 200 bytes each) and must be routed very quickly. Me using the term "routing" may be a bit misleading. The messages arrive via TCP socket connections. I will just need to take in a message, examine its intended destination, and send it to one of several outgoing socket connections. Some messages require higher priority routing than others, but I don't need multi-hop routing or anything like that.
  
  I'm worried that BizTalk is a bit too heavy weight for what I want to do. I'm not sure I can afford the overhead involved in the various processes that BizTalk puts the messages through. While part of my system will require the mapping of properties in various schemas to each other, I know I can write a very lightweight system to do this myself.
  
  As far as the Service Broker, this too has me worried from a throughput point of view. One of the design goals of my system is to make as much DB intereaction as asychronous as possible. In most cases I can referenced cached "routing" data when figuring out the route to take. Logging of these messages can also be done asycronously since the data don't need to be real-time and will primarily be used for auditing the system.
  
  Putting all the incoming/outgoing load on SQL Server seems to violate one of the big concepts of learned over the years when designing scalable systems; keep your DB hits to a minimum. If I'm hitting the DB on every single incoming/outgoing messages it would seem to me to me that I'll need some pretty massive SQL Server hardware to back that up.
  
  Are my thoughts on this off base Are there any performance studies that show me message throughput for various hardware configurtions that utilize BizTalk or the Service Broker
  
  

• Handschuh

  Ohh, and another option is the SQL Server Service Broker in SQL 2005. It might be another useful alternative.
  
  
  

• Martin Danner

  RMD,
  
  AppCenter is a dead product, you should stay away from it. Most of it is also COM based and so the support for .NET is rather weak (mostly all the .NET-especific support is only about deploying assemblies to the GAC throughout a cluster).
  
  From your description, it sure sounds like perhaps transactional MSMQ queues with clustered receiver servers would be a very good alternative, but the point where you might have a little trouble is creating your service. There is little documentation at all as to whether it is possible (and how) to create a clustered .NET service, since the cluster API is mostly an unmanaged API and even a fairly obscure one at that. See http://windowssdk.msdn.microsoft.com/en-us/library/ms701059.aspx for the gory details.
  
  However, with WinServer2K3 there was an addition to the clustering API which allowed you to do a simple form of clustering by using scripting. Basically the idea was that the clustered resource itself was merely a reference to a script (usually VBScript) that simply polled the necessary servers and started/stopped services on the right machine on failover/failback. It's not too pretty, but it might do the trick (and be easier to implement). You can find documentation on this here:
  http://windowssdk.msdn.microsoft.com/en-us/library/ms701901.aspx
  
  That said, have you given BizTalk some consideration It can do what you're describing: it already has a built-in, robust and scalable Pub/Sub mechanism for routing, supports very good scalability, supports transactional processes and MSMQ queues and can be clustered if needed (and then supports several other variants that can help)
  
  
  
• Clustered .NET Applications