Skip to main content

BizTalk 2010 licensing - definitive answer & technical explanation

I should note that I am posting this because a number of large companies/providers did not have any sort of clear answer for us on this, and in some cases had incorrect recommendations.  Hopefully this helps you - if anything in this post is incorrect, PLEASE comment below with your sources.

Initially
We went back and forth for months on this...are you SURE we need Enterprise?  Cuz Enterprise is super duper expensive (STD=10k, ENT=75k) compared to Standard.

Up until now our answer has been "Yes, you need it because Enterprise is the only version that supports clustering, and our application must have HA capabilities."  Semi-wrong!  Microsoft recommends against clustering BizTalk hosts, unless you have a technical reason for it (some adapters require clustering).  They actually recommend the 'scale out' method (moar servars!), and here is how that is done.  Note the sub-points (a,b,c) are direct quotes from MSDN.

BizTalk's 3 main functions
1. Receiving - You can 'scale out' receiving hosts, but each BZ server must run the same receiving host instance - you then put these behind a load balancer.
a. To make your environment highly available, you must create two or more host instances for each receiving host that you create. For example, you can create three different receive hosts (A, B, and C) to receive messages from three different companies. To make each of these hosts highly available you then create host instances of each of these hosts in two or more computers. Note that you can have instances of each host on one computer without losing the security boundary, manageability, or scalability.
b. To provide high availability in this configuration, each computer runs three host instances: one instance for each of the three companies. The host instances for each company contain the receive locations and pipelines to communicate with that company. During typical operations, as long as you have done the necessary work for scale out in front of the receive adapters (for example, if you configure network load balancing for HTTP), the messaging load is distributed among the three host instances for each host. If a host instance on one computer fails, the host instances running on the other two computers provide redundancy and maintain service availability.
c. For example, BizTalk Server solutions that use the HTTP or SOAP adapter (otherwise known as the Web services adapter) require a load balancer such as Network Load Balancing (NLB) to distribute the receiving workload.
2. Processing - This is dependent on the database, not BZ host, so if a host dies - the data is in the DB, not on the host - others able to pick up.
a. BizTalk Server maintains orchestration state centrally in Microsoft SQL Server, and not locally on each BizTalk Server computer.
b. If an error occurs while BizTalk Server processes an orchestration, another instance of the same processing host can complete the orchestration from the last persisted state.
3. Sending - Same idea as receiving.  i.e. If you are using the MSMQ service, that service should be clustered (not the same as clustering the BZ host).
a. Therefore, providing high availability for the sending hosts means that you use the same techniques as for providing high availability for the processing hosts.

The only caveats in this are what adapters you are using - some, like MSMQ, POP3 or FTP receive, require clustering - architecture/dev will have to confirm what adapters you are using.
"BizTalk Server provides functionality that allows you to configure a BizTalk host as a clustered resource within a Windows Server 2008 failover cluster group. Host cluster support is provided to support high availability for integrated BizTalk adapters that should not be run in multiple host instances simultaneously, such as the FTP receive handler or, under certain circumstances, the POP3 receive handler. Host cluster support is also provided to ensure transactional consistency for messages sent or received by the MSMQ adapter in scenarios that require that the MSMQ service is clustered."

Note you CAN use clustering, but ONLY IF YOU USE FAILOVER - which inherently means active/standby.  If you DO cluster, MSDTC must also be clustered (before you cluster BZ, no less).
"BizTalk Server provides functionality that allows you to configure a BizTalk host as a clustered resource within a Windows Server 2008 failover cluster group."

So if you do require clustering, you open Pandora's shared storage and have to cluster everything attached to BizTalk.

BizTalk groups
So after all this - phew! - we don't need Enterprise because we don't require clustering...right?  BZZZT.  You still want high availability & scalability, which is done via multiple host instances (servers, really, unless you have multiple BizTalk instances), which means multiple VMs/servers.  Standard Edition is limited to a single VM/server per BizTalk group, and thus cannot participate...please proceed directly to Enterprise Edition.

The ramifications of this are huge....a 'small' deployment of two BizTalk servers now costs $150k (includes SA) just in licensing, so be VERY careful when designing BizTalk into your systems.

Also, keep in mind that the SQL back-end is completely separate from BizTalk...it doesn't care if you're using Standard or a huge Enterprise cluster...just needs to be SQL.

Sources




Guess I'll have to work on the 2013 version of this...

Comments

Popular posts from this blog

DFSR - eventid 4312 - replication just won't work

This warning isn't documented that well on the googles, so here's some google fodder:


You are trying to set up replication for a DFS folder (no existing replication)Source server is 2008R2, 'branch office' server is 2012R2 (I'm moving all our infra to 2012R2)You have no issues getting replication configuredYou see the DFSR folders get created on the other end, but nothing stagesFinally you get EventID 4312:
The DFS Replication service failed to get folder information when walking the file system on a journal wrap or loss recovery due to repeated sharing violations encountered on a folder. The service cannot replicate the folder and files in that folder until the sharing violation is resolved.  Additional Information:  Folder: F:\Users$\user.name\Desktop\Random Folder Name\  Replicated Folder Root: F:\Users$  File ID: {00000000-0000-0000-0000-000000000000}-v0  Replicated Folder Name: Users  Replicated Folder ID: 33F0449D-5E67-4DA1-99AC-681B5BACC7E5  Replication Group…

Fixing duplicate SPNs (service principal name)

This is a pretty handy thing to know:

SPNs are used when a specific service/daemon uses Kerberos to authenticate against AD. They map a specific service, port, and object together with this convention: class/host:port/name

If you use a computer object to auth (such as local service):
MSSQLSVC/tor-sql-01.domain.local:1433

If you use a user object to auth (such as a service account, or admin account):
MSSQLSVC/username:1433

Why do we care about duplicate SPNs? If you have two entries trying to auth using the same Kerberos ticket (I think that's right...), they will conflict, and cause errors and service failures.

To check for duplicate SPNs:
The command "setspn.exe -X

C:\Windows\system32>setspn -X
Processing entry 7
MSSQLSvc/server1.company.local:1433 is registered on these accounts:
CN=SERVER1,OU=servers,OU=resources,DC=company,DC=local
CN=SQL Admin,OU=service accounts,OU=resources,DC=company,DC=local

found 1 groups of duplicate SPNs. (truncated/sanitized)

Note that y…

Logstash to Nagios - alerting based on Windows Event ID

This took way longer than it should have to get going...so here's a config and brain dump...

Why?
You want to have a central place to analyze Windows Event/IIS/local application logs, alert off specific events, alert off specific situations.  You don't have the budget for a boxed solution.  You want pretty graphs.  You don't particularly care about individual server states.  (see rationale below - although you certainly have all the tools here to care, I haven't provided that configuration)

How?
ELK stack, OMD, NXlog agent, and Rsyslog.  The premise here is as follows:

Event generated on server into EventLogNXlog ships to Logstash inputLogstash filter adds fields and tags to specified eventsLogstash output sends to a passive Nagios service via the Nagios NSCA outputThe passive service on Nagios (Check_MK c/o OMD) does its thing w. alerting
OMD
Open Monitoring Distribution, but the real point here is Check_MK (IIRC Icinga uses this...).  It makes Nagios easy to use and main…