Bitrix24 Self-Hosted em Alta Disponibilidade: Cluster HA

Por que Alta Disponibilidade é Essencial no Bitrix24 On-Premise (Alaio)

Implantações on-premise do Bitrix24 transferem toda a responsabilidade pela redundância para a sua equipe e, em portais de 100 a 300 usuários, o custo de uma paralisação não planejada em um servidor único quase sempre supera o investimento em uma arquitetura de cluster com HA que elimina pontos únicos de falha no hardware, no sistema operacional e no banco de dados.

As edições em nuvem do Bitrix24 gerenciam a redundância automaticamente. No momento em que você migra para a edição self-hosted (on-premise) - geralmente para atender a requisitos de soberania de dados, políticas internas de segurança ou obrigações de conformidade - essa responsabilidade passa inteiramente para a sua equipe. Um servidor único com 47 GB de RAM e 16 núcleos de CPU suporta confortavelmente um portal de médio porte, mas oferece proteção zero contra falhas de hardware, travamentos no sistema operacional ou corrupção de banco de dados.

Na prática, o custo de uma paralisação não planejada em um portal de 100 a 300 usuários quase sempre supera o custo da infraestrutura adicional necessária para evitá-la. Implantações em cluster também reduzem as janelas de manutenção: é possível aplicar atualizações nos nós um de cada vez sem tirar o portal do ar. Para uma visão completa do que envolve uma implantação on-premise, consulte Self-Hosted CRM: Why Choose Bitrix24 On-Premise for Data Sovereignty.

Componentes Principais de uma Arquitetura HA para Bitrix24

Uma configuração de HA em nível de produção para o Bitrix24 self-hosted exige cinco camadas totalmente redundantes: balanceador de carga, dois ou mais nós web sem estado, armazenamento de arquivos compartilhado, um cluster de banco de dados MySQL master-replica e um barramento compartilhado de cache e sessão - deixar qualquer uma dessas camadas sem redundância compromete toda a arquitetura.

Uma configuração de HA em nível de produção para o Bitrix24 self-hosted é composta tipicamente por cinco camadas:

Todas as camadas devem ser redundantes - fortalecer o nível web enquanto se mantém um banco de dados isolado derrota o propósito da arquitetura.

Requisitos do Ambiente Web e Controle de Versão

Todos os nós do cluster devem executar o mesmo template de VM do Bitrix, com CentOS Stream 9, nginx 1.26+, Apache 2.4.62+, PHP 8.2+ e Percona Server 8.0+; ambientes distintos entre nós causam bugs sutis e difíceis de diagnosticar, e versões desatualizadas bloqueiam atualizações críticas.

O ambiente web do Bitrix é versionado e prescritivo. Com base em dados de auditoria de projetos, operar em um ambiente desatualizado (por exemplo, versão 7.5.1 do ambiente web quando a versão 9.x já é a atual) introduz riscos de instabilidade e bloqueia determinadas atualizações. A imagem de máquina virtual oficial do Bitrix inclui:

• SO: CentOS Stream 9 (o CentOS 7 chegou ao fim de vida e possui CVEs sem correção)
• Proxy reverso: nginx 1.26+
• Servidor de aplicação: Apache 2.4.62+
• PHP: 8.2+ (modo PHP-FPM; display_errors e display_startup_errors devem estar desativados em produção)
• Banco de dados: Percona Server 8.0+ (MySQL 5.7 está em EOL)

Ao construir os nós do cluster, sempre implante cada nó a partir da mesma versão do template de VM do Bitrix. Ambientes mistos - um nó com PHP antigo e outro com PHP novo - causam bugs sutis e difíceis de diagnosticar.

Pontos-chave de ajuste do MySQL para implantações em cluster: - Desative o query_cache (removido no MySQL 8, mas ainda presente em algumas configurações do Percona 5.7 - causa condições de corrida na invalidação de cache entre os nós) - Desative o local_infile (endurecimento de segurança) - Aumente o innodb_log_file_size além do padrão de 64 MB - um portal de médio porte com um banco de dados de ~28 GB se beneficia de valores entre 512 MB e 2 GB para reduzir a pressão de checkpoint - Ajuste join_buffer_size e sort_buffer_size com base em profiling da carga de trabalho, não pelos valores padrão

