SQL Server 2016 Vários Grupos de Disponibilidade e instâncias

A) cada instância sql também precisa ser seu próprio cluster do Windows ou um cluster pode ser suficiente para todas as instâncias nomeadas?

O SQL Server não tem associação de cluster, os servidores sim. Se o servidor fizer parte de um cluster do Windows, todas as instâncias do SQL Server poderão fazer parte do mesmo cluster. Não é possível que um servidor faça parte de mais de um cluster.

B) Isso vai funcionar?

Pode... somente se você tiver uma pequena carga de trabalho incomum. Apenas os threads de trabalho por si só me fariam supor que você não vai se divertir. Isso, juntamente com 4 instâncias por servidor, que não se comunicam umas com as outras, que estão todas tentando pisar nos calos umas das outras (por assim dizer), me deixa pensando: "Estou muito feliz por não ter que admin isso!".

Minha tomada pessoal

Eu me afastaria de pensar em AGs como este. Se você quer se consolidar, isso é ótimo e eu sou a favor! No entanto, isso precisa ser feito de uma forma que não acabe prejudicando você ou seus clientes.

Se fosse eu, e eu fosse encarregado da mesma coisa, eu imediatamente voltaria aos servidores "6". Ainda não sei quantos vou precisar... a menos, é claro, que não façamos nenhuma pesquisa ou teste científico - nesse caso eu aumentaria minhas preocupações.

Não sabemos coisas como o número total de bancos de dados, quanta geração de logs cada banco de dados cria, etc., que precisaríamos para começar a entender o que será necessário.

Sem dúvida, você pode consolidá-los. É mesmo a coisa certa para colocá-los todos em um único cluster? eu não iria .

Cada cluster é um domínio de falha e, embora existam alguns recursos realmente incríveis, como grupos de disponibilidade distribuídos, isso ainda acaba sendo mais do que um único cluster. Pense desta forma, todos os seus AGs estão em um único cluster - o que acontece se você tiver um problema com o referido cluster? Todos os AGs estão inativos agora? Pode ser. Provavelmente. De qualquer forma, não é algo que eu gostaria de lidar às 5 da manhã.

Algumas das principais coisas que você verá quando tiver muitos AGs ou bancos de dados em AGs:

1. Exaustão do thread de trabalho
2. Consultas DMV lentas
3. Respostas lentas da API de cluster
4. Instâncias lentas ou sem resposta do SQL Server

Meu conselho seria coletar métricas:

1. Número de banco de dados
2. Número de réplicas necessárias para HA e DR
3. Taxa de geração de registros
4. Uso de CPU/disco/memória

Isso lhe dará um começo sobre como as peças precisarão se encaixar. É preciso mergulhar muito mais em como isso vai acabar, mas espero que isso o aponte na direção certa.

A) cada instância sql também precisa ser seu próprio cluster do Windows ou um cluster pode ser suficiente para todas as instâncias nomeadas?

Um será suficiente. 1 grupo de janelas. Você tem dois nós que irão compor o cluster do Windows (armazenamento não compartilhado)

cada AG\Listener terá uma entrada na seção de função no gerenciador de cluster de failover.

Eu me certificaria de que cada AG tenha seu próprio ponto de extremidade de espelho versus compartilhamento de pontos de extremidade de espelho

B) Isso vai funcionar?

ele funcionará desde que você tenha os recursos para executar instâncias SQL empilhadas. Não sei se você planeja executar ativo/passivo ou ativo/ativo.

Se você executa ativo/passivo, o Software Assurance permite que você tenha as réplicas secundárias gratuitamente, desde que não sejam somente leitura e você não esteja descarregando seus backups para o secundário. Isso significa que você precisa ter RAM e CPU suficientes para executar todas as 4 instâncias ativas do SQL em um nó...

Se você executar Active/Active (2 instâncias ativas em cada nó). Você terá que licenciar ambos os lados, mas aliviará a contenção de recursos (CPU RAM) ao distribuir a carga de trabalho entre dois nós no cluster.