Conexão de um cluster RabbitMQ e Redis

Introdução

Importante

O guia a seguir é válido apenas para o ONLYOFFICE Docs Enterprise Edition e Developer Edition.

Use este guia para conectar o ONLYOFFICE Docs a um cluster RabbitMQ e a um Redis Cluster. Para executar o próprio ONLYOFFICE Docs como cluster, siga o guia Como instalar o ONLYOFFICE Docs no Kubernetes via Helm.

observação

O ONLYOFFICE Docs Community Edition não usa Redis. A partir da versão 9.4.0, também não usa RabbitMQ.

Edição da configuração

As configurações abaixo são feitas no arquivo local.json:

Para Linux: /etc/onlyoffice/documentserver/local.json
Para Windows: %ProgramFiles%\ONLYOFFICE\DocumentServer\config\local.json

Adicione os parâmetros às seções existentes do arquivo e, em seguida, reinicie os serviços do ONLYOFFICE Docs.

Conexão de um cluster RabbitMQ

O ONLYOFFICE Docs se conecta a uma única URL do RabbitMQ. O parâmetro rabbitmq.url aceita uma única string; uma lista de URLs de brokers não é suportada. Torne o cluster RabbitMQ acessível por meio de um único endpoint:

um balanceador de carga TCP, por exemplo, o HAProxy, com um endereço de alta disponibilidade (keepalived ou VRRP);
um nome DNS que resolva para os nós em execução.

Especifique esse endpoint no local.json:

{
  "rabbitmq": {
    "url": "amqp://<user>:<password>@rabbitmq.example.com:5672"
  }
}

Para o Docker, passe a mesma URL na variável de ambiente AMQP_URI.

Quando um nó do RabbitMQ fica indisponível, o ONLYOFFICE Docs se reconecta automaticamente. Com filas clássicas, volta a consumir mensagens quando o nó que detém uma fila é reiniciado.

Heartbeat

O ONLYOFFICE Docs ativa o keepalive TCP e usa o tempo limite de heartbeat AMQP proposto pelo RabbitMQ, 60 segundos por padrão, para detectar conexões interrompidas. Defina o tempo limite de inatividade do balanceador de carga do RabbitMQ com um valor maior que o tempo limite do heartbeat. Para solicitar outro tempo limite, defina heartbeat em segundos em rabbitmq.url:

{
  "rabbitmq": {
    "url": "amqp://<user>:<password>@rabbitmq.example.com:5672?heartbeat=30"
  }
}

Filas de quórum

Por padrão, o ONLYOFFICE Docs usa filas clássicas. Você pode mudar para filas de quórum, que o RabbitMQ replica entre os nós do cluster. Defina x-queue-type como quorum para quatro filas:

{
  "rabbitmq": {
    "queueconverttask": {"options": {"arguments": {"x-queue-type": "quorum"}}},
    "queueconvertresponse": {"options": {"arguments": {"x-queue-type": "quorum"}}},
    "queueconvertdead": {"options": {"arguments": {"x-queue-type": "quorum"}}},
    "queuedelayed": {"options": {"arguments": {"x-queue-type": "quorum"}}}
  }
}

Mantenha queuepubsub como fila clássica: ela é uma fila exclusiva com exclusão automática (auto-delete), o que as filas de quórum não permitem.

As filas de quórum suportam dois níveis de prioridade no RabbitMQ 4.0 a 4.2 e 32 níveis a partir do RabbitMQ 4.3. As versões anteriores não suportam prioridades, portanto as tarefas de conversão deixam de ser priorizadas.

aviso

O RabbitMQ não pode alterar o tipo de uma fila existente. Antes de reiniciar o ONLYOFFICE Docs com as novas configurações, pare-o e exclua as filas ds.converttask6, ds.convertresponse, ds.convertdead e ds.delayed, ou defina novos nomes nos parâmetros name dessas filas. Faça isso durante uma janela de manutenção: as mensagens que restarem nas filas excluídas serão perdidas.

Conexão de um Redis Cluster

O ONLYOFFICE Docs suporta o Redis Cluster com os dois clientes Redis que inclui, node-redis (padrão) e ioredis. Especifique os nós do cluster na seção services.CoAuthoring.redis do local.json.

Para node-redis, use optionsCluster:

{
  "services": {
    "CoAuthoring": {
      "redis": {
        "name": "redis",
        "optionsCluster": {
          "rootNodes": [
            {"url": "redis://192.168.0.150:7000"},
            {"url": "redis://192.168.0.150:7001"},
            {"url": "redis://192.168.0.150:7002"}
          ],
          "defaults": {"username": "default", "password": "<password>"}
        }
      }
    }
  }
}

Para ioredis, use iooptionsClusterNodes e iooptionsClusterOptions:

{
  "services": {
    "CoAuthoring": {
      "redis": {
        "name": "ioredis",
        "iooptionsClusterNodes": [
          {"host": "192.168.0.150", "port": 7000},
          {"host": "192.168.0.150", "port": 7001},
          {"host": "192.168.0.150", "port": 7002}
        ],
        "iooptionsClusterOptions": {"redisOptions": {"password": "<password>"}}
      }
    }
  }
}

O Redis Cluster suporta apenas o banco de dados 0.

Mapeamento de endereços dos nós

Os nós do cluster informam ao cliente os seus próprios endereços. Se o ONLYOFFICE Docs não conseguir acessar esses endereços, por exemplo, por causa de NAT ou de redes do Docker, erros como MOVED ... ou Cannot read properties of undefined (reading 'master') aparecem nos logs.

Mapeie cada endereço anunciado para um que o ONLYOFFICE Docs consiga acessar. Para node-redis, adicione nodeAddressMap a optionsCluster:

"optionsCluster": {
  "rootNodes": [{"url": "redis://redis1.example.com:7000"}],
  "nodeAddressMap": {
    "10.0.0.5:7000": {"host": "redis1.example.com", "port": 7000},
    "10.0.0.6:7000": {"host": "redis2.example.com", "port": 7000},
    "10.0.0.7:7000": {"host": "redis3.example.com", "port": 7000}
  }
}

Para ioredis, adicione natMap a iooptionsClusterOptions:

"iooptionsClusterOptions": {
  "natMap": {
    "10.0.0.5:7000": {"host": "redis1.example.com", "port": 7000},
    "10.0.0.6:7000": {"host": "redis2.example.com", "port": 7000},
    "10.0.0.7:7000": {"host": "redis3.example.com", "port": 7000}
  }
}

Verificação da configuração

As etapas 3 e 4 exigem filas de quórum replicadas em pelo menos três nós do RabbitMQ e um Redis Cluster com uma réplica para cada nó mestre.

Reinicie o ONLYOFFICE Docs e verifique o log do DocService, /var/log/onlyoffice/documentserver/docservice/out.log no Linux.
- Os erros de conexão com o RabbitMQ são registrados como [AMQP] connect error, com o número da tentativa e o tempo até a próxima tentativa.
- Os erros do Redis contêm redisClient.
Abra um documento em dois navegadores e edite-o em conjunto.
Com o documento aberto, pare um nó do RabbitMQ. Verifique se a edição continua e se o documento é salvo depois que você o fecha.
Inicie o nó do RabbitMQ novamente e, em seguida, repita o teste com um nó mestre do Redis. Inicie o nó do Redis novamente após o teste.

Introdução​

Edição da configuração​

Conexão de um cluster RabbitMQ​

Heartbeat​

Filas de quórum​

Conexão de um Redis Cluster​

Mapeamento de endereços dos nós​

Verificação da configuração​