> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/on-premises/de/wartung/horizontal-scaling.md).

# Horizontale Skalierung

Ab Version 3.5.6 unterstützt Server Pro horizontale Skalierung.

Dieses Dokument listet die technischen Anforderungen auf und enthält Richtlinien für den Betrieb von Server Pro auf mehr als einem Knoten.

{% hint style="danger" %}
Ab Server CE/Server Pro `5.0.3` wurden die Umgebungsvariablen umbenannt von `SHARELATEX_*` auf `OVERLEAF_*`.

Wenn Sie eine `4.x` Version (oder früher) verwenden, stellen Sie bitte sicher, dass die Variablen entsprechend mit einem Präfix versehen sind (z. B. `SHARELATEX_SITE_URL` anstatt `OVERLEAF_SITE_URL`)
{% endhint %}

Die Einrichtung horizontaler Skalierung erfordert einen erheblichen Aufwand. Wir empfehlen, horizontale Skalierung zu erwägen **nur** wenn eine bestimmte Größe erreicht wird. Als Beispiel wurde eine Server-Pro-Installation für insgesamt 1.000 Benutzer erfolgreich auf einem einzelnen Server mit zwei 4-Kern-Prozessoren und 32 GB Arbeitsspeicher eingerichtet. Siehe die [Hardwareanforderungen](/on-premises/de/erste-schritte/requirements/hardware-requirements.md) Dokumentation für Empfehlungen.

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

Wir können bei der Fehlerbehebung von Fehlern in den Server-Pro-Containern helfen, die möglicherweise auf eine Fehlkonfiguration zurückzuführen sind, und allgemeine Hinweise auf Grundlage dieses Dokuments geben. Leider können wir keine Unterstützung bei der Konfiguration von Anwendungen/Systemen Dritter bieten.

Die Behebung technischer Probleme, die speziell auf Ihre Hardware/Ihre Software zurückzuführen sind, um die externen Komponenten bereitzustellen, ist nicht durch unsere Supportbedingungen abgedeckt.

### Anforderungen

#### Externes, zentrales Datenspeichern

Die Datenspeicherung in Server Pro kann in vier Datenspeicher aufgeteilt werden:

