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 utilizando SafeKit, garantindo failover automático e replicação síncrona sem necessidade de armazenamento partilhado.
Para obter ajuda, pode utilizar SafeKit AI 🤖.
1. Visão geral
- Arquitetura: Utiliza um sistema de dois nós (Primário/Secundário).
- Proteção de dados: Implementa a replicação síncrona em tempo real para zero perda de dados (RPO=0).
2. Instalação
- Programas: Instale o motor SafeKit em ambos os servidores.
- Módulo: Descarregue o pré-configurado
hyperv.safemódulo de aplicação.
3. Configuração
- Consola Web: Configure as pastas específicas que contêm os ficheiros Hyper-V.
- Monitorização: Comece a monitorizar e a proteger a aplicação Hyper-V.
Limitações de Alta Disponibilidade do SafeKit
| Limite / Requisito | Motivo e Impacto | Alternativa Recomendada |
|---|---|---|
| Tamanho da replicação: Alguns TB | Tempo de ressincronizaçã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 escrita em disco) | • Utilizar armazenamento partilhado externo (mais caro, mais complexo). |
| Contagem de ficheiros: < 1.000.000 ficheiros | • Desempenho do tempo de ressincronização após uma falha (etapa 3). • Tempo necessário para verificar cada ficheiro entre ambos os nós. | • Colocar os vários ficheiros a replicar num disco rígido virtual / máquina virtual. • Nesse caso, apenas os ficheiros que representam o disco rígido virtual / a máquina virtual serão replicados e ressincronizados. |
| Capacidade de failover: ≤ 32 VMs | • Cada VM é executada num módulo de espelho independente. • Máximo de 32 módulos de espelho em execução no mesmo cluster. | • Utilizar um armazenamento partilhado externo e outra solução de clustering de VMs (mais caro, mais complexo). |
| Arquitetura de rede: Rede LAN/VLAN entre locais remotos | • Failover automático do endereço IP virtual com 2 nós na mesma sub-rede. • Boa largura de banda para a ressincronização (etapa 3). • Baixa latência para replicação síncrona: tipicamente < 5 ms de RTT; valores superiores devem ser validados em função da taxa de escrita da aplicação. | • Utilizar um balanceador de carga para o endereço IP virtual se os 2 nós se encontrarem em 2 sub-redes (suportado pelo SafeKit, especialmente na cloud). • Utilizar soluções de cópia de segurança com replicação assíncrona para redes de alta latência. |
Visão geral da solução SafeKit / Hyper-V
A solução está descrita aqui: 💡Simples Hyper-V Alta disponibilidade sem armazenamento partilhado (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).
- Aplicações críticas instaladas 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.
- Interligação mínima de 1 Gb/s entre nós (recomenda-se 10 Gb/s para uma ressincronização mais rápida).
- O failover IP requer ambos os nós no mesmo LAN ou LAN estendido (L2) — redes L3 não suportadas com encaminhamento (exceto com 🛠️ cloud load balancers).
Sobre os 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 num dispositivo USB over IP (como o DIGI AnywhereUSB).
- O dongle também pode ser colocado num PC externo com o Servidor de licenças 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
- Descarregue e instale a versão gratuita do SafeKit em 2 nós Windows.
Nota: a versão gratuita inclui todas as funcionalidades do SafeKit. No final da avaliação, poderá ativar as 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 palavra-passe para o admin utilizador da consola SafeKit.
Defina a mesma palavra-passe em todos os nós. - Apagar das verificações antivírus C:/safekit/ (o diretório de instalação padrão) e todas as pastas replicadas que vai definir.
Os antivírus podem enfrentar desafios de deteção com o SafeKit devido à sua estreita integração com o sistema operativo, mecanismos de IP virtual, replicação em tempo real e reinicialização de serviços críticos.
Descarregue SafeKit (Windows) >
Instalação do módulo em Windows
- Descarregue o módulo hyperv.safe. O módulo é gratuito. Contém os ficheiros userconfig.xml e os scripts de reinicialização.
- Colocar hyperv.safe sob C:/safekit/Application_Modules/generic.
Download 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 ficheiros VM1 , caso contrário, a recuperação no nó secundário poderá falhar com dados inconsistentes. - Terá de repetir esta configuração para todas as VMs que pretende replicar e reiniciar.
- O sistema de ficheiros onde estão armazenados os ficheiros da MV replicados por SafeKit deve ser NTFS; ReFS não é compatível.
- O SafeKit suporta a replicação de Pontos de verificação de produção Hyper-V, mas não pontos de verificação padrão. Não utilize 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 a replicação SafeKit, todos os ficheiros da máquina virtual VM1 (ficheiro de configuração, disco rígido virtual, etc.) devem ser armazenados na mesma pasta, mesmo que este não seja o comportamento padrão do Hyper-V (por exemplo, D:/Repli-Hyper-V/VM1, em que VM1 é o nome da máquina virtual).
Se todos os ficheiros de VM1 não estiverem na mesma pasta, utilize o gestor Hyper-V:
- Exporte VM1 numa pasta, por exemplo em D:/Repli-Hyper-V
- Esta exportação irá criar uma pasta D:/Repli-Hyper-V/VM1 contendo todos os ficheiros VM1
- Remover VM1 do inventário do gestor Hyper-V
- Importe VM1, previamente exportado, para o gestor Hyper-V
⚠️ Tire um snapshot da sua VM antes de iniciar o procedimento.
⚠️ VM1 deve ser criado apenas num único nó. A única coisa a criar no outro nó é o directório VM1 (D:/Repli-Hyper-V/VM1).
⚠️ Certifique-se de que os nomes dos switches virtuais referenciados pela máquina virtual existem em ambos os servidores Hyper-V e correspondem à 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 cumpridos. Para detetar problemas de compatibilidade entre nós Hyper-V (hardware, rede, configuração), consulte🛠️ KB SK-0088 neste documento.
2. Inicie a consola SafeKit
- Inicie a consola web num navegador num nó do cluster conectando-se a
http://localhost:9010. - Entrar
admincomo o nome de utilizador e a palavra-passe definida durante a instalação.
Também é possível executar a consola num browser numa estação de trabalho externa ao cluster.
⚠️ A configuração do SafeKit é feita em ambos os nós a partir de um único browser.
ℹ️ Para proteger a consola web, consulte 🛠️ 11\. Proteger o serviço web SafeKit no Guia do utilizador.

