--- title: "Arquiteturas de alta disponibilidade e boas práticas de clustering de software" canonical: "https://safekit.eviden.com/pt-br/best-practises/high-availability-architectures-and-best-practices/" description: "Conheça arquiteturas de alta disponibilidade (HA) e boas práticas para clusters de aplicações. O SafeKit implementa clusters Mirror e Farm sem discos compartilhados, evita a perda de dados e oferece failover automático para aplicações críticas." category: "best-practises" lang: "pt-br" topics: "Quais são as arquiteturas de alta disponibilidade e as boas práticas?, Tabelas comparativas de arquiteturas de alta disponibilidade e boas práticas" --- # Arquiteturas de alta disponibilidade e boas práticas de clustering de software {#high-availability-architectures--software-clustering-best-practices} ## Quais são as arquiteturas de alta disponibilidade e as boas práticas? {#what-are-the-high-availability-architectures-and-the-best-practices} ### Visão geral {#overview} Este artigo apresenta diferentes arquiteturas de alta disponibilidade e boas práticas, comparando as vantagens e desvantagens de cada uma. ![Arquiteturas de alta disponibilidade e boas práticas](https://safekit.eviden.com/wp-content/uploads/2023/03/high-availability-architectures-and-best-practices.png "w:400") As tabelas comparativas a seguir detalham a arquitetura de alta disponibilidade do SafeKit e suas boas práticas. O SafeKit é um produto de software para alta disponibilidade. ### Quais são as arquiteturas de alta disponibilidade? {#what-are-the-high-availability-architectures} Há dois tipos de [arquiteturas de alta disponibilidade](): as voltadas a aplicações de back-end, como bancos de dados, e as voltadas a aplicações de front-end, como serviços web. As arquiteturas de back-end se baseiam em dois servidores que compartilham ou replicam dados e fazem o failover automático da aplicação em caso de falhas de hardware ou software. As arquiteturas de front-end usam uma farm de dois ou mais servidores. O balanceamento de carga, por hardware ou software, distribui as sessões TCP entre os servidores disponíveis. Também é necessário escolher entre alta disponibilidade no nível da aplicação ou da máquina virtual. ### Quais são as boas práticas? {#what-are-the-best-practices} Este artigo analisa boas práticas de arquiteturas de alta disponibilidade comparando: * [clustering de software e hardware](), * [arquitetura sem compartilhamento e com disco compartilhado](), * [alta disponibilidade de aplicação e de máquina virtual](), * [alta disponibilidade e tolerância a falhas](), * [replicação síncrona e assíncrona](), * [replicação de arquivos e discos](), * [técnicas de replicação de dados](), * [RPO e RTO com exemplos](), * [split-brain e quorum](), * [endereços IP virtuais](). ## Tabelas comparativas de arquiteturas de alta disponibilidade e boas práticas {#comparative-tables-on-high-availability-architectures-and-best-practices} Escolher a solução de Alta Disponibilidade (High Availability - HA) correta é essencial para garantir a continuidade dos negócios e minimizar o tempo de inatividade. Esta comparação oferece uma análise técnica direta de duas abordagens arquiteturais principais: o clustering via software sem compartilhamento (Shared-Nothing) da SafeKit em contraposição aos métodos tradicionais de HA, que geralmente se baseiam em hardware, discos compartilhados (como uma SAN) e configurações complexas. Essas distinções abrangem a simplicidade de implantaçã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 via software SafeKit vs. HA tradicional / Clustering de hardware** Tópico | SafeKit (Clustering via software / Abordagem principal) | HA tradicional / Clustering de hardware ---|---|--- [Clustering via software vs. Clustering de hardware](https://safekit.eviden.com/best-practises/clustering-software-vs-hardware-clustering/) | • Um cluster de software simples, com o pacote SafeKit instalado de forma direta em dois servidores | • Clustering de hardware complexo que exige armazenamento externo ou balanceadores de carga de rede [Cluster Shared Nothing vs. Cluster de discos compartilhados](https://safekit.eviden.com/best-practises/shared-nothing-architecture-vs-shared-disk-architecture/) | • O SafeKit é um cluster sem compartilhamento (Shared-Nothing): fácil de implantar, mesmo em locais remotos | • Um cluster de discos compartilhados é complexo de implantar [Alta disponibilidade de aplicação vs. Alta disponibilidade completa de máquina virtual](https://safekit.eviden.com/pt-br/best-practises/vm-ha-vs-application-ha/) | • A HA de aplicação suporta falhas de hardware e de software por meio de verificadores (checkers) de aplicação.
• Tempo de recuperação rápido ao reiniciar apenas a aplicação ([RTO na faixa de 1 minuto ou menos](https://safekit.eviden.com/best-practises/what-is-rpo-and-rto-with-examples/)).
• A HA de aplicação exige a definição de scripts de reinicialização por aplicação e das pastas a serem replicadas (módulos de aplicação SafeKit). | • A HA completa de VM suporta falhas de hardware e algumas falhas de software, como uma VM travada.
• Reinicialização da VM em caso de falha e tempo de recuperação dependente da inicialização do sistema operacional.
• Nenhum script de reinicialização precisa ser definido com a HA completa de VM (módulos SafeKit 🛠️ [hyperv.safe](https://safekit.eviden.com/quick-install/safekit-quick-installation-guide-with-hyper-v/) ou 🛠️ [kvm.safe](https://safekit.eviden.com/quick-install/safekit-quick-installation-guide-with-kvm/)). Os hipervisores operam em ativo/ativo com múltiplas máquinas virtuais. [Alta disponibilidade vs. Tolerância a falhas (Fault Tolerance)](https://safekit.eviden.com/best-practises/high-availability-cluster-vs-fault-tolerant-system/) | • Sem servidor dedicado no SafeKit. Cada [servidor pode atuar como o servidor de failover do outro](https://safekit.eviden.com/architectures/active-active-cluster-real-time-replication/).
• Falha de software com reinicialização em outro ambiente de sistema operacional.
• Atualização contínua (rolling upgrade) de aplicações e SO possível servidor por servidor (versões N e N+1 podem coexistir). | • Servidor secundário dedicado à execução da mesma aplicação sincronizada a nível de instrução.
• Exceção de software ocorrendo 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](https://safekit.eviden.com/best-practises/synchronous-replication-vs-asynchronous-replication/) | • 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 backup. [Replicação de arquivos em nível de byte vs. Replicação de disco em nível de bloco](https://safekit.eviden.com/best-practises/byte-level-file-replication-vs-block-level-disk-replication/) | • O SafeKit implementa replicação de arquivos em tempo real em nível de byte e é configurado de forma simples, definindo os diretórios da aplicação a serem replicados, mesmo no disco do sistema. | • A replicação de disco em nível de bloco é complexa de configurar e exige a alocação dos dados da aplicação em um disco dedicado. [Heartbeat, Failover e Quorum para evitar 2 nós Masters](https://safekit.eviden.com/best-practises/heartbeat-failover-quorum-windows-linux-cluster/) | • Para evitar 2 masters (Split-Brain), o SafeKit oferece um verificador simples de split-brain configurado em um roteador. | • Para evitar 2 masters, outros clusters exigem uma configuração complexa com uma terceira máquina, um disco de quorum dedicado ou um link de interconexão exclusivo. [Endereço IP Virtual: Primário/Secundário, balanceamento de carga de rede, failover](https://safekit.eviden.com/best-practises/how-a-virtual-ip-address-works/) | • Nenhum servidor proxy dedicado ou configuração de rede especial é necessária em um cluster SafeKit para os endereços IP virtuais. | • Configurações de rede especiais são necessárias em outros clusters para endereços IP virtuais (nota: o SafeKit oferece um health check adaptado para balanceadores de carga). **Em resumo** , a escolha arquitetural entre clustering por software (como o SafeKit) e clustering por hardware (arquiteturas tradicionais com disco compartilhado/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) em nível de aplicação, que priorizam a rápida recuperação das aplicações (baixo RTO) e a flexibilidade de implantação (inclusive entre sites remotos). Isso frequentemente resulta em uma solução mais simples, eficiente e resiliente do que configurações de cluster altamente complexas e dependentes de hardware. Para maximizar a continuidade dos negócios com uma gestão simplificada, é essencial avaliar uma abordagem baseada em software.