📍 Base de Conhecimento — site principal: acp-24.com.br →

Bitrix24 Self-Hosted em Alta Disponibilidade: Cluster Master-Replica

Published: · Updated: · 12 min read · Por: Equipe Bitrix24 da ACP Group

Um cluster master-replica para Bitrix24 self-hosted elimina o ponto único de falha e garante continuidade operacional mesmo durante falhas de hardware ou manutenção planejada. Este guia cobre a arquitetura, os componentes e os passos essenciais para DevOps que precisam de HA real em ambientes on-premise.

Por que Alta Disponibilidade é Necessária no Bitrix24 On-Premise

Alta disponibilidade no Bitrix24 On-Premise é necessária quando há mais de 200-300 usuários simultâneos, integrações críticas em tempo real ou SLAs de 99,9 %+ de uptime, pois uma instalação padrão em servidor único derruba todo o portal CRM em caso de falha.

Em uma instalação padrão de Bitrix24 self-hosted, todos os componentes — web server, PHP-FPM, banco de dados MySQL/Percona e armazenamento de arquivos — rodam em um único servidor. Se esse servidor falhar, o portal CRM cai completamente. Para empresas com centenas de usuários simultâneos ou integrações críticas em tempo real, isso é inaceitável.

Com base em nossa experiência em projetos de implantação, os gatilhos mais comuns para adoção de HA são:

  • Volume de usuários acima de 200-300 concorrentes em horário de pico
  • Integrações com sistemas externos (ERP, telefonia, e-commerce) que não toleram indisponibilidade
  • Requisitos de SLA internos ou contratuais (99,9 %+ de uptime)
  • Janelas de manutenção zero — atualizações precisam ser aplicadas sem downtime

Antes de montar o cluster, vale entender o dimensionamento de hardware para diferentes volumes de usuários — os requisitos de HA somam-se aos de capacidade, não substituem.

Arquitetura do Cluster: Visão Geral dos Componentes

O cluster de HA para Bitrix24 é composto por quatro camadas independentes — balanceador de carga, 2+ nós web stateless, banco de dados com replicação MySQL/Percona e armazenamento compartilhado —, exigindo Redis ou Memcached externo para sessões e cache, sob risco de perda de sessão no failover.

Um cluster de HA para Bitrix24 é composto por quatro camadas independentes. Cada camada pode ser escalada ou failoverizada de forma separada.

Camada Componente típico Papel no HA
Balanceador de carga Nginx / HAProxy Distribui tráfego, detecta nós mortos
Web nodes 2+ servidores Bitrix (Apache + PHP-FPM) Processamento stateless da aplicação
Banco de dados MySQL/Percona Master + 1-2 Replicas Replicação assíncrona ou semissíncrona
Armazenamento compartilhado NFS / GlusterFS / S3-compatível Arquivos do portal compartilhados entre nós web

A sessão de usuário e o cache de OPcache precisam ser externalizados para um serviço compartilhado (Redis ou Memcached) — caso contrário, um usuário que cai em um nó diferente após o failover perde a sessão ativa.

Diagrama da Topologia Master-Replica

Na topologia padrão de HA do Bitrix24, o balanceador de carga detecta falhas em segundos e redireciona o tráfego automaticamente; gravações vão sempre ao MySQL Master, leituras são distribuídas entre master e replicas via ProxySQL, e sessões são centralizadas no Redis.

O diagrama abaixo descreve o fluxo de uma requisição HTTP desde o cliente até os nós de banco de dados em uma topologia típica de dois nós web com replicação MySQL master-replica. O balanceador de carga verifica a saúde de cada nó a cada poucos segundos; se um nó não responde, o tráfego é redirecionado automaticamente para o nó restante. As gravações no banco de dados vão sempre para o master; as leituras podem ser distribuídas entre master e replicas com o auxílio do ProxySQL.

flowchart LR
    Client([Usuário / Integração]) --> LB[Load Balancer\nNginx / HAProxy]
    LB --> WN1[Web Node 1\nApache + PHP-FPM]
    LB --> WN2[Web Node 2\nApache + PHP-FPM]
    WN1 --> SH[(Armazenamento\nCompartilhado\nNFS / GlusterFS)]
    WN2 --> SH
    WN1 --> PX[ProxySQL]
    WN2 --> PX
    PX --> DBM[(MySQL Master)]
    PX --> DBR1[(MySQL Replica 1)]
    DBM -- replicação --> DBR1
    WN1 --> RD[(Redis\nSessões + Cache)]
    WN2 --> RD

