SafeKit: Software Tudo-em-Um de Alta Disponibilidade SANless e Clustering de Aplicações

O SafeKit oferece os seguintes recursos para Windows e Linux em um único produto de software:

• Balanceamento de carga
• Replicação de arquivos síncrona em tempo real
• Failover de aplicação automático
• Failback automático após uma falha de servidor

Não. O SafeKit é simples de implantar — não é necessária experiência avançada.

Não. O SafeKit funciona em seus servidores existentes, máquinas virtuais ou na nuvem — não são necessários discos compartilhados ou armazenamento SAN.

Não. O SafeKit funciona com edições padrão de Windows e Linux e não precisa de licenças de bancos de dados "Enterprise".

O SafeKit resolve:

• Falhas de hardware (20% dos problemas), incluindo a falha completa de uma sala de servidores
• Falhas de software (40% dos problemas), incluindo a reinicialização de processos críticos
• Erros humanos (40% dos problemas) graças à sua facilidade de uso

Você pode implementar replicação em tempo real e failover para:

• Todos os tipos de aplicações, diretórios de arquivos e serviços
• Bancos de dados
• Máquinas virtuais Hyper-V ou KVM completas
• Docker, Podman e aplicações em nuvem

O SafeKit elimina os seguintes requisitos:

• Balanceadores de carga de rede ou servidores proxy dedicados
• Discos compartilhados ou armazenamento SAN replicado
• Edições "Enterprise" de sistemas operacionais e bancos de dados
• Competências especializadas em manutenção de clusters

Não. A replicação de dados é simplesmente o ato de copiar dados do Servidor A para o Servidor B. Embora seja crítica, a replicação por si só não oferece disponibilidade. Sem os outros componentes de uma estrutura de HA, a replicação é apenas uma "cópia passiva" que exige intervenção manual e demorada para se tornar útil:

• Se o Servidor A travar, o software de replicação de dados não direcionará automaticamente seus usuários para o Servidor B.
• Ele não detectará que a aplicação parou.
• Ele não reiniciará os serviços.

Muitos fornecedores exigem que você "junte" vários produtos diferentes para obter replicação baseada em host, failover e balanceamento de carga. Essa arquitetura fragmentada é uma estratégia perigosa para sistemas de missão crítica:

• Integração Frágil: Quando você usa o produto A para replicação e o produto B para clustering, você cria um "castelo de cartas". Cada atualização de SO ou patch de segurança corre o risco de quebrar o elo de comunicação frágil entre esses mecanismos separados.
• Alta Carga Cognitiva e Erro Humano: Gerenciar múltiplas interfaces aumenta o risco de erros. Durante uma falha de sistema sob alta pressão, alternar entre diferentes GUIs ou usar diferentes sintaxes de CLI para diagnosticar um problema leva à confusão e ao tempo de inatividade prolongado.
• Jogo de Empurra entre Fornecedores: Se um failover falhar, o fornecedor da replicação pode culpar a ferramenta de clustering, deixando você preso no meio do caminho sem uma solução clara. Uma solução tudo-em-um oferece um único ponto de responsabilidade.
• Manutenção Complexa: Sistemas fragmentados exigem competências especializadas para cada componente separado, tornando a solução mais difícil de manter e significativamente mais cara ao longo do tempo.

Para automatizar a recuperação e eliminar o tempo de inatividade, um produto tudo-em-um deve gerenciar diversas partes técnicas móveis simultaneamente:

• Replicação Baseada em Host: replicação síncrona em tempo real de dados críticos de aplicações entre servidores, sem depender de armazenamento compartilhado (SAN). Isso garante zero perda de dados (RPO=0) e elimina dependências caras de hardware.
• Endereço IP Virtual (VIP): fornece um ponto de entrada único para os usuários. Quando ocorre uma falha, o software move o VIP do nó com falha para o nó íntegro, para que os usuários não precisem alterar sua configuração.
• Detectores de Erros de Hardware e Software: o sistema deve realizar constantemente o "heartbeat" tanto do servidor físico quanto dos processos de software específicos para identificar um travamento ou uma queda imediatamente.
• Scripts de Reinicialização Customizáveis: nem toda aplicação inicia da mesma forma. Uma ferramenta tudo-em-um permite scripts personalizados para garantir que serviços complexos sejam iniciados na ordem correta.
• Failover Automático: a inteligência para orquestrar toda a migração de um servidor para outro sem a necessidade de intervenção humana.

