BizTalk 2006 R2 , A Scaled Down Solution Explained

by Kevin Saitta

After some thought and consideration as to what my customers requirements were, I realized that we needed to come up with a scaled down BizTalk solution that would meet their needs; not only on functionality, but budget as well.

With that said, the requirements (in an extremely narrow nutshell) were as follows;

A. Keep the solution on budget.
B. Design for scalability.
C. Only allow for minimal down time with fast recovery.
D. Low initial start up cost.

I realize that the word low in point D above is ** extremely ** subjective.

With these goals in mind, this is the solution that I came up with:



A simple walk through

With security being a big concern we decided to use a dual firewall solution that would contain a DMZ and business domain (services layer). Each domain will reside in their own network segments. The business domain would have its own domain controller to further secure the network. How you ask? By allowing the business domain to have its own domain controller we reduce risk of the corporate internal network being compromised ( not pictured in diagram ). By setting up the business domain in this fashion, we secure the corporate environment in the event a security breach went unnoticed on the application side ( BizTalk / Custom Apps ) of this solution. Also, because the AD servers in this business domain do not trust any accounts in the corporate domain(s), a compromise to the external domain does not expose the internal Active Directory.

Not bad if you ask me. Wait, no one is asking, sorry about that. I keep thinking out loud.

In the DMZ zone we decided to go with a software load balancer due to cost and two secure FTP/ HTTP servers. The reason for two servers in the DMZ is so that customers will be able to send data 24/7. If one server goes down, the load balancer will serve the request to the other server which gives you the uptime needed.

The business domain is where all the magic happens. This domain consist of the BizTalk server, the clustered SQL Server which will holds all databases for the entire solution, file / application server and the SCOM server. Normally we would break the database out across different servers, but due to the budget constraints it made more sense to place everything on a shared disk array with a cluster setup in active / passive mode. This will not only save us on hardware cost but license fees as well (keeping on budget).

The SCOM server is used to monitor this solution both on the application level and server.

Next, we are going to take a look at port configuration needed for the different firewalls in this solution. I addition I will also explain the different software / servers needed. If this is a little redundant, I apologize in advance.

Firewalls

A minimum of two firewalls are required to secure the Solution.

External Facing

The external firewall must have the following ports open for communication with the end users and partners:

• Port 22 SFTP


• Port 443 HTTPS

Internal / External

The internal firewall that will interact between the business layer and the DMZ zone. The following ports will need to be open:

BizTalk

• Port 445 Receive Adapter

SQL Server

• Port 1433

SCOM

• Root/Management Server <== Port 1433 ==> Operations Manager Database


• Management Server <== Port 5723 ==> Root Management Server


• Agent <== Port 5723 ==> Management Server

Active Directory communication and Kerberos

• LDAP to Directory Service 389/UDP 389/TCP


• LDAP to Global Catalog Server 3268/TCP


• Kerberos Authentication 88/TCP 88/UDP

DNS Server Access

• DNS Lookup 53/TCP 53/UDP

For Restricting Active Directory replication traffic and client RPC traffic to a specific port please see the following link:

http://support.microsoft.com/?kbID=224196

Intranet / Corporate Firewall ( Not Pictured )

SCOM

• Operations Console <== Port 5724 ==> Root Management Server


• Web Browser <== Port 51908 ==> Web Console Server

Other ports will need to be opened depending on the services that will need to be accessed.
Remote desktop is recommended for access to the Business domain ( services layer ). By using remote desktop, you will be able to view and / or access servers in this zone.

Remote Desktop

• Port 3389

Load Balancer

A load balancer balances the load between servers, but more importantly, if one server goes down, the load balancer sends all requests to the server(s) left running. An example of hardware load balancing is BIG-IP from F5 Networks. An example of software load balancing is the Network Load Balancing Service included in Windows.

NOTE: Some Load Balancers only understand server level availability and have no understanding of the application that run on the servers. This means that if the application is unavailable the load balancer will still deliver request to the server, hence the need for a monitoring solution as SCOM and / or a load balancer that understands application level availability.

I would like to thank Lori for catching my typo as I previously left out the word SOME in the NOTE above. In addition as Lori points out hardware level load balancers now do more than balance the load. See Lori's post here http://devcentral.f5.com/weblogs/macvittie/archive/2008/06/11/3352.aspx.


SFTP Sever

These servers will allow the secure delivering of messages from the trading partners.
If you need a SFTP software stop by the following blog:
All Things IIS, contains a lot of great information in regards to SFTP and IIS.

Active Directory Server

This server hosts the Business Active Directory domain. It contains information about all the groups and individual accounts that need access to BizTalk and others Servers in the network segment.

http://www.microsoft.com/windowsserver2003/technologies/directory/activedirectory/default.mspx

BizTalk Server

This server has an installation of the BizTalk Server runtime and instances of various BizTalk Hosts. The number of BizTalk Servers in the environment depends on the type of hosts they run and the performance needs. As your performance needs increase, you can add more BizTalk Servers to your environment for host instances of your processing hosts.

http://www.microsoft.com/biztalk/en/us/default.aspx

SQL Server

These servers will hold the Application Database, BizTalk MessageBox and Enterprise Single Sign-On databases, which is the reason for the active / passive cluster to ensure you have minimal downtime.

http://www.microsoft.com/SQL/default.mspx

System Center Operations Manager 2007 (SCOM) Server

System Center Operations Manager (SCOM), formerly Microsoft Operations Manager (MOM), is a performance and event monitoring system that targets Windows systems across one or more communications networks such as Active Directory, Microsoft SQL Server, BizTalk Server and SCOM, which itself can be monitored.

http://www.microsoft.com/systemcenter/opsmgr/default.mspx

Well that is it for this blog post and I hope this gives you an idea of architecting a small solution for the BizTalk beast!

Until next time, happy architecting and coding your solutions…

One last note, remember when in front of your customers, service must be number one at all times. Customer value is what this is all about…

KDWAG out, I mean Kev...