Alta Disponibilidade Linux com SafeKit: Instale o Módulo mirror.safe para Failover
Guia de Instalação Rápida de Alta Disponibilidade para Linux
Este guia explica como configurar um cluster mirror para Linux usando SafeKit, garantindo o failover automático e a replicação síncrona sem a necessidade de armazenamento compartilhado.
Para obter ajuda, você pode usar 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 perda zero de dados (RPO = 0).
2. Instalação
- Software: Instale o motor SafeKit em ambos os servidores.
- Módulo: Baixe o módulo de aplicativo pré-configurado
mirror.safe.
3. Configuração
- Console da Web: configure as pastas específicas que contêm os arquivos Linux.
- Monitoramento: Inicie o monitoramento e a proteção do aplicativo Linux.
Limitações SafeKit de Alta Disponibilidade
| Limite/Requisito | Motivo e Impacto | Alternativa recomendada |
|---|---|---|
| Tamanho da replicação: alguns TBs | Tempo de resincronização após 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 do disco) | • Usar armazenamento compartilhado externo (mais caro, mais complexo). |
| Contagem de arquivos: < 1.000.000 de arquivos | • Desempenho do tempo de resincronização após uma falha (etapa 3). • Tempo necessário para comparar cada arquivo entre os dois nós. | • Coloque os vários arquivos a serem replicados em um disco rígido virtual/máquina virtual. • Apenas os arquivos que representam o disco rígido virtual/máquina virtual serão replicados e resincronizados neste caso. |
| Capacidade de failover: ≤ 32 VMs | • Cada VM é executada em um módulo mirror independente. • Máximo de 32 módulos mirror em execução no mesmo cluster. | • Utilize um armazenamento compartilhado externo e outra solução de cluster de máquinas virtuais (mais cara e mais complexa). |
| 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 resincronização (passo 3). • Baixa latência para replicação síncrona: normalmente < 5 ms RTT; valores mais altos devem ser validados em relação à taxa de gravação do aplicativo. | • Se os dois nós estiverem em sub-redes diferentes (comum na nuvem), use outras opções de redirecionamento: um balanceador de carga, CLIs de provedor de nuvem, BGP ou redirecionamento de DNS. • Utilize soluções de backup com replicação assíncrona para redes com alta latência. |
Visão geral da solução SafeKit/Linux
As soluções são descritas aqui: **💡 A mais simples alta disponibilidade Linux: replicação síncrona e failover de 2 nós.
**
Instalação da solução SafeKit/Linux (mirror.safe)
Pré-requisitos
- Você precisa que o aplicativo que deseja reiniciar no SafeKit esteja instalado em 2 nós (máquinas virtuais ou servidores físicos).
Instalação de pacotes no Linux
- Instale a versão gratuita do SafeKit em 2 nós Linux. Observação: a avaliação gratuita inclui todos os recursos SafeKit. Ao final da avaliação, você pode ativar chaves de licença permanentes sem desinstalar o pacote.
- Após o download do pacote safekit_xx.bin, execute-o para extrair o rpm e o script safekitinstall e, em seguida, execute o script safekitinstall
- Responda sim à configuração automática do firewall
- Defina a senha para o console da web e o usuário padrão admin. Defina a mesma senha em todos os nós.
Observação: o módulo genérico mirror.safe que você vai configurar é entregue dentro do pacote.
Configuração passo a passo da solução SafeKit/Linux
Pré-requisitos
- Linux foi instalado em 2 nós.
- Os dados replicados totais são limitados a alguns terabytes — além disso, o tempo de resincronização torna-se significativo.
- Interconexão mínima de 1 Gb/s entre os nós (10 Gb/s recomendada para resincronização mais rápida).
- O failover de IP requer que ambos os nós estejam na mesma LAN ou LAN estendida (L2) — redes L3 roteadas não são suportadas (exceto com balanceadores de carga em nuvem 🛠️).
1. Inicie o console SafeKit
- Inicie o console da web em um navegador em um nó do cluster, conectando-se a
http://localhost:9010. - Insira
admincomo nome de usuário e a senha definida durante a instalação.
Você também pode 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.

