在群集中配置 Integration Services
建议不要对 Integration Services 建立群集，因为 Integration Services 服务不是群集服务或能够识别群集的服务，而且不支持从一个群集节点故障转移到另一个节点。因此，在群集环境内，应当在群集的每个节点上安装 Integration Services 并将其作为一个独立服务来启动。
.gif "重要说明") 重要提示 |
|---|
Microsoft 建议不要将 Integration Services 服务配置为群集资源。 |
尽管 Integration Services 服务不是群集服务，但是您可以在将 Integration Services 服务单独安装在群集的每个节点上之后，手动配置该服务，使其作为群集资源运行。对于那些认为此配置的优点大于缺点的客户，本主题包含有关将该服务配置为群集资源的说明。
但是，如果您建立群集硬件环境的目的是实现高可用性，那么，不将 Integration Services 服务配置为群集资源也可以实现此目标。若要从群集中的其他任何节点管理该群集中某一节点上的包，请在群集的每个节点上修改 Integration Services 服务的配置文件。可以修改每个配置文件，使其指向包所存储到的所有可用 SQL Server 实例。本解决方案提供大多数客户所需的高可用性，而不会带来在将 Integration Services 服务配置为群集资源时可能遇到的问题。有关如何更改配置文件的详细信息，请参阅配置 Integration Services (SSIS) 服务。
了解 Integration Services 服务的角色
了解 Integration Services 服务的角色对于就如何在群集环境中配置该服务做出明智决定至关重要。
Integration Services 服务支持使用 SQL Server Management Studio 中的管理界面来列出、启动、停止、监视、导入和导出 Integration Services 包。在设计包时，不需要 Integration Services 服务。在运行包或者安排 SQL Server 代理作业运行包时，也不需要 Integration Services 服务。
即使在 Integration Services 服务未运行时，也可以完成如下任务：
在 Business Intelligence Development Studio 中设计和运行包。
使用 dtexec 命令提示实用工具 (dtexec.exe)、执行包实用工具 (dtexecui.exe)、SQL Server 代理或者 SQL Server 导入和导出向导来运行包。
使用 Transact-SQL 查询列出存储在 msdb 数据库中的包，使用 Windows 资源管理器列出存储在文件系统中的包。
创建并运行 SQL Server 代理作业和维护计划。
了解将 Integration Services 配置为群集资源的缺点
将 Integration Services 服务配置为群集资源的一些潜在缺点包括：
发生故障转移时，正在运行的包不重新启动。可以通过从检查点重新启动包来从包失败中恢复。可以从检查点重新启动，而不必将服务配置为群集资源。有关详细信息，请参阅通过使用检查点重新启动失败的包。
在不同于 SQL Server 的资源组中配置 Integration Services 服务时，不能使用客户端计算机上的 Management Studio 来管理存储在 msdb 数据库中的包。在这个双跃点方案中，Integration Services 服务不能委托凭据。
如果群集内有多个 SQL Server 资源组包括 Integration Services 服务，则故障转移可能会导致意外的结果。请考虑下面的方案。组 1 运行于节点 A 上，其中包括 SQL Server 服务和 Integration Services 服务。组 2 运行于节点 B 上，其中也包括 SQL Server 服务和 Integration Services 服务。组 2 故障转移到节点 A。由于 Integration Services 服务是单实例服务，因此尝试在节点 A 上启动 Integration Services 服务的另一个实例时将失败。尝试故障转移到节点 A 的 SQL Server 服务是否也失败取决于组 2 中 Integration Services 服务的配置。如果 Integration Services 服务配置为影响资源组中的其他服务，那么，由于 Integration Services 服务失败，因此正在故障转移的 SQL Server 服务也将失败。如果 Integration Services 服务配置为不影响资源组中的其他服务，则该服务将能够故障转移到节点 A。除非组 2 中的 Integration Services 服务配置为不影响资源组中的其他服务，否则，当正在故障转移的 Integration Services 服务失败时，正在故障转移到的 SQL Server 服务也将失败。
将 Integration Services 服务配置为群集资源
对于那些认为将 Integration Services 服务配置为群集资源所带来的优点大于缺点的客户，本节包含必要的配置说明。但是，Microsoft 不建议将 Integration Services 服务配置为群集资源。
若要将 Integration Services 服务配置为群集资源，必须按照下列步骤操作：
在群集上安装 Integration Services。
将 Integration Services 配置为群集资源。
配置 Integration Services 服务和包存储区。
将 Integration Services 服务作为群集资源联机。
在群集上安装 Integration Services
若要在群集上安装 Integration Services，必须将 Integration Services 安装在群集的每个节点上。
在群集上安装 Integration Services
安装并配置具有一个或更多节点的群集。
（可选）安装群集服务（如 SQL Server 数据库引擎）。
在群集的每个节点上安装 Integration Services。
将 Integration Services 服务配置为群集资源
在将 Integration Services 安装在群集的每个节点上之后，需要将 Integration Services 配置为群集资源。在将 Integration Services 服务配置为群集资源时，可以向与 SQL Server 数据库引擎 相同或不同的资源组中添加该服务。下表描述了在选择资源组时可能存在的优缺点。
当 Integration Services 和 SQL Server 位于同一个资源组中时 |
当 Integration Services 和 SQL Server 位于不同的资源组中时 |
|---|---|
客户端计算机可以使用 SQL Server Management Studio 来管理存储在 msdb 数据库中的包，因为 SQL Server 数据库引擎 和 Integration Services 服务运行于同一台虚拟服务器上。此配置避免了双跃点方案中的委托问题。 |
客户端计算机不能使用 SQL Server Management Studio 来管理存储在 msdb 数据库中的包。客户端可以连接到运行 Integration Services 服务的虚拟服务器。但是，客户端计算机不能将用户的凭据委托给运行 SQL Server 的虚拟服务器。这称作双跃点方案。 |
Integration Services 服务在 CPU 和其他计算机资源方面能够与其他 SQL Server 服务竞争。 |
Integration Services 服务在 CPU 和其他计算机资源方面不能与其他 SQL Server 服务竞争，因为不同的节点上配置了不同的资源组。 |
将包加载和保存到 msdb 数据库的速度会加快，生成的网络通信流量会较少，因为这两项服务运行于同一台计算机上。 |
将包加载和保存到 msdb 数据库的速度可能会减慢，生成的网络通信流量会较多。 |
这两项服务同时联机或脱机。 |
Integration Services 服务可以在 SQL Server 数据库引擎 处于脱机状态时联机。因此，存储在 SQL Server 数据库引擎 的 msdb 数据库中的包不可用。 |
Integration Services 服务不能根据需要快速移动到另一个节点。 |
Integration Services 服务可以根据需要更快地移动到另一个节点。 |
在确定了要向哪个资源组添加 Integration Services 之后，必须在该组中将 Integration Services 配置为群集资源。
将 Integration Services 配置为群集资源
打开**“群集管理器”**。
在控制台树中选择 Groups 文件夹。
在结果窗格中，选择计划添加 Integration Services 的组：
若要将 Integrations Services 作为群集资源添加到与 SQL Server 相同的资源组中，请选择 SQL Server 所属的组。
若要将 Integrations Services 作为群集资源添加到不同于 SQL Server 的组中，请选择 SQL Server 所属的组以外的组。
在**“文件”菜单上，指向“新建”，再单击“资源”**。
在“资源向导”的**“新资源”页上，键入名称并选择“一般服务”作为“服务类型”。不要更改“组”的值。单击“下一步”**。
在**“可能的所有者”页上，将群集的节点作为可能的资源所有者来添加或删除。单击“下一步”**。
若要添加依赖关系，请在**“依赖关系”页上的“可用资源”下选择一项资源，然后单击“添加”。对于故障转移情况，SQL Server 和用来存储 Integration Services 包的共享磁盘应在 Integration Services 联机前重新联机。在选择依赖关系之后，单击“下一步”**。
在**“一般服务参数”页上，输入 MsDtsServer100 作为服务名。单击“下一步”**。
在**“注册表复制”页上单击“添加”**，以添加用来标识 Integration Services 服务的配置文件位置的注册表项。此文件必须位于 Integration Services 服务所在资源组中的共享磁盘上。
在**“注册表项”对话框中，键入 SOFTWARE\Microsoft\Microsoft SQL Server\100\SSIS\ServiceConfigFile。单击“确定”，然后单击“完成”**。
Integration Services 服务现已添加为群集资源。
配置 Integration Services 服务和包存储区
在将 Integration Services 配置为群集资源之后，必须针对群集内每个节点上的 Integration Services 服务，修改配置文件的位置和内容。这些修改会使得配置文件和包存储区在发生故障转移时对于所有的节点可用。在修改配置文件的位置和内容之后，必须将该服务联机。
配置 Integration Services 服务和包存储区
在 %ProgramFiles%\Microsoft SQL Server\100\DTS\Binn\MsDtsSrvr.ini.xml 中找到该配置文件。将该文件复制到已添加 Integration Services 服务的组的共享磁盘上。
在共享磁盘上，创建一个名为 Packages 的新文件夹来充当包存储区。为适当的用户和组授予对这个新文件夹的“列出文件夹”和“写入”权限。
在共享磁盘上，用文本编辑器或 XML 编辑器打开配置文件。将 ServerName 元素的值更改为同一资源组中虚拟 SQL Server 的名称。
将 StorePath 元素的值更改为上一步骤中在共享磁盘上所创建的 Packages 文件夹的完全限定路径。
将注册表中 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\100\SSIS\ServiceConfigFile 的值更新为共享磁盘上服务配置文件的完全限定路径和文件名。
将 Integration Services 服务联机
- 在**“群集管理器”中选择 Integration Services 服务，单击右键，然后在弹出菜单中选择“联机”**。Integration Services 服务现已作为群集资源联机。
连接到群集中的 Integration Services
在群集或任何服务器上配置 Integration Services 服务后，可能需要配置 DCOM 权限才能从客户端计算机连接到该服务。有关详细信息，请参阅连接到远程 Integration Services 服务器。
Integration Services 服务不能委托凭据。因此，在满足下列条件时，不能使用 Management Studio 来管理存储在 msdb 数据库中的包：
Integration Services 服务和 SQL Server 运行于不同的服务器或虚拟服务器上。
运行 SQL Server Management Studio 的客户端是第三台计算机。
客户端可以连接到运行 Integration Services 服务的虚拟服务器。但是，客户端计算机不能将用户的凭据委托给运行 SQL Server 的虚拟服务器。这称作双跃点方案。
|
.gif "Integration Services 图标(小)")
使 Integration Services 保持最新