SQL Clustering ou Hyper V Clustering

Question

Em breve, estaremos implementando nossa instalação do Dynamics AX. Nosso objetivo é ter alta disponibilidade e estamos trabalhando de perto com nossos implementadores.

Nós levantamos a questão para eles sobre o SQL e o Hyper-V Clustering. Eles recomendaram que, quando executados em uma plataforma virtualizada completa, não houvesse nenhum motivo real para virtualizar na camada de aplicativo (SQL) e que apenas configurasse o clustering Hyper V no Windows Server e criassem seu SQL e todas as outras VMs de aplicativo relacionadas em LUNs para back-end. armazenamento (no nosso caso HP P2000) e apenas executando os arquivos VHD no modo de alta disponibilidade usando CSV's.

Isso é verdade? Ou deveríamos estar agrupando o SQL separadamente no nível do VHD?

Muito obrigado!

    

Answer 1

They recommended that when running in a complete virtualized platform there is no real reason to virtualize at application layer

Este é um conselho potencialmente perigoso. O clustering do Hyper-V permite alta disponibilidade no caso de uma falha de hardware - isso é tudo.

O cluster de convidados permite alta disponibilidade no nível do sistema operacional no caso de um BSOD, falha no Windows Update, falha do aplicativo ou qualquer outro modo de falha que não esteja relacionado ao hardware. Ele também permite corrigir esses sistemas e aplicativos sem incorrer em tempo de inatividade do aplicativo, o que pode ser importante para algo como uma instalação do Dynamics.

Existem muitas configurações nas quais não faz sentido adicionar clusters no convidado ao usar clustering no nível do hipervisor, porque você está OK restaurando a partir do backup no caso de uma falha do SO, mas dizer que é nunca necessário porque o armazenamento em cluster é feito no hypervisor é um conselho incompleto na melhor das hipóteses. Eles são mais eficazes quando usados em conjunto.

    

Answer 2

They recommended that when running in a complete virtualized platform there is no real reason to virtualize at application layer

Incompetência. Simples assim.

Depende totalmente das suas necessidades. E como você faz isso.

O cluster padrão do nível do SQL Server é ativo / passivo e isso reinicia a instância do sql server quando o outro falha, o que ainda deve ser mais rápido do que reiniciar a VM.

A alternativa do SQL Server é High Availability Groups e tem o benefício de 2 sotorages, portanto, se um servidor de tratamento de dados remover os arquivos do banco de dados, a outra máquina poderá assumir o controle. Não é necessário armazenamento compartilhado.

Isso realmente depende do que você precisa.

Isso também depende do patch;) Quando você corrige a VM que contém o SQL Server - isso pode ser um tempo de inatividade. Você pode fazer aquilo? (tempo de inatividade planejado, janela de manutenção).

Geralmente "nenhuma razão real", como você disse, é incompetência ou má comunicação - há várias razões. A questão é se eles são relevantes para você. Nós não podemos decidir isso. Mas há boas razões para não usar um CSV e usar armazenamento local replicado para um grupo de alta disponibilidade no SQL Server.