Máquinas virtuais de alta disponibilidade

Question

Eu tenho lido muito sobre virtualização de alta disponibilidade, seja via Hyper-V ou VMWare. Nesse contexto, essencialmente alta disponibilidade significa que a VM é hospedada por um cluster de servidores físicos (nós), portanto, se um dos servidores físicos ficar inativo, a VM ainda poderá ser atendida por outros servidores físicos. Até aí tudo bem, o cluster físico e a própria VM estão altamente disponíveis.

No entanto, se o serviço fornecido, digamos SQL server, MSDTC ou qualquer outro serviço, estiver sendo fornecido pela imagem da VM e pelo sistema operacional virtualizado. Então, imagino que ainda há um ponto de falha na camada virtual que não é contabilizado. Algo poderia acontecer dentro da própria máquina virtual que o cluster físico não pode explicar, correto? Nessa instância, o cluster de failover físico (Hyper-V) ou o host VMWare não podem fazer failover, porque o problema não é com um dos servidores no cluster físico - a falha em um nó físico não faria nenhum bem.

Isso requer a criação de um cluster de failover virtual em cima do físico, ou isso não é necessário?

Como alternativa, suponho que você possa ignorar o clustering phsyical e apenas clusterizar na camada virtual (clustering de failover baseado em filho), porque isso ainda deve sobreviver a uma falha física.

Veja a imagem abaixo mostrando pai baseado (à esquerda), filho (à direita) e uma combinação (centro). O pai é baseado tanto quanto você precisa ir, ou é baseado em filho mais apropriado?

    

Answer 1

A resposta é que depende.

As soluções de cluster geralmente fazem mais do que a camada de aplicativo. Tradicionalmente, um gráfico de dependência de cluster incluirá coisas como

1. Verificação de disponibilidade de rede / IP
2. Armazenamento / compartilhamento de disponibilidade de volume.

Executar algumas dessas verificações dentro de uma VM é extremamente difícil. Por exemplo, Nos Clusters do Windows 2003, é necessária uma unidade de quorum que use um bloqueio SCSI para garantir que seja o proprietário dos recursos. Em falhas, também envia 'pacotes de veneno' para adquirir esse bloqueio. Todos esses recursos são quase impossíveis de implementar sem um RDM para um LUN.

Todos esses componentes de 'detecção de hardware' terão uma grande sobrecarga dentro de uma VM (o desempenho da VM é sempre ótimo para aplicativos de usuário, mas qualquer base de kernel sempre incorrerá em graus variáveis de sobrecarga).

Assim, no caso de clusters do Microsoft Windows 2003 (e tive que virtualizar, usei sua abordagem 'filho').

O lugar ideal para se lutar é,

• VMware HA para detecção de falhas de hardware.
• monitoramento de aplicativos do vSphere

Seguido por

• VMware HA
• Um monitor de aplicativo somente (sem a dependência de hardware)
• Certifique-se de que a afinidade anti está ativada para as VMs emparelhadas, para que o DRS e o HA nunca reiniciem os nós nos mesmos hosts!

Finalmente

• Agrupamento filho

Answer 2

O cluster físico torna seu hardware virtual altamente disponível, ou seja, as falhas de um servidor físico não afetam nenhuma determinada máquina virtual. No entanto, a própria máquina virtual ainda pode falhar (por exemplo, queda do sistema operacional, desligamento de alguém do servidor virtual etc.), portanto, o serviço em execução na máquina virtual ainda pode falhar em algum momento (embora seja menos provável do que seja para o mesmo serviço executado em hardware físico autônomo). Para atenuar esse risco, você cria o serviço em cluster, para que o serviço não seja afetado, mesmo se um servidor virtual falhar. É claro que você poderia obter mais ou menos os mesmos resultados, se você criasse o serviço em cluster diretamente em servidores físicos.

