Quando configurei pela primeira vez um cluster Hyper-V 2012 de 2 nós, o failover foi praticamente instantâneo. Eu tinha uma VM Sql Server 2012 (no Win2012) com 8 GB de RAM alocados para ela. Eu poderia devolver o nó em que ele estava e ele pularia para o outro nó sem interromper minha conexão Sql.
Depois adicionei uma segunda VM ao cluster (clone da primeira VM), também com 8GB. 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 quorum?
No meu caso, ambos os nós estão conectados ao mesmo DAS e os arquivos VM residem em CSVs. Eu esperaria que os discos não fossem um fator, já que nada precisa ser movido. Deveria ser tudo RAM, certo? Então, à medida que a RAM aumenta, o desempenho do failover diminui?
Responder1
Em retrospecto, acho que deveria saber. A resposta está em duas partes, porque, na 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 de cluster drenando o nó e reiniciando-o para você. Portanto, quando você reinicializa diretamente o nó via RDP ou "Stop Cluster Service" na GUI do aplicativo Clustering, a primeira coisa que acontece é que as VMs são migradas ao vivo. Como você está apenas migrando as VMs em tempo real, o tempo que leva depende do que precisa ser transferido e da conexão de rede. Se você tiver uma NIC de 1 Gb, vai demorar um pouco (~ 118 MB/seg). Quanto mais RAM suas VMs tiverem, maismelhor atendido você será por NICs mais rápidos.
Failover real
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, é o mesmo que se você "desligasse" e iniciasse novamente. Portanto, um failover "real" sempre será sobre quanto tempo leva para suas VMs inicializarem.
Tangente
Isso é uma decepção para mim, conceitualmente, porque sinto que toda a conversa sobre clustering na 'Net sugere que uma falha de nó ("hard") está escondida pelo sistema de cluster --- deveria ser como se os serviços nunca foi abaixo. Provavelmente é propagado pelo fato de que todas as páginas da web que me lembro de ter lido testaram o failover de cluster em software (failover planejado). Então, tudo o que eles estão realmente fazendo é provar que o Live Migration funciona conforme anunciado (sem tempo de inatividade da perspectiva do cliente).
Meu principal erro foi entender mal o próprio failover. Além do conceito de ter um servidor de backup quente/quente/frio, onde o failover automático ocorre em um servidor quente, também existe o failover quente/quente/frio. Como mencionadoaqui, o failover a quente é instantâneo, o failover a quente é medido em segundos e o failover a frio é medido em minutos. Fui ingênuo ao presumir que toda falha automática é "quente". Acho que esperava 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 máquinas que fosse pelo menos tão rápido quanto a RAM para garantir que funcionaria.