Integration Services (SSIS) in a Cluster

Clustering Integration Services is not recommended because the Integration Services service is not a clustered or cluster-aware service, and does not support failover from one cluster node to another. Therefore, in a clustered environment, Integration Services should be installed and started as a stand-alone service on each node in the cluster.

Although the Integration Services service is not a clustered service, you can manually configure the service to operate as a cluster resource after you install Integration Services separately on each node of the cluster.

However, if high availability is your goal in establishing a clustered hardware environment, you can achieve this goal without configuring the Integration Services service as a cluster resource.  To manage your packages on any node in the cluster from any other node in the cluster, modify the configuration file for the Integration Services service on each node in the cluster. You modify each of these configuration files to point to all available instances of SQL Server on which packages are stored. This solution provides the high availability that most customers need, without the potential problems encountered when the Integration Services service is configured as a cluster resource. For more information about how to change the configuration file, see Configuring the Integration Services Service (Legacy SSIS Service)

Understanding the role of the Integration Services service is critical to making an informed decision about how to configure the service in a clustered environment. For more information, see Integration Services Service (Legacy SSIS Service).

Understanding the Disadvantages of Configuring Integration Services as a Cluster Resource

Some of the potential disadvantages of configuring the Integration Services service as a cluster resource include the following:

• When a failover occurs, running packages do not restart. You can recover from package failures by restarting packages from checkpoints. You can restart from checkpoints without configuring the service as a cluster resource. For more information, see Restart Packages by Using Checkpoints.

• When you configure the Integration Services service in a different resource group from SQL Server, you cannot use Management Studio from client computers to manage packages that are stored in the msdb database. The Integration Services service cannot delegate credentials in this double-hop scenario.

• When you have multiple SQL Server resource groups that include the Integration Services service in a cluster, a failover could lead to unexpected results. Consider the following scenario. Group1, which includes the SQL Server service and the Integration Services service, is running on Node A. Group2, which also includes the SQL Server service and the Integration Services service, is running on Node B. Group 2 fails over to Node A. The attempt to start another instance of the Integration Services service on Node A fails because the Integration Services service is a single-instance service. Whether the SQL Server service that is trying to fail over to Node A also fails depends on the configuration of the Integration Services service in Group 2. If the Integration Services service was configured to affect the other services in the resource group, the SQL Server service that is failing over will fail because the Integration Services service failed. If the service was configured not to affect the other services in the resource group, the SQL Server service will be able to fail over to Node A.Unless the Integration Services service in Group 2 was configured not to affect the other services in the resource group, the failure of the Integration Services service that is failing over could cause the SQL Server service that is failing over to fail also.

Related Tasks

For step-by-step instructions on configuring the Integration Services service in a cluster, see Configure the Integration Services Service as a Cluster Resource.

Related Content