Configuração da Replicação MySQL Master-Replica

Configure o .settings.php do Bitrix24 com perfis de conexão separados para default (master) e slave (replica somente leitura), e aplique replicação semissíncrona baseada em GTID com formato de log binário ROW e sync_binlog = 1 para garantir durabilidade e permitir failover automático via Orchestrator ou ProxySQL.

A conexão com o banco de dados do Bitrix24 é definida em /home/bitrix/www/bitrix/.settings.php (bloco connections). Em uma configuração em cluster, você configura dois perfis de conexão:

'default' => [
    'className' => '\Bitrix\Main\DB\MysqliConnection',
    'host'      => 'db-master.internal',
    'database'  => 'sitemanager',
    'login'     => 'bitrix',
    'password'  => '<strong-password>',
    'options'   => 2,
],
'slave'   => [
    'className' => '\Bitrix\Main\DB\MysqliConnection',
    'host'      => 'db-replica.internal',
    'database'  => 'sitemanager',
    'login'     => 'bitrix',
    'password'  => '<strong-password>',
    'options'   => 2,
    'readonly'  => true,
],

O Bitrix24 utiliza a conexão slave automaticamente para consultas de leitura quando ela está presente. Lista de verificação da replicação:

1. Replicação baseada em GTID - promoção de failover mais simples do que a baseada em arquivo e posição
2. Replicação semissíncrona - pelo menos uma replica confirma cada commit antes de o master retornar o sucesso; evita perda de dados em caso de falha do master
3. Formato do log binário: ROW - obrigatório para compatibilidade com o Bitrix
4. innodb_flush_log_at_trx_commit = 1 e sync_binlog = 1 no master - fundamentais para durabilidade
5. Monitoramento de lag da replica - emita alertas se Seconds_Behind_Master ultrapassar 30 segundos; a lógica de sessão e cache do Bitrix pressupõe replicação em tempo quase real

Para failover automático, ferramentas como Orchestrator ou ProxySQL podem promover uma replica a master e atualizar a string de conexão sem intervenção manual.

Armazenamento Compartilhado para Arquivos Enviados

O diretório /home/bitrix/www/upload deve ser idêntico em todos os nós web em tempo real; o NFS v4 é a opção mais prática para implantações com até ~500 usuários, mas o cache baseado em arquivos deve ser substituído por Memcached ou Redis antes de adicionar um segundo nó web.

O diretório /home/bitrix/www/upload (e alguns outros, incluindo cache se você utilizar cache baseado em arquivos) deve ser idêntico em todos os nós web em tempo real. As opções estão ordenadas pela complexidade operacional:

O NFS continua sendo a opção mais prática para implantações on-premise de médio porte. Monte-o com noatime,nodiratime para reduzir a amplificação de escrita e monitore a disponibilidade da montagem com um watchdog - uma montagem NFS travada que trava em vez de retornar erro é uma causa clássica de congelamento dos nós web.

O diretório cache merece atenção especial: o cache baseado em arquivos não escala entre nós. Migre para Memcached ou Redis como backend de cache (/bitrix/.settings.php, seção cache) antes de adicionar o segundo nó web.

Balanceador de Carga e Persistência de Sessão

O balanceador de carga deve usar distribuição least_conn com verificações de saúde max_fails=3 fail_timeout=15s, enquanto as sessões devem ser migradas do handler padrão de sistema de arquivos para o Redis com persistência ativada, garantindo que os usuários em qualquer nó mantenham suas sessões após trocas.

O balanceador de carga fica na frente de todos os nós web e desempenha duas funções: distribuição de tráfego e verificação de integridade.

Exemplo de upstream nginx (simplificado):

upstream bitrix_nodes {
    least_conn;
    server web1.internal:80 max_fails=3 fail_timeout=15s;
    server web2.internal:80 max_fails=3 fail_timeout=15s;
    keepalive 32;
}

