Alta disponibilidade Hyper-V com SafeKit: Instale o módulo hyperv.safe para failover
Guia de instalação rápida de alta disponibilidade para Hyper-V
Este guia explica como configurar um cluster de espelhos para Hyper-V usando SafeKit, garantindo failover automático e replicação síncrona sem a necessidade de armazenamento compartilhado.
Para obter ajuda, você pode usar SafeKit AI 🤖.
1. Visão geral
- Arquitetura: Usa um sistema de dois nós (Primário/Secundário).
- Proteção de dados: Implementa replicação síncrona em tempo real para zero perda de dados (RPO=0).
2. Instalação
- Programas: Instale o mecanismo SafeKit em ambos os servidores.
- Módulo: Baixe o pré-configurado
hyperv.safemódulo de aplicação.
3. Configuração
- Consola Web: Configure as pastas específicas que contêm os arquivos Hyper-V.
- Monitoramento: Comece a monitorar e proteger o aplicativo Hyper-V.
Limitações de Alta Disponibilidade do SafeKit
| Limite / Requisito | Motivo e Impacto | Alternativa Recomendada |
|---|---|---|
| Tamanho da replicação: Alguns TBs | Tempo de ressynchronização após uma falha (etapa 3): • Rede de 1 Gb/s ≈ 3 horas / TB • Rede de 10 Gb/s ≈ 1 hora / TB (dependendo do desempenho de gravação em disco) | • Usar armazenamento compartilhado externo (mais caro, mais complexo). |
| Contagem de arquivos: < 1.000.000 arquivos | • Desempenho do tempo de ressynchronização após uma falha (etapa 3). • Tempo necessário para verificar cada arquivo entre ambos os nós. | • Colocar os vários arquivos a serem replicados em um disco rígido virtual / máquina virtual. • Nesse caso, apenas os arquivos que representam o disco rígido virtual / a máquina virtual serão replicados e ressynchronizados. |
| Capacidade de failover: ≤ 32 VMs | • Cada VM é executada em um módulo de espelhamento independente. • Máximo de 32 módulos de espelhamento em execução no mesmo cluster. | • Usar um armazenamento compartilhado externo e outra solução de clustering de VMs (mais caro, mais complexo). |
| Arquitetura de rede: Rede LAN/VLAN entre sites remotos | • Failover automático do endereço IP virtual com 2 nós na mesma sub-rede. • Boa largura de banda para ressynchronização (etapa 3). • Baixa latência para replicação síncrona: tipicamente < 5 ms de RTT; valores superiores devem ser validados em relação à taxa de gravação da aplicação. | • Usar um balanceador de carga para o endereço IP virtual se os 2 nós estiverem em 2 sub-redes diferentes (suportado pelo SafeKit, especialmente na nuvem). • Usar soluções de backup com replicação assíncrona para redes de alta latência. |
Visão geral da solução SafeKit / Hyper-V
A solução é descrita aqui: 💡Simples Hyper-V Alta disponibilidade sem armazenamento compartilhado (SAN)
Instalação da solução SafeKit/Hyper-V no Windows (hyperv.safe)
Pré-requisitos
- Função Hyper-V instalada em 2 nós Windows (incorporada gratuitamente em todas as versões Windows, incluindo Windows para PC).
- Aplicativos críticos instalados em uma ou mais máquinas virtuais.
- Máximo de 32 máquinas virtuais por host Hyper-V.
- Total de dados replicados limitado a alguns terabytes — além disso, o tempo de ressincronização torna-se significativo.
- Interconexão mínima de 1 Gb/s entre nós (10 Gb/s recomendados para ressincronização mais rápida).
- O failover IP requer ambos os nós no mesmo LAN ou LAN estendido (L2) — redes L3 roteadas não suportadas (exceto com 🛠️ cloud load balancers).
Sobre produtos sob licença LMS Siemens
- Para evitar a quebra da licença Siemens no failover, o dongle que contém a chave Siemens pode ser colocado em um dispositivo USB over IP (como DIGI AnywhereUSB).
- O dongle também pode ser colocado em um PC externo com o Servidor de licença LMS no PC.
- Nas versões recentes do sistema de licenciamento Siemens, a chave de licença pode ser colocada no Trusted Platform Module da VM.
Instalação do pacote em Windows
- Baixe e instale a versão gratuita do SafeKit em 2 nós Windows.
Nota: a versão gratuita inclui todos os recursos do SafeKit. No final da avaliação, você poderá ativar chaves de licença permanentes sem desinstalar o pacote. - Ao concluir a instalação do pacote, selecione Set console credentials and firewall rules now e configure uma senha para o admin usuário do console SafeKit.
Defina a mesma senha em todos os nós. - Excluir das verificações antivírus C:/safekit/ (o diretório de instalação padrão) e todas as pastas replicadas que você vai definir.
Os antivírus podem enfrentar desafios de detecção com o SafeKit devido à sua estreita integração com o sistema operacional, mecanismos de IP virtual, replicação em tempo real e reinicialização de serviços críticos.
Instalação do módulo em Windows
- Baixe o módulo hyperv.safe. O módulo é gratuito. Ele contém os arquivos userconfig.xml e os scripts de reinicialização.
- Colocar hyperv.safe sob C:/safekit/Application_Modules/generic.
Baixar hyperv.safe (Windows) >
Configuração passo a passo da solução SafeKit / Hyper-V
⚠️ Leia atentamente estes itens antes de começar:
- A configuração Hyper-V é apresentada com uma máquina virtual chamada
VM1. Leia atentamente “1. Pré-requisitos” para o organização de arquivos VM1 , caso contrário, a recuperação no nó secundário poderá falhar com dados inconsistentes. - Você terá que repetir esta configuração para todas as VMs que deseja replicar e reiniciar.
- O sistema de arquivos onde estão armazenados os arquivos da VM replicados por SafeKit deve ser NTFS; ReFS não é compatível.
- SafeKit suporta replicação de Pontos de verificação de produção Hyper-V, mas não pontos de verificação padrão. Não use pontos de verificação padrão; caso contrário, a recuperação no nó secundário poderá falhar com dados inconsistentes.
1. Pré-requisitos
Para replicação SafeKit, todos os arquivos da máquina virtual VM1 (arquivo de configuração, disco rígido virtual, etc.) devem ser armazenados na mesma pasta, mesmo que esse não seja o comportamento padrão do Hyper-V (por exemplo, D:/Repli-Hyper-V/VM1, onde VM1 é o nome da máquina virtual).
Se todos os arquivos de VM1 não estiverem na mesma pasta, use o gerenciador Hyper-V:
- Exporte VM1 em uma pasta, por exemplo em D:/Repli-Hyper-V
- Esta exportação criará uma pasta D:/Repli-Hyper-V/VM1 contendo todos os arquivos VM1
- Remova VM1 do inventário do gerente Hyper-V
- Importe VM1, previamente exportado, para o gerenciador Hyper-V
⚠️ Tire um snapshot da sua VM antes de iniciar o procedimento.
⚠️ VM1 deve ser criado apenas em um único nó. A única coisa a ser criada no outro nó é o diretório VM1 (D:/Repli-Hyper-V/VM1).
⚠️ Certifique-se de que os nomes dos switches virtuais referenciados pela máquina virtual existam em ambos os servidores Hyper-V e correspondam à mesma rede física.
⚠️ O failover do módulo Hyper-V (hyperv.safe) poderá falhar se os pré-requisitos de migração da VM não forem atendidos. Para detectar problemas de compatibilidade entre nós do Hyper-V (hardware, rede, configuração), consulte🛠️ KB SK-0088 neste documento.
2. Inicie o console SafeKit
- Inicie o console da web em um navegador em um nó do cluster conectando-se a
http://localhost:9010. - Entrar
admincomo nome de usuário e a senha definida durante a instalação.
Também é possível executar o console em um navegador em uma estação de trabalho externa ao cluster.
⚠️ A configuração do SafeKit é feita em ambos os nós a partir de um único navegador.
ℹ️ Para proteger o console da web, consulte 🛠️ 11\. Protegendo o serviço da web SafeKit no Guia do usuário.

