Zum Hauptinhalt springen

Verbinden eines RabbitMQ- und Redis-Clusters

Einführung​

Wichtig

Die folgende Anleitung gilt nur für ONLYOFFICE Docs Enterprise Edition und Developer Edition.

Verwenden Sie diese Anleitung, um ONLYOFFICE Docs mit einem RabbitMQ-Cluster und einem Redis Cluster zu verbinden. Um ONLYOFFICE Docs selbst als Cluster zu betreiben, folgen Sie der Anleitung ONLYOFFICE Docs auf Kubernetes.

hinweis

ONLYOFFICE Docs Community Edition verwendet kein Redis. Ab Version 9.4.0 verwendet es auch kein RabbitMQ.

Bearbeiten der Konfiguration​

Die folgenden Einstellungen werden in der Datei local.json vorgenommen:

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

Fügen Sie die Parameter zu den vorhandenen Abschnitten der Datei hinzu und starten Sie anschließend die ONLYOFFICE Docs-Dienste neu.

Verbinden eines RabbitMQ-Clusters​

ONLYOFFICE Docs verbindet sich mit einer einzigen RabbitMQ-URL. Der Parameter rabbitmq.url akzeptiert eine Zeichenfolge; eine Liste von Broker-URLs wird nicht unterstützt. Machen Sie den RabbitMQ-Cluster über einen Endpunkt erreichbar:

  • einen TCP-Load-Balancer, zum Beispiel HAProxy, mit einer hochverfügbaren Adresse (keepalived oder VRRP);
  • einen DNS-Namen, der auf die laufenden Knoten aufgelöst wird.

Geben Sie diesen Endpunkt in local.json an:

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

Übergeben Sie für Docker dieselbe URL in der Umgebungsvariablen AMQP_URI.

Fällt ein RabbitMQ-Knoten aus, stellt ONLYOFFICE Docs die Verbindung automatisch wieder her. Bei klassischen Warteschlangen werden die Nachrichten wieder verarbeitet, sobald der Knoten, dem eine Warteschlange gehört, neu gestartet wird.

Heartbeat​

ONLYOFFICE Docs aktiviert TCP-Keepalive und verwendet das von RabbitMQ vorgeschlagene AMQP-Heartbeat-Timeout, standardmäßig 60 Sekunden, um unterbrochene Verbindungen zu erkennen. Stellen Sie das Leerlauf-Timeout des RabbitMQ-Load-Balancers länger als das Heartbeat-Timeout ein. Um ein anderes Timeout anzufordern, geben Sie heartbeat in Sekunden in rabbitmq.url an:

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

Quorum-Warteschlangen​

Standardmäßig verwendet ONLYOFFICE Docs klassische Warteschlangen. Sie können zu Quorum-Warteschlangen wechseln, die RabbitMQ über die Cluster-Knoten repliziert. Setzen Sie x-queue-type für vier Warteschlangen auf quorum:

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

Belassen Sie queuepubsub als klassische Warteschlange: Sie ist eine exklusive Warteschlange mit automatischem Löschen (auto-delete), was Quorum-Warteschlangen nicht zulassen.

Quorum-Warteschlangen unterstützen in RabbitMQ 4.0 bis 4.2 zwei Prioritätsstufen und ab RabbitMQ 4.3 32 Stufen. Frühere Versionen unterstützen keine Prioritäten, daher werden Konvertierungsaufgaben nicht mehr priorisiert.

warnung

RabbitMQ kann den Typ einer vorhandenen Warteschlange nicht ändern. Bevor Sie ONLYOFFICE Docs mit den neuen Einstellungen neu starten, beenden Sie es und löschen Sie die Warteschlangen ds.converttask6, ds.convertresponse, ds.convertdead und ds.delayed oder legen Sie in den name-Parametern dieser Warteschlangen neue Namen fest. Tun Sie dies während eines Wartungsfensters: Nachrichten, die in den gelöschten Warteschlangen verbleiben, gehen verloren.

Verbinden eines Redis Clusters​

ONLYOFFICE Docs unterstützt Redis Cluster mit beiden enthaltenen Redis-Clients, node-redis (Standard) und ioredis. Geben Sie die Cluster-Knoten im Abschnitt services.CoAuthoring.redis von local.json an.

Verwenden Sie für node-redis 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>"}
        }
      }
    }
  }
}

Verwenden Sie für ioredis iooptionsClusterNodes und 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 unterstützt nur die Datenbank 0.

Zuordnen von Knotenadressen​

Die Cluster-Knoten teilen dem Client ihre eigenen Adressen mit. Wenn ONLYOFFICE Docs diese Adressen nicht erreichen kann, zum Beispiel wegen NAT oder Docker-Netzwerken, erscheinen in den Protokollen Fehler wie MOVED ... oder Cannot read properties of undefined (reading 'master').

Ordnen Sie jede angekündigte Adresse einer Adresse zu, die ONLYOFFICE Docs erreichen kann. Fügen Sie für node-redis nodeAddressMap zu optionsCluster hinzu:

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

Fügen Sie für ioredis natMap zu iooptionsClusterOptions hinzu:

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

Überprüfen der Einrichtung​

Die Schritte 3 und 4 erfordern Quorum-Warteschlangen, die über mindestens drei RabbitMQ-Knoten repliziert werden, und einen Redis Cluster mit einer Replik für jeden Master.

  1. Starten Sie ONLYOFFICE Docs neu und überprüfen Sie das DocService-Protokoll, unter Linux /var/log/onlyoffice/documentserver/docservice/out.log.
    • RabbitMQ-Verbindungsfehler werden als [AMQP] connect error protokolliert, mit der Nummer des Versuchs und der Zeit bis zum nächsten Versuch.
    • Redis-Fehler enthalten redisClient.
  2. Öffnen Sie ein Dokument in zwei Browsern und bearbeiten Sie es gemeinsam.
  3. Beenden Sie einen RabbitMQ-Knoten, während das Dokument geöffnet ist. Überprüfen Sie, dass die Bearbeitung fortgesetzt wird und das Dokument nach dem Schließen gespeichert wird.
  4. Starten Sie den RabbitMQ-Knoten wieder und wiederholen Sie den Test dann mit einem Redis-Master-Knoten. Starten Sie den Redis-Knoten nach dem Test wieder.