Se o seu gerenciador de failover e a sua replicação de dados forem dois produtos diferentes, eles podem não estar "em sincronia".

O Perigo: Se ocorrer um failover, mas a replicação não tiver terminado de enviar os bits mais recentes, o Servidor B iniciará a aplicação com dados desatualizados ou corrompidos.

Uma solução de HA SANless tudo-em-um garante que o mecanismo de failover esteja ciente do estado da replicação. Ela só permitirá que a aplicação seja iniciada no nó de backup se houver a garantia de que os dados estão atualizados, evitando nós ativos em conflito e perda de dados.

Frequentemente ignorado em guias técnicos e mal executado por soluções de HA tradicionais, o failback automático continua sendo o requisito mais crítico para uma verdadeira resiliência. Um verdadeiro produto tudo-em-um lida com o "Retorno ao Normal" de forma tão elegante quanto lida com a falha. Quando o servidor que falhou volta a ficar online, ele está com os dados desatualizados. O software de HA deve:

1. Resincronizar os dados em segundo plano, do nó ativo para o nó recuperado.
2. Manter o Tempo de Atividade (Uptime): esta resincronização deve ocorrer sem interromper a aplicação que está sendo executada no nó ativo.
3. Restaurar a Redundância: uma vez que os dados estejam espelhados novamente, o cluster retorna automaticamente ao estado protegido, pronto para o próximo evento.

O método técnico utilizado para a replicação baseada em host impacta significativamente o quanto você precisará alterar a configuração da sua aplicação existente.

• O Desafio da Replicação em Nível de Bloco: A maioria das soluções SANless replica no nível de disco/bloco. Isso não é transparente para a aplicação. Ela exige que você reconfigure a aplicação inteiramente para mover seus dados para um volume de "disco replicado" específico e recém-criado. Isso geralmente envolve uma migração complexa e possíveis mudanças na lógica da aplicação.
• A Vantagem do SafeKit em Nível de Arquivo: O SafeKit realiza a replicação baseada em host no nível de arquivo, o que é completamente transparente para a aplicação. Você não precisa mover os dados para um disco especial; basta configurar o SafeKit para replicar as pastas existentes da aplicação. Essas pastas podem até permanecer no disco do sistema, permitindo que você proteja uma aplicação exatamente onde ela já está instalada.

Tempo de resincronização após uma falha (etapa 3)

• Rede de 1 Gb/s ≈ 3 horas para 1 terabyte.
• Rede de 10 Gb/s ≈ 1 hora para 1 terabyte ou menos, dependendo do desempenho de gravação do disco.

Alternativa

• Para um grande volume de dados, use armazenamento compartilhado externo.
• Mais caro, mais complexo.

• Desempenho do tempo de resincronização após uma falha (etapa 3).
• Tempo para verificar cada arquivo entre os dois nós.

Alternativa

• Coloque os muitos arquivos a serem replicados em um disco rígido virtual / máquina virtual.
• Somente os arquivos que representam o disco rígido virtual / máquina virtual serão replicados e resincronizados nesse caso.

• Cada VM é executada em um módulo de espelhamento independente.
• Máximo de 32 módulos de espelhamento executando no mesmo cluster.

Alternativa

• Use um armazenamento compartilhado externo e outra solução de cluster para VMs.
• Mais caro, mais complexo.

• Failover automático do endereço IP virtual com 2 nós na mesma sub-rede.
• Boa largura de banda para resincronização (etapa 3) e boa latência para replicação síncrona (tipicamente um tempo de ida e volta inferior a 2 ms).

Alternativa

• Use um balanceador de carga para o endereço IP virtual se os 2 nós estiverem em 2 sub-redes (suportado pelo SafeKit, especialmente na nuvem).
• Use soluções de backup com replicação assíncrona para redes com alta latência.

O console web do SafeKit oferece uma interface intuitiva para orquestrar a alta disponibilidade de suas aplicações críticas. Em apenas alguns passos, você pode configurar um mirror cluster SafeKit para garantir a continuidade do negócio:

