MS SQL server: instâncias únicas ou múltiplas?

Question

Qual é o custo (CPU ou memória inteligente) de ter várias instâncias do SQL Server 2005 em vez de apenas uma instância com bancos de dados prefixados?

Uma empresa tem três provedores de aplicativos. Cada um deles instalará um aplicativo e cada um deles precisará de dois ou três bancos de dados. Todos eles devem usar a mesma instância ou todos os provedores devem usar sua própria instância nomeada?

Existe algum motivo strong para uma ou outra configuração?

    

Answer 1

O único motivo strong para instalar instâncias separadas no mesmo hardware é se você tiver requisitos de isolamento de segurança muito rigorosos. Caso contrário, é sempre melhor ter apenas uma instância. Uma única instância pode otimizar melhor todos os recursos de hardware para a carga que você está enfrentando. Várias instâncias não se comunicam entre si e elas se sobrepõem à memória, à carga de E / S e à CPU, resultando em um desempenho pior.

Além disso, uma única instância é mais fácil de administrar, monitorar e solucionar problemas do que instâncias separadas.

    

Answer 2

Se você dividir seus SQL Servers em instâncias individuais (ou talvez em máquinas virtuais separadas), as vantagens são:

Melhor limitação de recursos. O Resource Governor do SQL 2008 é um bom começo, mas ainda não é tão refinado, especialmente quando se trata de limitar IO. Com os servidores virtuais, você pode acelerar a CPU, a memória e o IO no nível da máquina virtual, oferecendo a capacidade de limitar recursos mesmo em versões mais antigas do SQL Server.

Atualizações e downgrades de desempenho mais fáceis. Se uma máquina virtual precisar ser ampliada, como se seu aplicativo se tornasse mais popular, você poderia colocá-lo em uma máquina mais potente sem sofrer interrupções. Se você estiver usando várias instâncias, por outro lado, está procurando uma instalação que consome muito tempo e exige muita mão-de-obra.

Janelas de interrupção mais flexíveis - se você tiver todos os seus bancos de dados em um único SO (várias instâncias do SQL), precisará coordenar bastante os patches do Windows. Se eles forem divididos em diferentes convidados virtuais, você poderá fazer correções sempre que for mais conveniente para cada convidado individual (e seus bancos de dados correspondentes).

Melhores limites de segurança. Se um SQL Server tiver problemas e um terceiro precisar se envolver com a solução de problemas, você poderá conceder a eles permissões no nível do SO sem se preocupar com o que eles farão. os outros SQL Servers instalados na caixa.

Menos problemas com compatibilidade de aplicativos. Alguns aplicativos simplesmente não são compatíveis com instâncias nomeadas do SQL Server.

Não são todos os unicórnios e arco-íris, no entanto. Algumas desvantagens da abordagem de várias instâncias e / ou de servidores virtuais incluem:

• Possivelmente mais caro - você tem que pagar pela camada de virtualização e, dependendo de como parte do seu software é licenciado, você pode ter que pagar de forma diferente por isso. Alguns utilitários são licenciados pelo número de CPUs nas máquinas host, e nem todas as CPUs podem ser alocadas para o SQL Server.
• Resolução de problemas possivelmente mais difícil - alguns fornecedores gostam de apontar os dedos para a camada de virtualização.
• Mais gerenciamento do sistema operacional - todos os sistemas operacionais adicionados significam mais gerenciamento e manutenção.

Eu fiz um webcast sobre consolidação vs virtualização com especialistas do SQL Server Kevin Kline e Ron Talmage . O registro é necessário para isso, no entanto.

    

Answer 3

Se você quiser seguir esse caminho, recomendo separar as instâncias em um hardware diferente em vez de executar instâncias separadas na mesma máquina. Se cada uma dessas instâncias pretende ser martelada, prefiro que todas martelem uma instância do que martelem três instâncias na mesma caixa, com a sobrecarga adicionada envolvida na manutenção dessas instâncias.

    

Answer 4

Mantenha os aplicativos em instâncias separadas. Dessa forma, os provedores não podem ver o trabalho uns dos outros. Eles provavelmente preferirão dessa forma, pois eles verão seus aplicativos como informações proprietárias. Além disso, eles podem precisar de configurações diferentes no banco de dados (por exemplo, agrupamento).

A desvantagem disso é que as instâncias exigirão um pouco mais de memória.

Se qualquer um dos aplicativos tiver uma carga pesada, pode haver um caso para colocá-lo em seu próprio servidor ou, pelo menos, em seu próprio volume de disco fisicamente separado. Geralmente, instâncias separadas seriam preferíveis para separar as VMs de um servidor de banco de dados.