SQL Clustering no Hyper V - um cluster dentro de um cluster é um benefício

Question

Este é um re-hash de umperguntaPerguntei há algum tempo - depois que um consultor chegou e transmitiu ideias para outras equipes do departamento, toda a questão foi levantada novamente, por isso estou procurando respostas mais detalhadas.

Pretendemos configurar um cluster SQL de várias instâncias em vários blades físicos que executarão uma variedade de sistemas diferentes em cada instância SQL. Em uso geral, haverá uma instância SQL virtual em execução em cada host VM. Novamente, na operação geral, cada host VM será executado em um blade subjacente dedicado. A configuração deve nos dar muita flexibilidade para manutenção de qualquer VM individual ou blade subjacente, com todas as instâncias SQL capazes de fazer failover conforme necessário.

Meu plano original era fazer o seguinte:

1. Instale 2008 R2 em cada lâmina
2. Adicione Hyper V a cada blade
3. Instale uma VM 2008 R2 em cada blade
4. Dentro das VMs – crie um cluster de failover e instale o clustering do SQL Server.

O consultor sugeriu que fizéssemos o seguinte:

1. Instale 2008 R2 em cada lâmina
2. Adicione Hyper V a cada blade
3. Instale uma VM 2008 R2 em cada blade
4. Crie um cluster nas máquinas HOST que hospedará todas as VMs.
5. Dentro das VMs – crie um cluster de failover e instale o clustering do SQL Server.

A grande diferença é a adição da etapa 4, na qual agrupamos também todas as VMs convidadas. O argumento é que isso melhora ainda mais a manutenção, uma vez que não temos nenhum vínculo entre o cluster SQL e o hardware físico. Podemos, em teoria, migrar ao vivo as VMs convidadas em torno dos hosts sem afetar o cluster SQL, portanto, para a manutenção de rotina dos blades físicos, movemos o cluster SQL sem interrupção e sem a necessidade de failover.

Parece uma boa ideia, mas não encontrei nada na internet onde as pessoas digam que fizeram isso e que funciona bem. Posso realmente fazer as migrações ao vivo dos convidados sem que o cluster SQL hospedado neles fique perturbado?

Alguém tem alguma experiência com essa configuração, boa ou ruim? Existem alguns prós e contras que não considerei?

Entendo que o espelhamento também é uma opção valiosa a ser considerada - neste caso, estamos favorecendo o clustering, pois ele fará toda a instância e temos um bom número de bancos de dados. Alguns bancos de dados são para sistemas pesados ​​de terceiros que podem nem funcionar bem com espelhamento (e meu entendimento sobre clustering é que os failovers são completamente transparentes para os clientes).

Obrigado.

Answer 1

Se esses blades serão totalmente dedicados apenas à execução do SQL Server, por que você está se preocupando com a virtualização?

Por que você simplesmente não instala o Windows Server e o SQL Server em cada um deles e configura seu cluster adequadamente, sem a sobrecarga adicional de virtualização?

Answer 2

Parece complicado.

Eu teria que pesar a "complexidade" da sua solução com a confiabilidade e a relativa simplicidade de uma implementação de servidor SQL em cluster físico padrão.

TODOS os bancos de dados são de missão crítica? Na minha experiência, geralmente não, então costumo hospedar os bancos de dados mais importantes em servidores configurados com resiliência total e o restante (geralmente uma grande proporção) em servidores SQL simples.

Isso permite que você se concentre em manter os sistemas mais importantes em funcionamento, e não em tentar manter “todas as bolas no ar ao mesmo tempo”.

Todos os servidores precisarão de manutenção de rotina regular. Dada a regularidade, severidade e importância dos patches de segurança, deixamos de tentar manter um tempo de atividade teórico de 5 noves (que os usuários gostaram, mas na verdade não PRECISAM) para um mais realista "vamos manter os servidores seguros e seguro - mas haverá pequenas janelas de manutenção OBRIGATÓRIAS para nos permitir manter os servidores devidamente corrigidos."

Answer 3

Das opções listadas, eu escolheria a número 2, mas não agruparia o SQL (etapa 5) porque ela adiciona uma camada de complexidade da qual você não ganha muito. O clustering do Hyper-V já permitirá que você execute essa VM em qualquer host, para que você esteja protegido contra falhas de hardware.

Presumo que você esteja planejando usar VHDs de tamanho fixo para o log SQL e volumes de banco de dados.

Eu entendo perfeitamente os comentários de outras pessoas sobre ignorar completamente o Hyper-V e apenas usar os 2 blades como um cluster SQL normal - essa certamente seria a abordagem tradicional. No entanto, as vantagens de flexibilidade da virtualização de cargas de trabalho são enormes para manutenção, atualizações e falhas de hardware. A portabilidade das VMs é muito atraente.

Observe, porém, que o valor desta solução também depende do seu ambiente. Se você não tiver outros servidores Hyper-V e sua equipe não tiver muita experiência com Hyper-V, virtualizar uma de suas cargas de trabalho mais críticas pode não ser uma boa ideia. No entanto, se você é como muitas lojas de TI e começou a virtualizar servidores menos críticos, construiu alguns hosts e possui as habilidades e os procedimentos para executar o Hyper-V de maneira confiável, expandir esse foco para cargas de trabalho mais críticas é completamente razoável. Pessoalmente, prefiro gerenciar o cluster no nível do host em vez do nível SQL e acho que veremos isso sendo feito cada vez mais, embora ainda não seja tão comum.

Finalmente, suas perguntas sobre a execução de SQL no Hyper-V: sim, a migração ao vivo funcionará bem com SQL e não será notada - E - O espelhamento de banco de dados SQL é ótimo, mas sim, não é universalmente suportado, portanto não cabe em todos situação.

Answer 4

Acho que seu consultor está certo. Tenho exatamente a ideia que ele tem, que desejo implementar em meu ambiente atual. 2 peças físicas de hardware, cada peça de hardware executando o Hyper-V com 2 instalações W2k8.

1. Instale 2 VMs no primeiro host físico.
2. Instale SQL em VM1 e Mirror ou cluster para/com VM2 com configuração de tolerância a falhas no nível de sistema operacional para failover para ambiente replicado.
3. Instale o W2k8 no segundo servidor físico e no cluster de failover Hyper-V.

Isso fornece o nível completo de clustering de failover e H/A completo em seu ambiente SQL.

Ou talvez minha ideia seja estúpida?