2. Configurar endereços de nós
- Insira os endereços IP do nó, pressione a
Tab keypara verificar a conectividade e preencha os nomes dos nós. Se node1 ou node2 estiverem em vermelho, verifique a conectividade do navegador com ambos os nós e verifique o firewall em ambos os nós para 🛠️ solucionar problemas. - Em seguida, clique em
Save and applypara salvar a configuração. - Verifique a mensagem
Success✅ em ambos os nós. - Se ocorrer uma
Failurede configuração ❌ em um nó, abra o acordeão ▼ desse nó e revise as mensagens. Observe que você pode usar a IA SafeKit 🤖 para obter assistência.
ℹ️ Se desejar, você pode adicionar uma nova LAN and nodes (primeiro ➕) para criar um segundo heartbeat e uma rede de replicação dedicada.
ℹ️ Se você clicar em Advanced configuration, o arquivo cluster.xml será exibido. Este arquivo é preenchido automaticamente pelo console e implantado nos nós.

3. Selecione um módulo
- No
New module, clique no módulomirror.safe.
ℹ️ 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 por xxx.safe no diretório Application_Modules/generic/ no nó de conexão (node1) se você colocou um módulo lá durante a instalação.

4. Configure o módulo
- Em
Module startup at boot, escolha o início automático do módulo na inicialização sem atraso. - Em
Macros/SERVICES, insira os nomes dos serviços do seu aplicativo, na ordem de inicialização, separados por vírgulas. Consulte esta captura de tela para obter um exemplo visual dos serviços Milestone XProtect 🖼️. - Nas
Heartbeat networks, você deve ter uma única rede de pulsações na qual a replicação é feita. Se você adicionou uma LAN privada na etapa 2, poderá configurar duas pulsações com o fluxo de replicação na LAN privada. - Em
Virtual IP addresses, insira um endereço IP virtual. Um endereço IP virtual é um endereço IP padrão na mesma rede IP (mesma sub-rede) que os endereços IP de ambos os nós.
Os clientes da aplicação devem ser configurados com o endereço IP virtual (ou o nome DNS associado ao endereço IP virtual).
O endereço IP virtual é alterado automaticamente em caso de falha. - Em
Replicated directories, defina os caminhos dos diretórios a serem replicados. Verifique se eles existem em ambos os nós e contêm os dados do aplicativo.
A replicação de dados e de logs é essencial para um banco de dados.
Você pode criar diretórios replicados adicionais conforme necessário.
Veja esta captura de tela para um exemplo visual da replicação SQL Milestone XProtect 🖼️. - Em
Checkers, você poderá configurar verificadores, se necessário, como monitoramento de processos, verificadores personalizados, TCP, ping ou verificadores de divisão de cérebro.
Por exemplo, se um nome de processo for exibido emMonitored processes/services, ele será monitorado com uma ação de reinicialização em caso de falha. A configuração de um nome de processo incorreto fará com que o módulo pare logo após o seu início.
ℹ️ Se você clicar em Advanced configuration, o arquivo userconfig.xml será exibido. Este arquivo é preenchido automaticamente pelo console e implantado nos nós com os scripts de reinicialização.
ℹ️ Em uma implantação na nuvem, você não precisa configurar um endereço IP virtual no SafeKit. O IP virtual é gerenciado no nível do balanceador de carga da nuvem 🛠️
ℹ️ Ao aplicar a configuração SafeKit, o startup type dos serviços é automaticamente definido como Manual nos serviços Windows. Isso garante que os serviços não sejam iniciados automaticamente quando o sistema é inicializado, mas sim apenas quando o próprio módulo é iniciado (o mesmo se aplica no Linux).

