SafeKit: Software de Alta Disponibilidade SANless Tudo-em-Um e Clustering de Aplicações
O que é o SafeKit?
O SafeKit é uma solução de software de alta disponibilidade tudo-em-um que garante 100% de tempo de atividade (uptime) das aplicações, combinando replicação baseada em host em tempo real, failover automático e balanceamento de carga num único pacote.
Ao sincronizar dados entre servidores padrão, o SafeKit elimina a necessidade de armazenamento partilhado (SAN) dispendioso ou competências de TI especializadas, proporcionando uma forma simples e económica de proteger bases de dados empresariais (como SQL Server), sistemas de segurança críticos (como o software de gestão de vídeo Milestone XProtect) e software de controlo industrial SCADA (como aplicações Siemens) em ambientes Windows e Linux.
🔍 Hub de Navegação de Alta Disponibilidade SafeKit
Explore o SafeKit: Funcionalidades, vídeos técnicos, documentação e teste gratuito
| Tipo de Recurso | Descrição | Link Direto |
|---|---|---|
| Funcionalidades Chave | Porquê escolher o SafeKit para uma Alta Disponibilidade simples e económica? | Veja porquê escolher o SafeKit para Alta Disponibilidade |
| Casos de Uso | Descubra como o SafeKit garante a alta disponibilidade de infraestruturas críticas | Ver todos os casos de utilização (Software OEM, Servidores Edge, SCADA e mais) |
| Modelo de Implementação | HA SANless Tudo-em-Um: Clustering de Software Shared-Nothing | Veja o SafeKit HA SANless Tudo-em-Um |
| Estratégias de HA | SafeKit: Infraestrutura (VM) vs. Alta Disponibilidade ao Nível da Aplicação | Veja SafeKit HA & Redundância: VM vs. Nível da Aplicação |
| Especificações Técnicas | Limitações Técnicas para o Clustering SafeKit | Veja as Limitações de Alta Disponibilidade do SafeKit |
| Prova de Conceito | SafeKit: Configuração de Alta Disponibilidade & Demos de Failover | Veja os Tutoriais de Failover do SafeKit |
| Arquitetura | Como funciona o Mirror Cluster do SafeKit (Replicação em Tempo Real & Failover) | Veja SafeKit Mirror Cluster: Replicação em Tempo Real & Failover |
| Arquitetura | Como funciona o Farm Cluster do SafeKit (Balanceamento de Carga de Rede & Failover) | Veja SafeKit Farm Cluster: Balanceamento de Carga de Rede & Failover |
| Vantagens Competitivas | Comparação: SafeKit vs. Clusters de Alta Disponibilidade (HA) Tradicionais | Veja a Comparação SafeKit vs. Cluster de HA Tradicional |
| Recursos Técnicos | Alta Disponibilidade SafeKit: Documentação, Downloads & Teste | Veja o Teste Gratuito & Documentação Técnica do SafeKit HA |
| Soluções Pré-configuradas | Biblioteca de Módulos de Aplicação SafeKit: Soluções de HA Prontas a Usar | Veja os Módulos de Aplicação de Alta Disponibilidade SafeKit |
Porquê Escolher o SafeKit para uma Alta Disponibilidade Simples e Económica?
Quais são as funcionalidades do SafeKit?
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
Preciso de competências especiais para configurar o SafeKit?
Não. O SafeKit é simples de implementar — não é necessária experiência avançada.
O SafeKit requer hardware adicional?
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.
São necessárias licenças de software extra para o SafeKit?
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.
Que problemas resolve o SafeKit?
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
Quais as aplicações suportadas pelo SafeKit?
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
Como é que o SafeKit reduz os custos?
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
Como é definido o preço e o licenciamento do SafeKit High Availability?
O SafeKit apresenta um modelo de licenciamento por nó transparente e económico, baseado estritamente no número de servidores, independentemente dos núcleos de CPU ou sockets. Ao contrário de muitos concorrentes de alta disponibilidade que exigem subscrições recorrentes, o SafeKit oferece licenças perpétuas para garantir um menor Custo Total de Propriedade (TCO) e ativos de software a longo prazo.
- Sem Custos Ocultos: Todos os módulos de aplicação HA pré-configurados são fornecidos gratuitamente.
- Avaliação sem Riscos: Descarregue um teste gratuito de 30 dias para testar o failover e a replicação no seu ambiente.
- Orçamentos Personalizados: Por favor, contacte-nos para um orçamento adaptado aos seus requisitos específicos de alta disponibilidade.
Casos de Uso do SafeKit
SafeKit para OEM
Oferecer alta disponibilidade com a sua aplicação aumenta o valor do negócio ao garantir um serviço contínuo, reduzindo os riscos de inatividade e reforçando a confiança do cliente, permitindo simultaneamente que operações críticas funcionem sem interrupção em infraestruturas padrão.
Adicione o SafeKit ao seu catálogo como uma opção de alta disponibilidade: uma solução exclusivamente de software adaptada à sua aplicação, sem custos ocultos como armazenamento partilhado, totalmente agnóstica em relação ao hardware e implementável em ambientes físicos, virtuais ou na nuvem, com uma administração simples e plug-and-play.
SafeKit para Edge
Os locais de Edge muitas vezes não possuem centro de dados nem competências especializadas em HA — e, no entanto, a continuidade do negócio é crítica. O SafeKit mantém as aplicações de Edge a funcionar em fábricas, plataformas petrolíferas, navios, segurança de edifícios, controlo de tráfego aéreo, redes 5G, saúde, retalho…
O SafeKit transforma dois servidores de Edge comuns (de qualquer marca) num cluster HA plug-and-play — sem armazenamento partilhado/SAN. Uma única stack leve oferece replicação em tempo real e failover automático (podendo também incluir balanceamento de carga), sendo fácil de instalar e administrar.
SafeKit para VMS
O Software de Gestão de Vídeo (VMS) é fundamental para a segurança pública, gravando e exibindo vídeos em direto e arquivados para que os agentes de segurança possam reagir instantaneamente a incidentes. Qualquer interrupção no VMS coloca pessoas e ativos diretamente em risco.
O SafeKit evita a perda de vídeo e lacunas de monitorização ao manter o acesso contínuo a transmissões em direto e gravadas, mesmo durante falhas de servidor ou software. Integra-se perfeitamente com as principais plataformas de VMS, como Milestone, Genetec, Hanwha , entre outras, para manter a vigilância operacional quando ela é mais necessária.
SafeKit para EACS
Os Sistemas de Controlo de Acesso Eletrónico (EACS) são essenciais para a segurança física, controlando e monitorizando o acesso a áreas privadas e sensíveis através de portas, cartões, leitores e sensores. Qualquer interrupção no sistema pode expor imediatamente pessoas, edifícios e ativos a intrusões.
O SafeKit mantém as decisões de controlo de acesso, alarmes e credenciais sempre disponíveis, eliminando pontos únicos de falha. Oferece uma operação resiliente para soluções EACS, tais como Hirsch Microsesame, Nedap AEOS e Siemens SiPass , garantindo um acesso seguro mesmo durante incidentes de infraestrutura.
SafeKit para SCADA
Os sistemas SCADA (Supervisory Control and Data Acquisition) estão no centro dos ambientes industriais, permitindo aos operadores monitorizar e controlar processos críticos através de sensores, válvulas, bombas, motores e interfaces homem-máquina.
O SafeKit minimiza o tempo de inatividade da produção ao garantir que os sistemas de controlo SCADA — como os que alimentam os torradores de café Probat e as máquinas de triagem de bagagem ALSTEF — permanecem operacionais apesar de incidentes de hardware ou software. Isto permite que os operadores mantenham total visibilidade e controlo dos processos industriais em todos os momentos, evitando paragens dispendiosas e riscos de segurança.
SafeKit para BMS
Os Sistemas de Gestão Técnica Centralizada (BMS) são centrais para os edifícios modernos, fornecendo controlo automatizado de AVAC, distribuição elétrica, iluminação, segurança contra incêndios e sistemas de águas. Qualquer interrupção no sistema pode impactar diretamente a segurança, o conforto dos ocupantes e as operações do edifício.
O SafeKit salvaguarda a automação de edifícios ao permitir que os serviços de BMS continuem a ser executados de forma transparente em caso de falha. Suporta plataformas como o Siemens Desigo CC, Bosch BIS e sistemas relacionados para manter as operações dos edifícios seguras, eficientes e ininterruptas.
SafeKit para ATC
Os sistemas de Controlo de Tráfego Aéreo (ATC) são fundamentais para a segurança da aviação, permitindo a monitorização e o controlo em tempo real dos movimentos das aeronaves no solo e no ar através de aplicações de vigilância, orientação e controlo.
O SafeKit reforça a resiliência do sistema ATC ao garantir o acesso ininterrupto dos controladores a aplicações críticas do lado ar (airside). É utilizado com soluções de ATC e aeroportuárias, tais como ADB SafeGate , para suportar operações de tráfego aéreo seguras e contínuas sob todas as condições.
SafeKit para OCC
Os Centros de Controlo de Operações (OCC) estão no cerne das redes de metro modernas, centralizando a supervisão dos movimentos dos comboios, fornecimento de energia, sinalização, informações aos passageiros e gestão de incidentes. Em linhas de metro automáticas e sem condutor, o OCC é o ponto único de controlo das operações.
O SafeKit garante a supervisão ininterrupta do metro, assegurando que as aplicações do OCC permanecem disponíveis durante falhas. Suporta Centros de Controlo de Operações para as linhas de metro automáticas e sem condutor de Paris , permitindo um serviço contínuo e uma resposta rápida a incidentes sem dependência de condutores a bordo.
Porque é Essencial um Produto de Alta Disponibilidade SANless Tudo-em-Um?
No mundo da continuidade de negócio, muitas organizações acreditam erradamente que ter uma cópia de segurança (backup) ou uma ferramenta de replicação de dados é o mesmo que ter Alta Disponibilidade (HA). Na realidade, estas são apenas peças de um puzzle muito maior. Para garantir verdadeiramente 100% de tempo de atividade (uptime), necessita de uma solução tudo-em-um que integre todas as camadas do processo de failover.
Eis porque é que uma abordagem fragmentada falha e porque é necessário um produto integrado e tudo-em-um como o SafeKit — que utiliza replicação baseada em host ao nível do ficheiro.
A replicação baseada em host é suficiente por si só para Alta Disponibilidade?
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.
Os Riscos Ocultos das Soluções Fragmentadas: Porque é que a HA em Silos Aumenta as Falhas
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 além dos dados, que componentes específicos são necessários para um verdadeiro failover SANless?
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.
Porque é que o mecanismo de failover deve estar sincronizado com a replicação baseada em host?
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.
O que acontece quando o servidor com falha é reparado (failback)?
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:
- Resincronizar os dados em segundo plano, do nó ativo para o nó recuperado.
- Manter o Tempo de Atividade (Uptime): esta resincronização deve ocorrer sem interromper a aplicação que está a correr no nó ativo.
- 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.
Replicação ao Nível do Bloco vs. Ficheiro: Porque é que a Transparência é Importante
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.
Escolher a sua estratégia de Alta Disponibilidade: HA de VM vs. HA de Aplicação
SafeKit oferece duas abordagens principais para garantir a continuidade do negócio: Alta Disponibilidade de Máquinas Virtuais (VM HA) e Alta Disponibilidade de Aplicações (Application HA). Embora ambos os métodos forneçam capacidades de failover automático, diferem significativamente no seu âmbito, nos mecanismos de replicação de dados, na velocidade de recuperação e na compatibilidade com plataformas. Esta comparação detalha essas diferenças para ajudar a identificar a estratégia ideal para ambientes de TI específicos, quer o foco seja um suporte amplo à virtualização ou uma recuperação de aplicações granular e de alta velocidade.
Comparação de Funcionalidades: SafeKit VM HA vs. Clustering de Aplicação SafeKit
| Funcionalidade de Comparação | VM HA com módulo SafeKit Hyper-V ou KVM | Application HA com módulos de aplicação SafeKit |
|---|---|---|
| Diagrama de Implementação | ||
| Âmbito do Failover | SafeKit em 2 hipervisores: replicação e failover da VM completa. | SafeKit em 2 máquinas virtuais ou físicas: replicação e failover ao nível da aplicação. |
| Dados Replicados | Replica mais dados (Aplicação + Sistema Operativo). | Replica apenas os dados da aplicação, resultando em menores volumes de dados. |
| Processo de Recuperação & Velocidade (RTO) | Reinício da VM no hipervisor 2 se o hipervisor 1 falhar. O tempo de recuperação depende do reinício do sistema operativo. Monitor de VM e mecanismo de failover. | Tempo de recuperação rápido com o reinício da aplicação no SO2 se o servidor 1 falhar. Tipicamente cerca de 1 minuto ou menos (baixo RTO). Monitor de aplicações e failover por software. |
| Instalação | A aplicação é instalada uma vez numa única VM. | A aplicação é instalada em dois nós. |
| Configuração | Solução genérica para qualquer aplicação/SO em execução na VM. • Não requer conhecimento técnico da aplicação instalada na VM. • É a melhor solução se não souber como a aplicação funciona. • Basta definir a localização dos ficheiros da VM. | Requer conhecimento técnico da própria aplicação. • Quais os serviços que precisam de ser reiniciados. • As pastas específicas da aplicação que necessitam de replicação em tempo real. • A configuração de um endereço IP virtual para failover. |
| Compatibilidade de Plataforma | Funciona com Windows/Hyper-V e Linux/KVM, mas não é compatível com VMware. | Independente da plataforma; funciona com máquinas físicas ou virtuais, infraestrutura cloud e qualquer hipervisor, incluindo VMware. |
| Ideal Para | Ideal para gerir ambientes complexos com múltiplas aplicações distribuídas por várias VMs através de uma única política de HA. | Ideal para integrar a alta disponibilidade diretamente numa solução de software, independentemente do hardware ou hipervisor subjacente. |
Limitações da Alta Disponibilidade SafeKit
Porquê uma replicação de alguns Terabytes?
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.
Porquê uma replicação < 1.000.000 ficheiros?
- 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.
Porquê um failover ≤ 32 VMs replicadas?
- 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.
Porquê uma rede LAN/VLAN entre sites remotos?
- 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.
Tutoriais Técnicos e Demos de Failover do SafeKit
Vídeo SafeKit: Webinar (9:43)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Capítulos
- Introdução (0:38)
- Demonstração do SafeKit (1:41)
- Exemplos de soluções de redundância e alta disponibilidade (2:00)
- SafeKit vendido em muitos países diferentes com a Milestone (0:49)
- Escolha entre 2 soluções: máquina virtual ou cluster de aplicações (2:29)
- Vantagens distintivas (2:06)
SafeKit: Como Implementar HADR (6:42)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Capítulos
- Introdução ao SafeKit HADR sobre VLANs estendidas (Stretched VLANs) (1:06)
- Como funciona o espelhamento síncrono e a confirmação dupla (Double-Acknowledgment) (1:41)
- Mecanismo de failover: ARP gratuito (GARP) e IP virtual (2:10)
- Desenhar para WAN lenta: estratégias de alta disponibilidade (HA) vs. cópias de segurança (Backup) (2:45)
Saiba mais sobre o SafeKit HADR
Vídeo SafeKit: Clustering ao Nível da Máquina Virtual (5:15)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Capítulos
- 2 nós Hyper-V e 2 máquinas virtuais (0:49)
- Configurar o cluster e dois módulos hyperv.safe (1:59)
- Iniciar e testar a replicação, migração e failover de VMs em caso de falha (crash) (2:26)
Vídeo SafeKit: Clustering ao Nível de Aplicação com SQL (8:47)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Capítulos
- 2 nós com SQL Server (0:32)
- Configurar o cluster e o módulo mirror.safe (3:58)
- Iniciar e testar a replicação, migração e failover do SQL em caso de falha (crash) (4:17)
Vídeo SafeKit: Integração OEM de Alta Disponibilidade (4:22)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Capítulos
- SafeKit para integração OEM (0:09)
- Exemplo de configuração OEM: Milestone XProtect (2:18)
- Explicação dos cenários de failover (1:49)
- Resumo: adicione alta disponibilidade (HA) OEM ao seu catálogo (0:15)
Vídeo SafeKit: Clustering com Balanceamento de Carga de Rede (5:03)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Capítulos
- 2 nós com Apache (0:13)
- Configurar o cluster e o módulo farm.safe (2:20)
- Iniciar e testar o equilíbrio de carga de rede e o failover em caso de falha (crash) (2:30)
Vídeo SafeKit: Tutorial da Plataforma de Certificação Gratuita (6:11)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Capítulos
- A plataforma de formação e certificação (1:41)
- O que é um módulo de formação SafeKit? (1:57)
- Como obter um certificado SafeKit? (1:40)
- Partilhe o seu certificado no LinkedIn (0:53)
Plataforma de formação e certificação aqui
Vídeo SafeKit: Concorrência e Arquiteturas de Cluster (13:21)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Capítulos
- Introdução (4:10)
- Cluster de máquinas virtuais (1:20)
- Cluster espelhado (Mirror) (6:04)
- Cluster repartido (Farm) (1:46)
Ver comparação entre o SafeKit e Clusters HA Tradicionais
Vídeo SafeKit: Consola no Smartphone (0:54)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Vídeo SafeKit: Notificações por Email em Failover (1:04)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Como funciona o cluster espelho (mirror cluster) do SafeKit com o Windows/Linux?
Passo 1. Replicação em tempo real
O Servidor 1 (PRIM) executa a aplicação Windows/Linux. Os clientes estão ligados a um endereço IP virtual. O SafeKit replica em tempo real as modificações efetuadas 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.
Apenas necessita de 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.
Passo 2. Failover automático
Quando o Servidor 1 falha, o Servidor 2 assume o controlo. O SafeKit alterna o endereço IP virtual e reinicia a aplicação Windows/Linux 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 já não são replicados para o Servidor 1.
O tempo de failover é igual ao tempo de deteção de falhas (30 segundos por defeito) mais o tempo de inicialização da aplicação.
Passo 3. Failback automático
O failback envolve reiniciar o Servidor 1 após a resolução do problema que causou a sua 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 interromper a aplicação Windows/Linux, que pode continuar em execução no Servidor 2.
Passo 4. Retorno ao normal
Após a reintegração, os ficheiros ficam novamente em modo espelho (mirror), como no passo 1. O sistema regressa ao modo de alta disponibilidade, com a aplicação Windows/Linux em execução no Servidor 2 e o SafeKit a replicar as atualizações de ficheiros para o Servidor 1.
Se o administrador pretender que a aplicação seja executada no Servidor 1, isso pode ser feito manualmente através da consola web num momento apropriado ou automaticamente através de configuração.
Como configurar um Cluster Espelho (Mirror Cluster) do SafeKit para o Windows/Linux?
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.
Como monitorizar um cluster espelho (mirror cluster) do SafeKit para o Windows/Linux?
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.
Como funciona o cluster SafeKit em modo farm com Windows/Linux?
Endereço IP virtual num cluster em modo farm
Na figura anterior, a aplicação Windows/Linux 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 está configurado localmente em cada servidor no cluster em modo 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 disponibiliza verificadores de aplicação e scripts de recuperação configuráveis.
Equilíbrio de carga num filtro de rede
O algoritmo de equilíbrio 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 nos outros servidores rejeitam-no.
Assim que um pacote é aceite pelo filtro num servidor, apenas a CPU e a memória deste servidor são utilizadas pela aplicação Windows/Linux que responde ao pedido do cliente. As mensagens de saída são enviadas diretamente do servidor da aplicação para o cliente.
Se um servidor falhar, o protocolo de heartbeat da farm reconfigura os filtros no cluster de equilíbrio de carga de rede para redistribuir o tráfego pelos servidores restantes disponíveis.
Aplicações com estado (stateful) ou sem estado (stateless)
Com uma aplicação Windows/Linux 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 equilíbrio de carga do SafeKit é configurada com base no endereço IP do cliente. Assim, o mesmo cliente está sempre ligado ao mesmo servidor em múltiplas sessões TCP. E os diferentes clientes são distribuídos pelos vários servidores da farm.
Com uma aplicação Windows/Linux sem estado (stateless), não existe afinidade de sessão. O mesmo cliente pode estar ligado a diferentes servidores da 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 equilíbrio de carga do SafeKit é configurada com base 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.
Como configurar um cluster SafeKit em modo farm para Windows/Linux?
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.
Como monitorizar um cluster SafeKit em modo farm para Windows/Linux?
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.
Comparação do SafeKit com Clusters de Alta Disponibilidade (HA) Tradicionais
Esta comparação destaca as diferenças fundamentais entre o SafeKit e as soluções tradicionais de cluster de alta disponibilidade (HA), como Failover Clusters, HA por virtualização e SQL Always-On. O SafeKit é concebido como uma solução de baixa complexidade, exclusivamente em software, para redundância genérica de aplicações, contrastando com a elevada complexidade e os requisitos específicos de armazenamento (armazenamento partilhado, SAN) típicos dos mecanismos HA tradicionais.
Comparação do SafeKit com clusters tradicionais de alta disponibilidade (HA)
| Soluções | Complexidade | Comentários |
|---|---|---|
| Failover Cluster (Microsoft) | Elevada | Armazenamento específico (armazenamento partilhado, SAN) |
| Virtualização (VMware HA) | Elevada | Armazenamento específico (armazenamento partilhado, SAN, vSAN) |
| SQL Always-On (Microsoft) | Elevada | Apenas o SQL é redundante, requer SQL Enterprise Edition |
| SafeKit | Baixa | O mais simples, genérico e exclusivamente em software. Não adequado para replicação de grandes volumes de dados. |
Em resumo , o SafeKit alcança alta disponibilidade com baixa complexidade através de um mecanismo simples de espelhamento baseado em software, que elimina a necessidade de hardware dedicado e dispendioso, como uma SAN (Storage Area Network). Isto torna-o numa solução altamente acessível para implementar rapidamente a redundância de aplicações sem alterações complexas na infraestrutura.
Diferenciadores Arquitetónicos: SafeKit Definido por Software vs. Clusters HA de Hardware
Escolher a solução de Alta Disponibilidade (High Availability - HA) correta é essencial para garantir a continuidade do negócio e minimizar o tempo de inatividade. Esta comparação oferece uma análise técnica direta de duas abordagens arquiteturais principais: o clustering por software sem partilha (Shared-Nothing) da SafeKit em contrapartida aos métodos tradicionais de HA, que dependem tipicamente de hardware, discos partilhados (como uma SAN) e configurações complexas. Estas distinções abrangem a simplicidade de implementação, os métodos de replicação de dados, a velocidade de recuperação (RTO/RPO) e a complexidade operacional. A tabela abaixo detalha as principais diferenças nos tópicos fundamentais de alta disponibilidade.
Comparação de Alta Disponibilidade: Clustering por software SafeKit vs. HA tradicional / Clustering de hardware
| Tópico | SafeKit (Clustering por software / Abordagem principal) | HA tradicional / Clustering de hardware |
|---|---|---|
| Clustering por software vs. Clustering de hardware | • Um cluster de software simples, com o pacote SafeKit instalado de forma direta em apenas dois servidores | • Clustering de hardware complexo que exige armazenamento externo ou equilibradores de carga de rede |
| Cluster Shared Nothing vs. Cluster de discos partilhados | • O SafeKit é um cluster sem partilha (Shared-Nothing): fácil de implementar, mesmo em locais remotos | • Um cluster de discos partilhados é complexo de implementar |
| Alta disponibilidade de aplicação vs. Alta disponibilidade completa de máquina virtual | • A HA de aplicação suporta falhas de hardware e de software através de verificadores (checkers) de aplicação. • Tempo de recuperação rápido ao reiniciar apenas a aplicação (RTO na ordem de 1 minuto ou menos). • A HA de aplicação exige a definição de scripts de reinício por aplicação e das pastas a replicar (módulos de aplicação SafeKit). | • A HA completa de VM suporta falhas de hardware e algumas falhas de software, como uma VM bloqueada. • Reinício da VM em caso de falha e tempo de recuperação dependente da reinicialização do sistema operativo. • Nenhum script de reinício precisa de ser definido com a HA completa de VM (módulos SafeKithyperv.safeoukvm.safe). Os hipervisores operam em ativo/ativo com múltiplas máquinas virtuais. |
| Alta disponibilidade vs. Tolerância a falhas (Fault Tolerance) | • Sem servidor dedicado no SafeKit. Cadaservidor pode atuar como o servidor de failover do outro. • Falha de software com reinício noutro ambiente de sistema operativo. • Atualização contínua (rolling upgrade) de aplicações e SO possível servidor a servidor (as versões N e N+1 podem coexistir). | • Servidor secundário dedicado à execução da mesma aplicação sincronizada ao nível da instrução. • Exceção de software a ocorrer em ambos os servidores ao mesmo tempo. • Atualização contínua indisponível. • Hardware ou hipervisores específicos com tolerância a falhas. |
| Replicação síncrona vs. Replicação assíncrona | • O SafeKit implementa replicação síncrona em tempo real, sem qualquer perda de dados em caso de falha. • Pré-requisito essencial para a alta disponibilidade. | • Com a replicação assíncrona, ocorre perda de dados em caso de falha. • Não indicada para alta disponibilidade, mas sim para soluções de cópia de segurança (backup). |
| Replicação de ficheiros ao nível do byte vs. Replicação de disco ao nível do bloco | • O SafeKit implementa replicação de ficheiros em tempo real ao nível do byte e é configurado de forma simples, definindo as diretorias da aplicação a replicar, mesmo no disco do sistema. | • A replicação de disco ao nível do bloco é complexa de configurar e exige a alocação dos dados da aplicação num disco dedicado. |
| Heartbeat, Failover e Quorum para evitar 2 nós Masters | • Para evitar 2 masters (Split-Brain), o SafeKit oferece um verificador simples de split-brain configurado num router. | • Para evitar 2 masters, outros clusters exigem uma configuração complexa com uma terceira máquina, um disco de quorum dedicado ou uma ligação de interligação exclusiva. |
| Endereço IP Virtual: Primário/Secundário, equilíbrio de carga de rede, failover | • Nenhum servidor proxy dedicado nem configuração de rede especial são necessários num cluster SafeKit para os endereços IP virtuais. | • Configurações de rede especiais são necessárias noutros clusters para endereços IP virtuais (nota: o SafeKit oferece um health check adaptado a equilibradores de carga). |
Em resumo , a escolha arquitetónica entre clustering por software (como o SafeKit) e clustering por hardware (arquiteturas tradicionais com disco partilhado/SAN) tem um impacto significativo na complexidade da implementação, nos custos operacionais e na eficácia da recuperação após falhas. A principal conclusão desta comparação é a transição para arquiteturas shared-nothing e alta disponibilidade (HA) ao nível da aplicação, que privilegiam a rápida recuperação das aplicações (baixo RTO) e a flexibilidade de implementação (incluindo entre locais remotos). Isto resulta frequentemente numa solução mais simples, eficiente e resiliente do que configurações de cluster altamente complexas e dependentes de hardware. Para maximizar a continuidade do negócio com uma gestão simplificada, é essencial avaliar uma abordagem baseada em software.
Diferenciais Chave do Cluster Mirror SafeKit
Escolher a abordagem correta de replicação de dados é fundamental para garantir a continuidade do negócio. Esta comparação destaca os principais diferenciadores do cluster espelho SafeKit com replicação de ficheiros em tempo real face às alternativas tradicionais, como a replicação ao nível da base de dados, a replicação de disco, as soluções de disco partilhado e os sistemas tolerantes a falhas.
Cluster espelho SafeKit: vantagens sobre abordagens alternativas de replicação e clustering
| Característica | Vantagem SafeKit | Limitação das alternativas |
|---|---|---|
| 3 produtos em 1 | Poupa no Windows e Linux o custo de armazenamento externo partilhado/replicado, equipamentos de balanceamento de carga e edições enterprise de sistemas operativos e bases de dados. Inclui todas as funcionalidades de clustering: replicação síncrona de ficheiros em tempo real, monitorização de falhas, reinício automático, failover de IP virtual. | As abordagens tradicionais exigem produtos separados para replicação de armazenamento, balanceamento de carga e clustering — aumentando custos e complexidade. |
| Configuração muito simples | Configuração através de módulos de aplicação. Novos serviços e diretórios replicados podem ser adicionados facilmente. Tudo gerido por uma consola web centralizada. Nenhum controlador de domínio ou Active Directory necessário. | Microsoft cluster e soluções semelhantes exigem configuração complexa de Active Directory e controladores de domínio. |
| Replicação síncrona | A replicação em tempo real é síncrona sem perda de dados em caso de falha (RPO = 0). | A replicação assíncrona pode perder transações recentes que ainda não foram replicadas no momento da falha. |
| Failback totalmente automatizado | Após uma falha, quando um servidor reinicia, o failback de replicação é totalmente automático. O servidor que falhou é reintegrado no cluster sem parar a aplicação no servidor restante. | A maioria das soluções de replicação (especialmente ao nível da base de dados) exige ressincronização manual. A aplicação pode mesmo ser parada durante o failback. |
| Replicação de qualquer tipo de dados | A replicação funciona para bases de dados e para quaisquer ficheiros que precisem de ser replicados. | A replicação ao nível da base de dados protege apenas a base de dados, não ficheiros de configuração, registos ou outros dados da aplicação. |
| Replicação de ficheiros vs. replicação de disco | A replicação baseia-se em diretórios de ficheiros que podem estar localizados em qualquer sítio, inclusive no disco do sistema. | A replicação de disco exige uma partição dedicada e configuração especial da aplicação para armazenar os dados. |
| Replicação de ficheiros vs. disco partilhado | Os servidores podem ser implementados em dois locais remotos sem infraestrutura partilhada. | As soluções de disco partilhado exigem proximidade física e não conseguem abranger locais remotos. |
| Locais remotos e IP virtual | Todas as funcionalidades de clustering funcionam para 2 servidores em locais remotos. A LAN estendida permite o reencaminhamento VIP de nível 2. Para redes IP diferentes, o VIP é gerido por um balanceador de carga com health check do SafeKit. | Muitas soluções de clustering não suportam failover entre locais remotos ou exigem redirecionamento DNS complexo com tempos de recuperação imprevisíveis. |
| Quórum e split brain | Funciona com apenas 2 servidores. Um verificador simples de split brain para um router gere o isolamento de rede entre os locais. | A maioria das soluções de clustering exige um 3.º servidor para gestão do quórum. |
| Cluster ativo/ativo | O servidor secundário não é dedicado. O cluster pode operar em modo ativo/ativo com 2 módulos espelho diferentes. | Os sistemas tolerantes a falhas dedicam o secundário à execução da mesma aplicação sincronizada ao nível das instruções. |
| Solução HA uniforme | O SafeKit implementa tanto o cluster espelho (replicação + failover) como o cluster farm (balanceamento de carga + failover). Uma arquitetura N-camadas pode ser tornada altamente disponível com uma única solução no Windows e Linux. | Arquiteturas típicas misturam tecnologias diferentes para balanceamento de carga, replicação e failover — aumentando a complexidade operacional. |
| RTO / RPO | Reinício rápido da aplicação em caso de falha: cerca de 1 minuto ou menos. Zero perda de dados (replicação síncrona). | A replicação completa de VM (VMware HA, Hyper-V cluster) exige o reinício de todo o sistema operativo num novo hipervisor, resultando em tempos de recuperação mais longos. |
Em resumo , o cluster espelho SafeKit oferece uma solução de alta disponibilidade unificada e económica que combina replicação síncrona de ficheiros, failover e failback automáticos, balanceamento de carga e suporte a locais remotos — tudo sem exigir hardware dedicado, armazenamento partilhado ou um terceiro servidor de quórum. Esta simplicidade torna-o particularmente adequado para editores de software e organizações que necessitam de HA fiável em servidores Windows e Linux padrão.
Diferenciais Chave do Cluster Farm SafeKit
O SafeKit Farm Cluster é uma solução de alta disponibilidade especificamente concebida para ambientes de aplicações escaláveis onde a distribuição de carga e o failover rápido são essenciais. Ao contrário dos métodos tradicionais que requerem balanceadores de carga de hardware dedicados ou configurações de rede complexas, o SafeKit disponibiliza uma solução de clustering integrada e definida por software, instalada diretamente nos servidores de aplicação. A tabela abaixo detalha as funcionalidades principais e as vantagens únicas do SafeKit Farm Cluster, focando em como simplifica o balanceamento de carga de rede e garante a disponibilidade contínua dos serviços nas plataformas Windows e Linux.
Principais diferenciadores do SafeKit Farm Cluster com balanceamento de carga e failover
| Vantagem | Benefício detalhado e mecanismo |
|---|---|
| Sem balanceador de carga, servidores proxy dedicados ou endereço Ethernet multicast especial | • A solução não requer balanceadores de carga ou servidores proxy dedicados acima da farm para implementar o balanceamento de carga. O SafeKit é instalado diretamente nos servidores de aplicação na farm. O balanceamento de carga baseia-se num endereço IP virtual padrão / endereço MAC Ethernet e funciona com servidores físicos ou máquinas virtuais em Windows e Linux sem configuração de rede especial • Isto não acontece com balanceadores de carga de rede • Isto não acontece com proxies dedicados em Linux • Isto não acontece com umendereço Ethernet multicast específicoem Windows |
| Todas as funcionalidades de clustering | • A solução inclui todas as funcionalidades de clustering: endereço IP virtual, balanceamento de carga por endereço IP do cliente ou por sessões, monitorização de falhas de servidor / rede / software, reinício automático da aplicação com tempo de recuperação rápido e umaopção de replicação com um módulo espelho • Isto não acontece com outras soluções de balanceamento de carga. Estas conseguem efetuar balanceamento de carga, mas não incluem uma solução de clustering completa com scripts de reinício e reinício automático da aplicação em caso de falha. Não oferecem opção de replicação • A configuração do cluster é muito simples e efetuada por meio demódulos de aplicação. Não há controlador de domínio ou Active Directory para configurar em Windows. A solução funciona em Windows e Linux |
| Sites remotos e endereço IP virtual | • Se os servidores estão ligados à mesma rede IP através de uma LAN estendida entre sites remotos, oendereço IP virtualdo SafeKit funciona com balanceamento de carga ao nível 2 • Se os servidores estão ligados a redes IP diferentes entre sites remotos, o endereço IP virtual pode ser configurado ao nível de um balanceador de carga com o auxílio do health check do SafeKit. Assim, pode implementar balanceamento de carga, mas também todas as funcionalidades de clustering do SafeKit, nomeadamente a monitorização e a recuperação automática da aplicação crítica nos servidores de aplicação |
| Solução uniforme de alta disponibilidade | • O SafeKit implementa um farm cluster com balanceamento de carga e failover. Mas implementa também umcluster espelho com replicação e failover. • Assim, uma arquitetura N-camadas pode ser tornada altamente disponível e com carga balanceada com a mesma solução em Windows e Linux (mesma instalação, configuração, administração com a consola SafeKit ou com a interface de linha de comandos). Isto é único no mercado • Isto não acontece com uma arquitetura que mistura diferentes tecnologias para balanceamento de carga, replicação e failover |
Em resumo , o SafeKit Farm Cluster oferece uma abordagem unificada e baseada em software para balanceamento de carga e alta disponibilidade que reduz drasticamente a complexidade e o custo. Ao incorporar o balanceamento de carga e o failover diretamente na camada do servidor de aplicação utilizando um endereço IP virtual padrão, elimina a necessidade de hardware de rede externo (balanceadores de carga ou proxies) e configurações multicast especializadas. Esta abordagem integrada, aliada à sua capacidade de se combinar com o cluster espelho para HA N-camadas completa, torna o SafeKit uma solução de simplicidade e abrangência únicas para alcançar uma entrega de aplicações escalável e resiliente em ambientes diversificados.
Alta Disponibilidade de VM: SAN-Less SafeKit vs. HA Hyper-V/VMware
Ao implementar alta disponibilidade, uma decisão fundamental é proteger ao nível da máquina virtual (VM) ou ao nível da aplicação. A HA ao nível da VM replica e faz failover de máquinas virtuais inteiras, proporcionando uma solução genérica para qualquer aplicação. A HA ao nível da aplicação visa apenas os dados e serviços da aplicação, resultando em tempos de recuperação mais rápidos e menor utilização de recursos. O SafeKit oferece de forma única ambas as abordagens — sem exigir armazenamento partilhado (SAN) em nenhum dos casos — permitindo escolher a melhor opção para a sua infraestrutura e requisitos de recuperação.
SafeKit HA de VM vs HA de aplicação vs Hyper-V Cluster & VMware HA tradicionais
| Critério | HA de VM com módulo SafeKit Hyper-V ou KVM | HA de aplicação com módulos de aplicação SafeKit | Microsoft Hyper-V Cluster & VMware HA |
|---|---|---|---|
| Arquitectura | SafeKit instalado em 2 hipervisores. Replicação e failover da VM completa. | SafeKit instalado em 2 máquinas virtuais ou físicas. Replicação e failover ao nível da aplicação. | Cluster de hipervisores com armazenamento partilhado. Reinício da VM noutro anfitrião se o hipervisor falhar. |
| Armazenamento | Sem disco partilhado — replicação síncrona em tempo real sem perda de dados | Sem disco partilhado — replicação síncrona apenas dos dados da aplicação | Requer disco partilhado e gabinete de discos externo específico |
| Dados replicados | Replica mais dados (aplicação + SO) | Replica apenas dados da aplicação | Sem replicação — armazenamento partilhado acedido por todos os anfitriões |
| Tempo de recuperação | Reinício da VM no hipervisor 2 se o hipervisor 1 falhar. Tempo de recuperação = tempo de reinício da VM. Failover se a VM falhar. | Recuperação rápida com reinício da aplicação no servidor 2. Cerca de 1 minuto ou menos (ver RTO/RPO aqui). Verificador avançado de aplicação e failover por software. | Reinício completo da VM num novo hipervisor. Tempo de recuperação depende do reinício do SO + arranque da aplicação. |
| Recuperação de desastres / Locais remotos | Sem necessidade de SAN — replicação integrada no SafeKit entre locais remotos | Sem necessidade de SAN — replicação integrada no SafeKit entre locais remotos | Requer gabinetes de discos replicados via SAN ou vSAN |
| Configuração | Definir a localização da pasta de ficheiros da VM onde a aplicação está instalada. Solução genérica para qualquer aplicação/SO. | Definir serviços a reiniciar, pastas da aplicação a replicar e um endereço IP virtual para failover num módulo de aplicação. | Competências de TI específicas necessárias para configurar o sistema |
| Plataformas suportadas | Funciona com Hyper-V e KVM (não VMware directamente, excepto aninhando Hyper-V ou KVM dentro do VMware). | Funciona em qualquer infraestrutura: servidores físicos, máquinas virtuais VMware, Hyper-V, KVM, nuvem. | Limitado a ambientes VMware vSphere ou Microsoft Hyper-V |
| Competências de TI | Nenhuma competência de TI específica necessária. Failover automático. | Nenhuma competência de TI específica necessária. Failover automático. | Competências de TI específicas necessárias para configurar o sistema |
Em resumo , o SafeKit é a única solução que oferece alta disponibilidade tanto ao nível de VM como ao nível de aplicação sem armazenamento partilhado. Para máxima flexibilidade e tempos de recuperação mais rápidos (cerca de 1 minuto), a HA ao nível da aplicação é a abordagem preferida — funciona em qualquer plataforma (física, virtual ou nuvem) e replica apenas os dados importantes. Para ambientes onde proteger a VM inteira é mais simples, o módulo Hyper-V/KVM do SafeKit oferece uma alternativa genérica sem SAN ao tradicional Microsoft Hyper-V Cluster ou VMware HA — eliminando o custo e a complexidade da infraestrutura de armazenamento partilhado enquanto garante zero perda de dados através de replicação síncrona em tempo real.
Note que as soluções SafeKit são as mais simples de implementar, mas estão limitadas à replicação de alguns terabytes e ao failover de 32 VMs.
Teste Gratuito do SafeKit HA & Documentação Técnica
💡 Para iniciar a sua jornada de alta disponibilidade com o SafeKit, comece com os Guias de Instalação Rápida.
📦 Pacotes de Software HA do SafeKit - Versão 8.2
Esta tabela fornece os ficheiros de instalação do SafeKit para a versão atual, organizados por sistema operativo e tipo de instalador.
| SO / Plataforma | Tipo de Instalador | Benefício Chave / Documentação | Link de Download |
|---|---|---|---|
| Todas as Plataformas | Documento PDF | Boletim Oficial de Lançamento de Software (Suporte de SO e Correções) | 📄 Ver SafeKit 8.2 SRB |
| Windows (Intel 64-bit) | Instalador .exe | Inclui Microsoft VC++ Redistributable | ⬇️ Descarregar SafeKit 8.2 Windows EXE |
| Windows (Intel 64-bit) | Instalador .msi | Não inclui Microsoft VC++ Redistributable | ⬇️ Descarregar SafeKit 8.2 Windows MSI |
| Linux (Intel 64-bit) | .BIN Auto-extraível | Inclui pacote Linux e script de instalação | ⬇️ Descarregar SafeKit 8.2 Linux BIN (Intel) |
| Linux (ARM 64-bit) | .BIN Auto-extraível | Inclui pacote Linux e script de instalação | ⬇️ Descarregar SafeKit 8.2 Linux BIN (ARM) |
🔑 Chave de Teste HA do SafeKit
O link seguinte fornece acesso a uma avaliação completa das funcionalidades, concebida para testar e configurar um cluster de High Availability com o SafeKit.
➡️ Obtenha a Sua Chave de Teste Gratuita de 1 Mês para Testar a High Availability do SafeKit
📚 Guias de Configuração do SafeKit para o seu Cluster HA
Documentação essencial para configurar e gerir o seu cluster de Alta Disponibilidade SafeKit.
- Guias de Instalação Rápida do SafeKit
- Guia do Utilizador do SafeKit em HTML (Versão 8.2) / Descarregar PDF
- Notas de Lançamento do SafeKit em HTML (Versão 8.2) / Descarregar PDF
- Boletim de Lançamento de Software do SafeKit 8.2 (SRB)
- Base de Conhecimento do SafeKit
📞/🤖 Suporte SafeKit
- 📞 Suporte pago / 🤖 Suporte gratuito
🎓 Formação e Certificação Gratuitas sobre SafeKit
Ganhe experiência valiosa em High Availability (HA) com o nosso programa de certificação gratuito.
ℹ️ Documentação de Marketing do Produto
Explore a nossa documentação de marketing do produto para o software de Alta Disponibilidade SafeKit, que inclui uma ficha técnica detalhada, um white paper do produto e uma visão técnica geral.
- Ficha Técnica do Cluster de Alta Disponibilidade SafeKit (PDF)
- White Paper sobre Tecnologia de Clusters de Alta Disponibilidade (PDF)
- White Paper – Guia de Alta Disponibilidade (PDF)
- Referência Técnica para Preparação de RFI e RFP
Biblioteca de Módulos de Aplicação SafeKit: Soluções HA Prontas a Utilizar
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, Contentores, Cloud). Identifique o módulo .safe pré-configurado específico (por exemplo, mirror.safe, farm.safe, entre outros) necessário para replicação em tempo real, balanceamento de carga e failover automático de aplicações empresariais críticas em Windows ou Linux. Simplifique a configuração do seu cluster HA com ligações diretas para guias de instalação rápida.
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, é um ficheiro zip que contém um ficheiro de configuração (userconfig.xml) e scripts de reinício.
⚠️ Nota: * Os módulos mirror.safe e farm.safe estão incluídos por defeito no pacote de instalação do SafeKit.
Soluções de Alta Disponibilidade (HA) SafeKit: Guias de Instalação Rápida (com módulos .safe descarregáveis)
