BizTalk Server 2004 Technical Guide for High Availability

BizTalk Server 2004 Technical Guide...

Collapse All

Microsoft Corporation

September 2004

Applies to: BizTalk Server 2004

Summary: The BizTalk Server 2004 Technical Guide for High Availability contains information to help you understand, plan, and implement a highly available BizTalk Server 2004 environment. (25 printed pages)

Download sample code

References

SQL Server 2000 Failover Clustering (http://go.microsoft.com/fwlink/?LinkId=32797)

Designing and Deploying Server Clusters (http://go.microsoft.com/fwlink/?LinkId=32798)

Creating a Highly Available BizTalk Server Environment

This document describes how to provide high availability for the data and communications in Microsoft® BizTalk® Server 2004 when integrating disparate systems and applications. BizTalk Server 2004 separates the data from the hosts that process the data, enabling you to resolve availability issues by scaling the databases and hosts independently.

Demonstrating High Availability

Deployment configuration and application design have a significant impact on availability. However, high availability for BizTalk Server 2004 focuses on recovering functional components that might disrupt availability in a BizTalk Server deployment, instead of on building deployments that sustain large volumes of peak throughput.

To demonstrate high availability in BizTalk Server 2004, you do not have to send millions of messages to measure the product's effectiveness in sustaining heavy workload and preventing failure. Instead, you have to apply failure and measure the product's effectiveness in recovery. A highly available BizTalk Server deployment makes errors and failures transparent to external applications and systems, and makes sure that all services continue functioning correctly with minimal disruption.

Designing for High Availability

Designing a BizTalk Server 2004 deployment that provides high availability involves implementing redundancy for each functional component involved in an application integration or business process integration scenario. BizTalk Server 2004 simplifies the implementation of these scenarios by conceptually separating the data from the hosts that process the data. So providing high availability for BizTalk Server 2004 involves running multiple host instances and clustering the BizTalk Server databases, as follows:

Architecture for BizTalk Hosts. BizTalk Server 2004 lets you separate hosts and run multiple host instances to provide high availability for key functions such as receiving messages, processing orchestrations, and sending messages. These hosts do not require any additional clustering or load-balancing mechanism because BizTalk Server 2004 automatically distributes workload across multiple computers through host instances. However, hosts running the receive handler for the HTTP, SOAP, and BizTalk Message Queuing (MSMQT) adapters require a load-balancing mechanism such as Network Load Balancing (NLB) to provide high availability.
Architecture for BizTalk Server databases. High availability for the BizTalk Server 2004 databases typically consists of two database computers configured in an active/passive server cluster configuration. These computers share a common disk resource (such as a RAID5 SCSI disk array or storage area network) and use Windows Clustering to provide backup redundancy and fault tolerance.

Note
Highly-available environments are, by nature, multi-computer environments. When configuring BizTalk Server 2004 in a multi-computer environment. You must use global domain user groups and accounts.

This document provides information about how to address high availability in each of these categories. Because BizTalk Server 2004 is built on Microsoft Windows Server™ 2003 (or Windows® 2000 Server) and Microsoft SQL Server™ 2000, make sure that you deploy these products with high availability before configuring hosts for BizTalk Server 2004. The following links include information about providing high availability for these underlying products:

Chapter 15 - High Availability Options, SQL Server Resource Kit, available at http://go.microsoft.com/fwlink/?LinkId=24431.
The Microsoft SQL Server Resource Kit covers many administrative and deployment planning areas. Chapter 15 covers planning for fault tolerance and recovery.
Microsoft Windows Server 2003 Deployment Kit, available at http://go.microsoft.com/fwlink/?LinkId=24432.
The Microsoft Windows Server 2003 Deployment Kit provides guidelines and recommended processes for designing and deploying Windows Server 2003 technologies.
Windows Server 2003 Deployment Kit: Planning Server Deployments, available at http://go.microsoft.com/fwlink/?LinkId=24433.
This book provides information about planning server storage, and information about designing and deploying file servers, print servers, and terminal servers in medium and large organizations.

Architecture for BizTalk Hosts

BizTalk Server 2004 provides great flexibility in addressing high availability because you can strategically dedicate logical hosts to run specific areas of functionality such as receiving and sending messages or processing orchestrations.

A BizTalk Host is a collection of BizTalk Server items such as adapter handlers, receive locations (including pipelines), and orchestrations. You typically group in a host items that have similar scale properties.

After you create a host (a logical container), you can add physical BizTalk Server computers (host instances) to the host. For each host, you can have only one instance of a particular BizTalk Server computer. However, you can have instances of a particular host on one or more computers, and you can have instances of different hosts on a particular computer.

Items that are contained in BizTalk Hosts can perform the following functions:

Receiving. These items do the initial processing of messages after they are picked up in a receive location. When a host contains a receiving item, such as a receive location or pipeline, it acts as a security boundary, and the message decoding and decrypting occurs in a pipeline within the host.
Sending. These items do the final processing of messages before they are sent out to the send port. When a host contains a sending item, such as a send port or pipeline, the host acts as a security boundary, and the message signing and encryption occurs in a pipeline within the host.
Processing. These items process messages based on the instructions in an orchestration.

One BizTalk Host can contain items that receive, send, and process messages. We recommend that you create different hosts for each function to create security boundaries and for easier management and scalability. In particular, we recommend that you use different hosts for processing and for receive/send operations, and that you separate trusted and non-trusted items.

For example, if you receive one message, run an orchestration, and send ten messages, you want to separate the receive and send functionality into two separate hosts because the send items will have ten times more traffic than the receive items. If you receive one message, run an orchestration, and send one message, you can think of these items as a unit of work and group them into one single host. Alternatively, you can separate them into three different hosts to increase performance and flexibility, although this also increases the management cost.

For more information about hosts and host instances, see "Managing BizTalk Hosts and Host Instances" in BizTalk Server 2004 Help (http://go.microsoft.com/fwlink/?LinkId=32936).

To provide high availability for BizTalk Hosts, you must have two or more host instances for each host in your environment (on two or more computers). By having more than one host instance for each host you make sure that if one host instance becomes unavailable, the other computers that are running instances of the same host can resume the functions of the problematic or failed host instance, and that the overall system can continue performing with minimal disruption.

Message Persistence

BizTalk Server 2004 relies heavily on SQL Server 2000 for high availability because every host involved in BizTalk Server 2004 saves messages to the MessageBox database. For example, when BizTalk Server 2004 receives an incoming message, the receive host persists it to the MessageBox database before other hosts retrieve the message for orchestration processing and sending.

If your BizTalk Server solution involves orchestration, BizTalk Server routes the message to the host that executes the business process (processing host), and saves the message to the MessageBox database after the orchestration finishes. The sending host then retrieves the message from the database before sending it to the external application through the appropriate send adapter.

Separating the Host and Database Functions

Because BizTalk Server 2004 separates the data from the hosts that process the data, one step that you can take to create a highly available environment is to separate the host functions (sending, receiving, and processing) that occur in BizTalk Server 2004 from the database functions that occur in SQL Server 2000. By separating these functions, you can independently scale the processing, sending, and receiving hosts and the databases that store the data. The runtime and database layers are related, that is, if you increase the number of BizTalk Server computers you probably have to increase the number of computers that are running SQL Server. However, there is no direct relationship between the database layer and the BizTalk layer. They are two independent layers and you can scale them out separately.

What you must do to make the hosts highly available is different from what you must do to make the databases highly available. The following sections explain what you must do to make the receiving, sending, and processing hosts highly available. For more information about how to make the database layer highly available, see "Architecture for BizTalk Server 2004 Databases" later in this document.

For deployments where BizTalk Server processes more than SQL Server processes, you can configure multiple BizTalk Server computers that use the same computer that is running SQL Server. This configuration uses the resources available on each computer. For example, if CPU or memory use runs high (more than 75 percent) on the BizTalk Server computer but runs low (less than 25 percent) on the computer that is running SQL Server, you can include additional BizTalk Server computers to distribute the workload while raising the resource utilization on the computer that is running SQL Server.

Scaled-Out Receiving Hosts

When a host contains a receiving item, such as a receive location or pipeline, it acts as a security boundary, and the message decoding and decrypting occurs in a pipeline within the host. To make the receiving hosts highly available, you must have two or more BizTalk Server computers that are running instances of each receiving host. By scaling out the receiving hosts you can guarantee availability for BizTalk Server 2004 deployments that are messaging intensive. While these deployments might perform minimal processing for orchestrations, they can route many messages of varying types with great speed and reliability.

You can enhance security and scalability in your environment by separating the receiving host from the hosts that process orchestrations and send messages because you can secure and scale each host independently of other hosts. For example, you can add two computers (host instances) to the receiving host without adding any computers to the processing or sending hosts.

Multiple Hosts for Receiving Messages

The following figure shows a BizTalk Server 2004 deployment that provides high availability for the receiving host by having two computers that are running instances of the receiving host. Note that in this figure the processing and sending hosts are not highly available.

Figure 1 Deployment in which the receiving host has two computers running instances of the receiving host

For large deployments, for scenarios dealing with multiple trading partners, and for scenarios when you use different protocols, you can spread out the receiving functionality across multiple receiving hosts. For example, you can create a host for receiving messages for each adapter, or different hosts for receiving messages from different partners. When you create multiple receiving hosts you can create security boundaries and ease the manageability and scalability of your environment; however, it does not make your environment highly available.

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.

The following figure shows a highly available three-computer BizTalk Server environment with hosts dedicated to receiving messages from different companies.

Figure 2 Three-computer environment

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.

Scaling the BizTalk Server 2004 Receive Adapters

Besides host instances, the process of scaling and providing high availability for the receive hosts also depends on the specific adapters that you implement in your deployment. Each adapter has protocol-specific characteristics that make planning and deployment different in each case. However, BizTalk Server 2004 lets you apply the same high-availability solution for all adapters, primarily through additional computers and host instances.

Depending on the specific protocol being used, some receive adapters require an additional mechanism for distributing incoming messages among multiple host computers to provide high availability. For example, BizTalk Server 2004 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. The following table summarizes the high-availability guidelines for the most common adapters in BizTalk Server 2004.

Table 1 High availability guidelines for common adapters

Adapter	High-availability guidelines
HTTP	Add multiple computers to the receive host and configure NLB to distribute incoming messages across the multiple host computers.
Web services	Add multiple computers to the receive host and configure NLB to distribute incoming messages across the multiple host computers.
File	Add multiple computers to the receive host with the receive location on each host computer referencing the same file folder or Universal Naming Convention (UNC) path. For a complete highly available solution, you must make sure that the file location to which the UNC path points is highly available (or at least reliable).
SQL	Add multiple computers to the receive host with the receive location on each host computer referencing the same database table.
BizTalk Message Queuing (MSMQT)	Add multiple computers to the receive host and configure NLB for fault tolerance.
FTP	Add multiple computers to the FTP receive host with only one active host instance. When a failure occurs, manually start the second host instance or use the sample script described below.
SAP	Add multiple computers to the receive host for this adapter and configure an active/active node with the database running on one node and the central instance of the R/3 system running on the other node.
MQSeries	Add multiple computers to the receive host for this adapter, use clustered queue managers in MQSeries for Windows, and cluster the MQSeries Server for Windows.

HTTP Adapter

The HTTP receive adapter in BizTalk Server 2004 is an Internet Server API (ISAPI) extension (BTSHTTPReceive.dll) that runs as a host instance on each receive host computer. When a partner sends a message to BizTalk Server through the HTTP protocol, the message typically arrives at a specific URL on a BizTalk Server computer with Internet Information Services (IIS) installed. You create a host instance in BizTalk Server with a receive location that subscribes to this URL. When messages arrive at the URL, BizTalk Server retrieves them and persists them in the MessageBox database.

BizTalk Server 2004 provides high availability for the HTTP receive adapter by letting you create multiple host instances of the same receive host. These host instances subscribe to a specific URL that can be a shared, cluster IP address if you are using NLB to distribute incoming messages across multiple receive hosts. These hosts all function to serve the virtual IP address of the cluster, so that if one cluster member fails, others can still serve this IP address.

Web Services Adapter

Unlike the HTTP receive adapter, the receive adapter for Web services does not involve an ISAPI extension. It receives incoming messages through a URL that you specify by using the BizTalk Web Services Publishing Wizard. This wizard exports a Web service and creates a virtual directory that functions as the receive location.

To provide high availability for the Web services adapter, add multiple computers to the receive host and use NLB to distribute incoming messages. When a client sends a message to BizTalk Server through the Web services adapter, NLB load balances the message to one of the receiving hosts, and the appropriate host instance running on the host persists the message to the MessageBox database.

File Adapter

The File receive adapter retrieves messages from a file folder or UNC path. This adapter is frequently used within companies instead of in business-to-business scenarios because both parties require permissions to the path, and companies do not typically share file systems. You configure the File receive handler to subscribe to the path so that BizTalk Server retrieves the message when it arrives at the receive location.

BizTalk Server 2004 provides high availability for the file receive adapter by letting you create host instances on multiple host computers that subscribe to the same UNC path. If a host instance running on one host computer encounters errors or fails, the same host instance running on another host computer can retrieve the message and persist it to the MessageBox database.

SQL Adapter

The receive handler for the SQL adapter checks a database table in SQL Server 2000 for incoming messages by running a query or stored procedure. When clients send a message to BizTalk Server through the SQL adapter, the receive handler retrieves the message from the database table and persists it in the MessageBox database.

For high availability, create multiple host instances of the same receive handler across multiple host computers. To provide high availability for the database table, use Windows Clustering to cluster two database computers that are running SQL Server 2000.

BizTalk Message Queuing Adapter

The BizTalk Message Queuing adapter (MSMQT) involves partners sending messages directly to Message Queuing (also known as MSMQ) queues on the BizTalk Server computers. To provide high availability for the BizTalk Message Queuing adapter, add multiple BizTalk Server computers to the host running BizTalk Message Queuing, and configure a load-balancing mechanism to distribute incoming messages across the multiple host instances.

Because the BizTalk Message Queuing adapter guarantees in-order message reliability, only one host instance at a time can service a single BizTalk Message Queuing queue for a specific client. BizTalk Message Queuing can load-balance a single queue, but only for many clients. If only one client is connected, then load balancing acts only as fault tolerance. If many clients are communicating to the same queue, the client-queue pair is both load balanced and fault tolerant. So a load-balancing mechanism such as NLB actually provides fault tolerance in this case because the additional computers function as backups for the computer that is servicing the queue. (The host instances running on each computer do not service the queue at the same time.)

SAP Adapter

SAP supports a configuration based on a two-node cluster in an active/active configuration. The database runs on one node and the central instance of the R/3 system runs on the other node. If a failure occurs, the surviving node continues to provide both services: database and central instance. Windows Clustering monitors the R/3 and database resources for failure and switches over services if a failure occurs.

MQSeries Adapter

The Microsoft BizTalk Adapter for MQSeries serves as a bridge between BizTalk Server 2004 and IBM MQSeries servers. To provide a highly available solution when you use this adapter, you must have multiple instances of the host running the MQSeries adapter, use clustered queue managers in MQSeries for Windows, and cluster the MQSeries Server for Windows. For more information about clustering the queue manager and clustering the MQSeries Server, see the IBM WebSphere MQ documentation. For more information about making the MQSeries adapter highly available, see "High Availability" in Microsoft BizTalk Adapter for MQSeries Help.

FTP Adapter

While you can have two or more host instances of the host running the FTP adapter and the EDI adapter, these adapters support only one host instance running at a time. Therefore, if the server hosting the active host instance for the FTP adapter or the EDI adapter fails, you must manually start a host instance in one of the available BizTalk Servers. You can add the sample script BTSAdapterAvailability.vbs that you downloaded with this document to the Task Scheduler to run every few minutes to monitor the status of the main host instance. If this host instance becomes unavailable, the script starts the host instance in the second server. You can also create a Microsoft Operations Manager event that automatically starts the second host instance when the first host instance becomes unavailable.

Important
While the use of the script BTSAdapterAvailability.vbs will help you start a second host instance when the first host instance becomes unavailable, this is not a highly available solution. You must thoroughly test this script in your test environment before determining whether to use it in your production environment.

Note
We recommend that you run the Task Scheduler and the script on a different computer from the computer running the BizTalk host instances.

Scaled-Out Processing Hosts

A scaled-out processing host improves performance and provides high availability by isolating orchestration functionality onto two or more separate host computers. This isolation lets you add multiple computers to a processing host for redundancy. A processing host in BizTalk Server 2004 runs one or more host instances that coordinate various business processes and creates an instance of programmatic objects for orchestrations.

The following figure shows a BizTalk Server 2004 deployment that provides high availability for the processing host by having two computers that are running instances of the processing host. Note that in this figure the receiving and sending hosts are not highly available.

Figure 3 Deployment in which two computers are running instances of the processing host

In this configuration, the work for processing orchestrations is load balanced between two BizTalk Server computers that have instances of the processing host and run independently of each other. If one computer encounters errors or fails, BizTalk Server automatically uses the host instance on the other computer to process remaining orchestrations.

Maintaining Orchestration State

BizTalk Server 2004 maintains orchestration state centrally in SQL Server 2000, and not locally on each BizTalk Server computer. By persisting the state in the MessageBox database, BizTalk Server overcomes the limitation of relying on a single processing host instance to process the orchestration, and lets any processing host instance process the orchestration. 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.

Scaled-Out Sending Hosts

A scaled-out sending host makes sure that the sending functionality in BizTalk Server 2004 is highly available. If you add multiple computers to a host for sending messages, you can run multiple sending host instances for redundancy and high availability.

The following figure shows a BizTalk Server 2004 deployment that provides high availability for the sending host by having two computers that are running instances of the sending host. Note that in this figure the receiving and processing hosts are not highly available.

Figure 4 Deployment showing two computers running instances of the sending host

High Availability for Sending Hosts

Sending functionality in BizTalk Server 2004 is similar to processing functionality in the sense that neither of these activities requires any association between host and data. Just as any processing host instance can retrieve messages from the MessageBox database and process them, any sending host instance can retrieve messages from the MessageBox database and send them. Therefore, providing high availability for the sending hosts means that you use the same techniques as for providing high availability for the processing hosts.

Architecture for BizTalk Server 2004 Databases

BizTalk Server 2004 relies heavily on SQL Server 2000 for data persistence. All other components and hosts in BizTalk Server have specific roles in the process of integrating disparate business applications (for example, receiving, processing, or routing messages), but the database computer captures this work and persists it to disk.

To provide high availability for the BizTalk Server 2004 databases, use Windows Clustering to configure two database computers that are running SQL Server 2000 to create a server cluster. This server clustering provides redundancy and fault tolerance for the BizTalk Server 2004 databases. Unlike load-balanced clustering, where a group of computers functions together to increase availability and scalability, server clustering typically involves a pair of database computers in an active/passive configuration so that one computer provides backup resources for the other.

The following figure shows a BizTalk Server database tier with high availability through active/passive server clustering.

Figure 5 Highly-available database tier with active/passive server clustering

If the active database computer encounters errors or fails, the passive computer becomes active and assumes control over the database resources until the failed computer is repaired. The database service fails over and restores data connections to the new active computer and enables the BizTalk Server application to continue functioning.

BizTalk Server 2004 Database Characteristics

The following table shows typical usage characteristics for the BizTalk Server 2004 databases.

Table 2 Typical usage characteristics for BizTalk Server 2004 databases

Database	Default database name	Usage characteristics
Configuration database	BizTalkMgmtDb	This database handles low-usage read and write operations.
MessageBox database	BizTalkMsgBoxDb	This database handles high-usage read and write operations.
Tracking database	BizTalkDTADb	This database handles potentially high-usage write operations depending on the amount of data that you configure to be tracked, and low-usage read operations.
Credential database	SSODB	This database handles low-usage read and write operations.
BAM Analysis database	BAMAnalysis	This SQL Server Analysis Services database handles potentially high-usage read and write operations, depending on the level of monitoring performed.
BAM Star Schema database	BAMStarSchema	This SQL Server Analysis Services database handles potentially high-usage read and write operations, depending on the level of monitoring performed.
BAM Primary Import database	BAMPrimaryImport	This SQL Server Analysis Services database handles potentially high-usage read and write operations, depending on the level of monitoring performed.
BAM Archive database	BAMArchive	This SQL Server Analysis Services database handles potentially high-usage read and write operations, depending on the level of monitoring performed
Rule Engine database	BizTalkRuleEngineDb	This database handles potentially low-usage read and write operations, unless you update the rules.
Human Workflow Services Administration database	BizTalkHwsDb	This database handles potentially high-usage read and write operations, depending on the level of workflow implemented.
BizTalk Base EDI database	BizTalkEDIDb	This database handles low-usage read and write operations.
Trading Partner Management database	TPM	This database handles low-usage read and write operations.
Tracking Analysis Services database	BizTalkAnalysisDb	This SQL Server Analysis Services database handles high-usage read and write operations.

BizTalk Server runtime operations typically use the first four databases (Configuration database, MessageBox databases, Tracking database, and Credential database). Depending on the traffic on these databases, you can put them on separate computers that are running SQL Server 2000.

Depending on the BizTalk Server functionality that you use, you may have some or all of the other databases in the table. You can scale out and cluster these databases as needed.

Make sure that you follow good SQL Server deployment practices, such as using separate disks for each database. For more information about SQL Server deployment best practices, see the SQL Server 2000 Resource Kit (http://go.microsoft.com/fwlink/?LinkId=34265).

For information about backing up your BizTalk Server 2004 databases, visit http://go.microsoft.com/fwlink/?linkid=32937.

Scaled-Out Databases

To provide high availability for the BizTalk Server 2004 databases, configure two computers that are running SQL Server 2000 in a Windows cluster. These computers can run in an active/active or active/passive configuration for redundancy and store data on a shared drive (such as a RAID5 SCSI disk array) or storage area network (SAN).

If the SQL Server service becomes unavailable for any reason, the database cluster transfers resources from the active computer to the passive computer. During this failover process, the BizTalk Server service instances experience database connection failures and automatically restart to reconnect to the databases. The functioning database computer (previously the passive computer) begins processing the database connections after assuming the resources during failover.

Running Multiple MessageBox Databases

To enhance the scalability of the BizTalk Server 2004 databases, you can configure BizTalk Server to store data across multiple MessageBox databases. You create the first MessageBox database when you run the Configuration Wizard. This MessageBox database is the master MessageBox database. There is a single master MessageBox database in your BizTalk Server deployment. The master MessageBox database contains the master subscription information and routes messages to the appropriate MessageBox database. Typically, you want to dedicate the master MessageBox to do routing only (select Disable new message publication) and let the other MessageBox databases do the processing.

When the master MessageBox database receives a new activation message—a brand new instance of a business process or a subscription message—the master MessageBox database distributes the activation message to the next available MessageBox database. For example, if you have one master MessageBox database and two MessageBox databases, the master MessageBox database routes the first activation message to MessageBox database 1, the second activation message to MessageBox database 2, the third activation message to MessageBox database 1, and so on in a round-robin pattern. The master MessageBox database uses built-in logic to load balance, and does not need additional load-balancing mechanisms.

After the master MessageBox database routes the activation message to a particular MessageBox database (for example, MessageBox database 1), the business process goes into memory and runs. If the business process has to wait for a message, and the wait time is longer than several seconds, the business process is persisted back into MessageBox database 1. The business process is waiting for a correlation message. When the correlation message arrives at the master MessageBox database, the message does a lookup operation in the database for the MessageBox database that contains the state for the correlation message (in this example, MessageBox 1). The master MessageBox database then delivers the message to the MessageBox database that contains the business process. The business process is then brought back into memory to continue processing until it finishes or until it has to wait for another correlation message.

BizTalk Server stores all the states in the MessageBox databases, and each MessageBox database contains state information for different business processes. For reliability, you must cluster all the MessageBox databases, including the master and secondary MessageBox databases.

To configure multiple MessageBox databases, you use the BizTalk Administration console to add the computers that are running SQL Server 2000. For more information, see "Adding a New MessageBox Database" in BizTalk Server 2004 Help. From an administration perspective, you only have to add new MessageBox databases. BizTalk Server automatically handles the round-robin distribution of activation messages and sends correlation messages to the correct MessageBox databases.

If you have to set a MessageBox database computer offline for maintenance, you can disable new message publication on that computer through the BizTalk Administration console. Messages will continue to go to that MessageBox database until all instances are completed, while any new messages are routed to the other MessageBox databases where new message publication is enabled.

Behavior of MSMQT When Disabling New Message Publication

While most adapters follow the behavior described earlier in this topic, the BizTalk Message Queuing Adapter (MSMQT) behaves differently when you disable new message publication on the MessageBox database that the adapter uses. Its behavior for processing inbound and outbound messages is as follows:

Inbound. When the BizTalk Message Queuing adapter receives an inbound message, BizTalk Server routes the message to its subscribers. The subscribers can be one or more business process instances or send ports. When BizTalk Server posts an incoming BizTalk Message Queuing message, it routes the message to the subscribers and not to the BizTalk Message Queuing instance that was created upon receipt of the first BizTalk Message Queuing message on a particular queue from a particular client. If you disable new message publication on a MessageBox database, BizTalk Server creates new business process instances for the incoming messages on the remaining publishing-enabled MessageBox databases.
However, BizTalk Message Queuing also posts some internal messages to itself to manage its own state information. BizTalk Server continues to post these messages to the BizTalk Message Queuing instance that resides on the disabled MessageBox database. These internal messages are separate from the actual business message.
Outbound. If the message is routed through BizTalk Message Queuing to a remote Windows Message Queuing or BizTalk Message Queuing queue, BizTalk Server first posts the message in a MessageBox database under the identity of a BizTalk Message Queuing instance, and the BizTalk Message Queuing adapter receives these messages from this MessageBox database and sends them to the remote queue. For each outgoing queue, BizTalk Server creates one BizTalk Message Queuing instance in the MessageBox database that handles all outgoing messages for that queue. Therefore, after BizTalk Server creates such an instance on a MessageBox database, BizTalk Server continues to post all outgoing messages for that queue on that MessageBox database, even if you disable message publishing on that MessageBox database.
If there is no traffic to the outgoing queue for 24 hours, BizTalk Message Queuing deletes the instance from the MessageBox database and re-creates it when the next message arrives. Therefore, if you disable MessageBox database publication and there is no activity for 24 hours, BizTalk Server starts to post new messages to the enabled MessageBox databases only.

Providing High Availability for Multiple MessageBox Databases

While adding MessageBox databases to your BizTalk Server 2004 deployment improves scalability, it does not provide high availability because each MessageBox database is unique and independent. To add redundancy involves configuring a server cluster for each MessageBox database, or an active/active/active/passive cluster configuration. BizTalk Server distributes data across the multiple MessageBox databases, so the databases do not share data or otherwise provide redundancy without server clustering.

Providing High Availability for the BizTalk Tracking Database

Depending on the requirements of your particular deployment, you might want to enhance performance for tracking by isolating the BizTalk Tracking database onto a separate SQL Server 2000 computer and by creating a separate BizTalk Host dedicated to host tracking. If your deployment has high throughput and involves tracking lots of data for these messages, the tracking overhead could potentially consume lots of resources on the computer that is running SQL Server. If this situation occurs and a high rate of incoming messages continues, BizTalk Server 2004 reaches a point where it cannot process new messages because the resources required to track messages are greater than the resources required to run the other BizTalk Server components (such as receiving messages and persisting them to the MessageBox database).

To improve performance and security, we recommend that you dedicate a host for tracking that does not contain any other items (such as receive locations, orchestrations, or pipelines) and that you disable tracking from the receiving, processing, and sending hosts. To provide high availability for the tracking host, create more than one host instance of the tracking host.

For each MessageBox database, BizTalk Server 2004 uses only one tracking host instance to move messages from the MessageBox database to the BizTalk Tracking database (BizTalkDTADb). If additional computers run instances of the tracking host, BizTalk Server automatically scales out the handling of each MessageBox database to a separate instance of the tracking host. If the number of MessageBox databases is larger than the number of tracking host instances, one or more tracking host instances will service more than one MessageBox database.

To provide high availability for the BizTalk Tracking database, use Windows Clustering to configure two database computers that are running SQL Server 2000 in an active/passive configuration.

Providing High Availability for the BAM Databases

Business Activity Monitoring (BAM) provides visibility into business processes independent of the IT implementation or across a heterogeneous IT implementation. The BAM SQL Server databases (BAM Star Schema database, BAM Primary Import database, and BAM Archive database) and the BAM Analysis database store the business activity data that is different from the operational monitoring data. To make sure your BAM infrastructure is highly available, do the following:

Cluster the BAM Primary Import database and the BAM Analysis database. The BAM Primary Import database is the center of the Business Activity Monitoring system. It is therefore important that you make this database highly available by using Windows Clustering and that you follow the next two recommendations to prevent this database from filling up. The BAM Analysis database is an Analysis Services database that stores the data that business analysts use to build activity aggregations and OLAP cubes, and therefore any downtime of this database affects their productivity. While you do not have to cluster the BAM Archive database, we recommend that you monitor the event log for errors when the Data Transformation Services (DTS) packages run to make sure the data has been transferred successfully, and to monitor the size of the database so that you can replace it before it fills up.
Define an online window. To allow for greater performance and avoid downtime, BAM partitions the data in the BAM Primary Import database into tables based on the timestamp when the activity was completed. BAM achieves this by regularly swapping the completed table with another empty table of identical format. After BAM does this, the additional completed activities go into the new partition (table), while BAM keeps the old partitions for the time defined in the online window. You must define an online window to make sure the number of partitions in the BAM Primary Import database does not grow too large. For more information about scheduling online windows, see "Archiving Primary Import Database Data" in BizTalk Server 2004 Help.
Schedule DTS packages to run periodically. Defining an online window makes sure your BAM Primary Import database does not fill up with old activity partitions. You must also schedule DTS packages to run periodically to create a new partition for the activity data and to move the data from the old partitions in the BAM Primary Import database into the BAM Archive database. For more information about scheduling DTS packages, see "Scheduling the DTS Packages" in BizTalk Server 2004 Help.
Carefully choose small sets of data items (checkpoints), and avoid including unnecessary data items when defining an activity.
When you design your aggregations, understand the trade-offs between scheduled and real-time aggregations. Real-time aggregations are automatically maintained by SQL Server triggers and have zero latency. It is ideal for some mission-critical low-latency scenarios, but it incurs a performance cost whenever the events are being written to the BAM Primary Import database. Scheduled aggregations rely on scheduled cubing DTS packages to update its aggregation data. Its latency is equal to or greater than the DTS schedule interval, but overall it has a smaller performance impact on the BAM Primary Import database.
If you choose scheduled aggregations, make sure you schedule the cubing DTS to run more frequently than the archiving DTS, because the archiving DTS will not move the activity data that has been processed for scheduled aggregation to the BAM Archive database.
Enable the BAM Event Bus Service in multiple computers to obtain failover functionality.

Providing High Availability for the Other BizTalk Server Databases

To provide high availability for the other BizTalk Server 2004 databases, configure two computers that are running SQL Server 2000 in a Windows cluster. These computers can run in an active/active or active/passive configuration for redundancy and store data on a shared drive (such as a RAID5 SCSI disk array) or storage area network (SAN).

Clustering the BizTalk Server Databases

This section provides guidelines for deploying a Microsoft BizTalk Server 2004 solution with high availability. If the BizTalk Server databases become unavailable, the BizTalk Server environment will not function correctly. To provide high availability, you can create a Microsoft SQL Server cluster for the BizTalk Server databases, as shown in the following figure.

Figure 6 SQL Server cluster created for the BizTalk Server databases

To create a highly available solution for the BizTalk Server databases, you must have at least two computers that are running SQL Server and a shared disk array in the cluster.

Procedures for Clustering the Databases

Before you start

When you create the domain groups for your BizTalk Server environment, you must create global domain accounts.
Configure the SQL Server cluster before you install and configure BizTalk Server 2004. For more information about clustering SQL Server, see SQL Server 2000 Failover Clustering (http://go.microsoft.com/fwlink/?LinkId=32797).
If you are also clustering the master secret server, configure that server first. For more information about high availability for Enterprise Single Sign-On, see "High Availability for Enterprise Single Sign-On" in this document.

To run the BizTalk Server 2004 Configuration Wizard

Install BizTalk Server 2004 on a runtime server.
Run the Configuration Wizard.

On the Configuration Options page, do the following:

Use this	To do this
Do you want to create or join a BizTalk Server group?	Select Yes from the drop-down list if this is the first BizTalk Server (has the BizTalk Server runtime installed) that you are configuring. Otherwise select No.
Will this Single Sign-On server (SSO) hold the master secret key?	Select Yes from the drop-down list if this is the first server you are configuring, and if you are not clustering the master secret server. Select No from the drop-down list If you already configured the master secret server. Important You must have already configured the clustered master secret server. If you did not configure it, and the master secret server will be a stand-alone server, cancel the Configuration Wizard and configure that server first.
Do you want to create a BizTalk Host Application?	Select No from the drop-down list. Note To create a highly available solution, you will create the BizTalk Hosts in the BizTalk Administration console after you complete the Configuration Wizard.
Do you want to create a BizTalk Isolated Host Application?	Select No from the drop-down list. Note To create a highly available solution, you will create the BizTalk Hosts in the BizTalk Administration console after you complete the Configuration Wizard.
Do you want to create an Analysis database drop-down list for tracking aggregations?	Select Yes from the drop-down list if you installed and clustered Analysis Services and want to create an analysis database for aggregated tracking data.
Do you want to use an Analysis Server for BAM aggregations?	Select Yes from the drop-down list if you installed and clustered Analysis Services and want to create an analysis database for Business Activity Monitoring.
Is a Rule Engine database already configured for the BizTalk Server group?	Select Yes from the drop-down list if you have already created and configured a Rule Engine database. Select No if you have to create and configure a Rule Engine database now.

Click Next.

On the Windows accounts page, review the Microsoft Windows accounts for the BizTalk Server environment (credentials). By default, the Windows accounts are local. You must change these accounts to domain groups and user accounts in a multi-computer environment. Click Edit to make changes or click Next to continue.

Important
A domain administrator must create the domain groups and user accounts before you run the Configuration Wizard. We recommend that they create global domain groups.

If you installed Business Activity Services, on the Addresses page, review the URL location, and then click Edit to make changes or click Next to continue.
On the Configuration property values page, review the configuration names, and then click Edit to make changes or click Next to continue.
On the Database configurations page, enter the location of BizTalk databases as follows: \\SQLClusterName\BizTalkDatabaseName, where SQLClusterName is the name of the SQL Server cluster resource.
On the Windows Service Configurations page, click Next if there are no insufficient configuration icons. Otherwise, select any item that has an insufficient configuration icon and do the following:
1. Click Edit to configure your Windows Service settings.
2. In the User name drop-down list, click Browse. The Select User window appears.
3. In the Look in drop-down list, select the domain and user that the service will run as and then click OK.
4. In the Password text box, enter the password for the user account you selected, and then click OK.
On the BizTalk Messaging page, click Next.
On the Windows SharePoint Services Site Configuration page, configure the Windows SharePoint Services site for Business Activity Services (BAS), and then click Next.
On the Summary page, review the components to be configured, click Save to save the configuration XML, and then click Next. Configuration begins as shown on the Configuration Progress page.
On the Configuration completed page, click Logfile to view the log file, and then click Finish.

Sample BizTalk Server High-Availability Scenarios

This section describes the scenarios in Microsoft® BizTalk® Server 2004 that provide high availability through scaled-out tiers of hosts. By separating areas of functionality into different hosts and tiers in BizTalk Server 2004, administrators can provide redundancy for each host and scale them independently of other hosts. To provide high availability for each functional area, you create separate hosts for each primary function—receiving, processing, sending, and tracking—and cluster the BizTalk Server 2004 databases. For a BizTalk Server 2004 solution that provides complete high availability, you must also cluster the master secret server.

Small BizTalk Server 2004 Deployments

The smallest available BizTalk Server 2004 deployment is made up of two computers that have an active/active cluster configuration for SQL Server 2000. Both computers contain instances of all the BizTalk Hosts in the environment. If one computer fails or encounters errors, the other computer maintains service availability for both SQL Server and BizTalk Server. This configuration is not highly available because you cannot cluster the master secret server. For more information about clustering the master secret server, see "High Availability for Enterprise Single Sign-On" in this document.

For small BizTalk Server 2004 deployments that contain fewer than five computers, we recommend that the SQL Server cluster that contains the BizTalk Server databases runs on separate computers from the BizTalk Server computers. The BizTalk Server computers can run all the BizTalk Hosts (receive, process, and send). To make this deployment highly available, cluster the SQL Server, and have two BizTalk Servers, each running an instance of each host in your environment.

The following figure shows a small BizTalk Server deployment that is highly available.

Figure 7 Small BizTalk Server deployment that is highly available

Medium-Sized BizTalk Server 2004 Deployments

For medium-sized deployments that contain five to ten computers, we recommend that you cluster the SQL Server that contains the BizTalk Server databases. If your scenario is receive-intensive, you may want to dedicate two BizTalk Servers to run the receiving host instances to provide a highly available solution. You can then have two more computers that are running both the processing and send host instances. To make this a highly available deployment, create host instances of both the processing and send hosts on two BizTalk Servers. Similarly, if you have a processing-intensive scenario, you may want to dedicate two BizTalk Servers to run the processing host instances, and have the remaining two BizTalk Servers running instances of both the receive and send hosts.

The following figure shows a highly available medium-sized BizTalk Server deployment with two BizTalk Servers dedicated to receiving operations.

Figure 8 Medium-sized BizTalk Server deployment that is highly available

For more information about high availability for Enterprise Single Sign-On, see "High Availability for Enterprise Single Sign-On" in this document.

Large-Scale BizTalk Server 2004 Deployments

For large-scale deployments that contain 10 or more computers, dedicate separate BizTalk Server computers for the receiving, processing, and sending functions. Also, if you have many BizTalk Server computers in a group, you can include additional MessageBox database computers to increase performance. In this case, cluster the MessageBox databases to provide high availability.

Such a distributed configuration demonstrates the flexibility of BizTalk Server 2004 because it lets you to evaluate and identify specific points of failure in your deployment, and then strategically allocate resources to reduce those points in the system. Today's dynamic business environment demands such flexibility because workload fluctuations and business requirements can change daily.

Instead of spending additional money to upgrade or acquire new hardware, you can use existing resources to achieve high availability by moving resources from computers that consume few resources to computers that are resource-intensive.

The following figure shows a large-scale BizTalk Server 2004 deployment.

Figure 9 Large-scale BizTalk Server 2004 deployment

For more information about high availability for Enterprise Single Sign-On, see "High Availability for Enterprise Single Sign-On" in this document.

Configuring BizTalk Server on an Existing Windows Cluster

We recommend separating the Microsoft® BizTalk® Server 2004 runtime resources (host instances) from the database resources, and providing high availability for these resources separately. For example, you might use two computers for a database server cluster and two BizTalk Server computers for the host instances.

However, if BizTalk Server is running on the same computer as a resource that has to be clustered (for example, Windows Message Queuing or a custom adapter), or if hardware constraints force you to install BizTalk Server on the same computers as your Microsoft SQL Server™ cluster, you cannot configure BizTalk Server as a cluster resource in a server cluster. You must install BizTalk Server as a stand-alone resource on each cluster node.

You achieve high availability for the BizTalk Server runtime resources by having host instances of all hosts in two or more BizTalk Server computers. Clustering the BizTalk Server runtime is not supported.

Installing BizTalk Server in a Server Cluster

The BizTalk Server service (host instance) is not cluster aware. However, you can install BizTalk Server independently (running as a non-clustered resource) on each node of a server cluster.

The BizTalk Server 2004 service (runtime) has a hard dependency on the Enterprise Single Sign-On (SSO) service. In other words, the SSO service must be installed locally on all computers that have the BizTalk Server runtime installed.

Therefore, if you want to install the BizTalk Server runtime on the nodes of a server cluster, you must install both BizTalk Server and SSO as non-cluster resources.

In an active/active cluster configuration, the configuration provides fault tolerance because if one computer fails the other computer can continue the work. It provides scalability, because both cluster nodes are running host instances (as non-clustered resources), but it does not provide high availability, because there is only one master secret server.

When a failover occurs, you can manually promote the SSO service on the second node to master secret server, and restore the master secret on this node. For more information about configuring an available SSO solution, see "High Availability for Enterprise Single Sign-On" in this document.

High Availability for Enterprise Single Sign-On

Even if you do not use the Enterprise Single-Sign-On (SSO) functionality for mapping credentials and single sign-on, SSO is a critical part of the overall Microsoft® BizTalk® Server 2004 infrastructure, because BizTalk Server uses SSO to help secure information for the receive locations. The BizTalk Server 2004 Installation Wizard automatically installs the SSO service on all computers where you install the BizTalk Server runtime components.

You must configure the first computer where you install the SSO service as the master secret server. The master secret server is the SSO server that stores the master secret (encryption key). The master secret is the encryption key that the SSO system uses to encrypt and decrypt the data it stores in the Credential database.

If an SSO server fails, and if you have other BizTalk Server computers (and therefore SSO servers) running the same host instance, the other SSO servers continue doing their work. This means that the master secret server still functions correctly, and therefore the BizTalk Server processing continues.

If the master secret server fails, all run-time operations that were running before it failed, including decryption of credentials, continue successfully. However, you cannot encrypt new credentials. Therefore, the BizTalk Server environment has a dependency on the availability of the master secret server, as shown in the following figure.

Figure 10 Figure showing dependency of BizTalk Server environment on availability of the master secret server

Making the Master Secret Server Available

For availability of the SSO system, and therefore of the BizTalk Server environment, it is critical that you back up the master secret as soon as it is generated. If you lose it, you lose the data that the SSO system encrypted by using that master secret. For more information about backing up the master secret, see "Backing Up the Master Secret" in BizTalk Server 2004 Help.

You can make the master secret server available in two ways:

Available, but not highly available. All the SSO servers have the master secret cached in memory, and run-time operations will continue even if the master secret server fails. However, you will not be able to change the configuration of ports or the SSO configuration. The BizTalk Server runtime will continue working without problems, but you cannot make any design changes. You can create a Microsoft Operations Manager (MOM) event to notify you when the master secret server becomes unavailable, and you can then manually promote an SSO server to master secret server and restore the master secret on this server.
Even if this configuration is not highly available, it can be satisfactory for most scenarios and it is consistent with scaling out the receiving, sending, and processing hosts.
Highly available. To provide redundancy for the master secret server, use Windows Clustering on a separate master secret server cluster, or configure the master secret server on an existing database cluster. The services provided by the master secret server do not consume many resources, and typically do not affect database functionality or performance when installed on a database cluster. The following figure shows how you can make the master secret server highly available.

Figure 11 Figure showing how you can make the master secret server highly available

While this configuration is highly available, it requires additional hardware resources. For more information about clustering the master secret server, see "Clustering the Master Secret Server" in BizTalk Server 2004 Help.

High Availability and the Microsoft Operations Framework

Applying the Microsoft Operations Framework (MOF) process model to the planning and implementation of a highly available Microsoft® BizTalk® Server 2004 solution can help you make sure that you have appropriate processes at the different stages of the release life cycle. By looking ahead at all the life cycle stages where high availability surfaces, you can make the installation, maintenance, and troubleshooting of availability issues in your environment easier.

This section contains information about the MOF processes where you have to consider high-availability tasks.

Microsoft Operations Framework Process Model

The Microsoft Operations Framework (MOF) provides guidance that enables organizations to achieve mission-critical system reliability, availability, supportability, and manageability of Microsoft products and technologies. MOF provides operational guidance in the form of white papers, operations guides, assessment tools, best practices, case studies, templates, support tools, and services. This guidance addresses the people, process, technology, and management issues pertaining to complex, distributed, and heterogeneous IT environments. For more information about the Microsoft Operations Framework, see http://go.microsoft.com/fwlink/?LinkId=31988.

The MOF process model enables companies to:

Facilitate consistent IT service management across service solutions.
Establish a structure for IT functions, processes, and procedures.
Represent a life-cycle approach.

Central to the MOF process model is its division into four quadrants of operational processes and procedures, named service management functions (SMFs). The SMFs are the foundation-level best practices and prescriptive guidance for operating and maintaining an IT environment.

The following figure shows the MOF processes where you have to consider high availability.

Figure 12 MOF processes

Changing Quadrant

The changing quadrant includes the service management functions (SMFs) required to identify, review, approve, and incorporate change into a managed IT environment. This includes changes in software, hardware, documentation, roles and responsibilities, and also specific process and procedural changes.

Change Management

Change management is responsible for changes in technology, systems, applications, hardware, tools, documentation, and processes, and also changes in roles and responsibilities.

During the change management process, as part of designing your BizTalk Server implementation, you can do the following:

Determine whether the service level agreement with your partners or customers requires a certain level of availability, uptime, and load-processing capabilities.
If you are upgrading from BizTalk Server 2000 or BizTalk Server 2002 to BizTalk Server 2004, you must determine whether your existing hardware will satisfy the minimum hardware requirements for BizTalk Server 2004 and the requirements from the service level agreement.
Determine the best cluster configuration for the BizTalk Server databases for your business needs. The run-time processes write to the BizTalk Configuration database, MessageBox databases, Tracking Analysis Services database, BAM Analysis database, BAM Star Schema database, BAM Primary Import database, and BAM Archive database. Therefore, these databases are especially important if a disaster occurs, and must have greater priority when determining what databases to cluster. Only users or tools write to the other databases. For the MessageBox databases, you can consider an active/active/active/passive four-server cluster to minimize the hardware needed.
Determine whether to cluster the master secret server, or if manually restoring the master secret on another Enterprise Single Sign-On server is satisfactory for your scenario. This solution is available, but not highly available.
Determine the number of hosts and host instances that you will need to process your expected message load and to provide high availability.
Create a list of the people that will be involved in the change-management process. This list will include, but is not limited to, the domain administrator, database administrator, infrastructure administrator, BizTalk Server administrator, and IT operations staff.

Configuration Management

Configuration management is responsible for identifying, controlling, and tracking all versions of software, hardware, documentation, processes, procedures, and all other components of the IT environment under the control of change management.

During the configuration management process, you must create a detailed plan for how you are going to implement your highly available solution for BizTalk Server 2004. You must also document the steps that you took to create your solution. At a high level, the steps are:

The domain controller creates the domain groups and accounts that you will use in your BizTalk Server environment.
The infrastructure administrator creates the Windows® cluster for the BizTalk Server databases and the Windows cluster for the master secret server.
The database administrator installs and configures Microsoft SQL Server™ 2000 on the Windows cluster for the BizTalk Server databases.
The BizTalk Server administrator configures the master secret server cluster.
The BizTalk Server administrator installs and configures BizTalk Server 2004 on the processing, receiving, and sending servers.
The BizTalk Server administrator creates the hosts and installs the host instances on the appropriate servers to provide high availability or to increase capacity, or both.

Operating Quadrant

The operating quadrant includes the SMFs required to monitor, control, manage, and administer service solutions daily to achieve and maintain service levels within predetermined parameters.

Job Scheduling

Job scheduling involves the continuous organization of jobs and processes in the most efficient sequence, maximizing system throughput and use to meet service level agreement requirements.

Make sure that you schedule planned downtime, such as scheduled updates, at times when the message load is low (for example, late at night) to minimize the potential effect on your business.

Supporting Quadrant

The supporting quadrant includes the SMFs required to identify, assign, diagnose, track, and resolve incidents, problems, and requests within the approved requirements that are contained in the service level agreements.

Optimizing Quadrant

The optimizing quadrant includes the SMFs that contribute to maintaining business and IT alignment by focusing on decreasing IT costs while maintaining or improving service levels. This includes review of outages and incidents, examination of cost structures, staff assessments, availability and performance analysis, and capacity forecasting.

Service Level Management

The goal of service level management is to maintain and continuously improve the quality of IT service, through a constant cycle of negotiating and monitoring service level requirements. The successful service level management function causes an improvement in quality of service, greater levels of customer productivity, and ideally, a reduction in the overall cost of services provided.

During the service level management process, you can do the following:

Evaluate how the current environment satisfies your service level agreement requirements.
Recommend the addition of new servers for processing, receiving, or sending messages to meet the requirements.
If necessary, recommend creating highly available solutions for points of failure that were not originally mitigated to meet the availability requirements in the service level agreement.

Availability Management

The single goal of availability management is to make sure that your customers can use a particular IT service whenever they want.

For the availability management process, you can establish mechanisms for notifying IT personnel when a hardware failure occurs so that they can fix or replace the hardware as quickly as possible, and mechanisms for notifying IT personnel when the server load is larger than a particular threshold.

Service Continuity Management

The objective of the service continuity management function is to make sure that a specified IT service provides value to the customer if regular-availability solutions fail.

During the service continuity function you must examine what high-availability configuration to implement to make sure that you continue providing your customers with the services they expect even when a planned or unplanned downtime occurs. Examples of unplanned downtime are hardware failures or acts of nature.