Configuração da Replicação MySQL/Percona

A replicação MySQL/Percona para Bitrix24 exige Percona 8.0.x com binlog_format = ROW, GTID habilitado e .settings.php apontando para o ProxySQL ou VIP; portais ainda em Percona 5.7 acumularam até 6 erros de estrutura de banco de dados identificados em auditorias de produção.

O Bitrix24 usa conexões MySQL definidas em /bitrix/.settings.php. Em ambiente de HA, este arquivo precisa apontar para o ProxySQL (ou para o IP virtual do master) em vez de localhost.

Parâmetros críticos no .settings.php

'default' => array(
  'className' => '\\Bitrix\\Main\\DB\\MysqliConnection',
  'host' => '10.0.0.10',   // IP do ProxySQL ou VIP
  'database' => 'sitemanager',
  'login'    => 'bitrix',
  'password' => '<senha_forte>',
  'options'  => 2,
),

Checklist de replicação

  • [ ] binlog_format = ROW no master — obrigatório para replicação consistente com o Bitrix24
  • [ ] gtid_mode = ON + enforce_gtid_consistency = ON — simplifica failover automático
  • [ ] sync_binlog = 1 e innodb_flush_log_at_trx_commit = 1 no master — durabilidade de dados
  • [ ] Monitorar Seconds_Behind_Master na replica — alertar se > 30 s
  • [ ] Versão do Percona/MySQL: use 8.0.x (a versão 5.7 está em fim de suporte e apresenta vulnerabilidades conhecidas, conforme identificado em auditorias de portais em produção)

Atenção: portais Bitrix24 que ainda rodam Percona 5.7 em produção têm estrutura de banco de dados com risco de corrupção silenciosa durante failover. Auditorias internas identificaram portais com até 6 erros de estrutura acumulados — parte deles corrigível automaticamente, outros exigindo intervenção manual.

Web Nodes: Configuração Stateless

Nós web stateless no Bitrix24 requerem externalização obrigatória de 5 elementos — sessões PHP e cache para Redis, arquivos de upload para NFS/GlusterFS, cron em apenas um nó com bloqueio distribuído e WebSocket com sticky session —, usando PHP-FPM 8.2.x e Percona 8.0.x como versões mínimas recomendadas.

Para que dois ou mais nós web operem corretamente em paralelo, o estado da aplicação não pode ficar armazenado localmente em nenhum deles.

Itens a externalizar

  1. Sessões PHP → Redis (configurar session.save_handler = redis no php.ini de todos os nós)
  2. Cache de dados do Bitrix24 → Redis ou Memcached (configurar em Configurações > Desempenho)
  3. Arquivos do portal (/home/bitrix/www/upload/, /home/bitrix/www/bitrix/cache/) → NFS mount ou GlusterFS com replicação síncrona
  4. Cron jobs → executar em apenas um nó ou usar bloqueio distribuído via Redis; o cron padrão do Bitrix24 fica em /home/bitrix/www/bitrix/modules/main/tools/cron_events.php
  5. Push & Pull (WebSocket) → instância dedicada ou balanceamento sticky session no LB para conexões WebSocket

Stack de web server recomendada

Componente Versão mínima recomendada
OS CentOS Stream 9 / Ubuntu 22.04 LTS
Nginx (proxy reverso) 1.26.x
Apache (dynamic) 2.4.62
PHP-FPM 8.2.x
Percona Server 8.0.x

Esses valores refletem o ambiente de referência atual do Bitrix24 (web-environment 9.x). Portais ainda rodando PHP 8.1 com Nginx 1.20 ou Apache 2.4.6 estão fora do perfil de suporte e devem ser atualizados antes de qualquer migração para HA.

Failover Automático: Estratégias e Ferramentas

Existem duas estratégias principais de failover automático de banco de dados para Bitrix24: Orchestrator com VIP (recomendado para on-premise puro, usando Keepalived/VRRP) e Percona XtraDB Cluster com RPO ≈ 0, exigindo mínimo de 3 nós; nós web falhos são removidos automaticamente pelo balanceador sem intervenção manual.

Existem duas abordagens principais para failover do banco de dados:

Opção A — Orchestrator + VIP (recomendada para on-premise puro)

  1. Orchestrator monitora a topologia de replicação e promove a replica mais atualizada a master em caso de falha
  2. Um IP virtual (Keepalived/VRRP) é movido para o novo master
  3. O ProxySQL reconfigura automaticamente as regras de roteamento de leitura/escrita

