MSSQL: bancos de dados separados de dev e prod como instâncias separadas em hardware compartilhado?

Question

Eu tenho um pequeno ambiente virtualizado que hospeda um pequeno site interno com back-end de banco de dados. No momento, eu separei meus servidores da Web e servidores de banco de dados em VMs separadas em execução no mesmo hardware.

No entanto, estou imaginando se uma estratégia melhor seria consolidar os servidores de banco de dados dev / prod na mesma (s) VM (s), mas usando instâncias separadas? Estou usando o espelhamento SQL para redundância, então eu teoricamente passaria de 4 SQL VMs para 2. Vantagens seriam menos VMs para gerenciar, alocação de recursos menos complexa e uma garantia de que o dev e o prod estivessem no mesmo patch / service nível de embalagem.

Quais são as desvantagens dessa abordagem? Se eu instalar uma instância padrão do MSSQL em um servidor Windows, posso simplesmente executar o instalador novamente para criar uma segunda instância (nomeada) e usá-la para o outro ambiente? Por fim, seria possível colocar instâncias diferentes em endereços IP separados se eu alocasse ambas para a mesma VM?

    

Answer 1

Ter menos VMs para gerenciar é um excelente incentivo para reduzir a dispersão de servidores! Usando instâncias do MSSQL para separar o desenvolvimento de ambientes de produção é muito fácil. Geralmente é tão fácil quanto você descreveu - execute o instalador novamente para criar uma segunda instância (nomeada).

Você pode usar o SQL Server Configuration Manager para vincular a instância nomeada a qualquer endereço IP no servidor desejado. Está abaixo de SQL Server Network Configuration > > Protocols for <INSTANCE NAME> .

As desvantagens de se fazer isso incluem os problemas de desempenho padrão, embora, se forem um tráfego baixo, você quase certamente não se deparará com nenhum problema.

    

Answer 2

Você certamente pode configurar várias instâncias do MSSQL e vinculá-las a IPs separados. No entanto, eu recomendaria contra isso se fosse para o propósito de dividir ambientes de produção e desenvolvimento.

Eu prefiro manter o dev e a produção em servidores / VMs completamente diferentes, de modo que nenhum recurso de desenvolvimento esteja consumindo recursos de produção. Não é incomum ter processos / códigos em fuga em uma máquina de desenvolvimento que consome tudo e deixa a caixa de joelhos. Isso obviamente não é bom para a produção. O tempo de inatividade para um ambiente de desenvolvimento não deve afetar a produção.

Obviamente, você ainda tem um denominador comum em sua máquina host para que algo de errado ainda tenha o potencial de derrubar tudo que você inerentemente compartilhou recursos no nível da VM, mas pelo menos você não terá contenção dentro de uma VM.

Há também o caso [bastante típico] em que a segurança do SO de produção é completamente diferente da segurança de desenvolvimento e eles são mutuamente exclusivos. Neste caso, você está de volta a servidores diferentes.

Editar:
Eu entendo o baixo impacto, isso é algo que você terá que pesar por si mesmo. Tenha em mente, porém, que uma consulta de baixo desempenho também pode esgotar a vida de um servidor. Se isso não for um problema para o seu ambiente de produção, você ficará bem com várias instâncias. Você provavelmente desejará definir limites máximos de memória em suas instâncias de SQL, o que ajudará a aliviar isso.

    

Answer 3

Uma abordagem ainda mais fácil seria usar dois bancos de dados na mesma instância do SQL Server; isso é o que eu faria, a menos que eu tivesse razões convincentes para precisar de dois casos diferentes.

De qualquer forma, sim, você pode ter duas instâncias no mesmo servidor (físico / virtual) com bastante facilidade; você só precisa executar a instalação novamente e especificar que deseja instalar uma instância nomeada.