3. Configure endereços de nós
- Insira os endereços dos nós IP, pressione o botão
Tab keypara verificar a conectividade e preencher os nomes dos nós. Se o nó1 ou o nó2 tiver a cor vermelha, verifique a conectividade do navegador com ambos os nós e verifique o firewall em ambos os nós para 🛠️ solução de problemas. - Em seguida, clique em
Save and applypara salvar a configuração. - Verifique o
Success✅ mensagem em ambos os nós. - Se a configuração
Failure❌ ocorre em um nó, abra o acordeão ▼ desse nó e revise as mensagens. Observe que você pode usar SafeKit AI 🤖 para obter assistência.
ℹ️ Se desejar, você pode adicionar um novo LAN and nodes (primeiro ➕) para criar uma segunda pulsação e uma rede de replicação dedicada.
ℹ️ Se você clicar em Advanced configuration, o cluster.xml arquivo é exibido. Este arquivo é preenchido automaticamente pelo console e implementado nos nós.

4. Selecione um módulo
- Em
New module, clique nohyperv.safemódulo.
ℹ️ No banner azul na parte superior, 🛜 node1 representa o nó de conexão do console. Este nó retransmite solicitações para node2 quando necessário.
ℹ️ O console procura xxx.safe no Application_Modules/generic/ diretório no nó de conexão (node1) se você colocou um módulo lá durante a instalação.

