Horizontale Skalierung

Ayakaleaf Pro unterstützt horizontale Skalierung. Wir haben getestet und bestätigt, dass es mit mehreren Replikaten korrekt läuft.

Dieses Dokument listet die technischen Anforderungen auf und bietet Richtlinien für den Betrieb von Ayakaleaf Pro auf mehr als einem Knoten.

Ab Server CE/Server Pro 5.0.3 wurden die Umgebungsvariablen von SHARELATEX_* in OVERLEAF_* umbenannt.

Wenn Sie eine 4.x-Version (oder älter) verwenden, stellen Sie sicher, dass die Variablen das entsprechende Präfix tragen (z. B. SHARELATEX_SITE_URL statt OVERLEAF_SITE_URL)

Die Einrichtung einer horizontalen Skalierung erfordert erheblichen Aufwand. Wir empfehlen, horizontale Skalierung nur ab einer gewissen Größenordnung in Betracht zu ziehen. Beispielsweise wurde eine Server Pro-Installation für insgesamt 1.000 Benutzer erfolgreich auf einem einzigen Server mit zwei 4-Kern-Prozessoren und 32 GB Arbeitsspeicher eingerichtet. Empfehlungen finden Sie in der Dokumentation zu den Hardwareanforderungen.

Eine Bereitstellung von Server Pro mit horizontaler Skalierung umfasst eine Reihe externer Komponenten, etwa einen Load Balancer und ein S3-kompatibles Speicher-Backend.

Wir können bei der Fehlersuche in den Server Pro-Containern helfen, die auf eine Fehlkonfiguration zurückzuführen sein könnten, und auf Grundlage dieses Dokuments allgemeine Ratschläge geben. Leider können wir keine Unterstützung bei der Konfiguration von Drittanbieter-Anwendungen/-Systemen leisten.

Die Lösung technischer Probleme, die spezifisch für Ihre Hardware/Software zur Bereitstellung der externen Komponenten sind, ist nicht durch unsere Supportbedingungen abgedeckt.

​

Anforderungen

​

Externer, zentraler Datenspeicher

Die Datenspeicherung in Server Pro lässt sich in vier Datenspeicher aufteilen:

• MongoDB

  • Der Großteil der Daten wird in MongoDB gespeichert.
  • Wir unterstützen entweder eine lokale oder eine externe Instanz, etwa MongoDB Atlas (ein vollständig verwalteter MongoDB-Dienst, der innerhalb der AWS-Infrastruktur läuft).
    

  Hinweis: Leider gibt es derzeit keine offizielle Unterstützung für MongoDB-kompatible Datenbanken wie CosmoDB/DocumentDB, da wir Server Pro nicht damit getestet haben. Auch wenn eine Bereitstellung von Server Pro mit kompatiblen Datenbanken möglicherweise funktioniert, unterstützen wir offiziell nur Bereitstellungen mit MongoDB.
  

• Redis

  • Redis speichert temporäre Daten, etwa ausstehende Dokumentaktualisierungen, bevor sie in MongoDB geschrieben werden.
  • Redis wird verwendet, um Dokumentaktualisierungen zwischen verschiedenen Diensten auszutauschen und den Editor über Zustandsänderungen in einem bestimmten Projekt zu benachrichtigen.
  • Redis wird zum Speichern der Benutzersitzungen verwendet.
  • Wir unterstützen entweder eine lokale oder eine externe Instanz.
    

  Hinweis: Leider gibt es derzeit keine offizielle Unterstützung für Redis-kompatible Key/Value-Stores wie KeyDB/Valkey, da wir Server Pro nicht damit getestet haben. Auch wenn eine Bereitstellung von Server Pro mit kompatiblen Stores möglicherweise funktioniert, unterstützen wir offiziell nur Bereitstellungen mit Redis.
  

