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

O SafeKit oferece as seguintes funcionalidades para Windows e Linux num único produto de software:

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

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

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

Não. O SafeKit funciona com edições padrão de Windows e Linux e não necessita de licenças de bases de dados enterprise.

O SafeKit resolve:

• Falhas de hardware (20% dos problemas), incluindo a falha total de uma sala de computadores
• Falhas de software (40% dos problemas), incluindo o reinício de processos críticos
• Erros humanos (40% dos problemas) graças à sua facilidade de utilização

Pode implementar replicação em tempo real e failover para:

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

O SafeKit elimina os seguintes requisitos:

• Balanceadores de carga de rede ou servidores proxy dedicados
• Discos partilhados ou armazenamento SAN replicado
• Edições Enterprise de sistemas operativos e bases 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 pilha de HA, a replicação é apenas uma "cópia passiva" que requer uma intervenção manual e demorada para se tornar útil:

• Se o Servidor A falhar, o software de replicação de dados não redirecionará automaticamente os seus utilizadores para o Servidor B.
• Não detetará que a aplicação parou.
• Não reiniciará os serviços.

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

• Integração Frágil: Quando utiliza o produto A para replicação e o produto B para clustering, cria um "castelo de cartas". Cada atualização de SO ou patch de segurança corre o risco de quebrar a frágil ligação de comunicação entre estes motores separados.
• Carga Cognitiva Elevada & Erro Humano: Gerir múltiplas interfaces aumenta o risco de erros. Durante uma falha de sistema sob alta pressão, saltar entre diferentes GUIs ou utilizar diferentes sintaxes de CLI para diagnosticar um problema leva à confusão e a um tempo de inatividade prolongado.
• Troca de Acusações entre Fornecedores: Se um failover falhar, o fornecedor da replicação pode culpar a ferramenta de clustering, deixando-o preso no meio sem um caminho claro para a resolução. Uma solução tudo-em-um oferece um único ponto de responsabilidade.
• Manutenção Complexa: Sistemas fragmentados requerem competências especializadas para cada componente separado, tornando a solução mais difícil de manter e significativamente mais dispendiosa ao longo do tempo.

Para automatizar a recuperação e eliminar o tempo de inatividade, um produto tudo-em-um deve gerir várias partes técnicas móveis em simultâneo:

• 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 partilhado (SAN). Isto garante zero perda de dados (RPO=0) e elimina dependências de hardware dispendiosas.
• Endereço IP Virtual (VIP): oferece um ponto de entrada único para os utilizadores. Quando ocorre uma falha, o software move o VIP do nó com falha para o nó saudável, para que os utilizadores não tenham de alterar a sua configuração.
• Detetores de Erros de Hardware e Software: o sistema deve efetuar constantemente um "heartbeat" tanto ao servidor físico como aos processos de software específicos para identificar imediatamente um bloqueio ou uma falha.
• Scripts de Reinício Personalizáveis: nem todas as aplicações iniciam da mesma forma. Uma ferramenta tudo-em-um permite scripts personalizados para garantir que serviços complexos iniciam na ordem correta.
• Failover Automático: a inteligência para orquestrar toda a transição de um servidor para outro sem intervenção humana.

Se o seu gestor de failover e a sua replicação de dados forem dois produtos diferentes, estes poderão não estar "em sincronia".