5. Configure o módulo
- Escolha um
Automaticinício do módulo na inicialização sem demora. - Normalmente, você tem um único
Heartbeatrede na qual a replicação é feita. Porém, você pode definir uma rede privada, se necessário (adicionando um LAN na etapa 3). - Colocar
VM_PATH, o caminho raiz do diretório replicado (D:/Repli-Hyper-V). - Entre
VM_NAME, o nome da máquina virtual (VM1).
Assumimos que todos os arquivos VM1 estão em D:/Repli-Hyper-V/VM1 (veja pré-requisitos). Este diretório será replicado em tempo real pelo SafeKit. Não execute replicação parcial, pois o failover não funcionará.
O NORMAL_STOP e FORCE_STOP os valores podem ser “stop”, “save“ou”off”:
- “
stop” desliga a VM quando o módulo é interrompido. - “
save” salva o estado atual da VM (suspender) quando o módulo é interrompido. - “
off” desliga a VM (desliga) quando o módulo é parado.
“stop” é recomendado porque causa o desligamento e depois a reinicialização da VM quando o módulo é parado e reiniciado. Assim, se a aplicação dentro da VM falhar, ela será reiniciada.
Este será o caso, por exemplo, ao alternar entre funções primárias e secundárias.
ℹ️ Você não precisa configurar um endereço IP virtual. VM1 será reinicializado no Hyper-V secundário com seu endereço físico IP, e este endereço IP será redirecionado.
ℹ️ Ao aplicar a configuração SafeKit, o Automatic Start Action da máquina virtual está configurada para Nothing em Hyper-V. Isso garante que a VM não seja iniciada automaticamente quando o host Hyper-V for iniciado, mas apenas quando o próprio módulo for iniciado.

