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
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.
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
Post a Comment