5. Editar scripts (opcional)
- Esta etapa é opcional e pode ser ignorada na maioria dos casos, pois os scripts de reinicialização já estão pré-configurados para reiniciar os serviços definidos na etapa anterior.
- Então, clique diretamente em
Next step. start_prim.ps1inicia todos os serviços na ordem especificada na listaSERVICES, enquantostop_prim.ps1para todos os serviços na ordem inversa.- Além disso,
start_prim.ps1verifica a inicialização de cada serviço e interrompe o módulo se algum serviço não for iniciado corretamente.

6. Criptografia de comunicação (opcional)
- Mantenha a criptografia da comunicação entre os nós.

7. Salvar e aplicar
Save and applya configuração e os scripts em ambos os nós.

8. Verifique se a configuração foi bem-sucedida
- Verifique a mensagem
Success✅ em ambos os nós e clique emMonitor modules. - Se ocorrer uma
Failurede configuração ❌ em um nó, abra o acordeão ▼ desse nó e revise as mensagens. Observe que você pode usar a IA SafeKit 🤖 para obter assistência.
⚠️ No Linux, você pode receber um erro nesta etapa se os diretórios replicados forem pontos de montagem. 🛠️ Consulte SK-0030 para resolver o problema.

9. Inicie o nó com dados atualizados
- Se o nó 1 tiver os diretórios replicados atualizados, 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.
⚠️ Também se presume que o aplicativo Linux esteja parado no nó 1 para que SafeKit instale os mecanismos de replicação e, em seguida, inicie o aplicativo no script start_prim.
⚠️ Use Start para inícios subsequentes: SafeKit mantém o servidor mais atualizado. Iniciar As primary é um início especial na primeira vez ou durante operações excepcionais.

10. Aguarde a transição para ALONE (verde)
- O nó 1 deve atingir o estado ALONE (verde), o que significa que o IP virtual está definido e que o script
start_primfoi executado no nó 1.
⚠️ Se ALONE (verde) não for atingido ou se o aplicativo não for iniciado, analise o motivo com o log do módulo 🖼️ do nó 1.
- Clique no ícone de log 🔍 do
node1para abrir o log do módulo e procure mensagens de erro, como um verificador que detecta um erro e interrompe o módulo. - Clique em
start_primno log: as mensagens de saída do script são exibidas à direita e os erros podem ser detectados, como um serviço iniciado incorretamente. - Use o SafeKit AI 🤖 para obter ajuda com as mensagens de log.
⚠️ Se o cluster estiver no estado WAIT (red) not uptodate, STOP (red) not uptodate, pare o nó WAIT e force o seu início como primário 🖼️.

11. Iniciar nó 2
- ⋯
Starto nó 2 com o seu menu contextual. - Aguarde o SECOND estado (verde).
ℹ️ O nó 2 permanece no SECOND estado (laranja) enquanto resincroniza os diretórios replicados (cópia do nó 1 para o nó 2).
- Isso pode levar algum tempo, dependendo do tamanho dos arquivos a serem resincronizados nos diretórios replicados e da largura de banda da rede.
- Para ver o progresso da cópia, consulte o log do módulo 🖼️ e os recursos de replicação 🖼️ do nó 2. Use o SafeKit AI 🤖 para obter assistência com as mensagens de log.

12. Verifique se o cluster está operacional
- Verifique se o cluster está verde/verde com os serviços Linux em execução no nó PRIM e não em execução no nó SECOND.
Apenas as alterações dentro dos arquivos são replicadas em tempo real neste estado.
⚠️ Os componentes que são clientes dos serviços Linux devem ser configurados com o endereço IP virtual. A configuração pode ser feita com um nome DNS (se um nome DNS tiver sido criado e associado ao endereço IP virtual).

