Estamos no meio da construção de um novo cluster sempre ativo do SQL Server 2017 na VM do Azure. O layout do disco de dados da VM é o seguinte
TempDb : 2 Azure Disk Read Cache
TempDBLog : 1 Azure Disk No Cache
UserDB : 3 Azure Disk Read Cache
UserDBLog : 2 Azure Disk No Cache
Meu plano é criar um pool de armazenamento múltiplo, ou seja, pool de armazenamento TempDB com 2 discos TempDB, pool de armazenamento UserDB com 3 User db Azure Disk.
No entanto, de acordo com a documentação da Microsoft sobre SQL Server em VMs do Azure:
Se estiver usando uma técnica de distribuição de disco, como Espaços de Armazenamento, você obterá o desempenho ideal ao ter dois pools, um para o(s) arquivo(s) de log e outro para os arquivos de dados. No entanto, se você planeja usar o SQL Server Failover Cluster Instances (FCI), deverá configurar um pool.
Isso é aplicável ao Always-On ou apenas aplicável ao FCI de armazenamento compartilhado. Por favor, oriente-me, Por favor, compartilhe bons artigos/docs para referência.
Obrigado
As FCIs no Azure usam espaços de armazenamento direto para replicação de disco, que imagino ser a origem desse requisito. Para AGs, você pode usar vários discos ou pools separados. Você deve garantir que os mesmos volumes e caminhos lógicos estejam disponíveis em cada nó, caso contrário, a replicação do AG será interrompida se você executar operações de arquivo e grupo de arquivos no primário. Por exemplo, se você adicionar um arquivo 'g:\sql\data\foo.ndf' a um banco de dados, esse caminho precisa existir em todos os outros nós do cluster para que essa alteração seja replicada. Consulte Solucionar problemas de uma operação de adição de arquivo com falha (grupos de disponibilidade sempre ativos) .
Além disso, onde quer que você coloque arquivos de dados Tempdb, coloque o log Tempdb também. Dividir o log do tempdb é um exagero, pois é provável que seja subutilizado, e seus padrões de acesso de E/S são mais como arquivos de dados tembdb do que arquivos de log do banco de dados do usuário. Em particular, a confirmação de transação não libera os logs do tempdb.
Experiência pessoal, sem links, mas eu costumava construí-los o tempo todo para os clientes.
O desempenho do seu disco é dimensionado com o número de discos usados no pool (até 4, então discos adicionais não aumentam realmente o desempenho). Eu não recomendaria usar nada menos que 4 discos em um pool e colocaria 4xData, 4xLog e colocaria o TempDB no SSD local da VM (unidade D:?) se estiver disponível para você. Caso contrário, coloque-o em outro conjunto de 4 discos. O TempDB é reconstruído na inicialização do servidor para que o armazenamento temporário seja adequado para eles.
Você paga apenas pela quantidade de dados que armazena (com discos padrão), portanto, obtenha quantos discos sua VM permitir. Esse era frequentemente o fator determinante para qual VM escolher, obtendo discos suficientes para anexar a ela.
Você precisa ter suas VMs em uma FCI para que os AGs funcionem, mas como eles não compartilharão discos, essa regra não se aplica a você. Este também foi um momento complicado durante a configuração, pois você deve se lembrar de DESMARCAR o botão adicionar armazenamento compartilhado.
O conselho final é certificar-se de que sua testemunha esteja em um grupo de recursos diferente de seus servidores SQL. O ideal é usar a opção de testemunha na nuvem.
EDIT: É muito mais provável que, quando houver um problema no Azure, ocorra em um rack inteiro ou subconjunto de racks de cada vez. Portanto, é muito provável que seu primário e a testemunha caiam ao mesmo tempo. O secundário não poderá sofrer failover automaticamente porque nunca obterá quorum.