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

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 da aplicação
• Failback automático após falha do servidor

O SafeKit elimina os seguintes requisitos:

• Balanceadores de carga de rede ou servidores proxy dedicados
• Discos partilhados ou armazenamento SAN replicado
• Edições empresariais de sistemas operativos e bases de dados
• Competências especializadas em manutenção de clusters

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 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 completas Hyper-V ou KVM
• Aplicações Docker, Podman e cloud

Não. O SafeKit é simples de implementar—não são necessários conhecimentos avançados.

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

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

Este software independente de plataforma é ideal para parceiros que revendem aplicações críticas e que necessitam de oferecer aos clientes uma opção simples e económica de elevada disponibilidade (HA) e redundância de sistema, sem a complexidade e os custos das SANs (Storage Area Networks). As funcionalidades 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 historial 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. Isto inclui setores como sistemas de gestão de vídeo (VMS), controlo de acesso, gestão de edifícios (BMS), software SCADA, logística automatizada e controlo crítico de tráfego aéreo/ferroviário, garantindo o tempo máximo de atividade (*uptime*) em toda a linha.

O SafeKit oferece um kit de recursos completo, gratuito e de acesso aberto para apoiar os seus parceiros, incluindo testes gratuitos, módulos de formação online abrangentes e a oportunidade de obter a certificação oficial SafeKit sem custos. Estas ferramentas permitem que os parceiros adquiram rapidamente as competências técnicas necessárias para implementar a solução de forma eficaz e fornecer suporte de classe mundial, minimizando o tempo de implementação e reduzindo a curva de aprendizagem.

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

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

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.

O Servidor 1 (PRIM) executa a aplicação. Os clientes estão ligados a um endereço IP virtual. O SafeKit replica em tempo real as modificações feitas nos ficheiros 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.
Basta configurar os nomes dos diretórios a replicar no SafeKit. Não existem pré-requisitos na organização do disco. Os diretórios podem estar localizados no disco do sistema.

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

O tempo de failover é igual ao tempo de deteção de falha (30 segundos por predefinição) mais o tempo de arranque da aplicação.

O failback envolve o reinício do Servidor 1 após a correção do problema que causou a falha.
O SafeKit ressincroniza automaticamente os ficheiros, atualizando apenas os ficheiros modificados no Servidor 2 enquanto o Servidor 1 estava parado.

O failback ocorre sem perturbar a aplicação, que pode continuar a ser executada no Servidor 2.

Após a reintegração, os ficheiros estão novamente em modo de espelhamento, tal 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 a replicar as atualizações de ficheiros para o Servidor 1.

Se o administrador desejar que a aplicação seja executada no Servidor 1, ele/ela pode executar um comando "swap" (troca) manualmente num momento apropriado ou automaticamente através da configuração.

Na figura anterior, a aplicação está a ser executada nos 3 servidores (3 é um exemplo, podem ser 2 ou mais). Os utilizadores estão ligados 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 deteta 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 baseia-se 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 num servidor aceita o pacote; os outros filtros noutros servidores rejeitam-no.
Assim que um pacote é aceite pelo filtro num servidor, apenas o CPU e a memória deste servidor são usados pela aplicação que responde ao pedido 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 com estado (stateful), existe afinidade de sessão. O mesmo cliente deve estar ligado ao mesmo servidor em múltiplas sessões TCP para recuperar o 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 ligado ao mesmo servidor em múltiplas sessões TCP. E diferentes clientes são distribuídos por diferentes servidores na farm.
Com uma aplicação sem estado (stateless), não há afinidade de sessão. O mesmo cliente pode estar ligado a diferentes servidores na farm em múltiplas sessões TCP. Não há contexto armazenado localmente num 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 ficheiros de instalação do SafeKit para a versão atual, organizados por sistema operativo e tipo de instalador.

➡️ Ir para Arquivos da v7.5

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

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

Explore a nossa documentação de marketing do produto para o software SafeKit HA, que inclui uma ficha técnica detalhada, um white paper do produto e uma 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 operativo (Bases de Dados, Servidores Web, VMs, Cloud). 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ócio 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 template de Alta Disponibilidade (HA) pré-configurado que define como uma aplicação específica será clusterizada e protegida pelo software SafeKit. Na prática, contém um ficheiro de configuração (userconfig.xml) e scripts de reinicialização.