13. Testes
- Pare o nó PRIM rolando para baixo no menu contextual e clicando em
Stop. - Verifique se há um failover no SECOND nó, que deve ficar ALONE (verde).
- E com Microsoft Management Console (MMC) no Windows ou com linhas de comando no Linux, verifique o failover dos serviços Linux (parado no nó 1 no script
stop_prime iniciado no nó 2 no scriptstart_prim).
⚠️ Se ALONE (verde) não for atingido no node2 ou se o aplicativo não for iniciado, analise o motivo com o log do módulo 🖼️ do nó 2.
- Clique no ícone de log 🔍 do
node2para abrir o log do módulo e procure mensagens de erro, como um verificador detectando um erro e interrompendo o módulo. - Clique em
start_primno log: as mensagens de saída do script são exibidas à direita e os erros podem ser detectados, como um serviço iniciado incorretamente. - Use o SafeKit AI 🤖 para obter ajuda com as mensagens de log.
⚠️
- Se tudo estiver bem, inicie o node1, que irá ressincronizar os diretórios replicados do node2.
- Se as coisas derem errado, pare node2 e force o nó 1 a iniciar como primário 🖼️, que será reiniciado com seus dados localmente íntegros no momento da parada.
ℹ️ Encontre mais detalhes, juntamente com vídeos, no Treinamento Online SafeKit.

14. Suporte
- Para obter suporte, faça 2
SnapshotsSafeKit (2 arquivos .zip), um para cada nó.
ℹ️ Mais informações sobre o suporte aqui.

Demonstração da solução mirror SafeKit
Vídeo SafeKit: Agrupamento em nível de aplicativo (8:47)
Neste vídeo, descubra como SafeKit implementa um cluster de HA mirror sem a complexidade de uma SAN. Embora esta demonstração use Microsoft SQL Server, a solução funciona de forma idêntica para outros bancos de dados e aplicativos.
Capítulos
- 🎬 2 nós com SQL Server (0:32)
- 🎬 Configure o cluster e o módulo mirror.safe (3:58)
- 🎬 Inicie e teste a replicação, migração e failover do SQL em caso de falha (4:17)
Implementação passo a passo
- 🛠️ Leia o guia sobre como configurar um cluster mirror no Windows
- 🛠️ Leia o guia sobre como configurar um cluster mirror no Linux
🔍 Explore o SafeKit
Encontre informações sobre os recursos, as arquiteturas, os vídeos, a documentação e a avaliação gratuita do SafeKit.
| Recurso | Descrição | Link |
|---|---|---|
| Principais características | Saiba por que o SafeKit é uma solução de alta disponibilidade simples e econômica. | Descubra as principais funcionalidades |
| Casos de uso | Saiba como o SafeKit mantém as aplicações e a infraestrutura críticas disponíveis. | Explore os casos de uso |
| Modelo de implantação | O SafeKit oferece alta disponibilidade sem a necessidade de uma SAN ou armazenamento compartilhado. | Explore o modelo de implantação |
| Estratégias de alta disponibilidade | Compare a alta disponibilidade para máquinas virtuais com a alta disponibilidade para aplicativos. | Compare as duas estratégias |
| Especificações técnicas | Verifique os requisitos técnicos e as limitações dos clusters do SafeKit. | Leia as especificações técnicas |
| Vídeos | Assista a demonstrações da configuração do SafeKit e do failover automático. | Assista aos vídeos técnicos |
| Arquitetura | Saiba como o cluster mirror replica arquivos em tempo real e lida com o failover. | Explore a arquitetura Mirror |
| Arquitetura | Saiba como o cluster farm equilibra o tráfego de rede e lida com o failover. | Explore a arquitetura Farm |
| Comparação de produtos | Compare o SafeKit com os clusters de alta disponibilidade tradicionais. | Compare as soluções |
| Recursos técnicos | Encontre a documentação técnica, baixe o SafeKit e acesse a versão de teste gratuita. | Acesse a documentação e a versão de teste gratuita |
| Módulos de aplicação | Use os módulos pré-configurados do SafeKit para configurar alta disponibilidade para seus aplicativos. | Explore os módulos do aplicativo |