3.º Configure endereços de nós
- Introduza 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 browser com ambos os nós e verifique a firewall em ambos os nós para 🛠️ solução de problemas. - Em seguida, clique em
Save and applypara guardar a configuração. - Verifique o
Success✅ mensagem em ambos os nós. - Se a configuração
Failure❌ ocorre num nó, abra o acordeão ▼ desse nó e reveja as mensagens. Note que pode utilizar SafeKit AI 🤖 para obter assistência.
ℹ️ Se desejar, pode adicionar um novo LAN and nodes (primeiro ➕) para criar uma segunda pulsação e uma rede de replicação dedicada.
ℹ️ Se clicar em Advanced configuration, o cluster.xml ficheiro é exibido. Este ficheiro é preenchido automaticamente pela consola 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 ligação da consola. Este nó retransmite pedidos para node2 quando necessário.
ℹ️ A consola procura xxx.safe no Application_Modules/generic/ diretório no nó de ligação (node1) se lá colocou um módulo durante a instalação.

5.º Configure o módulo
- Escolha um
Automaticinício do módulo no arranque sem demora. - Normalmente, tem um único
Heartbeatrede na qual é feita a replicação. No entanto, pode definir uma rede privada, se necessário (adicionando um LAN no passo 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 ficheiros VM1 estão em D:/Repli-Hyper-V/VM1 (ver pré-requisitos). Este diretório será replicado em tempo real pelo SafeKit. Não execute a 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” guarda o estado atual da VM (suspender) quando o módulo é interrompido. - “
off” desliga a VM (desliga) quando o módulo é parado.
“stop” é recomendado porque provoca o encerramento e depois o reinício da VM quando o módulo é parado e reiniciado. Assim, se a aplicação dentro da VM falhar, será reiniciada.
Este será o caso, por exemplo, quando se alterna entre funções primárias e secundárias.
ℹ️ Não precisa de configurar um endereço IP virtual. VM1 será reinicializado no Hyper-V secundário com o 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. Isto garante que a VM não é iniciada automaticamente quando o host Hyper-V é iniciado, mas apenas quando o próprio módulo é iniciado.

6. Verificador personalizado para detetar avarias 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 destas mensagens de pulsação.
Se o Hyper-V Heartbeat Service não responder à mensagem (VM bloqueada, bloqueada ou deixou de funcionar), o verificador personalizado executa uma ação para reiniciar a VM no mesmo nó Hyper-V ou noutro.
- Clique em
Checkers / Custom(ver imagem). - Basta definir um nome à 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 mal sucedidas em 24 horas, o módulo SafeKit hyperv pára no nó primário e existe um failover da VM no nó secundário. - Se 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 pretenda parar a máquina virtual, o verificador personalizado irá reiniciá-la automaticamente. Para evitar isso, pode temporariamente suspender o verificador 🖼️. Ou pode removê-lo excluindo a linha de configuração na consola.
ℹ️ O mesmo acontece quando pretende 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, suspender o verificador 🖼️ antes de prosseguir com a operação.
ℹ️ Por predefinição, o verificador personalizado permite 50 segundos para a VM arrancar antes de a considerar indisponível. Se a sua VM Hyper-V exigir mais tempo para arrancar, pode aumentar este atraso adicionando -InitialGrace ao verificador personalizado 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. Encriptação de comunicação (opcional)
- Mantenha a encriptação da comunicação entre os nós.

9.º Guarde 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 num nó, abra o acordeão ▼ desse nó e reveja as mensagens. Note que pode utilizar SafeKit AI 🤖 para obter assistência.

11. Inicie o nó com os 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 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 o SafeKit instale os mecanismos de replicação e, em seguida, inicie VM1 no start_prim guião.
⚠️ Usar Start para arranques subsequentes: SafeKit mantém o servidor mais atualizado. Começando As primary é uma inicialização especial à primeira ou durante operações excecionais.

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 atingido ou se VM1 não for iniciado, analise o porquê com o registo do módulo 🖼️ do nó 1.
- Clique no 🔍 registo ícone de
node1para abrir o registo do módulo e procurar mensagens de erro, como por exemplo um verificador que deteta um erro e para o módulo. - Clique em
start_primno registo: as mensagens de saída do script são apresentadas à direita e podem ser detetados erros, como VM1 iniciado incorretamente. - Utilize SafeKit AI 🤖 para obter assistência com mensagens de registo.
⚠️ Se o cluster estiver em WAIT (red) not uptodate, STOP (red) not uptodate estado, pare o nó WAIT e forçar o seu início como primário 🖼️.

13.º Iniciar nó 2
- ⋯
Startnó 2 com o 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).
- Isto pode demorar um pouco, dependendo do tamanho dos ficheiros a ressincronizar nos diretórios replicados e da largura de banda da rede.
- Para ver o progresso da cópia, consulte o registo do módulo 🖼️ e o recursos de replicação 🖼️ do nó 2. Utilize SafeKit AI 🤖 para obter assistência com as mensagens de registo.
ℹ️ Quando se utilizam discos diferenciais Hyper-V, apenas o disco diferencial necessita de ressincronização após a sincronização inicial, poupando tempo para discos rígidos virtuais de grandes dimensões.

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.
Apenas as alterações dentro dos ficheiros são replicadas em tempo real neste estado.

