Como posso acelerar o failover automático de um cluster do Hyper-V 2012?

Question

Quando configurei pela primeira vez um cluster Hyper-V 2012 de 2 nós, o failover foi praticamente instantâneo. Eu tinha uma VM do Sql Server 2012 (no Win2012) com 8 GB de RAM alocada para ela. Eu poderia pular o nó em que ele estava vivendo e pularia para o outro nó sem perder minha conexão Sql.

Em seguida, adicionei uma segunda VM ao cluster (clone da primeira VM), também com 8 GB. Agora o failover leva alguns segundos e minha conexão Sql é redefinida. É um fator da quantidade de RAM que precisa ser movida? É afetado pela rede? É a velocidade do disco de quorum?

No meu caso, os dois nós estão conectados ao mesmo DAS e os arquivos da VM estão em CSVs. Eu esperaria que os discos não sejam um fator, já que nada precisa ser movido. Tudo deve ser RAM, certo? Então, conforme a RAM aumenta, o desempenho de failover diminui?

    

Answer 1

Em retrospecto, eu acho que deveria saber. A resposta está em duas partes, porque, em minha opinião, há failover planejado e failover "real" / não planejado - e o failover planejado não conta.

Failover planejado

O failover planejado é, na verdade, apenas o sistema Clustering que drena o nó e, em seguida, o reinicia para você. Portanto, quando você reinicializa o nó diretamente via RDP ou "Stop Cluster Service" na GUI do aplicativo Cluster, a primeira coisa que acontece é que as VMs desativam o Live Migrated. Como você é realmente apenas o Live Migrating the VMs, o tempo que leva depende do que precisa ser transferido e da conexão de rede. Se você tiver uma placa de rede de 1 Gb, levará algum tempo (~ 118 MB / s). Quanto mais RAM suas VMs tiverem, o melhor servido você será por NICs mais rápidos .

Real failover

O failover não planejado / "real" ocorre quando você desconecta a máquina. Nesse caso, o sistema de cluster inicia automaticamente a VM em outro nó. O comportamento para o mundo exterior é o mesmo que se você tivesse reiniciado a VM. Para a VM, é como se você tivesse "desativado" e iniciado novamente. Portanto, um failover "real" sempre será sobre quanto tempo suas VMs carregam.

Tangente

Isto é uma decepção para mim, conceitualmente, porque eu sinto que toda a conversa de agrupamento no 'Net sugere que uma falha de nó (de hard) está escondida pelo sistema de cluster --- é como se fosse os serviços nunca caíram. É provável que seja propagado pelo fato de que todas as páginas da Web que eu lembro de ler testaram seu failover de cluster no software (failover planejado). Então, tudo o que eles realmente fazem é provar que o Live Migration funciona como anunciado (sem tempo de inatividade na perspectiva do cliente).

Meu erro principal foi entender mal o próprio failover. Além do conceito de ter um servidor de backup quente / quente / frio, em que o failover automático ocorre em um servidor ativo, também há failover de hot / warm / cold. Conforme mencionado aqui , o failover a quente é instantâneo, o failover a quente é medido em segundos, e o failover a frio é medido em minutos. Eu era ingênuo para assumir que toda falha automática é "quente". Eu acho que eu estava esperando algum tipo de mágica com a RAM, onde o cluster atualizaria uma cópia da RAM da VM em outro nó - algo como envio de log de transações com o Sql Server. Mas isso exigiria um canal de comunicação entre as máquinas que é pelo menos tão rápido quanto a RAM para garantir que funcionaria.