Saltar al contenido principal

Conexión de un clúster de RabbitMQ y Redis

Introducción​

Importante

La siguiente guía es válida solo para ONLYOFFICE Docs Enterprise Edition y Developer Edition.

Use esta guía para conectar ONLYOFFICE Docs a un clúster de RabbitMQ y a un Redis Cluster. Para ejecutar el propio ONLYOFFICE Docs como clúster, siga la guía ONLYOFFICE Docs para Kubernetes.

nota

ONLYOFFICE Docs Community Edition no utiliza Redis. A partir de la versión 9.4.0, tampoco utiliza RabbitMQ.

Edición de la configuración​

Los siguientes ajustes se realizan en el archivo local.json:

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

Añada los parámetros a las secciones existentes del archivo y, a continuación, reinicie los servicios de ONLYOFFICE Docs.

Conexión de un clúster de RabbitMQ​

ONLYOFFICE Docs se conecta a una única URL de RabbitMQ. El parámetro rabbitmq.url admite una sola cadena; no se admite una lista de URL de brokers. Haga que el clúster de RabbitMQ sea accesible a través de un único punto de conexión:

  • un balanceador de carga TCP, por ejemplo, HAProxy, con una dirección de alta disponibilidad (keepalived o VRRP);
  • un nombre DNS que se resuelva en los nodos en ejecución.

Especifique este punto de conexión en local.json:

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

Para Docker, pase la misma URL en la variable de entorno AMQP_URI.

Cuando un nodo de RabbitMQ deja de funcionar, ONLYOFFICE Docs se reconecta automáticamente. Con las colas clásicas, vuelve a consumir mensajes cuando se reinicia el nodo propietario de una cola.

Heartbeat​

ONLYOFFICE Docs activa el keepalive TCP y utiliza el tiempo de espera del heartbeat AMQP que propone RabbitMQ, 60 segundos de forma predeterminada, para detectar conexiones interrumpidas. Configure el tiempo de inactividad del balanceador de carga de RabbitMQ con un valor mayor que el tiempo de espera del heartbeat. Para solicitar otro tiempo de espera, establezca heartbeat en segundos en rabbitmq.url:

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

Colas de quórum​

De forma predeterminada, ONLYOFFICE Docs utiliza colas clásicas. Puede cambiar a colas de quórum, que RabbitMQ replica entre los nodos del clúster. Establezca x-queue-type en quorum para cuatro colas:

{
"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"}}}
}
}

Mantenga queuepubsub como cola clásica: es una cola exclusiva con eliminación automática (auto-delete), lo que las colas de quórum no permiten.

Las colas de quórum admiten dos niveles de prioridad en RabbitMQ 4.0 a 4.2 y 32 niveles a partir de RabbitMQ 4.3. Las versiones anteriores no admiten prioridades, por lo que las tareas de conversión ya no se priorizan.

aviso

RabbitMQ no puede cambiar el tipo de una cola existente. Antes de reiniciar ONLYOFFICE Docs con la nueva configuración, deténgalo y elimine las colas ds.converttask6, ds.convertresponse, ds.convertdead y ds.delayed, o establezca nuevos nombres en los parámetros name de estas colas. Hágalo durante una ventana de mantenimiento: los mensajes que queden en las colas eliminadas se pierden.

Conexión de un Redis Cluster​

ONLYOFFICE Docs admite Redis Cluster con los dos clientes Redis que incluye, node-redis (predeterminado) e ioredis. Especifique los nodos del clúster en la sección services.CoAuthoring.redis de 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>"}}
}
}
}
}

Redis Cluster solo admite la base de datos 0.

Asignación de direcciones de nodos​

Los nodos del clúster comunican al cliente sus propias direcciones. Si ONLYOFFICE Docs no puede acceder a estas direcciones, por ejemplo, debido a NAT o a redes de Docker, aparecen en los registros errores como MOVED ... o Cannot read properties of undefined (reading 'master').

Asigne cada dirección anunciada a una a la que ONLYOFFICE Docs pueda acceder. Para node-redis, añada 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, añada 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}
}
}

Comprobación de la configuración​

Los pasos 3 y 4 requieren colas de quórum replicadas en al menos tres nodos de RabbitMQ y un Redis Cluster con una réplica para cada nodo maestro.

  1. Reinicie ONLYOFFICE Docs y revise el registro de DocService, /var/log/onlyoffice/documentserver/docservice/out.log en Linux.
    • Los errores de conexión a RabbitMQ se registran como [AMQP] connect error, con el número de intento y el tiempo hasta el siguiente reintento.
    • Los errores de Redis contienen redisClient.
  2. Abra un documento desde dos navegadores y edítelo de forma conjunta.
  3. Con el documento abierto, detenga un nodo de RabbitMQ. Compruebe que la edición continúa y que el documento se guarda después de cerrarlo.
  4. Vuelva a iniciar el nodo de RabbitMQ y, a continuación, repita la prueba con un nodo maestro de Redis. Vuelva a iniciar el nodo de Redis después de la prueba.