• Projektdateien und Verlaufsdateien

  • Nicht bearbeitbare Projektdateien werden außerhalb von MongoDB gespeichert.

    Das neue Projektverlaufssystem (ab Server Pro 3.5) speichert den Verlauf ebenfalls außerhalb von MongoDB.

  • Für kleine Einzelinstanzen unterstützen wir entweder ein lokales Dateisystem (z. B. auf Basis einer lokalen SSD, NFS oder EBS) oder ein S3-kompatibles Datenspeichersystem.

  • Für horizontale Skalierung unterstützen wir ausschließlich S3-kompatible Datenspeichersysteme.
    

  Wichtig: NFS/Amazon EFS/Amazon EBS werden für horizontale Skalierung nicht unterstützt. Weitere Details zur Skalierung des Speichers in Server Pro finden Sie im Abschnitt zu den Hardware-Speicheranforderungen.

• Kurzlebige Dateien

  • LaTeX-Kompilierungen müssen für optimale Leistung auf schnellen, lokalen Datenträgern laufen. Die Ausgabe der Kompilierung muss nicht dauerhaft gespeichert oder gesichert werden.
  • Auch das Puffern neuer Datei-Uploads und das Erstellen von Projekt-ZIP-Dateien profitieren von einem lokalen Datenträger.

Wir empfehlen dringend, einen lokalen Datenträger zu verwenden. Die Verwendung jeglicher Art von Netzwerkdatenträgern (wie NFS oder EBS) kann zu unerwarteten Kompilierungsfehlern und anderen Leistungsproblemen führen.

​

Git-bridge

Git-bridge ist in Server Pro ab Version 4.0.1 verfügbar.

Die Git-Repositorys werden lokal auf dem Datenträger gespeichert. Es stehen keine Replikationsoptionen zur Verfügung. Git-bridge sollte als Singleton betrieben werden. Für optimale Leistung empfehlen wir, für die Git-bridge-Daten einen lokalen Datenträger zu verwenden. Der Datenträger mit den Git-bridge-Daten sollte regelmäßig gesichert werden.

Für die Datenspeicherung bei horizontaler Skalierung benötigen Sie:

• eine zentrale MongoDB-Instanz, die von allen Server Pro-Instanzen aus erreichbar ist
• eine zentrale Redis-Instanz, die von allen Server Pro-Instanzen aus erreichbar ist
• ein zentrales S3-kompatibles Speicher-Backend für Projekt- und Verlaufsdateien
• einen lokalen Datenträger auf jeder Instanz für kurzlebige Dateien
• einen lokalen Datenträger auf der Instanz, die den Git-bridge-Container hostet, für die Git-bridge-Daten

​

Anforderungen an den Load Balancer

• Persistentes Routing, z. B. per Cookie

  Diese Anforderung ergibt sich aus folgenden Komponenten:

  • Die Echtzeit-Bearbeitung in Server Pro verwendet WebSockets mit einem Fallback auf XHR-Polling. Jede Bearbeitungssitzung hat einen lokalen Zustand auf der Serverseite, und die Anfragen einer bestimmten Bearbeitungssitzung müssen immer an dieselbe Server Pro-Instanz geleitet werden. Die Kollaborationsfunktion nutzt Redis Pub/Sub, um Aktualisierungen zwischen mehreren Server Pro-Instanzen auszutauschen.
  • Die LaTeX-Kompilierung hält die Ausgabe und den Kompilierungs-Cache für optimale Leistung lokal vor. Nachdem eine Kompilierungsanfrage an eine Server Pro-Instanz gesendet wurde, müssen die nachfolgenden PDF-/Log-Download-Anfragen an dieselbe Server Pro-Instanz geleitet werden.

• Lange Request-Timeouts zur Unterstützung der Kompilierung großer LaTeX-Dokumente

• WebSocket-Unterstützung für optimale Leistung

• POST-Payload-Größe von 50 MB

• Keep-alive-Timeout muss niedriger sein als das Keep-alive-Timeout von Server Pro

  Das Keep-alive-Timeout in Server Pro kann über die Umgebungsvariable NGINX_KEEPALIVE_TIMEOUT konfiguriert werden. Der Standardwert beträgt 65 s.

  Mit dem Standardwert funktioniert ein Keep-alive-Timeout von 60 s im Load Balancer.

  Mit NGINX_KEEPALIVE_TIMEOUT=120 könnte der Load Balancer 115 s wählen.

