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 cluster espelho do SafeKit para garantir a continuidade do negócio:

• Failover de Aplicação (Separador Macros): Defina os serviços de aplicação específicos a serem reiniciados automaticamente em caso de falha.
• Rede(s) de Heartbeat: Caminho(s) de comunicação dedicado(s) utilizado(s) pelos nós do cluster para monitorizar continuamente a integridade e a disponibilidade uns dos outros e sincronizar as 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 baseada em host ao nível do byte.
• Checkers (Verificadores): Monitorizam a integridade da aplicação e acionam 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 testemunha (witness) ou de uma rede de heartbeat adicional. Saiba mais sobre heartbeat, failover e quórum num cluster.

A consola de gestão do SafeKit oferece uma vista 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 cluster espelho de 2 nós, a consola exibe claramente as funções de cada servidor:

• PRIM (Primary): o nó ativo que atualmente executa a aplicação e gere o IP Virtual. Realiza as gravações no armazenamento local e a replicação em tempo real para o nó secundário.
• SECOND (Secondary): o nó de reserva (standby) que recebe as atualizações síncronas ao nível do byte. Está pronto para assumir o controlo instantaneamente caso o Primário falhe.
• Estado ALONE: alerta-o visualmente quando o cluster está a ser executado num único nó (por exemplo, durante a manutenção ou após uma falha), indicando que a redundância foi temporariamente perdida.
• Progresso de Ressincronização: quando um nó com falha recupera, o seu estado muda para laranja durante a reintegração de dados em segundo plano, garantindo que não existe tempo de inatividade durante a fase de "retorno ao normal".

Para além dos simples ícones de estado, a interface disponibiliza uma orquestração de failover com um clique, permitindo reatribuir manualmente a função primária para manutenções planeadas, garantindo simultaneamente a disponibilidade contínua para a atividade dos utilizadores.

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

• Serviços com equilíbrio de carga (separador Macros): Defina os serviços de aplicação específicos (por exemplo, Apache, IIS, Nginx) que devem ser mantidos ativos em todos os nós.
• Rede(s) de heartbeat: Caminho(s) de comunicação utilizado(s) para detetar se um nó saiu da farm, acionando uma redistribuição imediata da carga.
• IP Virtual (Farm VIP): Ao contrário de um cluster mirror, o Farm VIP é partilhado entre os nós através de um algoritmo de filtragem de kernel para distribuir o tráfego de rede.
• Regras de equilíbrio de carga: Defina a política de distribuição de tráfego com base no endereço IP de origem ou na porta.
• Verificadores (Checkers): Monitorizam o estado de saúde da aplicação e acionam o reinício automático se for detetada uma falha no processo.

A monitorização de um cluster em modo 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): Numa farm saudável, ambos os nós estão no estado "UP" (50%), o que significa que ambos estão ativamente a receber e a processar pedidos de clientes através do IP Virtual partilhado.
• Reequilíbrio automático: Se um nó falhar, a consola mostra visualmente o nó restante a assumir 100% do tráfego. Não existe atraso de "failover", uma vez que o nó sobrevivente já se encontra ativo (além de um tempo de deteção de alguns segundos).
• Inserção de nós: Quando um nó reparado é reiniciado, este passa do estado "STOP" para "UP" e começa automaticamente a receber a sua parte da carga, sem intervenção do administrador.
• Sem sincronização de dados: Note que, num cluster em modo farm, não existe o estado de ressincronização "Laranja", uma vez que se pressupõe que os nós não têm estado (stateless) ou partilham uma base de dados no backend (que pode ser protegida separadamente num cluster mirror).

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