Evidian SafeKit: Software de Alta Disponibilidade Simples e Econômico

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 automático de aplicações
• Failback automático após falha do servidor

O SafeKit elimina os seguintes requisitos:

• Balanceadores de carga de rede ou servidores proxy dedicados
• Discos compartilhados ou armazenamento SAN replicado
• Edições corporativas de sistemas operacionais e bancos de dados
• Habilidades especializadas para manutenção de clusters

O SafeKit resolve:

• Falhas de hardware (20% dos problemas), incluindo a falha completa de uma sala de computadores
• Falhas de software (40% dos problemas), incluindo reinício 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 completas Hyper-V ou KVM
• Aplicações Docker, Podman e em nuvem

Não. O SafeKit é simples de implantar—não é necessário conhecimento avançado.

Não. O SafeKit roda nos seus servidores existentes, máquinas virtuais ou na nuvem—sem necessidade de discos compartilhados ou armazenamento SAN.

Não. O SafeKit funciona com edições padrão do Windows e Linux e não precisa de licenças corporativas de banco de dados.

Este software independente de plataforma é ideal para parceiros que revendem aplicações críticas e que precisam oferecer aos clientes uma opção simples e econômica de alta disponibilidade (HA) e redundância de sistema, sem a complexidade e os custos das SANs (Storage Area Networks). Os recursos centrais do SafeKit — balanceamento de carga (load balancing), replicação de dados em tempo real e failover automático — simplificam significativamente a integração de HA em qualquer oferta de serviço ou produto.

Com um histórico comprovado e inúmeras implementações em mais de 30 países através da nossa extensa rede de parceiros, o SafeKit é reconhecido como a solução de HA mais fácil e rápida de implementar para sistemas críticos. Isso inclui setores como sistemas de gerenciamento de vídeo (VMS), controle de acesso, gerenciamento predial (BMS), software SCADA, logística automatizada e controle crítico de tráfego aéreo/ferroviário, garantindo o tempo máximo de atividade (uptime) em todos os níveis.

O SafeKit oferece um kit de recursos completo, gratuito e de acesso aberto para apoiar seus parceiros, incluindo testes gratuitos, módulos de treinamento online abrangentes e a oportunidade de obter a certificação oficial SafeKit sem custo. Essas ferramentas permitem que os parceiros adquiram rapidamente as habilidades técnicas necessárias para implantar a solução de forma eficaz e fornecer suporte de nível internacional, minimizando o tempo de implantação e reduzindo a curva de aprendizado.

Nesta solução, apenas os dados da aplicação são replicados. Em caso de falha, somente a aplicação é reiniciada, não todo o sistema operacional ou a VM.

Nesta solução, a Máquina Virtual (VM) completa é replicada, incluindo tanto a Aplicação quanto o Sistema Operacional (SO). Em caso de falha, a VM inteira é reiniciada.

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 Servidor 1 (PRIM) executa a aplicação. Os clientes estão conectados a um endereço IP virtual. O SafeKit replica em tempo real as modificações feitas dentro dos arquivos através da rede.

A replicação é síncrona, sem perda de dados em caso de falha, ao contrário da replicação assíncrona.
Você só precisa configurar os nomes dos diretórios a serem replicados no SafeKit. Não há pré-requisitos quanto à organização do disco. Os diretórios podem estar localizados no disco do sistema.

Quando o Servidor 1 falha, o Servidor 2 assume. O SafeKit comuta o endereço IP virtual e reinicia a aplicação automaticamente no Servidor 2.
A aplicação encontra os arquivos replicados pelo SafeKit atualizados no Servidor 2. A aplicação continua a ser executada no Servidor 2, modificando localmente seus arquivos que não são mais replicados para o Servidor 1.

O tempo de failover é igual ao tempo de detecção de falha (30 segundos por padrão) mais o tempo de inicialização da aplicação.

O failback envolve reiniciar o Servidor 1 após corrigir o problema que causou a falha.
O SafeKit ressincroniza automaticamente os arquivos, atualizando apenas os arquivos modificados no Servidor 2 enquanto o Servidor 1 estava parado.

O failback ocorre sem interromper a aplicação, que pode continuar em execução no Servidor 2.