• Client-IPs

  Setzen Sie den Request-Header X-Forwarded-For auf die Client-IP.

• Beim Terminieren von SSL

  Der Load Balancer muss den Request-Header X-Forwarded-Proto: https hinzufügen.

Beispielkonfiguration für HAProxy

global
  group haproxy
  user haproxy

  # Verbose logging
  log stdout format raw local0 debug

defaults
  mode                    http
  option                  httpchk HEAD /status
  http-check              expect status 200
  default-server          check

  # Verbose logging
  log                     global
  option                  httplog

  # Reroute to a different backend if the sticky one is down
  option                  redispatch 1
  # These retries are for TCP connect errors, not on HTTP status 500 responses
  retries                 3

  # Sticky session for 24h of inactivity -- compile output is deleted after 24h
  cookie                  server-pro-ha insert maxidle 24h

  # Try to connect to any backend for 1min, then return 503
  timeout queue           1m
  # Give Server Pro instances 15s to startup
  timeout connect         15s

  # Abort requests from very slow clients (allow 1min of inactivity when reading a request)
  timeout client          1m

  # Allow slow compiles -- hard-coded limit in clsi is 10min
  timeout server          10m

  # Disconnect the editor after 23h -- 1h ahead of their last use yesterday
  timeout tunnel          23h

  # Note: The keepalive behavior in haproxy works great with the default keepalive setup in Server Pro.
  #       Haproxy is cleaning up connections in the background and it will redispatch requests when needed.

listen server-pro-ha-http
  bind :80
  http-request redirect scheme https unless { ssl_fc }

listen server-pro-ha-https
  bind :443 ssl crt /etc/ssl/certs/ssl-key-and-certificate-bundle.pem

  # Tell the application that we are behind https
  http-request set-header X-Forwarded-Proto https

  # Tell the application the actual client ip
  option forwardfor

  # See https://hstspreload.org/#deployment-recommendations
  http-response set-header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload;"

  # Route git traffic to the sibling container of the git-bridge
  use-server server-pro-ha-1 if { path_beg /git/ }

  # Debugging
  http-response add-header X-Served-By %s
  stats enable
  stats uri /haproxy

  server server-pro-ha-1 198.18.1.1:80 cookie server-pro-ha-1
  server server-pro-ha-2 198.18.1.2:80 cookie server-pro-ha-2
  server server-pro-ha-3 198.18.1.3:80 cookie server-pro-ha-3

​

Server Pro-Konfiguration

Secrets

Die Server Pro-Instanzen müssen gemeinsame Secrets verwenden:

• WEB_API_PASSWORD (Web-API-Authentifizierung)
• STAGING_PASSWORD und V1_HISTORY_PASSWORD mit demselben Wert (Verlaufs-Authentifizierung)
• CRYPTO_RANDOM (für das Sitzungscookie)
• OT_JWT_AUTH_KEY (Verlaufs-Authentifizierung)

Jedes dieser Secrets muss mit einem eigenen, eindeutigen Wert konfiguriert und zwischen den Instanzen geteilt werden.

Sind sie nicht konfiguriert und werden Benutzeranfragen an verschiedene Server Pro-Instanzen geleitet, schlagen die Authentifizierungsprüfungen fehl, und die Benutzer werden entweder häufig auf die Anmeldeseite umgeleitet oder ihre Aktionen in der Benutzeroberfläche schlagen auf unerwartete Weise fehl.

Sind sie nicht konfiguriert, verwendet Server Pro für jedes Secret einen neuen Zufallswert auf Basis von 32 zufälligen Bytes aus /dev/urandom (256 Zufallsbits).

# https://github.com/overleaf/overleaf/blob/45ca0f796c679103efd305ddbef28073c4a5de32/server-ce/init_scripts/00_regen_sharelatex_secrets.sh#L14
dd if=/dev/urandom bs=1 count=32 2>/dev/null | base64 -w 0 | rev | cut -b 2- | rev | tr -d '\n+/'

MongoDB

Richten Sie OVERLEAF_MONGO_URL (SHARELATEX_MONGO_URL bei Versionen 4.x und älter) auf die zentrale MongoDB-Instanz.

Redis