• Failover de Aplicação (Aba Macros): defina os serviços específicos da aplicação que devem ser reiniciados automaticamente em caso de falha.
• Rede(s) de Heartbeat: caminhos de comunicação dedicados usados pelos nós do cluster para monitorar continuamente a integridade e disponibilidade uns dos outros e sincronizar decisões de failover.
• Gestão de IP Virtual: configure o IP Virtual (VIP) para uma reconexão transparente do cliente após um failover.
• Replicação em Tempo Real: selecione os diretórios críticos para replicação síncrona em nível de byte baseada no host.
• Checkers (Verificadores): monitore a integridade da aplicação e acione a recuperação automática se uma falha de processo for detectada.

O cluster SafeKit inclui um verificador de "split-brain" dedicado para resolver problemas de isolamento de rede sem a necessidade de uma terceira máquina de testemunho (witness) ou uma rede de heartbeat adicional. Saiba mais sobre queda de energia e isolamento de rede em um cluster.

O console de gerenciamento do SafeKit oferece uma visão unificada de sua infraestrutura de alta disponibilidade. Ele permite que os administradores monitorem o estado operacional do cluster e acompanhem a sincronização de dados em tempo real.

Para um mirror cluster de 2 nós, o console exibe claramente as funções de cada servidor:

• PRIM (Primário): O nó ativo que está executando a aplicação e gerenciando o IP Virtual. Ele realiza gravações no armazenamento local e replicação em tempo real para o nó secundário.
• SECOND (Secundário): O nó de espera (standby) que recebe atualizações síncronas em nível de byte. Ele está pronto para assumir instantaneamente se o Primário falhar.
• Estado ALONE: Alerta visualmente quando o cluster está rodando em um único nó (ex: durante manutenção ou após uma falha), indicando que a redundância foi temporariamente perdida.
• Progresso de Ressincronização: Quando um nó que falhou se recupera, seu status fica laranja durante a reintegração de dados em segundo plano, garantindo que não haja tempo de inatividade durante a fase de "retorno ao normal".

Além de ícones de status simples, a interface oferece orquestração de failover com um clique, permitindo que você troque manualmente as funções (Primário/Secundário) para manutenção planejada sem interromper a atividade do usuário.

O cluster farm do SafeKit foi projetado para alta disponibilidade e escalabilidade de serviços. A configuração foca na distribuição do tráfego de entrada entre ambos os nós simultaneamente:

• Serviços Balanceados (aba Macros): Defina os serviços de aplicação específicos (ex: Apache, IIS, Nginx) que devem ser mantidos ativos em todos os nós.
• Rede(s) de Heartbeat: Caminho(s) de comunicação usados para detectar se um nó deixou o farm, acionando uma redistribuição imediata da carga.
• IP Virtual (Farm VIP): Diferente de um cluster mirror, o VIP do Farm é compartilhado entre os nós usando um algoritmo de filtragem de kernel para distribuir o tráfego de rede.
• Regras de Balanceamento de Carga: Defina a política de distribuição de tráfego com base no endereço IP de origem ou na porta.
• Checkers (Verificadores): Monitoram a integridade da aplicação e acionam o reinício automático caso uma falha de processo seja detectada.

O monitoramento de um cluster farm oferece visibilidade sobre a natureza Ativo-Ativo da infraestrutura, onde todos os nós contribuem para o desempenho da aplicação (mostrando 2 nós neste exemplo):

• Estado UP (50% em 2 nós): Em um farm saudável, ambos os nós estão no estado "UP" (50%), o que significa que ambos estão recebendo e processando ativamente as solicitações dos clientes por meio do IP Virtual compartilhado.
• Rebalanceamento Automático: Se um nó falhar, o console mostra visualmente o nó restante assumindo 100% do tráfego. Não há atraso de "failover", pois o nó sobrevivente já está ativo (exceto por um tempo de detecção de alguns segundos).
• Inserção de Nó: Quando um nó reparado é reiniciado, ele passa de "STOP" para "UP" e começa automaticamente a receber sua parcela da carga sem a intervenção do administrador.
• Sem Sincronização de Dados: Observe que, em um cluster farm, não existe o estado de ressincronização "Laranja", pois espera-se que os nós sejam sem estado (stateless) ou compartilhem um banco de dados de back-end (que pode ser protegido separadamente em um cluster mirror).

Além de ícones de status simples, a interface oferece gerenciamento de nós com um clique, permitindo parar ou iniciar manualmente um nó para manutenção planejada, enquanto o IP Virtual compartilhado redistribui automaticamente o tráfego sem interromper a atividade do usuário.