6. Verificador personalizado para detectar mau funcionamento da VM
O verificador personalizado envia mensagens de pulsação do host para a VM em intervalos regulares. É então tarefa do serviço de pulsação Hyper-V instalado na VM enviar uma resposta a cada uma dessas mensagens de pulsação.
Se o Hyper-V Heartbeat Service não responder à mensagem (VM travada, travada ou deixou de funcionar), o verificador customizado executa uma ação para reiniciar a VM no mesmo nó Hyper-V ou em outro.
- Clique em
Checkers / Custom(ver imagem). - Basta definir um nome de sua escolha em
Resource name(exemplo VM1).Resource nameidentifica a máquina virtual com um nome de recurso em SafeKit:custom.VM1. - Com
restartemAction, a VM será reiniciada no mesmo nó Hyper-V. Após três reinicializações malsucedidas em 24 horas, o módulo SafeKit hyperv para no nó primário e há um failover da VM no nó secundário. - Se você definir
stopstartemAction, haverá um failover direto no outro nó Hyper-V assim que a VM não responder às pulsações.
ℹ️ Para manutenção, caso queira parar a máquina virtual, o verificador personalizado irá reiniciá-la automaticamente. Para evitar isso, você pode temporariamente suspenda o verificador 🖼️. Ou você pode removê-lo excluindo a linha de configuração no console.
ℹ️ O mesmo acontece quando você deseja restaurar um ponto de verificação. Hyper-V interromperá a VM para executar a operação e o verificador de VM poderá reagir negativamente reiniciando automaticamente a VM. Para evitar isso, suspenda o verificador 🖼️ antes de prosseguir com a operação.
ℹ️ Por padrão, o verificador personalizado permite 50 segundos para a VM inicializar antes de considerá-la indisponível. Se sua VM Hyper-V exigir mais tempo para iniciar, você poderá aumentar esse atraso adicionando -InitialGrace ao verificador customizado vmcheck.ps1 em userconfig.xml. O valor é expresso em incrementos de 5 segundos. Por exemplo, -InitialGrace 20 permite um período de carência de 100 segundos: <custom ident="VM1" exec="vmcheck.ps1" arg="%VM_NAME% -InitialGrace 20" when="prim" action="restart"></custom>.

7. Edite scripts (opcional)
- Não edite scripts.
8. Criptografia de comunicação (opcional)
- Mantenha a criptografia da comunicação entre os nós.

9. Salve e aplique
Save and applya configuração e os scripts em ambos os nós.

10. Verifique a configuração bem-sucedida
- Verifique o
Success✅ mensagem em ambos os nós e clique emMonitor modules. - Se a configuração
Failure❌ ocorre em um nó, abra o acordeão ▼ desse nó e revise as mensagens. Observe que você pode usar SafeKit AI 🤖 para obter assistência.

11. Inicie o nó com dados atualizados
- Se o nó 1 tiver o diretório replicado atualizado para
VM1/, selecione-o e ⋯Force start▶As primary.
Quando o nó 2 for iniciado, todos os dados serão copiados do nó 1 para o nó 2.
⚠️ Se você fizer a escolha errada, corre o risco de sincronizar dados desatualizados em ambos os nós.
⚠️ Supõe-se também que VM1 é interrompido no nó 1 para que SafeKit instale os mecanismos de replicação e então inicie VM1 no start_prim roteiro.
⚠️ Usar Start para inicializações subsequentes: SafeKit mantém o servidor mais atualizado. Começando As primary é uma inicialização especial na primeira vez ou durante operações excepcionais.

12. Aguarde a transição para ALONE (verde)
- O nó 1 deve atingir o estado ALONE (verde), o que significa que o
start_primscript foi executado no nó 1.
⚠️ Se ALONE (verde) não for alcançado ou se VM1 não for iniciado, analise o porquê com o registro do módulo 🖼️ do nó 1.
- Clique no 🔍 registro ícone de
node1para abrir o log do módulo e procurar mensagens de erro, como um verificador detectando um erro e parando o módulo. - Clique em
start_primno log: mensagens de saída do script são exibidas à direita e erros podem ser detectados, como VM1 iniciado incorretamente. - Use SafeKit AI 🤖 para obter assistência com mensagens de log.
⚠️ Se o cluster estiver em WAIT (red) not uptodate, STOP (red) not uptodate estado, pare o nó WAIT e forçar seu início como primário 🖼️.