Richten Sie OVERLEAF_REDIS_HOST (SHARELATEX_REDIS_HOST bei Versionen 4.x und älter) und REDIS_HOST auf die zentrale Redis-Instanz.

S3-kompatibler Speicher für Projekt- und Verlaufsdateien

Details finden Sie in der Dokumentation zu S3-kompatiblem Speicher.

Kurzlebige Dateien

Der standardmäßige Bind-Mount einer lokalen SSD nach /var/lib/overleaf (/var/lib/sharelatex bei Versionen 4.x und älter) ist ausreichend. Achten Sie darauf, SANDBOXED_COMPILES_HOST_DIR auf den Mountpoint auf dem Host zu setzen.

Wir empfehlen dringend, einen lokalen Datenträger zu verwenden. Die Verwendung jeglicher Art von Netzwerkdatenträgern (wie NFS oder EBS) kann zu unerwarteten Kompilierungsfehlern und anderen Leistungsproblemen führen.

Proxy-Konfiguration

• Setzen Sie OVERLEAF_BEHIND_PROXY=true (SHARELATEX_BEHIND_PROXY bei Versionen 4.x und älter), um korrekte Client-IPs zu erhalten.
• Setzen Sie TRUSTED_PROXY_IPS auf die IP des Load Balancers (mehrere CIDRs können durch Kommas getrennt angegeben werden).

Git-bridge-Integration

Git-bridge ist in Server Pro ab Version 4.0.1 verfügbar.

Der Git-bridge-Container benötigt einen Server Pro-Geschwistercontainer zur Verarbeitung eingehender Git-Anfragen. Dieser Geschwistercontainer kann auch regulären Benutzerverkehr bedienen. In der Beispielkonfiguration fungiert die erste Instanz als Geschwistercontainer für Git-bridge, grundsätzlich kann aber jede Instanz diese Rolle übernehmen.

Warum muss ein Server Pro-Container als Geschwister für Git-bridge festgelegt werden? Server Pro gibt Download-URLs für den Verlaufsdienst an Git-bridge aus. Diese Verlaufs-URLs müssen so konfiguriert werden, dass sie vom Git-bridge-Container aus erreichbar sind.

Konfiguration des Server Pro-Containers:

• Setzen Sie GIT_BRIDGE_ENABLED auf 'true'

• Setzen Sie GIT_BRIDGE_HOST auf <git-bridge container name>, z. B. git-bridge

• Setzen Sie GIT_BRIDGE_PORT auf 8000

• Setzen Sie V1_HISTORY_URL auf http://<server-pro sibling container name>:3100/api.

  Hinweis: Dies ist nur auf dem Geschwistercontainer des Git-bridge-Containers erforderlich. Die anderen Instanzen können eine localhost-URL verwenden, was der Standard ist.

Konfiguration des Git-bridge-Containers:

• Setzen Sie GIT_BRIDGE_API_BASE_URL auf http://<server-pro sibling container name>/api/v0, z. B. http://server-pro-ha-1/api/v0
• Setzen Sie GIT_BRIDGE_OAUTH2_SERVER auf http://<server-pro sibling container name>, z. B. http://server-pro-ha-1
• Setzen Sie GIT_BRIDGE_POSTBACK_BASE_URL auf http://<git-bridge container name>:8000, z. B. http://git-bridge:8000
• Setzen Sie GIT_BRIDGE_ROOT_DIR auf den per Bind-Mount eingebundenen Git-bridge-Datenträger, z. B. /data/git-bridge

Beispielkonfiguration für docker-compose.yml

Die folgende Konfiguration zeigt ein in sich geschlossenes Setup. Damit die Demo funktioniert, müssen Sie einen gültigen SSL-Schlüssel bzw. ein gültiges Zertifikat bereitstellen und OVERLEAF_SITE_URL (SHARELATEX_SITE_URL bei Versionen 4.x und älter) anpassen. Für ein echtes Setup müssen Sie die Dummy-Secrets wie inline vermerkt durch echte Secrets ersetzen. Für ein echtes Setup müssen Sie außerdem die einzelnen Container auf dedizierte Knoten verschieben und die IP-Adressen an Ihr lokales Netzwerk anpassen.