O Perigo: Se ocorrer um failover mas a replicação ainda não tiver terminado de enviar os últimos bits, 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. Este apenas permitirá que a aplicação seja iniciada no nó de reserva (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 pelas soluções de HA tradicionais, o failback automático continua a ser o requisito mais crítico para uma verdadeira resiliência. Um verdadeiro produto tudo-em-um gere o "Regresso ao Normal" de forma tão elegante como gere a falha. Quando o servidor que falhou volta a estar online, os seus dados estão 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á a correr no nó ativo.
3. Restaurar a Redundância: assim que os dados estiverem novamente espelhados (mirrored), o cluster regressa automaticamente a um estado protegido, pronto para o próximo evento.

O método técnico utilizado para a replicação baseada em host tem um impacto significativo na quantidade de alterações que terá de efetuar na configuração da sua aplicação existente.

• O Desafio da Replicação ao Nível do Bloco: A maioria das soluções SANless replica ao nível do disco/bloco. Isto não é transparente para a aplicação. Exige que reconfigure totalmente a aplicação para mover os seus dados para um volume de "disco replicado" específico, criado recentemente. Isto envolve frequentemente uma migração complexa e potenciais alterações na lógica da aplicação.
• A Vantagem do SafeKit ao Nível do Ficheiro: O SafeKit efetua a replicação baseada em host ao nível do ficheiro, o que é completamente transparente para a aplicação. Não precisa de mover os dados para um disco especial; basta configurar o SafeKit para replicar as pastas existentes da aplicação. Estas pastas podem até permanecer no disco do sistema, permitindo-lhe proteger uma aplicação exatamente onde esta já está instalada.

Tempo de resincronização após uma falha (passo 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 escrita do disco.

Alternativa

• Para um grande volume de dados, utilize armazenamento partilhado externo.
• Mais caro, mais complexo.

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

Alternativa

• Coloque os muitos ficheiros a replicar num disco rígido virtual / máquina virtual.
• Apenas os ficheiros que representam o disco rígido virtual / máquina virtual serão replicados e resincronizados neste caso.

• Cada VM é executada num módulo de espelho independente.
• Máximo de 32 módulos de espelho a correr no mesmo cluster.

Alternativa

• Utilize armazenamento partilhado externo e outra solução de clustering de 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 (passo 3) e boa latência para replicação síncrona (tipicamente um tempo de ida e volta inferior a 2 ms).

Alternativa

• Utilize 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 cloud).
• Utilize soluções de backup com replicação assíncrona para redes com alta latência.

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

• Failover de Aplicação (Separador 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 utilizados pelos nós do cluster para monitorizar 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 ao nível do byte baseada no host.
• Checkers (Verificadores): monitorize a integridade da aplicação e acione a recuperação automática se for detetada uma falha de processo.

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 falha de energia e isolamento de rede num cluster.

A consola de gestão SafeKit oferece uma visão unificada da sua infraestrutura de alta disponibilidade. Permite aos administradores monitorizar o estado operacional do cluster e acompanhar a sincronização de dados em tempo real.

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

• PRIM (Primário): O nó ativo que está a executar a aplicação e a gerir o IP Virtual. Realiza escritas no armazenamento local e a replicação em tempo real para o nó secundário.
• SECOND (Secundário): O nó de reserva (standby) que recebe atualizações síncronas ao nível do byte. Está pronto para assumir o controlo instantaneamente se o Primário falhar.
• Estado ALONE: Alerta visualmente quando o cluster está a funcionar num ú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 recupera, o seu estado fica cor de laranja durante a reintegração de dados em segundo plano, garantindo que não há tempo de inatividade durante a fase de "regresso ao normal".

Além de ícones de estado simples, a interface oferece orquestração de failover com um clique, permitindo-lhe trocar manualmente as funções (Primário/Secundário) para manutenção planeada sem interromper a atividade do utilizador.

O cluster farm do SafeKit foi concebido para alta disponibilidade e escalabilidade de serviços. A configuração foca-se na distribuição do tráfego de entrada entre ambos os nós em simultâneo:

• Serviços com Balanceamento de Carga (separador 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 utilizados para detetar se um nó abandonou o farm, acionando uma redistribuição imediata da carga.
• IP Virtual (Farm VIP): Ao contrário de um cluster mirror, o VIP do Farm é partilhado entre os nós através de 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): Monitorizam o estado da aplicação e ativam o reinício automático caso seja detetada uma falha num processo.

A monitorização 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): Num farm saudável, ambos os nós estão no estado "UP" (50%), o que significa que ambos estão a receber e a processar ativamente os pedidos dos clientes através do IP Virtual partilhado.
• Reequilíbrio Automático (Re-balancing): Se um nó falhar, a consola mostra visualmente o nó restante a assumir 100% do tráfego. Não existe atraso de "failover", pois o nó sobrevivente já está ativo (à exceção de um tempo de deteção de alguns segundos).
• Inserção de Nó: Quando um nó reparado é reiniciado, este transita de "STOP" para "UP" e começa automaticamente a receber a sua parcela da carga sem a intervenção do administrador.
• Sem Sincronização de Dados: Note que, num cluster farm, não existe o estado de ressincronização "Laranja", pois pressupõe-se que os nós sejam sem estado (stateless) ou partilhem uma base de dados de back-end (que pode ser protegida separadamente num cluster mirror).

Para além de ícones de estado simples, a interface oferece gestão de nós com um clique, permitindo parar ou iniciar manualmente um nó para manutenção planeada, enquanto o IP Virtual partilhado redistribui automaticamente o tráfego sem interromper a atividade do utilizador.