Opção B — Percona XtraDB Cluster (PXC) / Galera

  • Replicação síncrona multi-master
  • Menor risco de perda de dados (RPO ≈ 0)
  • Maior latência de escrita; adequado para portais com gravações intensas e requisito de RPO zero
  • Requer ao menos 3 nós para evitar split-brain

Failover de nós web

O balanceador de carga (Nginx upstream com max_fails e fail_timeout, ou HAProxy com health checks ativos) remove automaticamente um nó do pool quando ele não responde. Não há necessidade de intervenção manual para tráfego HTTP.

Para garantir que atualizações de módulos do Bitrix24 não causem downtime, o procedimento correto é:

  1. Fazer backup completo (banco de dados + arquivos + configurações)
  2. Aplicar e testar a atualização em ambiente de staging (servidor separado com cópia do portal)
  3. Migrar customizações de /bitrix/php_interface/ para /local/ antes de atualizar o core
  4. Aplicar em produção com o nó em questão removido temporariamente do pool de load balancing

Esse fluxo é consistente com as melhores práticas documentadas em projetos de atualização de portais de médio e grande porte.

Armazenamento Compartilhado: NFS vs. GlusterFS vs. Object Storage

Para portais Bitrix24 on-premise com até ~500 usuários, NFS com DRBD oferece o melhor equilíbrio entre simplicidade e redundância; ambientes maiores devem usar GlusterFS ou Ceph, enquanto NFS puro representa um ponto único de falha e S3-compatível (MinIO) é preferível em implantações híbridas ou private cloud.

A escolha do backend de armazenamento compartilhado tem impacto direto na performance e na resiliência.

Opção Latência HA nativo Complexidade Melhor para
NFS (servidor dedicado) Baixa Não (SPOF) Baixa Ambientes menores, NFS + DRBD
GlusterFS (2+ bricks) Média Sim Média On-premise, sem cloud
Ceph (RBD/CephFS) Média Sim Alta Data centers com muitos nós
S3-compatível (MinIO) Média-alta Sim Média Híbrido / private cloud

Para portais com até ~500 usuários em on-premise, NFS com DRBD (espelhamento de bloco entre dois servidores de storage) oferece o melhor equilíbrio entre simplicidade e redundância. Para ambientes maiores ou implantados em nuvem privada, GlusterFS ou Ceph são mais adequados — veja mais sobre deploys em nuvem privada em Bitrix24 self-hosted no AWS, Azure ou nuvem privada.

Segurança e Endurecimento no Ambiente HA

Clusters de HA do Bitrix24 ampliam a superfície de ataque em relação ao servidor único; auditorias de portais em produção identificaram 5 falhas recorrentes críticas — HSTS ausente, erros PHP visíveis no browser, 2FA desabilitado, acesso irrestrito ao /bitrix/admin/ e módulos desatualizados com web-environment 7.x contendo vulnerabilidades conhecidas.

Um cluster expõe mais superfície de ataque do que um servidor único. Os pontos críticos identificados em auditorias de segurança em portais de produção incluem:

  • HSTS não configurado nos nós web — adicionar Strict-Transport-Security no bloco server do Nginx de cada nó
  • Erros PHP visíveis no browser (display_errors = On) — desativar em todos os php.ini dos nós
  • Autenticação de dois fatores desabilitada — habilitar via módulo OTP nativo do Bitrix24 para todos os usuários admin
  • Acesso irrestrito ao painel administrativo — restringir o path /bitrix/admin/ a um pool de IPs de gestão via ACL no balanceador
  • Módulos desatualizados — o core e os módulos devem estar sempre na versão mais recente; portais com web-environment 7.x apresentam vulnerabilidades conhecidas

O guia completo de endurecimento está em Bitrix24 Self-Hosted: checklist de segurança com 25 pontos.

Monitoramento e Runbook de HA

O monitoramento eficaz de um cluster de HA para Bitrix24 exige acompanhamento de 6 métricas essenciais — incluindo Seconds_Behind_Master com alerta acima de 30 s, saúde dos nós web, uso do pool ProxySQL acima de 80 %, latência de NFS/GlusterFS acima de 50 ms, memória Redis acima de 80 % e ausência de execução do cron por mais de 5 minutos.

