Estamos nos estágios iniciais de planejamento de um novo ambiente de banco de dados para nossos aplicativos ERP e CRM (de terceiros). O objetivo é usar Always On Availability Groups para HA, patches contínuos, secundários somente leitura, etc. Queremos usar failover automático, sem que o aplicativo cliente precise estar ciente do HA.
Temos um servidor físico com especificações bastante massivas. Ele estará executando duas instâncias do SQL Server: uma para o aplicativo ERP que requer o SQL Server 2016 e uma para o aplicativo CRM que é mais adequado até 2017 (e isso também nos permite conceder direitos de administrador de sistema ao suporte do fornecedor do aplicativo CRM sem afetar a aplicação ERP).
Também temos uma infraestrutura ESX bastante madura e queremos usar algumas VMs como nós de failover. Eles não serão construídos de forma tão decadente quanto o servidor primário, mas garantiremos um desempenho aceitável para interrupções curtas ou janelas de manutenção no servidor primário.
Meu pensamento inicial era ter duas VMs de failover: uma para a instância do ERP e outra para o CRM. Não parece que um único servidor possa ser membro de vários clusters de failover do Windows, ou seja, não consigo fazer um cluster ERP com a ERP VM e o servidor físico, além de um cluster CRM com a CRM VM e o mesmo servidor físico .
Se, em vez disso, eu construísse um cluster de três nós e controlasse em quais nós cada instância pode ser executada, estaria provocando efeitos colaterais desagradáveis? Meu principal medo é que a votação do quorum possa ficar um pouco estranha se começarmos a adicionar mais servidores de banco de dados ao cluster, e podemos ter uma instância inativa inesperadamente, mesmo que todos os nós que podem hospedar essa instância ainda estejam ativos. Isso é mesmo um risco, e existem maneiras razoáveis de mitigá-lo? Existem complicações possíveis suficientes para que eu use uma única VM mais robusta que possa lidar com as duas instâncias?
tl; dr:
Eu estaria me dando um tiro no pé construindo um cluster de três nós onde a instância 1 só pode ser executada nos servidores A e B e a instância 2 só pode ser executada nos servidores A e C? Devo apenas criar um cluster de dois nós (mais o membro do quorum) e garantir que o servidor B possa lidar com as duas instâncias do SQL Server?
Não consigo ver quaisquer razões pelas quais você teria quaisquer problemas. Apenas certifique-se de adicionar um compartilhamento de arquivo ou testemunha de disco ao cluster, pois isso garantirá que não haja "estranheza" no quorum. Contanto que você configure os AGs corretamente, não vejo motivos para não usar sua abordagem sugerida. O único aspecto negativo que consigo pensar é que será um ambiente adicional para gerenciar e manter, mas você já está fazendo isso com 2 instâncias no seu primário. Você usará as VMs para as conexões somente leitura?
Visto que você é
e
Este:
Não é realmente uma boa ideia. Compartilhar uma VM do Windows e um cluster maior cria complexidade e risco desnecessários, sem basicamente nada de útil em troca.
Basta criar VMs separadas para cada uma das duas instâncias e executá-las no mesmo host ESX, se desejar.
Para cada um, você pode adicionar uma VM secundária com uma réplica AG para HA.