背景：我们公司承载SaaS DSS应用程序，客户向我们提供每日和/或每周数据，我们处理并合并到他们现有的数据库中。 在营业时间内，服务器的负载相当小，因为大多数用户通过网站运行简单的预定义查询，或者运行大多数情况下击中SSAS OLAP多维数据集的钻取报表。
我pipe理IT运营团队，到目前为止，这已经为我们提出了一个有趣的“缩放”问题。 对于我们每天刷新的客户端来说，服务器在晚上只有“忙”的时间，大概4-6小时。 对于我们的每周刷新客户端来说，服务器每周只有8-10个小时“忙”！
我们尽最大努力使用一些简单的方法分发负载，将日常客户端均匀地分布在服务器之间，这样我们就不会每天晚上连续处理客户端。 但是长期的这种扩张战略会产生两个值得注意的问题。 首先，它将消耗相当大量的硬件，闲置很长一段时间。 其次，它需要大量的生产支持，以便基本上“调度”ETL，以便它们不会重叠，并且如果在特定的服务器或分配的时隙上增加资源，则将客户端/时间表移动。
正如标题所暗示的，我们试过的一个选项是并行运行多个SSIS包，但在大多数情况下，这已经产生了非常不一致的结果。 最常见的失败是DTExec，SQL和SSAS争夺物理内存和抛出内存错误，ETL运行时间比预期长3,4,5倍。 因此，从我迄今为止的实践经验来看，似乎在同一个硬件上运行多个ETL包并不是一个好主意，但是我不能成为第一个不希望围绕手动调度扩展多个ETL的人，处理。
我们考虑过的一个select是虚拟化服务器，这显然不会给你任何额外的资源，但将资源争用转移到pipe理程序上，从我的经验来看，它似乎同时pipe理CPU / RAM /磁盘I / O比让DTExec，SQL和SSAS在Windows中战胜它还要优雅得多。
对论坛的问题：所以我对论坛的问题是，我们在这里错过了一些明显的东西吗？ 有没有工具可以帮助pipe理在同一个硬件上运行多个SSIS包？ 如果不是运行DTExec，SQL和SSAS同一台机器（每台机器都运行该configuration），而是在一台机器上运行SSIS的三台机器运行，另一台机器上运行SQL和SSAS的第三？ 显然这只有在我们能够独立处理超过三个ETL的情况下才有意义。
我们考虑过的另一个select是完全重新devise我们的SSIS软件包，为所有客户端提供一个“主”软件包，试图根据CPU /内存/磁盘利用率已经“繁忙”的情况来智能地select服务器，但是这将是一个艰巨的努力，似乎我们正在试图重塑一些你会认为有人会出售的东西（尽pipe我没有find它的运气）。
总而言之，我们是否错过了一个明显的解决scheme，是否有人知道是否有任何工具（免费或者购买，无关紧要）能够在多个服务器上并行运行多个SSIS ETL包？ （我称之为“基于队列和节点的”系统，但这不是一个正式的术语）。 最终，VMWare的分布式资源调度程序解决了这个问题，因为您只需为每个虚拟机运行一个一致的数量的客户端，而这些客户端永远不会发生冲突，然后将其留给VMWare来移动虚拟机以平衡硬件使用。 我绝对不反对使用VMWare来做到这一点，但由于我们是一个100％的Microsoft应用程序堆栈，似乎有人会通过检查资源在应用程序层而不是虚拟机pipe理程序层解决此问题在操作系统，SQL，SSAS级别的利用率。
任何有关这方面的讨论都是开放的，请记住，没有任何build议太疯狂或激进！ :-)现在，VMWare是我们发现摆脱“手动”平衡资源的唯一select，所以任何将我们留在纯粹的Microsoft堆栈上的build议都会很棒。
多谢你们，
试试这个： http : //blogs.msdn.com/b/sqlperf/archive/2011/05/25/the-balanced-data-distributor-for-ssis.aspx
您也可以使用Service broker（或其他消息队列）在家中增长一个解决scheme，
以及等待工作的侦听器软件包，并将其安装到安装了SSIS的盒子农场的工作包上。