* **MongoDB**

  * Der Großteil der Daten wird in MongoDB gespeichert.
  * Wir unterstützen entweder eine lokale Instanz oder eine externe Instanz, wie zum Beispiel [MongoDB](https://www.mongodb.com/atlas) Atlas (ein vollständig verwalteter MongoDB-Dienst, der in der AWS-Infrastruktur läuft).<br>

  **Hinweis:** Leider gibt es derzeit keine offizielle Unterstützung für MongoDB-kompatible Datenbanken wie CosmoDB/DocumentDB, da wir Server Pro mit ihnen nicht getestet haben. Zwar **könnte** eine Bereitstellung mit kompatiblen Datenbanken möglich sein, wir unterstützen offiziell jedoch nur Bereitstellungen mit MongoDB.<br>
* **Redis**

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

  **Hinweis:** Leider gibt es derzeit keine offizielle Unterstützung für Redis-kompatible Key-/Value-Stores wie KeyDB/Valkey, da wir Server Pro mit ihnen nicht getestet haben. Zwar **könnte** eine Bereitstellung mit kompatiblen Stores möglich sein könnte, unterstützen wir offiziell jedoch nur Bereitstellungen mit Redis.<br>
* **Projektdateien und History-Dateien**

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

    Das neue Projekt-History-System (Server Pro ab 3.5) speichert die History ebenfalls außerhalb von MongoDB.
  * Für kleine Einzelinstanzen unterstützen wir entweder ein lokales Dateisystem (das auf einer lokalen SSD, NFS oder EBS basieren kann) oder ein [S3-kompatibles Datenspeichersystem](/on-premises/de/konfiguration/overleaf-toolkit/s3.md).
  * Für horizontale Skalierung **nur** unterstützen wir S3-kompatible Datenspeichersysteme.<br>

  **Wichtig:** NFS/Amazon EFS/Amazon EBS sind **nicht** für horizontale Skalierung unterstützt. Bitte sehen Sie sich den [Hardware-Speicher](/on-premises/de/erste-schritte/requirements/hardware-requirements.md#storage) Anforderungsabschnitt zur Skalierung des Speichers in Server Pro für weitere Details an.
* **Flüchtige Dateien**
  * LaTeX-Kompilierungen müssen für optimale Leistung auf schnellen lokalen Datenträgern ausgeführt werden. Die Ausgabe der Kompilierung muss nicht dauerhaft gespeichert oder gesichert werden.
  * Auch das Puffern neuer Dateiuploads und das Erstellen von Projekt-ZIP-Dateien profitiert von der Verwendung eines lokalen Datenträgers.

{% hint style="danger" %}
Wir raten dringend zur Verwendung eines lokalen Datenträgers. Die Verwendung jeglicher Art von Netzwerkdatenträgern (wie NFS oder EBS) kann zu unerwarteten Kompilierungsfehlern und anderen Leistungsproblemen führen.
{% endhint %}

#### **Git-bridge**

{% hint style="info" %}
Git-bridge ist in Server Pro ab Version 4.0.1 verfügbar.
{% endhint %}

Die Git-Repositorys werden lokal auf dem Datenträger gespeichert. Es gibt keine Replikationsoptionen. Git-bridge sollte als ein **Singleton**. 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 mit horizontaler Skalierung benötigen Sie:

* eine zentrale MongoDB-Instanz, auf die alle Server-Pro-Instanzen zugreifen können
* eine zentrale Redis-Instanz, auf die alle Server-Pro-Instanzen zugreifen können
* ein zentrales S3-kompatibles Speicher-Backend für Projekt- und History-Dateien
* einen lokalen Datenträger auf jeder Instanz für flüchtige 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. mithilfe eines Cookies

  Diese Anforderung ergibt sich aus diesen Komponenten:

  * Die Echtzeit-Bearbeitungsfunktion in Server Pro verwendet WebSockets mit einem Fallback auf XHR-Polling. Jede Bearbeitungssitzung hat lokalen Zustand auf der Serverseite, und die Anfragen einer bestimmten Bearbeitungssitzung müssen immer an dieselbe Server-Pro-Instanz weitergeleitet werden. Die Kollaborationsfunktion verwendet Redis [Pub/Sub](https://redis.io/docs/latest/develop/interact/pubsub/) zum Teilen von Aktualisierungen zwischen mehreren Server-Pro-Instanzen.
  * Die LaTeX-Kompilierung hält die Ausgabe und den Kompilierungs-Cache lokal, um optimale Leistung zu erzielen. Nachdem eine Kompilierungsanfrage an eine Server-Pro-Instanz gestellt wurde, müssen die folgenden PDF-/Log-Download-Anfragen an dieselbe Server-Pro-Instanz weitergeleitet werden.
* **Lange Request-Timeouts** um die Kompilierung großer LaTeX-Dokumente zu unterstützen
* **WebSocket-Unterstützung** für optimale Leistung
* **POST-Payload-Größe von 50 MB**
* **Keep-alive-Timeout** muss niedriger sein als der Keep-alive-Timeout von Server Pro

  Der Keep-alive-Timeout in Server Pro kann mithilfe der Umgebungsvariablen `NGINX_KEEPALIVE_TIMEOUT`. Der Standardwert ist 65 s.

  Mit der Standardeinstellung 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.
* Wenn **SSL-Terminierung**

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

<details>

<summary>Beispielkonfiguration für HAProxy</summary>

```
global
  group haproxy
  user haproxy

  # Ausführliche Protokollierung
  log stdout format raw local0 debug

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

  # Ausführliche Protokollierung
  log                     global
  option                  httplog

  # Leite auf ein anderes Backend um, wenn das zugewiesene ausfällt
  option                  redispatch 1
  # Diese Wiederholungsversuche gelten für TCP-Verbindungsfehler, nicht für HTTP-Status-500-Antworten
  retries                 3

  # Sticky-Session für 24 h Inaktivität -- die Kompilierungsausgabe wird nach 24 h gelöscht
  cookie                  server-pro-ha insert maxidle 24h

  # Versuche 1 min lang, eine Verbindung zu einem beliebigen Backend herzustellen, dann 503 zurückgeben
  timeout queue           1m
  # Gib den Server-Pro-Instanzen 15 s zum Starten
  timeout connect         15s

  # Breche Anfragen von sehr langsamen Clients ab (erlaube 1 min Inaktivität beim Lesen einer Anfrage)
  timeout client          1m

  # Erlaube langsame Kompilierungen -- das fest codierte Limit in clsi beträgt 10 min
  timeout server          10m

  # Trenne den Editor nach 23 h -- 1 h vor ihrer letzten Nutzung gestern
  timeout tunnel          23h

  # Hinweis: Das Keepalive-Verhalten in haproxy funktioniert hervorragend mit dem Standard-Keepalive-Setup in Server Pro.
  #       Haproxy bereinigt Verbindungen im Hintergrund und redispatcht Anfragen bei Bedarf.

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

  # Teile der Anwendung mit, dass wir hinter HTTPS sind
  http-request set-header X-Forwarded-Proto https

  # Teile der Anwendung die tatsächliche Client-IP mit
  option forwardfor

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

  # Leite Git-Traffic an den Schwester-Container von git-bridge weiter
  use-server server-pro-ha-1 if { path_beg /git/ }

  # Fehlersuche
  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
```

</details>

#### Server-Pro-Konfiguration

**Geheimnisse**

Die Server-Pro-Instanzen müssen sich auf gemeinsame Secrets einigen:

* `WEB_API_PASSWORD` (Web-API-Authentifizierung)
* `STAGING_PASSWORD` und `V1_HISTORY_PASSWORD` gleicher Wert (History-Authentifizierung)
* `CRYPTO_RANDOM` (für das Session-Cookie)
* `OT_JWT_AUTH_KEY` (History-Authentifizierung)

All diese Secrets müssen mit jeweils einem eindeutigen Wert konfiguriert und zwischen den Instanzen geteilt werden.

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

Wenn dies nicht konfiguriert ist, verwendet Server Pro für jedes Secret einen neuen zufälligen Wert auf Basis von 32 zufälligen Bytes aus `/dev/urandom` (256 zufällige Bits).

{% code overflow="wrap" %}

```bash
# 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+/'
```

{% endcode %}

**MongoDB**

Richten Sie `OVERLEAF_MONGO_URL` (`SHARELATEX_MONGO_URL` für Versionen `4.x` und früher) auf die zentrale MongoDB-Instanz.

**Redis**

Richten Sie `OVERLEAF_REDIS_HOST` (`SHARELATEX_REDIS_HOST` für Versionen `4.x` und früher) und `REDIS_HOST` auf die zentrale Redis-Instanz.

**S3-kompatibler Speicher für Projekt- und History-Dateien**

Bitte sehen Sie sich die Dokumentation zu [S3-kompatiblen Speicher](/on-premises/de/konfiguration/overleaf-toolkit/s3.md) für Details an.

**Flüchtige Dateien**

Die standardmäßige Bind-Mount-Einbindung einer lokalen SSD nach `/var/lib/overleaf` (`/var/lib/sharelatex` für Versionen `4.x` und früher) wird ausreichen. Achten Sie darauf, dass `SANDBOXED_COMPILES_HOST_DIR` auf den Einhängepunkt auf dem Host.

{% hint style="danger" %}
Wir raten dringend zur Verwendung eines lokalen Datenträgers. Die Verwendung jeglicher Art von Netzwerkdatenträgern (wie NFS oder EBS) kann zu unerwarteten Kompilierungsfehlern und anderen Leistungsproblemen führen.
{% endhint %}

**Proxy-Konfiguration**

* Setzen Sie `OVERLEAF_BEHIND_PROXY=true` (`SHARELATEX_BEHIND_PROXY` für Versionen `4.x` und früher) für korrekte Client-IPs.
* Setzen Sie `TRUSTED_PROXY_IPS` auf die IP des Load Balancers (mehrere CIDRs können angegeben werden, getrennt durch ein Komma).

**Git-bridge-Integration**

{% hint style="info" %}
Git-bridge ist in Server Pro ab Version 4.0.1 verfügbar.
{% endhint %}

Der git-bridge-Container benötigt einen Schwester-Server-Pro-Container, um eingehende Git-Anfragen zu verarbeiten. Dieser Schwester-Container kann auch normalen Benutzerdatenverkehr bedienen. In der Beispielkonfiguration fungiert die erste Instanz als Schwester-Container für git-bridge, aber eigentlich könnte jede Instanz diese Rolle übernehmen.

Warum müssen wir einen Server-Pro-Container als Schwester-Container für git-bridge festlegen? Server Pro gibt git-bridge Download-URLs für den History-Dienst aus. Wir müssen diese History-URLs so konfigurieren, dass sie vom git-bridge-Container aus erreichbar sind.

Server-Pro-Container-Konfiguration:

* 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 Schwester-Container für den git-bridge-Container erforderlich. Die anderen Instanzen können eine localhost-URL verwenden, was der Standard ist.

git-bridge-Container-Konfiguration:

* 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`

<details>

<summary>Beispielkonfiguration für docker-compose.yml</summary>

Die folgende Konfiguration zeigt ein in sich geschlossenes Setup. Damit die Demo funktioniert, müssen Sie einen gültigen SSL-Schlüssel/ein gültiges SSL-Zertifikat bereitstellen und die `OVERLEAF_SITE_URL` (`SHARELATEX_SITE_URL` für Versionen `4.x` und früher). Für ein tatsächliches Setup müssen Sie die Platzhalter-Secrets wie inline vermerkt durch echte Secrets ersetzen. Für ein tatsächliches Setup müssen Sie die einzelnen Container auf dedizierte Knoten verschieben und die IP-Adressen an Ihr lokales Netzwerk-Setup anpassen.

```yaml
version: '2.2'

# Tatsächliche horizontale Skalierungs-Einrichtung: Wählen Sie Ihr eigenes Netzwerk und ersetzen Sie die IPs in der Konfiguration.
networks:
    default:
        ipam:
            config:
                # Dieses Subnetz ist Teil eines reservierten Subnetzes, das für Benchmarking verwendet wird
                # https://tools.ietf.org/html/rfc2544
                # Das vollständige Subnetz ist 198.18.0.0/15
                # Verwenden Sie 198.18.0.0/24 für den Load Balancer und die Datenbanken
                # Verwenden Sie 198.18.1.0/24 für server-pro
                # Verwenden Sie 198.18.0.128/25 für den flüchtigen Container
                - gateway: 198.18.0.1
                  ip_range: 198.18.0.128/25
                  subnet: 198.18.0.0/23

services:
    # Tatsächliche horizontale Skalierungs-Einrichtung: Führen Sie haproxy außerhalb von Docker auf einem separaten Host aus.
    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 zu 'ports': Host-Netzwerk verwenden, um docker-proxy-Overhead zu vermeiden
        network_mode: host

        # Alternative zu 'network_mode: host': docker-proxy für Netzwerktrennung verwenden
        # ports:
        #     - "80:80"
        #     - "443:443"
        # Netzwerke:
        #     default:
        #         ipv4_address: 198.18.0.2

        # Tatsächliche horizontale Skalierungs-Einrichtung: Entfernen Sie diese, da sie auf anderen Hosts laufen.
        depends_on:
            server-pro-ha-1:
                condition: service_started
            server-pro-ha-2:
                condition: service_started
            server-pro-ha-3:
                condition: service_started

    # Tatsächliche horizontale Skalierungs-Einrichtung: Führen Sie diesen Container neben server-pro-ha-1 aus.
    # Für Server Pro 4.0 und höher.
    git-bridge:
        restart: always
        # Das Tag sollte mit dem Container-Tag von `server-pro-ha-1` übereinstimmen.
        image: quay.io/sharelatex/git-bridge:4.0.1
        Volumes:
            # Tatsächliche horizontale Skalierungs-Einrichtung: Richten Sie /data/git-bridge auf eine dedizierte lokale SSD aus.
            - ~/git_bridge_data:/data/git-bridge
        container_name: git-bridge
        Umgebung:
            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"]

        # Tatsächliche horizontale Skalierungs-Einrichtung: Auf Host 198.18.0.6 ausführen und Port freigeben
        # ports:
        #     - "8000:8000"
        networks:
            default:
                ipv4_address: 198.18.0.6

    # Tatsächliche horizontale Skalierungs-Einrichtung: Führen Sie diesen Container auf einem separaten Host aus.
    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:
            # Tatsächliche horizontale Skalierungs-Einrichtung: Diesen Eintrag beibehalten.
            git-bridge:
                condition: service_started

            # Tatsächliche horizontale Skalierungs-Einrichtung: Die untenstehenden entfernen, da sie auf anderen Hosts laufen.
            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
            # Tatsächliche horizontale Skalierungs-Einrichtung: Geben Sie Ihre eigene Domain/Ihren eigenen App-Namen an.
            OVERLEAF_SITE_URL: 'https://overleaf.example.com'
            OVERLEAF_APP_NAME: Server-Pro-Demo zur horizontalen Skalierung

            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
            # Tatsächliche horizontale Skalierungs-Einrichtung: Wählen Sie sichere Anmeldedaten.
            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
            # Nur auf der Nebeninstanz von git-bridge erforderlich
            V1_HISTORY_URL: "http://server-pro-ha-1:3100/api"
            # /git-bridge

            # Horizontale Skalierung
            # Tatsächliche horizontale Skalierungs-Einrichtung: Wählen Sie sichere Anmeldedaten.
            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'
            # Tatsächliches Setup für horizontale Skalierung: IPs der Load Balancer
            TRUSTED_PROXY_IPS: 198.18.0.1,198.18.0.2
            # /Horizontale Skalierung

        # Tatsächliches Setup für horizontale Skalierung: auf Host 198.18.1.1 ausführen und Ports freigeben
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.1

    # Tatsächliche horizontale Skalierungs-Einrichtung: Führen Sie diesen Container auf einem separaten Host aus.
    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
        Umgebung:
            <<: *server-pro-ha-environment
            SANDBOXED_COMPILES_HOST_DIR: '/tmp/scratch-disk2/data/compiles'
            V1_HISTORY_URL: "http://localhost:3100/api"

        # Tatsächliches Setup für horizontale Skalierung: auf Host 198.18.1.2 ausführen und Ports freigeben
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.2

    # Tatsächliche horizontale Skalierungs-Einrichtung: Führen Sie diesen Container auf einem separaten Host aus.
    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
        Umgebung:
            <<: *server-pro-ha-environment
            SANDBOXED_COMPILES_HOST_DIR: '/tmp/scratch-disk3/data/compiles'
            V1_HISTORY_URL: "http://localhost:3100/api"

        # Tatsächliches Setup für horizontale Skalierung: auf Host 198.18.1.3 ausführen und Ports freigeben
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.3

    # Tatsächliche horizontale Skalierungs-Einrichtung: Führen Sie diesen Container auf einem separaten Host aus.
    minio:
        image: minio/minio:RELEASE.2023-05-18T00-05-36Z
        container_name: minio
        command: server /data
        Volumes:
            # Tatsächliches Setup für horizontale Skalierung: minio mit mehreren Festplatten ausführen, siehe MinIO-Dokumentation.
            - ~/minio_data:/data
        Umgebung:
            # Tatsächliche horizontale Skalierungs-Einrichtung: Wählen Sie sichere Anmeldedaten.
            MINIO_ROOT_USER: MINIO_ROOT_USER
            MINIO_ROOT_PASSWORD: MINIO_ROOT_PASSWORD

        # Tatsächliches Setup für horizontale Skalierung: auf Host 198.18.0.5 ausführen und Port freigeben
        # ports:
        #     - "9000:9000"
        networks:
            default:
                ipv4_address: 198.18.0.5

    # Tatsächliches Setup für horizontale Skalierung: diese Einrichtung einmal auf einem separaten Host ausführen.
    minio_setup:
        depends_on:
            - minio
        image: minio/mc:RELEASE.2023-05-18T16-59-00Z
        entrypoint: sh
        Befehl:
            - '-c'
            # Tatsächliche horizontale Skalierungs-Einrichtung: Wählen Sie sichere Anmeldedaten.
            - |
                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

                # Den Inhalt der Richtlinie aus dem vorherigen Abschnitt in policy-filestore.json einfügen
                # Erinnerung: Die Bucket-Namen entsprechend ersetzen.
                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

    # Tatsächliche horizontale Skalierungs-Einrichtung: Führen Sie diesen Container auf einem separaten Host aus.
    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

        # Tatsächliches Setup für horizontale Skalierung: auf Host 198.18.0.3 ausführen und Port freigeben
        # 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
        Befehl:
            - '-c'
            - |
                mongo 198.18.0.3 --eval "rs.initiate({ _id: \"overleaf\", members: [ { _id: 0, host: \"198.18.0.3:27017\" } ] })"

    # Tatsächliche horizontale Skalierungs-Einrichtung: Führen Sie diesen Container auf einem separaten Host aus.
    redis:
        restart: always
        image: redis:6.2
        container_name: redis
        expose:
            - 6379
        Volumes:
            - ~/redis_data:/data

        # Tatsächliches Setup für horizontale Skalierung: auf Host 198.18.0.4 ausführen und Port freigeben
        # ports:
        #     - "6379:6379"
        networks:
            default:
                ipv4_address: 198.18.0.4
```

</details>

#### Hardware

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

Die allgemeinen Empfehlungen zu [Hardware-Spezifikationen](/on-premises/de/erste-schritte/requirements/hardware-requirements.md) für Server-Pro-Instanzen gelten.

#### Aktualisierung von Server Pro

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

Die Migrationen müssen abgeschlossen sein, bevor die eigentliche Webanwendung gestartet wird. Sie können entweder in den Protokollen nach einem Eintrag für `Migrationen abgeschlossen` oder warten, bis die Anwendung Traffic annimmt.

Das Upgrade-Verfahren sieht folgendermaßen aus:

1. Ein Wartungsfenster planen
2. Alle Instanzen von Server Pro stoppen
3. Ein konsistentes Backup wie in der [Dokumentation](/on-premises/de/wartung/data-and-backups.md#performing-a-consistent-backup)
4. Eine einzelne Instanz von Server Pro mit der neuen Version starten
5. Validieren, dass die neue Instanz wie erwartet funktioniert
6. Die anderen Instanzen mit der neuen Version hochfahren


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://overleaf-pro.ayaka.space/on-premises/de/wartung/horizontal-scaling.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.