Gerenciamento de sessões: por padrão, o Bitrix24 armazena sessões no sistema de arquivos. Em um cluster, é necessário migrar as sessões para armazenamento compartilhado:

• Memcached - mais rápido, mas as sessões são perdidas na reinicialização do memcached
• Redis (com persistência ativada) - recomendado; sobrevive a reinicializações

Configure em /etc/php.d/session.ini (ou na configuração do pool PHP-FPM):

session.save_handler = redis
session.save_path    = "tcp://redis.internal:6379"

Configure também o Push & Pull (servidor de notificações em tempo real) em cada nó web para apontar para o mesmo canal pub/sub do Redis - caso contrário, usuários em nós diferentes perderão mensagens de chat e atualizações do feed ao vivo.

Diagrama da Arquitetura HA

A topologia canônica de HA do Bitrix24 roteia o tráfego HTTPS por um balanceador de carga nginx/HAProxy para dois nós web sem estado Apache+PHP-FPM que compartilham armazenamento NFS e um barramento Redis de sessão e cache, todos gravando em um master MySQL Percona 8.0 que replica via GTID para uma replica hot standby.

O tráfego HTTPS de entrada passa pelo balanceador de carga e chega a dois nós web sem estado, que compartilham um backend de armazenamento de arquivos e um barramento Redis de sessão e cache, com um par MySQL master-replica responsável por toda a persistência.

flowchart TD
    CLIENT[Users / Browsers] --> LB[Load Balancer\nnginx / HAProxy\nSSL Termination]
    LB --> WEB1[Web Node 1\nApache + PHP-FPM]
    LB --> WEB2[Web Node 2\nApache + PHP-FPM]
    WEB1 --> NFS[Shared Storage\nNFS / GlusterFS\nupload, static files]
    WEB2 --> NFS
    WEB1 --> REDIS[Redis\nSessions + Cache\n+ Push&Pull]
    WEB2 --> REDIS
    WEB1 --> DBMASTER[MySQL Master\nPercona 8.0]
    WEB2 --> DBMASTER
    DBMASTER -- GTID replication --> DBREPLICA[MySQL Replica\nPercona 8.0]
    DBMASTER -.failover.-> DBREPLICA

Endurecimento de Segurança em Todo o Cluster

Cada nó web adicional amplia a superfície de ataque, portanto os controles de segurança - incluindo listas de permissões de IP para o painel administrativo, cabeçalhos HSTS, exibição de erros PHP desativada, 2FA para todas as contas de administrador e uma lista de bloqueio de IP compartilhada sincronizada via ipset - devem ser aplicados de forma consistente no nível do balanceador de carga em todo o cluster.

Adicionar mais nós aumenta proporcionalmente a superfície de ataque. Uma auditoria de segurança em uma instalação típica de servidor único revela pontos que se amplificam em um cluster - cada nó deve ser protegido de forma consistente. Lista de verificação principal:

• Acesso ao painel administrativo restrito por lista de permissões de IP - aplique no nível do balanceador de carga (não apenas por nó) para que a regra seja respeitada mesmo que o nginx em um nó esteja mal configurado
• Cabeçalho HSTS + redirecionamento HTTP para HTTPS - configure no balanceador de carga, não nos nós individuais, para evitar inconsistências
• Exibição de erros PHP desativada - display_errors = Off e display_startup_errors = Off no php.ini de cada nó; expor stack traces no navegador revela caminhos de arquivos, estrutura SQL e detalhes de configuração
• Autenticação de dois fatores (2FA) para todas as contas de administrador - uma configuração no painel de administração do Bitrix em nível de cluster se aplica a todos os nós automaticamente
• Módulo Proactive Protection - certifique-se de que o nível mínimo de segurança está acima do padrão da plataforma; desative a incorporação em frames a menos que seja necessário
• Firewall com lista de bloqueio de IP - mantenha uma lista de bloqueio compartilhada (por exemplo, via ipset sincronizado entre os nós) e atualize-a regularmente
• Antivírus web - o antivírus web integrado do Bitrix adiciona alguma carga de CPU; avalie o impacto no desempenho de cada nó antes de ativá-lo em produção

