Aller au contenu principal

Connexion d'un cluster RabbitMQ et Redis

Introduction​

Important

Ce guide est valable uniquement pour ONLYOFFICE Docs Enterprise Edition et Developer Edition.

Utilisez ce guide pour connecter ONLYOFFICE Docs à un cluster RabbitMQ et à un Redis Cluster. Pour exécuter ONLYOFFICE Docs lui-même en cluster, suivez le guide ONLYOFFICE Docs pour Kubernetes.

remarque

ONLYOFFICE Docs Community Edition n'utilise pas Redis. À partir de la version 9.4.0, il n'utilise pas non plus RabbitMQ.

Modification de la configuration​

Les paramètres ci-dessous sont définis dans le fichier local.json :

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

Ajoutez les paramètres aux sections existantes du fichier, puis redémarrez les services ONLYOFFICE Docs.

Connexion d'un cluster RabbitMQ​

ONLYOFFICE Docs se connecte à une seule URL RabbitMQ. Le paramètre rabbitmq.url accepte une seule chaîne ; une liste d'URL de brokers n'est pas prise en charge. Rendez le cluster RabbitMQ accessible via un seul point de terminaison :

  • un équilibreur de charge TCP, par exemple HAProxy, avec une adresse hautement disponible (keepalived ou VRRP) ;
  • un nom DNS qui se résout vers les nœuds en cours d'exécution.

Indiquez ce point de terminaison dans local.json :

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

Pour Docker, transmettez la même URL dans la variable d'environnement AMQP_URI.

Lorsqu'un nœud RabbitMQ tombe en panne, ONLYOFFICE Docs se reconnecte automatiquement. Avec les files d'attente classiques, il reprend la consommation des messages lorsque le nœud propriétaire d'une file d'attente redémarre.

Heartbeat​

ONLYOFFICE Docs active le keepalive TCP et utilise le délai d'expiration du heartbeat AMQP proposé par RabbitMQ, 60 secondes par défaut, pour détecter les connexions interrompues. Définissez le délai d'inactivité de l'équilibreur de charge RabbitMQ à une valeur supérieure au délai d'expiration du heartbeat. Pour demander un autre délai, définissez heartbeat en secondes dans rabbitmq.url :

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

Files d'attente quorum​

Par défaut, ONLYOFFICE Docs utilise des files d'attente classiques. Vous pouvez passer aux files d'attente quorum, que RabbitMQ réplique sur les nœuds du cluster. Définissez x-queue-type sur quorum pour quatre files d'attente :

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

Laissez queuepubsub en file d'attente classique : il s'agit d'une file d'attente exclusive à suppression automatique (auto-delete), ce que les files d'attente quorum ne permettent pas.

Les files d'attente quorum prennent en charge deux niveaux de priorité dans RabbitMQ 4.0 à 4.2 et 32 niveaux à partir de RabbitMQ 4.3. Les versions antérieures ne prennent pas en charge les priorités, les tâches de conversion ne sont donc plus priorisées.

attention

RabbitMQ ne peut pas modifier le type d'une file d'attente existante. Avant de redémarrer ONLYOFFICE Docs avec les nouveaux paramètres, arrêtez-le et supprimez les files d'attente ds.converttask6, ds.convertresponse, ds.convertdead et ds.delayed, ou définissez de nouveaux noms dans les paramètres name de ces files d'attente. Faites-le pendant une fenêtre de maintenance : les messages restés dans les files d'attente supprimées sont perdus.

Connexion d'un Redis Cluster​

ONLYOFFICE Docs prend en charge Redis Cluster avec les deux clients Redis qu'il inclut, node-redis (par défaut) et ioredis. Indiquez les nœuds du cluster dans la section services.CoAuthoring.redis de local.json.

Pour node-redis, utilisez 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>"}
        }
      }
    }
  }
}

Pour ioredis, utilisez iooptionsClusterNodes et 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 ne prend en charge que la base de données 0.

Mappage des adresses des nœuds​

Les nœuds du cluster communiquent au client leurs propres adresses. Si ONLYOFFICE Docs ne peut pas atteindre ces adresses, par exemple à cause du NAT ou des réseaux Docker, des erreurs telles que MOVED ... ou Cannot read properties of undefined (reading 'master') apparaissent dans les journaux.

Associez chaque adresse annoncée à une adresse que ONLYOFFICE Docs peut atteindre. Pour node-redis, ajoutez nodeAddressMap à 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}
  }
}

Pour ioredis, ajoutez natMap à 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}
  }
}

Vérification de la configuration​

Les étapes 3 et 4 nécessitent des files d'attente quorum répliquées sur au moins trois nœuds RabbitMQ et un Redis Cluster avec un réplica pour chaque nœud maître.

  1. Redémarrez ONLYOFFICE Docs et consultez le journal DocService, /var/log/onlyoffice/documentserver/docservice/out.log sous Linux.
    • Les erreurs de connexion à RabbitMQ sont journalisées sous la forme [AMQP] connect error, avec le numéro de la tentative et le délai avant la prochaine tentative.
    • Les erreurs Redis contiennent redisClient.
  2. Ouvrez un document dans deux navigateurs et modifiez-le ensemble.
  3. Pendant que le document est ouvert, arrêtez un nœud RabbitMQ. Vérifiez que l'édition continue et que le document est enregistré après sa fermeture.
  4. Redémarrez le nœud RabbitMQ, puis répétez le test avec un nœud maître Redis. Redémarrez le nœud Redis après le test.