15.º Teste
- Pare o nó PRIM fazendo scroll para baixo no seu menu contextual e clicando
Stop. - Verifique se existe um failover no nó SECOND que se deve tornar ALONE (verde).
- Verifique com o gestor Hyper-V se
VM1está a ser executado no nó 2.
⚠️ Se ALONE (verde) não for atingido no nó2 ou se VM1 não for iniciado, analise o porquê com o registo do módulo 🖼️ do nó 2.
- Clique no 🔍 registo ícone de
node2para abrir o registo do módulo e procurar mensagens de erro, como por exemplo um verificador que deteta um erro e para o módulo. - Clique em
start_primno registo: as mensagens de saída do script são apresentadas à direita e podem ser detetados erros, como VM1 iniciado incorretamente. - Utilize SafeKit AI 🤖 para obter assistência com mensagens de registo.
⚠️ 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 um arranque no node1, que irá voltar a sincronizar os diretórios replicados do node2.
Se as coisas correrem mal, pare o nó2 e forçar o arranque como primário 🖼️ do nó1, que será reiniciado com os seus dados localmente íntegros no momento da paragem.
ℹ️ Repare que tem um 🕒 linha do tempo 🖼️ isto pode ser útil para compreender 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 precisa de configurar um verificador splitbrain.
- Aceda à 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 a reimplantar em ambos os nós (o módulo deve ser interrompido em ambos os nós para guardar e aplicar).
Parâmetros :
Resource nameidentifica a testemunha com um nome de recurso:splitbrain.witness. Pode alterar este 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 este valor com o IP da testemunha (um elemento robusto, normalmente um router).- Nota: pode definir vários IP separados por espaços em branco. Tenha em 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 pretender um reinício ou failover automático quando um serviço crítico dentro da VM falhar, pode configurar as propriedades de recuperação do serviço (ver imagem).
Primeiro deve configurar o Verificador personalizado de VM descrito anteriormente.
E depois no Microsoft Service Manager dentro da VM, selecione o seu serviço crítico e na propriedade de recuperação do serviço, basta configurar o encerramento da VM quando o serviço crítico falhar.
Para tal, 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 da linha de comandos”, defina /s /c “serviço falha”.
Claro, pode implementar uma recuperação mais subtil com os seus próprios scripts. Mas esteja ciente de que desligar a VM ativará o verificador personalizado no host. O verificador personalizado detetará que a pulsação Hyper-V já não está a responder e reiniciará a VM no mesmo servidor Hyper-V ou fará um failover no outro servidor Hyper-V (dependendo da sua configuração).
Para testar a funcionalidade, utilize o Gestor de Tarefas e elimine o processo (Terminar tarefa) associado ao serviço crítico. Uma paragem limpa do serviço através do Service Manager ou do comando “net stop” não desencadeia a ação de recuperação dentro do Windows Service Manager.

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