13. Iniciar nó 2
- ⋯
Startnó 2 com seu menu contextual. - Aguarde o estado SECOND (verde).
ℹ️ O nó 2 permanece no estado SECOND (laranja) enquanto ressincroniza os diretórios replicados (copia do nó 1 para o nó 2).
- Isso pode demorar um pouco, dependendo do tamanho dos arquivos a serem ressincronizados nos diretórios replicados e da largura de banda da rede.
- Para ver o progresso da cópia, consulte o registro do módulo 🖼️ e o recursos de replicação 🖼️ do nó 2. Use SafeKit AI 🤖 para obter assistência com mensagens de log.
ℹ️ Ao usar discos diferenciais Hyper-V, apenas o disco diferencial precisa de ressincronização após a sincronização inicial, economizando tempo para discos rígidos virtuais grandes.

14. Verifique se o cluster está operacional
- Verifique se o cluster está verde/verde com
VM1em execução no nó PRIM e não em execução no nó SECOND.
Somente as alterações dentro dos arquivos são replicadas em tempo real neste estado.

15. Teste
- Pare o nó PRIM rolando para baixo em seu menu contextual e clicando
Stop. - Verifique se há um failover no nó SECOND que deve se tornar ALONE (verde).
- Verifique com o gerente Hyper-V se
VM1está em execução no nó 2.
⚠️ Se ALONE (verde) não for alcançado no nó2 ou se VM1 não for iniciado, analise o porquê com o registro do módulo 🖼️ do nó 2.
- Clique no 🔍 registro ícone de
node2para abrir o log do módulo e procurar mensagens de erro, como um verificador detectando um erro e parando o módulo. - Clique em
start_primno log: mensagens de saída do script são exibidas à direita e erros podem ser detectados, como VM1 iniciado incorretamente. - Use SafeKit AI 🤖 para obter assistência com mensagens de log.
⚠️ Como o start_prim script importa a máquina virtual no nó 2, o failover pode falhar por causa de 🛠️ Configurações Hyper-V (consulte KB SK-0088 neste documento).
⚠️ Se tudo estiver bem, inicie uma inicialização no node1, que irá ressincronizar os diretórios replicados do node2.
Se as coisas derem errado, pare o node2 e forçar o início como primário 🖼️ do nó1, que será reiniciado com seus dados localmente íntegros no momento da parada.
ℹ️ Observe que você tem um 🕒 linha do tempo 🖼️ isso pode ser útil para entender o que acontece no cluster.

16. Se necessário, configure um verificador splitbrain
- Veja Quais são os diferentes cenários em caso de isolamento de rede num cluster? para saber se você precisa configurar um verificador splitbrain.
- Acesse a configuração do módulo e clique em
Checkers / Splitbrain(ver imagem) para editar os parâmetros do splitbrain. Save and applya nova configuração para reimplantá-la em ambos os nós (o módulo deve ser interrompido em ambos os nós para salvar e aplicar).
Parâmetros :
Resource nameidentifica a testemunha com um nome de recurso:splitbrain.witness. Você pode alterar esse valor para identificar a testemunha.Witness addressé o argumento para um ping quando um nó vai de PRIM para ALONE ou de SECOND para ALONE. Altere esse valor com o IP da testemunha (um elemento robusto, normalmente um roteador).- Nota: você pode definir vários IPs separados por espaços em branco. Preste atenção que os endereços IP devem ser acessíveis a partir de um nó, mas não do outro em caso de isolamento da rede.

17. Reinicialização automática se um serviço crítico falhar dentro da VM
Se desejar uma reinicialização ou failover automático quando um serviço crítico dentro da VM falhar, você pode configurar as propriedades de recuperação do serviço (veja a imagem).
Primeiro você deve configurar o Verificador personalizado de VM descrito anteriormente.
E então no Microsoft Service Manager dentro da VM, selecione seu serviço crítico e na propriedade de recuperação do serviço, basta configurar o desligamento da VM quando o serviço crítico falhar.
Para isso, nas opções de Recuperação do seu serviço crítico, escolha “Execute um programa “em caso de falhas e nas opções Executar programa, defina”C:/Windows/System32/shutdown.exe " e em “Parâmetros de linha de comando”, defina /s /c “serviço falha”.
Claro, você pode implementar uma recuperação mais sutil com seus próprios scripts. Mas esteja ciente de que desligar a VM ativará o verificador personalizado no host. O verificador personalizado detectará que a pulsação Hyper-V não está mais respondendo e reiniciará a VM no mesmo servidor Hyper-V ou fará um failover no outro servidor Hyper-V (dependendo de sua configuração).
Para testar o recurso, use o Gerenciador de Tarefas e elimine o processo (Finalizar tarefa) associado ao serviço crítico. Uma parada limpa do serviço por meio do Service Manager ou do comando “net stop” não aciona a ação de recuperação dentro do Windows Service Manager.

