> For the complete documentation index, see [llms.txt](https://ayakaleaf-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://ayakaleaf-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 gibt Hinweise zum Betrieb von Server Pro auf mehr als einem Knoten.

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

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

Das Einrichten der horizontalen Skalierung erfordert erheblichen Aufwand. Wir empfehlen, horizontale Skalierung in Betracht zu ziehen **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 Systemspeicher 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 Storage-Backend.

Wir können bei der Fehlersuche 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 Drittanbieter-Anwendungen/-Systemen bieten.

Die Behebung technischer Probleme, die speziell Ihre Hardware/Ihre Software betreffen, um die externen Komponenten bereitzustellen, fällt nicht unter unsere Supportbedingungen.

### Anforderungen

#### Externer, zentraler Datenspeicher

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

* **MongoDB**

  * Die meisten Daten werden 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 innerhalb der AWS-Infrastruktur läuft).<br>

  **Hinweis:** Leider gibt es derzeit keinen offiziellen Support für mit MongoDB kompatible Datenbanken wie CosmoDB/DocumentDB, da wir Server Pro nicht mit ihnen getestet haben. Auch wenn die Bereitstellung von Server Pro mit kompatiblen Datenbanken **kann** möglich sein, unterstützen wir offiziell nur Bereitstellungen mit MongoDB.<br>
* **Redis**

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

  **Hinweis:** Leider gibt es derzeit keinen offiziellen Support für mit Redis kompatible Key-/Value-Stores wie KeyDB/Valkey, da wir Server Pro nicht mit ihnen getestet haben. Auch wenn die Bereitstellung von Server Pro mit kompatiblen Stores **kann** möglich sein, unterstützen wir offiziell nur Bereitstellungen mit Redis.<br>
