Part 1: Infrastructure layout
Author: Paul Endras
In this article, I will demonstrate you the infrastructure layout of a BizTalk server 2016 environment with the new high availability feature AlwaysOn Availability Groups (in short AOAG) in SQL Server 2016.
Watch the whole video tutorial, including the demo:
BizTalk Server 2016 provides a new feature for high availability and disaster recovery in conjunction with SQL Server 2016.
Basically, the BizTalk Server relies heavily on database transactions for processing and storing business data. One or more instances of the SQL Server is needed to handle all that data persistency. Since SQL Server itself is based on distributed transactional processing the data consistency is guaranteed even in the case of failure.
Especially in enterprise-scale, real-time scenarios like B2B or B2C there is a need for high availability. Hence, the requirement is to avoid the cost of losing business transactions and valuable business data. This becomes a crucial point for any business.
The following topics will be covered:
1.Benefits of using AOAG with BizTalk Server 2016
So what are the benefits of AOAG in SQL Server 2016 when used together with BizTalk Server 2016 ?
Here are some of the most relevant aspects about AOAG and why you should use them with BizTalk Server 2016:
- The business data as well as processing data is kept redundant. This behavior takes place in real time, with nearly no costs at the level of the database.
- The windows failover cluster service can host the SQL database instances and provide automatic failover in case of failures.
- Since data is kept redundant, multiple instances of the database are hosted and can be used also for read-only purposes like database backup and reporting.
2.Real world scenarios
The real-world scenarios provide plenty of reasons why failures could happen.
Therefore, we can distinguish:
- Planned scenarios (e.g. maintenance work), or
- Unplanned scenarios (e.g. power failure)
The failure might affect different levels within the operational stack:
- Service layer
- Infrastructure layer (e.g. network, storage)
- Data layer
3.High availability options within the BizTalk Server 2016 environment
There are several approaches.
Within the Windows Server 2016 platform we can make use of the Failover Clustering feature right out-of-the-box. The concept of the failover cluster in Windows Server dates to the days of Windows NT 3.5. Since than the Windows failover cluster made tremendous improvements and now supports newer concepts like SQL Server AlwaysOn Availability Groups, that we discuss today.
- Failover on the service layer
The failover cluster feature in Windows Server 2016 covers both levels, the service layer as well as the data layer.
The classic failover cluster for application servers like SQL Server, Sharepoint Server or BizTalk Server uses failover clustering on the service / instance level. A common usage scenario is an active / passive cluster. This offers the service redundancy on all cluster nodes, where one only is serving actively while the other(s) is / are in spare and one gets active only when the active node is considered to be unavailable. There are further options and nuances, that we will not cover here in detail.
- Failover on the infrastructure layer
The Windows failover cluster provides additional cluster roles for the infrastructure layer, like network components (DHCP, DNS, DTC) as well as for other devices within your enterprise network, like the typical storage for FileShares or Archives. The concept of clustering the infrastructure layer covers both the unplanned and the planned kind of failures.
- Failover on the data layer
In following demo, I will focus on handling the risks of failures on the data layer.
For this purpose, the Windows failover cluster is used to provide a cluster role and cluster resources for the SQL Server AlwaysOn Availability Groups.
The concept of clustering the data layer covers both the unplanned and the planned kind of failures.
The aim here is to run the BizTalk Server environment with all of its applications regardless of failures on the data layer. The uptime of the whole middleware layer must be guaranteed.
Hint: The concept of AOAG in SQL Server supports also the SQL Server in virtual machines in the Azure Cloud.
4.Introduction to the demo
So lets have a closer look at the infrastructure layout for the given scenario.
Here is the big picture that summarises the server landscape:
From the bottom to the top you can see:
- The ADS Domain Server with DNS
- The Cluster Shared Disks with the Quorom-Disk
- The layer with the SQL Server Cluster Nodes, each node has several SQL instances installed for the BizTalk databases
- The BizTalk Server
I will go into the details for each and every functional server in a minute. But before, I would like to summarice the prerequisites briefly.
In the given scenario, the Windows Server was setup with all the roles and features needed. I was using the Windows Nano Server together with some Powershell scripts to quickly setup the cluster server. For the sql server instances an unattended setup with a configuration file might do a good job.
This way you have full control over the automatic creation and can reproduce the results as needed. I am not going into the details about setting up the windows failover cluster here, as we will be focusing more on the AOAG in SQL Server together with the BizTalk Server configuration.
Hint: Please follow the links below and at the end of this presentation for the basic concepts on failover cluster with Windows Server 2016.
6.The infrastructure layout
1.Active Directory Domain Server with DNS
Here you can see the infrastructure as whole with all the servers included. The foundation of this infrastructure is the Domain Controller is hosting the Active Directory. Here you can see all the different kind of accounts, e.g. users, groups, computers. An OU includes all the BizTalk Server accounts.
This server provides also the DNS role. As you can see, the DNS lists all the domain and network resources needed for the cluster, the cluster service as well as the cluster automatic update service. Keep in mind the SQL Listeners for the AlwaysOn Availability Groups are also listed here in the DNS.
2.Cluster Shared Disks including Quorum Disk
This the file server which provides the virtual iscsi – Disks. These are needed for the sql instances and for the cluster Quorum disk.
3.SQL Server Nodes (three nodes)
In this scenario, the failover cluster consists of three cluster nodes. In general, the minimum number is 2 nodes for AOAG SQL Server 2016 and the maximum is 9 nodes (=1 primary + 8 secondary) as database replicas.
Each of the BizTalk core databases needs its own instance:
- SingleSignOn database
- MessageBox database
- Management database
- Tracking database
In this example: 4 databases x 3 nodes = 12 instances
Here you can see an instance for the SingleSignOn database in the Availability Group together with its replicas from the other instances.
4.BizTalk Server (Group)
Later I will show you the actual settings for this BizTalk Server Group. The BizTalk Server Group is configured to use the SQL Listener instead of instance names. This BizTalk Server Group consists of multiple hosts and is now configured for high availability with AlwaysOn Availability Groups.
In this article, I demonstrated you a full-fledged infrastructure layout for a BizTalk Server 2016 environment using the AOAG feature in SQL Server 2016. I mentioned the options for BizTalk Server high availability, benefits of using AOAG, the prerequisites and the involved servers in the cluster solution. There are further options to scale-out the BizTalk Server, either using multiple Messageboxes or using additional processing hosts with intelligent server distribution.
In the next article, I will show you the AOAG SQL Server 2016 in detail including the most significant configuration settings.
Need more information on BizTalk Server solutions ? Contact me: email@example.com
The information given here is as is, and without any obligation or guarantees. You can use this information at your own risk.