--- title: "Arquitecturas de alta disponibilidade e boas práticas de clustering de software" canonical: "https://safekit.eviden.com/pt-pt/best-practises/high-availability-architectures-and-best-practices/" description: "Explore arquitecturas de alta disponibilidade (HA) e boas práticas para clusters de aplicações. O SafeKit implementa clusters Mirror e Farm sem discos partilhados, evita a perda de dados e proporciona failover automático para aplicações críticas." category: "best-practises" lang: "pt-pt" topics: "Quais são as arquitecturas de alta disponibilidade e as boas práticas?, Tabelas comparativas de arquitecturas de alta disponibilidade e boas práticas" --- # Arquitecturas de alta disponibilidade e boas práticas de clustering de software {#high-availability-architectures--software-clustering-best-practices} ## Quais são as arquitecturas 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 várias arquitecturas de alta disponibilidade e boas práticas, comparando as vantagens e desvantagens de cada uma. ![Arquitecturas 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 seguintes detalham a arquitectura de alta disponibilidade SafeKit e as respectivas boas práticas. O SafeKit é um produto de software para alta disponibilidade. ### Quais são as arquitecturas de alta disponibilidade? {#what-are-the-high-availability-architectures} Existem dois tipos de [arquitecturas de alta disponibilidade](): as destinadas a aplicações de back-end, como bases de dados, e as destinadas a aplicações de front-end, como serviços Web. As arquitecturas de back-end baseiam-se em dois servidores que partilham ou replicam dados e efectuam failover automático da aplicação em caso de falhas de hardware ou software. As arquitecturas de front-end baseiam-se numa farm de dois ou mais servidores. O balanceamento de carga, por hardware ou software, distribui as sessões TCP pelos servidores disponíveis. É também necessário escolher entre alta disponibilidade ao nível da aplicação e ao nível da máquina virtual. ### Quais são as boas práticas? {#what-are-the-best-practices} Este artigo analisa as boas práticas das arquitecturas de alta disponibilidade comparando: * [clustering de software e hardware](), * [arquitectura sem partilha e com disco partilhado](), * [alta disponibilidade da aplicação e da máquina virtual](), * [alta disponibilidade e tolerância a falhas](), * [replicação síncrona e assíncrona](), * [replicação de ficheiros 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 arquitecturas 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 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](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 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](https://safekit.eviden.com/best-practises/shared-nothing-architecture-vs-shared-disk-architecture/) | • 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](https://safekit.eviden.com/pt-pt/best-practises/vm-ha-vs-application-ha/) | • 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](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 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 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 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](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 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](https://safekit.eviden.com/best-practises/byte-level-file-replication-vs-block-level-disk-replication/) | • 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](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 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](https://safekit.eviden.com/best-practises/how-a-virtual-ip-address-works/) | • 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.