cluster aware

Viewing 1 reply thread
  • Author
    • #13492

      BizTalk Server (BTS) is by nature more efficient than an active/active NLBS scenario. Generally BTS is not installed as an active/passive cluster. For high availability scenarios you should generally install one BTS server and then add the second BTS server to the first server’s group during configuration. This way both servers will work together to share the load and if one goes offline, the other one will continue processing. An enterprise-level, high availability architecture – as designed by Microsoft Consulting Services – would ideally have four seperate server boxes: two servers in Active/Passive running SQL Server and two BTS servers running together in one group.

    • #13493

      1. What does \”being cluster aware\” actually mean?
      2. Is bts 2006 \”cluster aware\”?[/quote:ab417a68bb]

      Cluster aware mean that the product can be installed on, and take advantage of the reliability features offered by the clustering services built into Windows Server, such as creating an Active/Passive cluster for failover.

      The quote you mentioned talked about BizTalk not being cluster aware in a very specific scenario related to the use of the MSMQ adapter. Clustering (and reliability) in biztalk is usually a more complex matter because it depends a lot on what you are doing in biztalk and what adapters you’re using. Notice that for reliabilitty you should always cluster your BizTalk databases, which can be done because SQL Server.

      After that, some protocols (and hence, some of the adapters biztalk supports) have characteristics that make them more appropriate for other scalability and reliability mechanism than clustering, and so you need to consider very carefully what adapters you’ll be using and what the characteristics of your load will be to design an appropriate biztalk processing infrastructure.

      For example, if you mostly receive messages through HTTP/WebServices, then putting multiple BizTalk boxes and using load balancing (such as NLB) is a far better approach than clustering. Also, with biztalk you can do very cool things like dedicating specific servers in your biztalk group to only receive messages but not process them, while dedicating other boxes to just running orchestrations, and other to sending messages. Or you could even dedicate some boxes to running especific business processes. This is all possible thanks to the very flexible host/instance/binding model used throughout biztalk and the shared messagebox of the group.

      However, for MSMQ, things are somewhat different. The MSMQ protocol itself does not lend itself very well to load balancing, and hence, load balancing is rarely a good choice for improving availability of MSMQ receiving applications (and hence biztalk if you use the MSMQ adapter). The core MSMQ services in the OS, though, are cluster aware, which means that the MSMQ service can run on a cluster and do failover and have the MSMQ persistent queues stored as part of the cluster quorum (shared storage).

      Since BizTalk 2004 did not support clustering very well (if at all), building a really, really reliable MSMQ receiver using BizTalk was not a very supported scenario. In BizTalk 2006, however, you can install biztalk on the cluster nodes, and then cluster the BizTalk host where the MSMQ Receive adapter/handler is configured, and have biztalk do failover alongside the MSMQ service on the cluster. For the people that need this kind of reliabilty, this makes it considerably easier to build more reliably biztalk environments (and it can be done alongside non-clustered biztalk nodes dedicated to other purposes, as well, so it does not brake the overall architecture).


Viewing 1 reply thread
  • The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.