version: '2.2'

# Actual horizontal scaling setup: pick your own network and replace IPs in config.
networks:
    default:
        ipam:
            config:
                # This subnet is part of a reserved subnet used for benchmarking
                # https://tools.ietf.org/html/rfc2544
                # The full subnet is 198.18.0.0/15
                # Use 198.18.0.0/24 for lb and dbs
                # Use 198.18.1.0/24 for server-pro
                # Use 198.18.0.128/25 for ephemeral container
                - gateway: 198.18.0.1
                  ip_range: 198.18.0.128/25
                  subnet: 198.18.0.0/23

services:
    # Actual horizontal scaling setup: run haproxy outside docker on a separate host.
    lb:
        image: haproxy:2.6
        container_name: lb
        user: root
        logging:
            driver: local
            options:
                max-size: 10g
                max-file: '100'
        volumes:
            - ./haproxy.conf:/usr/local/etc/haproxy/haproxy.cfg
            # $ cat certificate.pem key.pem > ssl-key-and-certificate-bundle.pem
            - /path/to/ssl-key-and-certificate-bundle.pem:/etc/ssl/certs/ssl-key-and-certificate-bundle.pem
        # Alternative to "ports": use host network to avoid docker-proxy overhead
        network_mode: host

        # Alternative to "network_mode: host": use docker-proxy for network isolation
        # ports:
        #     - "80:80"
        #     - "443:443"
        # networks:
        #     default:
        #         ipv4_address: 198.18.0.2

        # Actual horizontal scaling setup: remove these as they run on other hosts.
        depends_on:
            server-pro-ha-1:
                condition: service_started
            server-pro-ha-2:
                condition: service_started
            server-pro-ha-3:
                condition: service_started

    # Actual horizontal scaling setup: run this container next to server-pro-ha-1.
    # For Server Pro 4.0 onwards.
    git-bridge:
        restart: always
        # The tag should match the `server-pro-ha-1` container tag.
        image: quay.io/sharelatex/git-bridge:4.0.1
        volumes:
            # Actual horizontal scaling setup: point /data/git-bridge at a dedicated local ssd.
            - ~/git_bridge_data:/data/git-bridge
        container_name: git-bridge
        environment:
            GIT_BRIDGE_API_BASE_URL: "http://server-pro-ha-1/api/v0"
            GIT_BRIDGE_OAUTH2_SERVER: "http://server-pro-ha-1"
            GIT_BRIDGE_POSTBACK_BASE_URL: "http://198.18.0.6:8000"
            GIT_BRIDGE_ROOT_DIR: "/data/git-bridge"
        user: root
        command: ["/server-pro-start.sh"]

        # Actual horizontal scaling setup: run on host 198.18.0.6 and expose port
        # ports:
        #     - "8000:8000"
        networks:
            default:
                ipv4_address: 198.18.0.6

    # Actual horizontal scaling setup: run this container on a separate host.
    server-pro-ha-1: &server-pro-ha-config
        restart: always
        image: quay.io/sharelatex/sharelatex-pro:4.0.1
        container_name: server-pro-ha-1
        hostname: server-pro-ha-1
        depends_on:
            # Actual horizontal scaling setup: keep this entry.
            git-bridge:
                condition: service_started

            # Actual horizontal scaling setup: remove the ones below as they run on other hosts.
            mongo:
                condition: service_healthy
            redis:
                condition: service_started
            minio:
                condition: service_started
            mongo_replica_set_setup:
                condition: service_completed_successfully
            minio_setup:
                condition: service_completed_successfully
        stop_grace_period: 60s
        volumes:
            - /tmp/scratch-disk1:/var/lib/sharelatex
            - /var/run/docker.sock:/var/run/docker.sock
        environment: &server-pro-ha-environment
            # Actual horizontal scaling setup: provide your own domain/app name.
            OVERLEAF_SITE_URL: 'https://overleaf.example.com'
            OVERLEAF_APP_NAME: Server Pro Horizontal Scaling Demo

            OVERLEAF_MONGO_URL: mongodb://198.18.0.3/sharelatex
            OVERLEAF_REDIS_HOST: 198.18.0.4
            REDIS_HOST: 198.18.0.4

            ENABLED_LINKED_FILE_TYPES: 'project_file,project_output_file'
            EMAIL_CONFIRMATION_DISABLED: 'true'

            SANDBOXED_COMPILES: 'true'
            SANDBOXED_COMPILES_SIBLING_CONTAINERS: 'true'
            SANDBOXED_COMPILES_HOST_DIR: '/tmp/scratch-disk1/data/compiles'

            # S3
            # Actual horizontal scaling setup: pick secure credentials.
            OVERLEAF_FILESTORE_BACKEND: s3
            OVERLEAF_FILESTORE_USER_FILES_BUCKET_NAME: overleaf-user-files
            OVERLEAF_FILESTORE_TEMPLATE_FILES_BUCKET_NAME: overleaf-template-files
            OVERLEAF_FILESTORE_S3_ACCESS_KEY_ID: OVERLEAF_FILESTORE_S3_ACCESS_KEY_ID
            OVERLEAF_FILESTORE_S3_SECRET_ACCESS_KEY: OVERLEAF_FILESTORE_S3_SECRET_ACCESS_KEY
            OVERLEAF_FILESTORE_S3_ENDPOINT: http://198.18.0.5:9000
            OVERLEAF_FILESTORE_S3_PATH_STYLE: 'true'
            OVERLEAF_FILESTORE_S3_REGION: ''

            OVERLEAF_HISTORY_BACKEND: "s3"
            OVERLEAF_HISTORY_PROJECT_BLOBS_BUCKET: "overleaf-project-blobs"
            OVERLEAF_HISTORY_CHUNKS_BUCKET: "overleaf-chunks"
            OVERLEAF_HISTORY_S3_ACCESS_KEY_ID: "OVERLEAF_HISTORY_S3_ACCESS_KEY_ID"
            OVERLEAF_HISTORY_S3_SECRET_ACCESS_KEY: "OVERLEAF_HISTORY_S3_SECRET_ACCESS_KEY"
            OVERLEAF_HISTORY_S3_ENDPOINT: http://198.18.0.5:9000
            OVERLEAF_HISTORY_S3_PATH_STYLE: 'true'
            OVERLEAF_HISTORY_S3_REGION: ''
            # /S3

            # git-bridge
            GIT_BRIDGE_ENABLED: 'true'
            GIT_BRIDGE_HOST: 198.18.0.6
            GIT_BRIDGE_PORT: 8000
            # Only needed on the sibling instance of git-bridge
            V1_HISTORY_URL: "http://server-pro-ha-1:3100/api"
            # /git-bridge

            # Horizontal scaling
            # Actual horizontal scaling setup: pick secure credentials.
            WEB_API_PASSWORD: WEB_API_PASSWORD
            STAGING_PASSWORD: V1_HISTORY_PASSWORD
            V1_HISTORY_PASSWORD: V1_HISTORY_PASSWORD
            CRYPTO_RANDOM: CRYPTO_RANDOM
            OT_JWT_AUTH_KEY: OT_JWT_AUTH_KEY
            OVERLEAF_BEHIND_PROXY: 'true'
            # Actual horizontal scaling setup: IPs of load balancers
            TRUSTED_PROXY_IPS: 198.18.0.1,198.18.0.2
            # /Horizontal scaling

        # Actual horizontal scaling setup: run on host 198.18.1.1 and expose ports
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.1

    # Actual horizontal scaling setup: run this container on a separate host.
    server-pro-ha-2:
        <<: *server-pro-ha-config
        hostname: server-pro-ha-2
        container_name: server-pro-ha-2
        volumes:
            - /tmp/scratch-disk2:/var/lib/sharelatex
            - /var/run/docker.sock:/var/run/docker.sock
        environment:
            <<: *server-pro-ha-environment
            SANDBOXED_COMPILES_HOST_DIR: '/tmp/scratch-disk2/data/compiles'
            V1_HISTORY_URL: "http://localhost:3100/api"

        # Actual horizontal scaling setup: run on host 198.18.1.2 and expose ports
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.2

    # Actual horizontal scaling setup: run this container on a separate host.
    server-pro-ha-3:
        <<: *server-pro-ha-config
        hostname: server-pro-ha-3
        container_name: server-pro-ha-3
        volumes:
            - /tmp/scratch-disk3:/var/lib/sharelatex
            - /var/run/docker.sock:/var/run/docker.sock
        environment:
            <<: *server-pro-ha-environment
            SANDBOXED_COMPILES_HOST_DIR: '/tmp/scratch-disk3/data/compiles'
            V1_HISTORY_URL: "http://localhost:3100/api"

        # Actual horizontal scaling setup: run on host 198.18.1.3 and expose ports
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.3

    # Actual horizontal scaling setup: run this container on a separate host.
    minio:
        image: minio/minio:RELEASE.2023-05-18T00-05-36Z
        container_name: minio
        command: server /data
        volumes:
            # Actual horizontal scaling setup: run minio with multiple disks, see minio docs.
            - ~/minio_data:/data
        environment:
            # Actual horizontal scaling setup: pick secure credentials.
            MINIO_ROOT_USER: MINIO_ROOT_USER
            MINIO_ROOT_PASSWORD: MINIO_ROOT_PASSWORD

        # Actual horizontal scaling setup: run on host 198.18.0.5 and expose port
        # ports:
        #     - "9000:9000"
        networks:
            default:
                ipv4_address: 198.18.0.5

    # Actual horizontal scaling setup: run this setup once on a separate host.
    minio_setup:
        depends_on:
            - minio
        image: minio/mc:RELEASE.2023-05-18T16-59-00Z
        entrypoint: sh
        command:
            - '-c'
            # Actual horizontal scaling setup: pick secure credentials.
            - |
                mc alias set s3 http://198.18.0.5:9000 MINIO_ROOT_USER MINIO_ROOT_PASSWORD \
                || sleep 10 && \
                mc alias set s3 http://198.18.0.5:9000 MINIO_ROOT_USER MINIO_ROOT_PASSWORD \
                || sleep 10 && \
                mc alias set s3 http://198.18.0.5:9000 MINIO_ROOT_USER MINIO_ROOT_PASSWORD \
                || sleep 10 && \
                mc alias set s3 http://198.18.0.5:9000 MINIO_ROOT_USER MINIO_ROOT_PASSWORD

                mc mb --ignore-existing s3/overleaf-user-files
                mc mb --ignore-existing s3/overleaf-template-files
                mc admin user add s3 \
                  OVERLEAF_FILESTORE_S3_ACCESS_KEY_ID \
                  OVERLEAF_FILESTORE_S3_SECRET_ACCESS_KEY

                mc mb --ignore-existing s3/overleaf-project-blobs
                mc mb --ignore-existing s3/overleaf-chunks
                mc admin user add s3 \
                  OVERLEAF_HISTORY_S3_ACCESS_KEY_ID \
                  OVERLEAF_HISTORY_S3_SECRET_ACCESS_KEY

                echo '
                  {
                    "Version": "2012-10-17",
                    "Statement": [
                      {
                        "Effect": "Allow",
                        "Action": [
                          "s3:ListBucket"
                        ],
                        "Resource": "arn:aws:s3:::overleaf-user-files"
                      },
                      {
                        "Effect": "Allow",
                        "Action": [
                          "s3:PutObject",
                          "s3:GetObject",
                          "s3:DeleteObject"
                        ],
                        "Resource": "arn:aws:s3:::overleaf-user-files/*"
                      },
                      {
                        "Effect": "Allow",
                        "Action": [
                          "s3:ListBucket"
                        ],
                        "Resource": "arn:aws:s3:::overleaf-template-files"
                      },
                      {
                        "Effect": "Allow",
                        "Action": [
                          "s3:PutObject",
                          "s3:GetObject",
                          "s3:DeleteObject"
                        ],
                        "Resource": "arn:aws:s3:::overleaf-template-files/*"
                      }
                    ]
                  }' > policy-filestore.json

                echo '
                  {
                    "Version": "2012-10-17",
                    "Statement": [
                      {
                        "Effect": "Allow",
                        "Action": [
                          "s3:ListBucket"
                        ],
                        "Resource": "arn:aws:s3:::overleaf-project-blobs"
                      },
                      {
                        "Effect": "Allow",
                        "Action": [
                          "s3:PutObject",
                          "s3:GetObject",
                          "s3:DeleteObject"
                        ],
                        "Resource": "arn:aws:s3:::overleaf-project-blobs/*"
                      },
                      {
                        "Effect": "Allow",
                        "Action": [
                          "s3:ListBucket"
                        ],
                        "Resource": "arn:aws:s3:::overleaf-chunks"
                      },
                      {
                        "Effect": "Allow",
                        "Action": [
                          "s3:PutObject",
                          "s3:GetObject",
                          "s3:DeleteObject"
                        ],
                        "Resource": "arn:aws:s3:::overleaf-chunks/*"
                      }
                    ]
                  }' > policy-history.json

                # Put the contents of the policy from the previous section in policy-filestore.json
                # Reminder: Replace the bucket names accordingly.
                mc admin policy create s3 overleaf-filestore policy-filestore.json
                mc admin policy attach s3 overleaf-filestore \
                  --user=OVERLEAF_FILESTORE_S3_ACCESS_KEY_ID || true

                mc admin policy create s3 overleaf-history policy-history.json
                mc admin policy attach s3 overleaf-history \
                  --user=OVERLEAF_HISTORY_S3_ACCESS_KEY_ID || true

    # Actual horizontal scaling setup: run this container on a separate host.
    mongo:
        restart: always
        image: mongo:4.4
        container_name: mongo
        command: "--replSet overleaf"
        expose:
            - 27017
        volumes:
            - ~/mongo_data:/data/db
        healthcheck:
            test: echo 'db.stats().ok' | mongo localhost:27017/test --quiet
            interval: 10s
            timeout: 10s
            retries: 5

        # Actual horizontal scaling setup: run on host 198.18.0.3 and expose port
        # ports:
        #     - "27017:27017"
        networks:
            default:
                ipv4_address: 198.18.0.3

    mongo_replica_set_setup:
        image: mongo:4.4
        entrypoint: sh
        depends_on:
            mongo:
                condition: service_healthy
        command:
            - '-c'
            - |
                mongo 198.18.0.3 --eval "rs.initiate({ _id: \"overleaf\", members: [ { _id: 0, host: \"198.18.0.3:27017\" } ] })"

    # Actual horizontal scaling setup: run this container on a separate host.
    redis:
        restart: always
        image: redis:6.2
        container_name: redis
        expose:
            - 6379
        volumes:
            - ~/redis_data:/data

        # Actual horizontal scaling setup: run on host 198.18.0.4 and expose port
        # ports:
        #     - "6379:6379"
        networks:
            default:
                ipv4_address: 198.18.0.4

​

Hardware

Wir empfehlen, für alle an der horizontalen Skalierung beteiligten Server Pro-Instanzen dieselben Hardwarespezifikationen zu verwenden.

Es gelten die allgemeinen Empfehlungen zu den Hardwarespezifikationen für Server Pro-Instanzen.

​

Server Pro aktualisieren

Im Rahmen des Upgrade-Prozesses führt Server Pro automatisch Datenbankmigrationen aus. Diese Migrationen sind nicht dafür ausgelegt, von mehreren Instanzen parallel ausgeführt zu werden.

Die Migrationen müssen abgeschlossen sein, bevor die eigentliche Webanwendung startet. Sie können entweder in den Logs nach dem Eintrag Finished migrations suchen oder warten, bis die Anwendung Datenverkehr annimmt.

Der Upgrade-Ablauf sieht wie folgt aus:

1. Planen Sie ein Wartungsfenster
2. Stoppen Sie alle Server Pro-Instanzen
3. Erstellen Sie ein konsistentes Backup wie in der Dokumentation beschrieben
4. Starten Sie eine einzelne Server Pro-Instanz mit der neuen Version
5. Prüfen Sie, ob die neue Instanz wie erwartet funktioniert
6. Starten Sie die übrigen Instanzen mit der neuen Version