Considerations while planning High Availability for Windows Service Bus

  • Article

I’ve recently been asked few questions related to Load Balancer in Windows Service Bus (WSB), and it seems to me there is quite confusion between High Availability and Scalability in WSB.

I decided to write down this article to try to clarify when and why it is recommended to use a Load Balance in front of WSB, as well as explaining main differences between High Availability and Scalability in Service Bus.

 

Service Bus Architecture

Before diving deeper, let me summary key components in Windows service Bus 1.1:

  • Service Bus Gateway: All incoming requests from clients are first received and processed by the Service Bus gateway. The protocol heads process the requests and perform the necessary authentication, authorization, and address resolution. The request is then forwarded to the appropriate message broker (which can reside on the same machine or remotely in another server of the farm)
  • Service Bus Message Broker: Manages the send and receive operations from Service Bus queues/topics/subscriptions, hosting one or more message containers. The service registers itself with Windows Fabric to provide high availability in this component.
  • Windows Fabric: This process contains the core logic necessary for high availability, farm and cluster formation, and internal Service Bus Message Broker balancing across computers in the farm.

High Availability for Windows Service Bus Services

High Availability for Gateway and Message broker services is achieved in different way, so let’s explain separately:

  • Gateway: This is the ‘visible’ Endpoint for Service Bus client application. Depending how client application define connection string to Service Bus Gateway:
    • Client app supports Multiple SB nodes in Connection String. The client application will try with the first one, if that node is down, the client will contact the next SB node. You achieve high availability as long as you specified all SB Nodes as connection string.
    • Client app supports just one SB Node in Connection String. If just one SB node can be specified, such as the case for BizTalk SB-Messaging Adapter, then the SB node you are pointing might become a single point of failure for your infrastructure, regardless the fact you have 3 or 5 SB nodes Farm. This is the scenario where configuring Load Balance for Service bus makes sense to achieve High Availability in this component.
    • Note: To avoid such single point of failure at Service Bus Gateway service, you should use a Virtual Service Bus name as connection string, instead of pointing directly to one of the nodes of the SB farm.
  • Message Broker : This service registers itself with Windows Fabric to provide high availability in Broker component. Windows Fabric contains the core logic necessary for high availability, farm and cluster formation, and internal Service Bus Message Broker balancing across computers in the farm. The only thing you should consider to achieve such High Availability is having 3 or 5 SB Nodes Farm.

PowerShell cmdlets to specify a Load Balance URL in Service Bus Farm

Once you have already configured a virtual name for SB Farm (such as SBFarm.contoso.com), spreading the load among all existing SB Nodes in the Farm,  then you need to execute below PowerShell cmdlets to update SB Farm configuration:

  • [1.RunOnOneNode]
    Stop-SBFarm
    Set-SBFarm -FarmDns ‘SBFarm.contoso.com’
  • [2.RunOnAllNodes]
    Update-SBHost
  • [3.RunOnOneNode]
    Start-sbfarm

From that moment on, when you execute Get-SBClientConfigurationyou will get the connection string of the Load Balance Virtual Name, instead of listing all the nodes of the farm.

Note: If you are using Custom non-wildcard Certificate for SB Farm, you might need to add Service Bus Load Balance FQN (such as SBFarm.contoso.com’) in the Subject Alternative Names property of the certificate

 

 

High Availability Vs Scalability in Windows Service Bus

The fact of having 3 or 5 SB nodes farm is a requirement to achieve High Availability, but it does not necessary means you are improving scalability. It really depends on the number of Message Containers you have.

All Service Bus for Windows Server messaging entities (queues, topics, subscriptions) are stored in containers. Each container is associated with only one database, which physically stores the entity and all of its messages. A database can serve one container. If a new container is created, a new database is created as well. When a queue or topic is created, the Service Bus for Windows Server automatically assigns that entity to a container. All messages are stored in that container’s database. All subscriptions to a topic are stored in the same container as the topic.

Each of the containers is loaded by one of the Message Brokers. The Service Bus for Windows Server attempts to distribute containers as evenly as possible between all available brokers. If a broker fails, all containers that had been loaded by the failed broker are moved to the remaining brokers. All operations that involve a particular entity are processed by the broker that has loaded the container that contains that entity

For optimal throughput, use at least as many containers as there are nodes in the farm. Note: You can check for the number of Message Containers you currently have by executing Get-SBMessageContainer cmdlet.

Hope you find this post interesting!!