tente isso: link
você também pode crescer em casa uma solução usando o Service Broker (ou outra fila de mensagens)
e pacotes de listener que aguardam trabalho e dipatch para pacotes de trabalho em um farm de caixas com o SSIS instalado.
Antecedentes: Nossa empresa hospeda aplicativos SaaS DSS, onde os clientes nos fornecem dados diários e / ou semanais, os quais processamos & mesclar em seu banco de dados existente. Durante o horário comercial, a carga nos servidores é muito pequena, pois são principalmente os usuários que executam consultas predefinidas simples por meio do site ou que executam relatórios detalhados que atingem principalmente o cubo SSAP OLAP.
Eu gerencio a equipe de operações de TI, e até agora isso apresentou uma interessante questão de "escala" para nós. Para nossos clientes atualizados diariamente, o servidor só fica "ocupado" por cerca de 4 a 6 horas da noite. Para nossos clientes de atualização semanal, o servidor só fica "ocupado" por talvez 8 a 10 horas por semana!
Fizemos o melhor possível para usar alguns métodos simples de distribuição de carga distribuindo os clientes diariamente de maneira uniforme entre os servidores, de modo que não estivéssemos tentando processar os clientes diários consecutivamente durante a noite. Mas a longo prazo, essa estratégia de dimensionamento cria dois problemas notáveis. Primeiro, vai consumir uma quantidade imensa de hardware que fica inativa por longos períodos de tempo. Em segundo lugar, é necessário um suporte significativo de Suporte de Produção para "programar" o ETL de forma que eles não sobreponham e movam os clientes / planejamentos se eles aumentarem os recursos em um determinado servidor ou no intervalo de tempo alocado.
Como o título implicaria, uma opção que tentamos é executar vários pacotes do SSIS em paralelo, mas na maioria dos casos isso gerou resultados MUITO inconsistentes. As falhas mais comuns são DTExec, SQL e SSAS que lutam por memória física e por erros de falta de memória, e ETLs que executam 3,4,5 vezes mais do que o esperado. Portanto, da minha experiência prática até agora, parece que executar vários pacotes ETL no mesmo hardware não é uma boa ideia, mas não posso ser a primeira pessoa que não quer dimensionar vários ETLs em torno de programação manual e sequencial em processamento.
Uma opção que consideramos é virtualizar os servidores, o que obviamente não oferece recursos adicionais, mas move a contenção de recursos para o hipervisor, que (da minha experiência) parece gerenciar CPU / RAM / Disco I simultâneos / O um pouco mais graciosamente do que deixar DTExec, SQL e SSAS batalharem no Windows.
Pergunta para o fórum: Então, minha pergunta para o fórum é: estamos perdendo algo óbvio aqui? Existem ferramentas por aí que podem ajudar a gerenciar a execução de vários pacotes do SSIS no mesmo hardware? Seria mais "eficiente" em termos de execução paralela se, em vez de executar a mesma máquina DTExec, SQL e SSAS (com cada máquina executando essa configuração), rodamos em pares de três máquinas com o SSIS sendo executado em uma máquina, SQL em outra e SSAS em um terceiro? Obviamente, isso só faria sentido se pudéssemos processar mais do que os três ETL que pudemos processar na máquina de forma independente.
Outra opção que consideramos é reformular completamente nosso pacote SSIS para ter um pacote "mestre" para todos os clientes que tentem escolher de forma inteligente um servidor baseado em quão "ocupado" ele já é em termos de CPU / Memória / Utilização de disco, mas isso seria um esforço hercúleo, e parece que estamos tentando reinventar algo que você pensaria que alguém venderia (embora eu não tenha tido sorte em encontrá-lo).
Então, em resumo, estamos perdendo uma solução óbvia para isso, e alguém sabe se alguma ferramenta (de graça ou para compra, não importa) facilita a execução de vários pacotes SSIS ETL em paralelo e em vários servidores? (O que eu chamaria de sistema "baseado em fila e nó", mas esse não é um termo oficial). Em última análise, o Distributed Resource Scheduler da VMWare resolve isso à medida que você simplesmente executa um número consistente de clientes por VM que você sabe que nunca entrará em conflito com programação, deixando o VMWare para mover as VMs para equilibrar o uso do hardware. Eu definitivamente não sou contra o uso do VMWare para fazer isso, mas como somos uma pilha de 100% de aplicativos da Microsoft, parece que alguém teria resolvido esse problema na camada do aplicativo em vez da camada do hipervisor verificando o recurso utilização nos níveis OS, SQL, SSAS.
Estou aberto a qualquer discussão sobre isso, e lembre-se nenhuma sugestão é muito louco ou radical! :-) No momento, o VMWare é a única opção que encontramos para evitar o balanceamento "manual" de nossos recursos, portanto, qualquer sugestão que nos deixe em uma pilha pura da Microsoft seria ótima.Obrigado pessoal,
tente isso: link
você também pode crescer em casa uma solução usando o Service Broker (ou outra fila de mensagens)
e pacotes de listener que aguardam trabalho e dipatch para pacotes de trabalho em um farm de caixas com o SSIS instalado.