Após a reintegração, os arquivos estão novamente no modo de espelhamento, como no passo 1. O sistema está de volta ao modo de alta disponibilidade, com a aplicação em execução no Servidor 2 e o SafeKit replicando as atualizações de arquivos para o Servidor 1.

Se o administrador desejar que a aplicação seja executada no Servidor 1, ele pode executar um comando de "swap" (troca) manualmente em um momento apropriado ou automaticamente por meio de configuração.

Na figura anterior, o aplicativo está rodando nos 3 servidores (3 é um exemplo, podem ser 2 ou mais). Os usuários estão conectados a um endereço IP virtual.
O endereço IP virtual é configurado localmente em cada servidor no cluster farm.
O tráfego de entrada para o endereço IP virtual é recebido por todos os servidores e dividido entre eles por um filtro de rede dentro do kernel de cada servidor.
O SafeKit detecta falhas de hardware e software, reconfigura os filtros de rede em caso de falha e oferece verificadores de aplicação e scripts de recuperação configuráveis.

O algoritmo de balanceamento de carga de rede dentro do filtro de rede é baseado na identidade dos pacotes do cliente (endereço IP do cliente, porta TCP do cliente). Dependendo da identidade da entrada do pacote do cliente, apenas um filtro em um servidor aceita o pacote; os outros filtros nos outros servidores o rejeitam.
Uma vez que um pacote é aceito pelo filtro em um servidor, apenas a CPU e a memória deste servidor são usadas pelo aplicativo que responde à solicitação do cliente. As mensagens de saída são enviadas diretamente do servidor de aplicação para o cliente.
Se um servidor falhar, o protocolo heartbeat do farm reconfigura os filtros no cluster de balanceamento de carga de rede para reequilibrar o tráfego nos servidores restantes disponíveis.

Com uma aplicação stateful (com estado), existe afinidade de sessão. O mesmo cliente deve estar conectado ao mesmo servidor em várias sessões TCP para recuperar seu contexto no servidor. Neste caso, a regra de balanceamento de carga do SafeKit é configurada no endereço IP do cliente. Assim, o mesmo cliente está sempre conectado ao mesmo servidor em várias sessões TCP. E diferentes clientes são distribuídos por diferentes servidores no farm.
Com uma aplicação stateless (sem estado), não há afinidade de sessão. O mesmo cliente pode estar conectado a diferentes servidores no farm em várias sessões TCP. Não há contexto armazenado localmente em um servidor de uma sessão para outra. Neste caso, a regra de balanceamento de carga do SafeKit é configurada na identidade da sessão TCP do cliente. Esta configuração é a melhor para distribuir sessões entre servidores, mas requer um serviço TCP sem afinidade de sessão.

Esta tabela fornece os arquivos de instalação do SafeKit para a versão atual, organizados por sistema operacional e tipo de instalador.

➡️ Ir para Arquivos v7.5

Obtenha valiosa experiência em High Availability (HA) com nosso programa de certificação gratuito.

• Obtenha Sua Certificação SafeKit em High Availability Gratuitamente

Explore nossa documentação de marketing do produto para o software SafeKit HA, que inclui uma ficha técnica detalhada, white paper do produto e visão geral técnica.

• Ficha Técnica do Cluster de High Availability SafeKit (PDF)
• White Paper sobre Tecnologia de Cluster de High Availability (PDF)
• Visão Geral Técnica de High Availability SafeKit (DOCX)

Esta tabela apresenta as soluções de Alta Disponibilidade (HA) do SafeKit, categorizadas por aplicação e ambiente operacional (Bancos de Dados, Servidores Web, VMs, Nuvem). Identifique o módulo .safe pré-configurado específico (ex: mirror.safe, farm.safe, entre outros) necessário para replicação em tempo real, balanceamento de carga e failover automático de aplicações de negócios críticas em Windows ou Linux. Simplifique a configuração do seu cluster de HA com links diretos para guias de instalação rápida.

⚠️ Nota: Os módulos .safe estão disponíveis para download nos guias de instalação. Um módulo .safe do SafeKit é essencialmente um modelo de Alta Disponibilidade (HA) pré-configurado que define como uma aplicação específica será clusterizada e protegida pelo software SafeKit. Na prática, ele contém um arquivo de configuração (userconfig.xml) e scripts de reinicialização.