Demonstração da solução SafeKit/Hyper-V
Vídeo SafeKit: Clustering ao nível da 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 o failover contínuo para as suas cargas de trabalho virtualizadas críticas. Embora esta demonstração utilize o 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)
- 🎬 Configurar 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: Funcionalidades, vídeos técnicos, documentação e teste gratuito
| Tipo de Recurso | Descrição | Link Direto |
|---|---|---|
| Funcionalidades Chave | Porquê escolher o SafeKit para uma Alta Disponibilidade simples e económica? | Veja porquê 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 utilização (Software OEM, Servidores Edge, SCADA e mais) |
| Modelo de Implementaçã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 ao Nível da Aplicação | Veja SafeKit HA & Redundância: VM vs. Nível da 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 & Demos de Failover | Veja os Tutoriais de Failover do SafeKit |
| Arquitetura | Como funciona o Mirror Cluster do SafeKit (Replicação em Tempo Real & Failover) | Veja SafeKit Mirror Cluster: Replicação em Tempo Real & Failover |
| Arquitetura | Como funciona o Farm Cluster do SafeKit (Balanceamento de Carga de Rede & Failover) | Veja SafeKit Farm Cluster: Balanceamento de Carga de Rede & 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 & Teste | Veja o Teste Gratuito & Documentação Técnica do SafeKit HA |
| Soluções Pré-configuradas | Biblioteca de Módulos de Aplicação SafeKit: Soluções de HA Prontas a Usar | Veja os Módulos de Aplicação de Alta Disponibilidade SafeKit |