Instalação do SQL Cluster nas opções do Hyper V

Question

Eu tenho lido sobre a execução de um cluster SQL em um ambiente Hyper V e parece haver algumas opções:

1. Instale o cluster de convidados em duas VMs que fazem parte de um cluster de failover.

2. Instale o cluster SQL em duas VMs, mas as próprias VMs não fazem parte de um cluster subjacente.

Com a opção 1, é um pouco mais complexa, pois há efetivamente dois clusters em exibição, mas isso adiciona alguma flexibilidade no sentido de que estou livre para migrar as VMs entre blades físicos em seus clusters para manutenção física sem afetar o status de o cluster convidado SQL que está sendo executado dentro deles.

Com a opção 2, a configuração é um pouco mais simples, pois há apenas 1 cluster na mistura, mas minhas VMs estão ancoradas nos blades físicos em que estão configuradas (ignorarei o fato de poder manualmente mover os VHDs para os propósitos desta questão).

Existem outros fatores que devo considerar aqui quando decidir qual opção escolher?

Estou livre para testar as duas opções e, provavelmente, o farão, mas se alguém tiver experiência de trabalho com essas configurações e puder oferecer algumas informações que seriam ótimas.

Editar:

Bons pontos levantados sobre a adição de espelhamento à mistura para adicionar uma segunda cópia do banco de dados. Estou pensando em ir apenas com 2 instâncias do SQL e usar o espelhamento sozinho, já que esse back-end será usado para um único aplicativo, já que será uma configuração razoavelmente estável com relação aos usuários, etc.

O ponto principal desta questão, no entanto, foi especificamente relacionado à configuração do cluster. ou seja, é melhor

a) Nos hosts Hyper V, crie um cluster de failover das VMs e, em seguida, dentro das próprias VMs, configure um segundo cluster e instale o Cluster SQL - cluster convidado na parte superior do cluster host

ou

b) Basta configurar o cluster SQL dentro das VMs e não ter a configuração do cluster de failover subjacente nas próprias máquinas Hyper V do host.

Já vi defensores de ambas as opções, mas realmente não entendo os prós e contras de cada abordagem.

    

Answer 1

Use 2 e, em seguida, use MIRRORING para alta disponibilidade. Isto dá-lhe mais do que um cluster de SQL, porque lhe dá duas cópias dos dados.

Este é o único ponto fraco de um cluster SQL - se o banco de dados morre de uma forma que danifica o arquivo de banco de dados (e que ocorre - não exatamente com frequência, mas se você deseja alta disponibilidade não deseja isso), então o cluster falhará e o novo processo de inicialização do SQL .... não carregará o banco de dados ou falhará.

Com o espelhamento, o segundo servidor recolhe sua própria cópia dos dados.

Um terceiro (pequeno) servidor SQL como "testemunha" (para que haja 3 instâncias, torna o failover mais estável) é sugerido.

Pessoalmente, acho que (depois de passar alguns meses no suporte do MS SQL Server trabalhando para a Microsoft) que usar um SQL Cluster para alta disponibilidade na primeira linha de defesa é uma negligência grosseira. Em 3 meses, eu tive um caso por mês em que o failover falhou por várias razões (uma incluindo o sistema SAN em que os dados foram mantidos em falha). Isso realmente faz você apreciar a cópia de dados de vida dupla de uma instância de espelho.

    

Answer 2

Supondo que você esteja executando o Windows 2008 R2 e o SQL 2008, então:

1. não é tão difícil de configurar, uma vez que o seu cluster de armazenamento e host é feito apenas alguns minutos a mais para configurar o cluster sql.

2. A migração ao vivo também não é uma solução ruim, assim você não fica preso a um blade no cluster.