O fato de você executar seu serviço em cluster em servidores físicos ou em cima de uma plataforma de virtualização em cluster depende dos seus requisitos. Se você não precisar de uma plataforma de virtualização para qualquer outra coisa ou o serviço em cluster precisar de muitos recursos do sistema, recomendo a criação do cluster em hardware físico. Mas se seu hardware físico tiver recursos de sobra ou se você já tiver um cluster de virtualização, eu executaria o serviço em cluster na máquina virtual, porque isso torna o gerenciamento do hardware (virtual) muito mais fácil.

    

Answer 3

Não se esqueça de tomar uma pílula de realidade ao longo do caminho, no entanto.

Você precisa entender o tempo de atividade necessário para seu aplicativo e, mais importante, o tempo máximo que o seu aplicativo pode ficar indisponível quando ele falhar. E vai.

Este segundo ponto é crítico; Eu vi um aplicativo "cinco noves" sendo gerenciado por um integrador de sistemas grande que ficou offline por quase um dia porque a complexidade da tecnologia sendo usada para mantê-lo altamente disponível. Para a disponibilidade operacional do dia-a-dia, a tecnologia marcava as caixas, mas quando algo dava errado com a configuração, as pessoas da empresa mencionada estavam devidamente presas.

Não me entenda mal, clusters, snapshots de SAN, snapshots de VM, replicação externa, virtualização de etapas de bloqueio de alta disponibilidade, Etc. têm seu lugar, mas apenas escolha o que for necessário, não o que parecer legal brilhante.

Eu sairei da minha caixa de sabão agora; -)

    

Answer 4

Does this necessitate building a virtual failover cluster on top of the physical one, or is this not necessary?

Sim.

    

Answer 5

Primeiro você precisa criar um sistema de alta disponibilidade (para SQL, para o sistema operacional, etc). Isso significa que você deve ter mais de um computador físico ou virtual e usar software capaz de oferecer suporte a alta disponibilidade.

Depois disso, você pode usar um sistema de virtualização de alta disponibilidade, que "apenas" protege você contra falhas de hardware.

O segundo nível de alta disponibilidade requer 2 computadores físicos (ou mais).
Então, digamos que seu primeiro nível de alta disponibilidade seja feito com 2 computadores: agora você não precisa se preocupar com o segundo nível, porque isso não lhe dará nada melhor.

    

Answer 6

Eu acho que você tem a essência das idéias sobre a disponibilidade abaixo. A funcionalidade de Hyper-v e VMware HA não fornece HA aos convidados, apenas a alta disponibilidade do serviço de virtualização. Com base nos requisitos de disponibilidade dos serviços ao cliente, você também precisa de HA no nível de convidado (e dependendo da tecnologia envolvida pode significar clustering). Você precisa avaliar cada serviço para os detalhes sobre como fornecer o tempo de atividade necessário. O SQL Server, por exemplo, pode usar espelhamento de transação ou cluster de servidor. Muitas vezes, a sobrecarga adicional e os desafios em clustering nos serviços virtuais superam os benefícios fornecidos e isso pode significar que o serviço acaba sendo fornecido em hardware dedicado. (escolhendo um pouco o sql server) O SQL Server é normalmente um potencial candidato a permanecer físico devido ao potencial de alta utilização de rede, E / S, CPU e memória, bem como a necessidade de redundância.

    

Answer 7

Se você quiser realmente HA, precisará agrupar suas HA-VMs também, sim.

Se você quiser evitar todos os SPOF você terá dificuldades.

• Use hardware diferente - nem uma única peça deve ser do mesmo fornecedor
• Use software diferente - incluindo o sistema operacional
• Use linguagens de programação diferentes para o mesmo aplicativo
• Use compiladores diferentes para o aplicativo
• Use diferentes fornecedores de rede para cada conjunto de conexão redundante
• Use provedores de energia diferentes
• Use locais diferentes para seus servidores
• ...

Uma vez eu participei de um curso para um sistema NAS, onde eles nos disseram que a NASA segue esse caminho - cada peça existe em três sabores diferentes. Somente se pelo menos dois deles tiverem o mesmo resultado, o resultado é ok. Além disso, tudo tem que ser redundante (em cada uma das três partes).

No pré-voo, todos os três têm que entregar o mesmo resultado, é claro.