Um cluster sem monitoramento ativo é tão arriscado quanto um servidor único — a diferença é que a falha silenciosa pode passar despercebida por mais tempo.

Métricas essenciais a monitorar

Métrica Ferramenta sugerida Limiar de alerta
Seconds_Behind_Master Prometheus + mysqld_exporter > 30 s
Saúde dos nós web HAProxy stats / Nginx status Qualquer nó DOWN
Uso de conexões ProxySQL ProxySQL admin interface > 80 % do pool
Latência de NFS/GlusterFS Node exporter + Grafana > 50 ms
Uso de sessões Redis redis_exporter > 80 % de memória
Cron do Bitrix24 Alertmanager + dead man's switch Ausência de execução > 5 min

Combine o monitoramento de HA com uma estratégia de backup e disaster recovery para cobrir cenários de corrupção de dados que o failover simples não resolve.

Considerações de TCO e Quando Vale o Investimento

Montar um cluster de HA para Bitrix24 tipicamente acrescenta 2 a 4 servidores extras, 20-40 % de esforço adicional na implantação e custo proporcional de licença/hora em nuvem; o investimento se justifica quando o custo de uma hora de indisponibilidade para o negócio supera esses valores recorrentes de infraestrutura.

Montar um cluster de HA aumenta o custo de infraestrutura, tipicamente dobrando ou triplicando o número de servidores. A decisão deve ser baseada no custo de uma hora de indisponibilidade para o negócio.

Em projetos típicos, o overhead de HA representa:

  • +2 a 4 servidores (segundo nó web, replica MySQL, nó de storage ou load balancer dedicado)
  • +20-40 % de esforço na fase de implantação inicial
  • +custo de licença/hora se os servidores extras forem provisionados em nuvem pública

Para contexto sobre TCO total de self-hosted vs. cloud, consulte a análise completa de TCO em 3 anos.

Perguntas Frequentes

Quantos servidores são necessários para um cluster HA mínimo do Bitrix24?

O mínimo viável é quatro máquinas: um balanceador de carga, dois nós web e um servidor de banco de dados com uma replica. Para eliminar também o SPOF do storage, adiciona-se um par NFS+DRBD ou um cluster GlusterFS de dois nós — totalizando seis máquinas.

O Bitrix24 suporta nós web em cluster nativamente?

Sim. O Bitrix24 corporate portal (versão self-hosted) foi projetado para operar em múltiplos nós web desde que sessões, cache e arquivos sejam externalizados — Redis para sessões/cache e NFS/GlusterFS para arquivos do /upload/. Nenhum patch ou customização de código é necessário para isso.

Qual é o RPO e RTO esperados com a arquitetura master-replica?

Com replicação assíncrona padrão, o RPO pode ser de alguns segundos (igual ao atraso de replicação). O RTO depende da ferramenta de failover: com Orchestrator + VIP, costuma ficar entre 30 e 90 segundos. Para RPO próximo de zero, use Percona XtraDB Cluster (replicação síncrona).

Posso atualizar módulos do Bitrix24 sem derrubar o cluster?

Sim, com o procedimento correto: remova temporariamente um nó web do pool do load balancer, aplique e teste a atualização nele, depois promova-o de volta e repita no outro nó. O banco de dados deve ser atualizado em staging primeiro. Migrações de schema que alteram tabelas grandes devem usar ferramentas como pt-online-schema-change para não bloquear o master.

Redis é obrigatório para HA ou é apenas uma boa prática?

É obrigatório para sessões quando há mais de um nó web. Sem Redis (ou Memcached) para sessões compartilhadas, um usuário cujo nó falha perde a sessão ativa e é deslogado. Para cache de aplicação, Redis melhora performance mas não é tecnicamente obrigatório.

Como integrar SSO/Active Directory em um ambiente HA?

A integração com Active Directory ou LDAP é configurada no nível da aplicação Bitrix24 e funciona identicamente em qualquer topologia — o portal se conecta ao domain controller independentemente de quantos nós web existam. Veja detalhes em nosso guia de integração com AD, LDAP e SSO.

Baseado em prática real

Este artigo é baseado em 6 documentos internos da prática do ACP Group — planos de trabalho, especificações, questionários e casos de implementação do Bitrix24.

Precisa de ajuda para implementar o Bitrix24?

ACP Group — Gold Partner of Bitrix24. 7+ years, 1300+ projects.
Call us +971 55 780 1481 or visit our main site.

Go to acp-24.com.br →