Eu tenho um WSFC com SQL Server 2016 Enterprise Edition e 4 grupos de disponibilidade. Cada servidor possui 1 CPU com 6 núcleos a 3,4 GHz e 256 GB de RAM.
Atualmente tenho uma instância em cada, eles atendem 4 Grupos de Disponibilidade com um total de ~300 GB de dados em 95 bancos de dados.
Tenho a tarefa de migrar mais bancos de dados (35 bancos de dados, 235 GB de dados) para este ambiente, o que tenho certeza que seria muito fácil - não fosse o fato de esses bancos de dados virem de um cluster com outro agrupamento. Portanto, estou pensando em adicionar uma instância em cada servidor e criar um grupo de disponibilidade separado para esse agrupamento.
Para ajudar a manter as coisas organizadas e simples, adicionarei um endereço IP em cada servidor para a nova instância. Dessa forma, posso abordar as duas instâncias na porta 1433 e não precisarei resolver isso na criação de grupos de disponibilidade - pelo menos é esse o meu pensamento. (Eu usei essa abordagem em um único servidor com 3 instâncias - todos eles têm seus próprios endereços IP, o que elimina a necessidade de resolvê-los pelo nome da instância - facilita o caso de o banco de dados precisar migrar para outro servidor.)
Encontrei uma pergunta semelhante de alguns anos atrás, mas como não havia razão evidente para as várias instâncias, o TS recebeu muitos porquês, donts e whats. No meu caso eu realmente preciso ter uma instância extra devido ao problema de agrupamento, minha pergunta para a Comunidade é: alguém poderia me dizer "Sim" ou "Não"? E se qualquer uma das respostas - você poderia me dar uma boa motivação?
Se eu não puder adicionar as instâncias, teria que ir com outro servidor e, devido aos custos de licença do Enterprise Edition, essa seria uma solução sem cluster - reduzindo o tempo de atividade, complicando rotinas de patch, removendo redundância e assim por diante. Então: eu poderia fazer isso?
Considerando que há um soquete único com 6 núcleos e comportará 130 bancos de dados, já é uma boa parte dos threads disponíveis apenas para uso Always On e sem contar mais nada.
É um requisito que o agrupamento no nível da instância seja o mesmo que o agrupamento do banco de dados? Isso não está claro.
Adicionar outra instância só tornará a solução de problemas inevitáveis que você terá, muito mais difícil, pois agora você precisará monitorar as duas instâncias para ver como uma está afetando a outra enquanto a outra está tendo problemas.
Eu, pessoalmente, não faria isso.
Você está deixando de lado o que já foi discutido e quer uma resposta absolutista para um ambiente que ninguém além de você tem acesso, o que é uma pergunta bastante difícil.
Em vez de adicionar outra instância, adicionaria outro conjunto de nós ao cluster ou criaria um novo cluster para que os itens fossem separados. Ainda não está claro se o requisito é o agrupamento em nível de instância para corresponder ao agrupamento em nível de banco de dados, portanto, nem temos certeza de que outra instância seja necessária.
Deixando de lado o licenciamento, uma instância autônoma seria um patch simplificado - usar um AG complica o patch.
Receio que seja mais ou menos por duas coisas:
Depois de ler a entrada de Sean, decidi não arriscar atolar um cluster que funciona bem com consequências possivelmente terríveis. Como eu não tinha certeza se poderia ignorar a diferença de agrupamento, instalei um SQL Server separado em uma máquina virtual.