* **Projektdateien und Verlaufsdateien**

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

    Das neue Projekthistorie-System (ab Server Pro 3.5) speichert die Historie 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 unterstützen wir **nur** S3-kompatible Datenspeichersysteme.<br>

  **Wichtig:** NFS/Amazon EFS/Amazon EBS werden **nicht** für horizontale Skalierung unterstützt. Siehe die [Hardware-Speicher](/on-premises/de/erste-schritte/requirements/hardware-requirements.md#storage) Anforderungen zum Skalieren des Speichers in Server Pro für weitere Details.
* **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 gespeichert oder gesichert werden.
  * Das Puffern neuer Datei-Uploads und das Erstellen von Projekt-ZIP-Dateien profitiert ebenfalls von einem lokalen Datenträger.

{% hint style="danger" %}
Wir raten dringend zur Verwendung eines lokalen Datenträgers. Die Verwendung jeglicher Art von Netzwerkdatenträgern (z. B. 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-Repositories werden lokal auf dem Datenträger gespeichert. Es gibt keine Replikationsoptionen. Git-Bridge sollte als **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 von allen Server-Pro-Instanzen zugegriffen werden kann
* eine zentrale Redis-Instanz, auf die von allen Server-Pro-Instanzen zugegriffen werden kann
* ein zentrales S3-kompatibles Storage-Backend für Projekt- und Verlaufsdateien
* ein lokaler Datenträger auf jeder Instanz für flüchtige Dateien
* ein lokaler Datenträger auf der Instanz, die den Git-Bridge-Container hostet, für 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 einen 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 Austausch von Aktualisierungen zwischen mehreren Server-Pro-Instanzen.
  * Die LaTeX-Kompilierung hält die Ausgabe und den Kompilierungs-Cache lokal für optimale Leistung. Wenn eine Kompilierungsanfrage an eine Server-Pro-Instanz gesendet wird, müssen die folgenden PDF-/Log-Download-Anfragen an dieselbe Server-Pro-Instanz weitergeleitet werden.
* **Lange Anfrage-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 konfiguriert werden `NGINX_KEEPALIVE_TIMEOUT`. Der Standardwert ist 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-IP-Adressen**

  Setzen Sie den Anfrage-Header `X-Forwarded-For` auf die Client-IP.
* Wenn **SSL beenden**

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

<details>

<summary>Beispielhafte HAProxy-Konfiguration</summary>

```
global
  group haproxy
  user haproxy

  # Ausführliches Logging
  log stdout format raw local0 debug

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

  # Ausführliches Logging
  log                     global
  option                  httplog

  # Umleitung zu einem anderen Backend, wenn das sticky Backend ausgefallen ist
  option                  redispatch 1
  # Diese Wiederholungen gelten für TCP-Verbindungsfehler, nicht für HTTP-Status-500-Antworten
  retries                 3

  # Sticky-Session für 24 h Inaktivität -- die Kompilierungs-Ausgabe 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
  # Geben Sie Server-Pro-Instanzen 15 s zum Starten
  timeout connect         15s

  # Anfragen sehr langsamer Clients abbrechen (beim Lesen einer Anfrage 1 Min. Inaktivität zulassen)
  timeout client          1m

  # Langsame Kompilierungen zulassen -- die fest codierte Grenze in clsi beträgt 10 Min.
  timeout server          10m

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

  # Hinweis: Das Keepalive-Verhalten in haproxy funktioniert hervorragend mit der Standard-Keepalive-Konfiguration in Server Pro.
  # Haproxy räumt Verbindungen im Hintergrund auf und verteilt Anfragen bei Bedarf neu.

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

  # Der Anwendung mitteilen, dass wir hinter https stehen
  http-request set-header X-Forwarded-Proto https

  # Der Anwendung die tatsächliche Client-IP mitteilen
  option forwardfor

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

  # Git-Traffic an den Nebencontainer der Git-Bridge weiterleiten
  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 Geheimnisse einigen:

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

Alle diese Geheimnisse müssen mit jeweils einem eigenen eindeutigen Wert konfiguriert und zwischen den Instanzen geteilt werden.

Wenn sie nicht konfiguriert sind und Benutzeranfragen an verschiedene Server-Pro-Instanzen weitergeleitet werden, schlägt ihre Authentifizierung fehl, und sie werden entweder häufig zur Anmeldeseite weitergeleitet oder ihre Aktionen in der Benutzeroberfläche schlagen auf unerwartete Weise fehl.

Wenn sie nicht konfiguriert sind, verwendet Server Pro für jedes Geheimnis einen neuen zufälligen Wert, basierend auf 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**

Punkt `OVERLEAF_MONGO_URL` (`SHARELATEX_MONGO_URL` für Versionen `4.x` und früher) auf der zentralen MongoDB-Instanz.

**Redis**

Punkt `OVERLEAF_REDIS_HOST` (`SHARELATEX_REDIS_HOST` für Versionen `4.x` und früher) und `REDIS_HOST` auf der zentralen Redis-Instanz.

**S3-kompatibler Speicher für Projekt- und Verlaufsdateien**

Weitere Informationen finden Sie in der Dokumentation zu [S3-kompatiblen Speicher](/on-premises/de/konfiguration/overleaf-toolkit/s3.md) für Details.

**Flüchtige Dateien**

Das standardmäßige Bind-Mount einer lokalen SSD nach `/var/lib/overleaf` (`/var/lib/sharelatex` für Versionen `4.x` und früher) reicht aus. Stellen Sie sicher, dass Sie `SANDBOXED_COMPILES_HOST_DIR` auf den Mount-Punkt auf dem Host verweisen.

{% hint style="danger" %}
Wir raten dringend zur Verwendung eines lokalen Datenträgers. Die Verwendung jeglicher Art von Netzwerkdatenträgern (z. B. 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 genaue Client-IP-Adressen.
* Setzen Sie `TRUSTED_PROXY_IPS` auf die IP des Load Balancers (es können mehrere CIDRs angegeben werden, durch Kommas getrennt).

**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 benachbarten Server-Pro-Container, um eingehende Git-Anfragen zu verarbeiten. Dieser benachbarte Container kann auch regulären Benutzerverkehr bedienen. In der Beispielkonfiguration fungiert die erste Instanz als benachbarter Container für Git-Bridge, aber tatsächlich könnte jede Instanz diese Funktion übernehmen.

Warum müssen wir einen Server-Pro-Container als benachbart zu Git-Bridge festlegen? Server Pro stellt Download-URLs für den Historiendienst an Git-Bridge bereit. Wir müssen diese Historien-URLs so konfigurieren, dass sie vom Git-Bridge-Container aus erreichbar sind.

Server-Pro-Container-Konfiguration:

* Setzen Sie `GIT_BRIDGE_ENABLED` zu `'true'`
* Setzen Sie `GIT_BRIDGE_HOST` zu `<Git-Bridge-Containername>` z. B. `git-bridge`
* Setzen Sie `GIT_BRIDGE_PORT` zu `8000`
* Setzen Sie `V1_HISTORY_URL` zu `http://<Name des benachbarten Server-Pro-Containers>:3100/api`.

  Hinweis: Dies ist nur auf dem benachbarten Container für den Git-Bridge-Container erforderlich. Die anderen Instanzen können eine localhost-URL verwenden, was die Standardvorgabe ist.

Git-Bridge-Container-Konfiguration:

* Setzen Sie `GIT_BRIDGE_API_BASE_URL` zu `http://<Name des benachbarten Server-Pro-Containers>/api/v0`, z. B. `http://server-pro-ha-1/api/v0`
* Setzen Sie `GIT_BRIDGE_OAUTH2_SERVER` zu `http://<Name des benachbarten Server-Pro-Containers>`, z. B. `http://server-pro-ha-1`
* Setzen Sie `GIT_BRIDGE_POSTBACK_BASE_URL` zu `http://<Git-Bridge-Containername>:8000`, z. B. `http://git-bridge:8000`
* Setzen Sie `GIT_BRIDGE_ROOT_DIR` zum bind-gemounteten Git-Bridge-Datenträger, z. B. `/data/git-bridge`

<details>

<summary>Beispielhafte docker-compose.yml-Konfiguration</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-Geheimnisse durch echte Geheimnisse ersetzen, wie weiter unten angegeben. 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ächliches Setup für horizontale Skalierung: Wählen Sie Ihr eigenes Netzwerk und ersetzen Sie die IPs in der Konfiguration.
networks:
    default:
        ipam:
            config:
                # Dieser Subnetzbereich 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 Load Balancer und 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ächliches Setup für horizontale Skalierung: 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": Verwenden Sie das Host-Netzwerk, um den Docker-Proxy-Overhead zu vermeiden
        network_mode: host

        # Alternative zu "network_mode: host": Verwenden Sie docker-proxy für Netzwerkisolierung
        # ports:
        #     - "80:80"
        #     - "443:443"
        # networks:
        #     default:
        #         ipv4_address: 198.18.0.2

        # Tatsächliches Setup für horizontale Skalierung: Entfernen Sie diese, da sie auf anderen Hosts ausgeführt werden.
        depends_on:
            server-pro-ha-1:
                condition: service_started
            server-pro-ha-2:
                condition: service_started
            server-pro-ha-3:
                condition: service_started

    # Tatsächliches Setup für horizontale Skalierung: Führen Sie diesen Container neben server-pro-ha-1 aus.
    # Für Server Pro 4.0 und neuer.
    git-bridge:
        restart: always
        # Das Tag sollte mit dem Container-Tag `server-pro-ha-1` übereinstimmen.
        image: quay.io/sharelatex/git-bridge:4.0.1
        volumes:
            # Tatsächliches Setup für horizontale Skalierung: Verweisen Sie /data/git-bridge auf eine dedizierte lokale 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"]

        # Tatsächliches Setup für horizontale Skalierung: Auf Host 198.18.0.6 ausführen und Port freigeben
        # ports:
        #     - "8000:8000"
        networks:
            default:
                ipv4_address: 198.18.0.6

    # Tatsächliches Setup für horizontale Skalierung: 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ächliches Setup für horizontale Skalierung: Behalten Sie diesen Eintrag bei.
            git-bridge:
                condition: service_started

            # Tatsächliches Setup für horizontale Skalierung: Entfernen Sie die folgenden, da sie auf anderen Hosts ausgeführt werden.
            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ächliches Setup für horizontale Skalierung: Geben Sie Ihre eigene Domain/Ihren eigenen Anwendungsnamen 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ächliches Setup für horizontale Skalierung: Wählen Sie sichere Zugangsdaten.
            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 benachbarten Instanz von git-bridge erforderlich
            V1_HISTORY_URL: "http://server-pro-ha-1:3100/api"
            # /git-bridge

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

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

    # Tatsächliches Setup für horizontale Skalierung: 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
        environment:
            <<: *server-pro-ha-environment
            SANDBOXED_COMPILES_HOST_DIR: '/tmp/scratch-disk2/data/compiles'
            V1_HISTORY_URL: "http://localhost:3100/api"

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

    # Tatsächliches Setup für horizontale Skalierung: 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
        environment:
            <<: *server-pro-ha-environment
            SANDBOXED_COMPILES_HOST_DIR: '/tmp/scratch-disk3/data/compiles'
            V1_HISTORY_URL: "http://localhost:3100/api"

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

    # Tatsächliches Setup für horizontale Skalierung: 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 der horizontalen Skalierung: minio mit mehreren Datenträgern ausführen, siehe MinIO-Dokumentation.
            - ~/minio_data:/data
        environment:
            # Tatsächliches Setup für horizontale Skalierung: Wählen Sie sichere Zugangsdaten.
            MINIO_ROOT_USER: MINIO_ROOT_USER
            MINIO_ROOT_PASSWORD: MINIO_ROOT_PASSWORD

        # Tatsächliches Setup der horizontalen 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 der horizontalen Skalierung: Führen Sie dieses Setup einmal auf einem separaten Host aus.
    minio_setup:
        depends_on:
            - minio
        image: minio/mc:RELEASE.2023-05-18T16-59-00Z
        entrypoint: sh
        Befehl an:
            - '-c'
            # Tatsächliches Setup für horizontale Skalierung: Wählen Sie sichere Zugangsdaten.
            - |
                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

                # Fügen Sie den Inhalt der Richtlinie aus dem vorherigen Abschnitt in policy-filestore.json ein
                # Hinweis: Ersetzen Sie die Bucket-Namen entsprechend.
                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ächliches Setup für horizontale Skalierung: 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 der horizontalen 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 an:
            - '-c'
            - |
                mongo 198.18.0.3 --eval "rs.initiate({ _id: \"overleaf\", members: [ { _id: 0, host: \"198.18.0.3:27017\" } ] })"

    # Tatsächliches Setup für horizontale Skalierung: 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 der horizontalen 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 Server-Pro-Instanzen, die an der horizontalen Skalierung teilnehmen, die gleiche Hardware-Spezifikation zu verwenden.

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

#### Upgrade 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 die Protokolle auf einen Eintrag von `Migrationen abgeschlossen` prüfen oder warten, bis die Anwendung Traffic annimmt.

Der Upgrade-Vorgang sieht folgendermaßen aus:

1. Planen Sie ein Wartungsfenster
2. Stoppen Sie alle Instanzen von Server Pro
3. Erstellen Sie ein konsistentes Backup, wie in der [Dokumentation](/on-premises/de/wartung/data-and-backups.md#performing-a-consistent-backup)
4. Starten Sie eine einzelne Instanz von Server Pro mit der neuen Version
5. Validieren Sie, dass die neue Instanz wie erwartet funktioniert
6. Starten Sie die anderen Instanzen mit der neuen Version


---

# 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://ayakaleaf-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.