Para procedimentos de atualização e práticas de testes, o padrão adotado em projetos reais é: sempre teste em uma replica de staging primeiro, faça backup do banco de dados, dos arquivos e das configurações e, em seguida, implante nó por nó. Isso é duplamente importante em um cluster, pois uma atualização mal-sucedida em um nó pode causar comportamento de split-brain se os esquemas de sessão ou cache divergirem. Consulte Bitrix24 Implementation Cost & Timeline: Real Data from 1,300+ Projects para obter estimativas realistas de planejamento ao dimensionar o orçamento do projeto de HA.

Procedimentos de Atualização e Manutenção em Ambiente Clusterizado

Atualizações progressivas em um cluster Bitrix24 exigem backup completo, validação em staging cobrindo CRM, tarefas, integrações e Push & Pull, seguida de implantação nó a nó com o nó atualizado drenado no balanceador de carga primeiro, mantendo um snapshot do banco de dados pré-atualização disponível por pelo menos 48 horas após a implantação.

As atualizações progressivas são um dos principais benefícios operacionais de um cluster HA. O procedimento recomendado com base em planos de projetos reais:

1. Backup completo do banco de dados master, de todo o armazenamento de arquivos e de todos os arquivos de configuração antes de qualquer alteração
2. Validação em staging - suba uma cópia de todo o cluster (ou, no mínimo, uma replica de nó único do ambiente de produção), aplique a atualização e execute testes funcionais: - Criação e edição de entidades no CRM - Fluxos de tarefas e processos de negócio - Integrações com ERP (scripts de sincronização, troca de dados via POST) - Chat e notificações Push & Pull
3. Migração de código: personalizações devem estar em /local/ e não dentro dos diretórios de módulos /bitrix/ - esta é a abordagem oficialmente suportada e evita que atualizações do núcleo sobrescrevam suas alterações. Migre quaisquer arquivos em /bitrix/php_interface/ para /local/ antes de atualizar
4. Implantação nó a nó: drene o nó 1 no balanceador de carga (defina como down na configuração de upstream), atualize-o, faça testes de verificação e repita para o nó 2
5. Verificações de banco de dados pós-atualização: execute a verificação de estrutura de banco de dados integrada do Bitrix e resolva os erros encontrados (geralmente alguns conflitos de schema corrigíveis automaticamente)
6. Plano de rollback: mantenha o snapshot do banco de dados pré-atualização prontamente acessível por pelo menos 48 horas após a implantação

Se sua equipe também está considerando migrar de um CRM em nuvem para uma solução self-hosted, a mesma abordagem em etapas se aplica - consulte How to Migrate from HubSpot to Bitrix24: Step-by-Step Plan para um framework de migração que se adapta facilmente a um destino de cluster on-premise.

Monitoramento e Testes de Failover

Um cluster HA Bitrix24 deve ser validado com testes de falha programados - interrupções mensais de nós web (critério de aprovação: failover em até 15 s, sem perda de sessão), interrupções trimestrais do master MySQL (critério de aprovação: reconexão em até 60 s) e restaurações completas de DR semestrais - instrumentados via Prometheus e Grafana monitorando lag de replicação, taxa de acerto do Redis e integridade dos upstreams.

Um cluster que nunca foi testado sob condições de falha não é um cluster HA - é uma configuração de servidor único mais cara. Incorpore estas verificações ao seu runbook:

Instrumente seu cluster com, no mínimo: métricas de recursos por nó (CPU, memória, I/O de disco), lag de replicação MySQL, taxa de acerto do Memcached/Redis e integridade dos upstreams no balanceador de carga - idealmente exibidas em um único dashboard (Prometheus + Grafana é uma stack comum no ecossistema Bitrix).

Parceria para self-hosting. Deseja o controle do Bitrix24 self-hosted sem gerenciar o servidor você mesmo? A ACP Group pode implantar e operar a solução para você - consulte managed self-hosted Bitrix24, planos de suporte e manutenção ou solicite um orçamento de implantação turnkey.