18. Suporte
- Para obter suporte, leve 2 SafeKit
Snapshots(2 arquivos .zip), um para cada nó.
ℹ️ Mais informações sobre o suporte aqui.

Demonstração da solução SafeKit/Hyper-V
Vídeo SafeKit: Clustering em nível de máquina virtual com Hyper-V (5:15)
Neste vídeo, descubra como o SafeKit implementa alta disponibilidade para Hyper-V sem a complexidade de uma SAN. Aprenda a configurar replicação de máquina virtual em dois nós para garantir failover contínuo para suas cargas de trabalho virtualizadas críticas. Embora esta demonstração use Hyper-V no Windows, a solução funciona de forma idêntica ao KVM no Linux.
Capítulos
- 🎬 Visão geral da arquitetura: 2 nós Hyper-V e 2 máquinas virtuais (0:49)
- 🎬 Configurando o cluster e os módulos hyperv.safe (1:59)
- 🎬 Testes em tempo real: replicação de VM, migração e failover automático em caso de falha (2:26)
Implementação passo a passo
- 🛠️ Leia o guia para configurar um cluster Hyper-V espelhado no Windows.
- 🛠️ Leia o guia para configurar um cluster KVM espelhado no Linux.
🔍 Hub de Navegação de Alta Disponibilidade SafeKit
Explore o SafeKit: Recursos, vídeos técnicos, documentação e teste gratuito
| Tipo de Recurso | Descrição | Link Direto |
|---|---|---|
| Recursos Principais | Por que escolher o SafeKit para uma Alta Disponibilidade simples e econômica? | Veja por que escolher o SafeKit para Alta Disponibilidade |
| Casos de Uso | Descubra como o SafeKit garante a alta disponibilidade de infraestruturas críticas | Ver todos os casos de uso (Software OEM, Servidores Edge, SCADA e mais) |
| Modelo de Implantação | HA SANless Tudo-em-Um: Clustering de Software Shared-Nothing | Veja o SafeKit HA SANless Tudo-em-Um |
| Estratégias de HA | SafeKit: Infraestrutura (VM) vs. Alta Disponibilidade no Nível da Aplicação | Veja SafeKit HA & Redundância: VM vs. Nível de Aplicação |
| Especificações Técnicas | Limitações Técnicas para o Clustering SafeKit | Veja as Limitações de Alta Disponibilidade do SafeKit |
| Vídeos | SafeKit: Configuração de Alta Disponibilidade e Demos de Failover | Veja os Tutoriais de Failover do SafeKit |
| Arquitetura | Como funciona o Mirror Cluster do SafeKit (Replicação e Failover em Tempo Real) | Veja SafeKit Mirror Cluster: Replicação em Tempo Real e Failover |
| Arquitetura | Como funciona o Farm Cluster do SafeKit (Balanceamento de Carga de Rede e Failover) | Veja SafeKit Farm Cluster: Balanceamento de Carga de Rede e Failover |
| Vantagens Competitivas | Comparação: SafeKit vs. Clusters de Alta Disponibilidade (HA) Tradicionais | Veja a Comparação: SafeKit vs. Cluster de HA Tradicional |
| Recursos Técnicos | Alta Disponibilidade SafeKit: Documentação, Downloads e Teste | Veja Teste Gratuito e Documentação Técnica do SafeKit HA |
| Soluções Pré-configuradas | Biblioteca de Módulos de Aplicação SafeKit: Soluções de HA Prontas para Uso | Veja os Módulos de Aplicação de Alta Disponibilidade SafeKit |