> 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/da/vedligeholdelse/horizontal-scaling.md).

# Vandret skalering

Fra version 3.5.6 understøtter Server Pro horisontal skalering.

Dette dokument oplister de tekniske krav og giver retningslinjer for at køre Server Pro på mere end én node.

{% hint style="danger" %}
Fra Server CE/Server Pro `5.0.3` miljøvariabler er blevet omdøbt fra `SHARELATEX_*` til `OVERLEAF_*`.

Hvis du bruger en `4.x` version (eller tidligere) skal du sørge for, at variablerne har det tilsvarende præfiks (f.eks. `SHARELATEX_SITE_URL` i stedet for `OVERLEAF_SITE_URL`)
{% endhint %}

Opsætning af horisontal skalering kræver en betydelig indsats. Vi anbefaler at overveje horisontal skalering **kun** når man når en vis skala. Som eksempel er en Server Pro-installation til 1.000 samlede brugere blevet sat op med succes ved hjælp af én server udstyret med to 4-kerne processorer og 32 GB systemhukommelse. Se [hardwarekrav](/on-premises/da/kom-godt-i-gang/requirements/hardware-requirements.md) dokumentationen for anbefalinger.

En implementering af Server Pro med horisontal skalering omfatter en række eksterne komponenter, såsom en load balancer og et S3-kompatibelt lagringsbackend.

Vi kan hjælpe med at fejlfinde fejl i Server Pro-containere, som kan være resultatet af fejlkonfiguration, og give generelle råd baseret på dette dokument. Desværre kan vi ikke yde assistance til konfiguration af tredjepartsapplikationer/-systemer.

Løsning af tekniske problemer, der er specifikke for din hardware/software, for at levere de eksterne komponenter, er ikke omfattet af vores supportvilkår.

### Krav

#### Ekstern, central datalagring

Datalagringen i Server Pro kan opdeles i fire datalagre:

* **MongoDB**

  * De fleste data gemmes i MongoDB.
  * Vi understøtter enten en lokal instans eller en ekstern instans, såsom [MongoDB](https://www.mongodb.com/atlas) Atlas (en fuldt administreret MongoDB-tjeneste, der kører i AWS-infrastrukturen).<br>

  **Bemærk:** Desværre er der på nuværende tidspunkt ingen officiel support for MongoDB-kompatible databaser såsom CosmoDB/DocumentDB, da vi ikke har testet Server Pro med dem. Selvom det **kan** være muligt, understøtter vi kun officielt implementeringer, der bruger MongoDB.<br>
* **Redis**

  * Redis gemmer midlertidige data, såsom afventende dokumentopdateringer, før de skrives til MongoDB.
  * Redis bruges til at kommunikere dokumentopdateringer mellem forskellige tjenester og til at underrette editoren om tilstandsændringer i et givent projekt.
  * Redis bruges til at gemme brugersessioner.
  * Vi understøtter enten en lokal instans eller en ekstern instans.<br>

  **Bemærk:** Desværre er der på nuværende tidspunkt ingen officiel support for Redis-kompatible nøgle/værdi-lagre såsom KeyDB/Valkey, da vi ikke har testet Server Pro med dem. Selvom det **kan** kan være muligt, understøtter vi kun officielt implementeringer, der bruger Redis.<br>
* **Projektfiler og historikfiler**

  * Ikke-redigerbare projektfiler gemmes uden for MongoDB.

    Det nye projekt-historiksystem (Server Pro 3.5 og frem) gemmer også historikken uden for MongoDB.
  * For små enkeltinstanser understøtter vi enten et lokalt filsystem (som kan være understøttet af en lokal SSD, NFS eller EBS) eller et [S3-kompatibelt datalagringssystem](/on-premises/da/konfiguration/overleaf-toolkit/s3.md).
  * Til horisontal skalering **kun** understøtter vi S3-kompatible datalagringssystemer.<br>

  **Vigtigt:** NFS/Amazon EFS/Amazon EBS er **ikke** understøttet til horisontal skalering. Se venligst [hardwarelagring](/on-premises/da/kom-godt-i-gang/requirements/hardware-requirements.md#storage) afsnittet om krav til skalering af lagring i Server Pro for flere detaljer.
* **Flygtige filer**
  * LaTeX-kompileringer skal køres på hurtige, lokale diske for optimal ydeevne. Outputtet fra kompileringen behøver ikke at blive gemt eller sikkerhedskopieret.
  * Buffering af nye filuploads og oprettelsen af projekt-zipfiler har også fordel af at bruge en lokal disk.

{% hint style="danger" %}
Vi anbefaler kraftigt at bruge en lokal disk. Brug af enhver form for netværksdisk (såsom NFS eller EBS) kan resultere i uventede kompileringsfejl og andre ydelsesproblemer.
{% endhint %}

#### **Git-bridge**

{% hint style="info" %}
Git-bridge er tilgængelig i Server Pro fra version 4.0.1.
{% endhint %}

Git-lagrepositorierne gemmes lokalt på disken. Der er ingen replikeringsmuligheder tilgængelige. Git-bridge bør køres som en **singleton**. For optimal ydeevne anbefaler vi at bruge en lokal disk til git-bridge-data. Git-bridge-datadisken bør sikkerhedskopieres regelmæssigt.

Til datalagring med horisontal skalering har du brug for:

* en central MongoDB-instans, der er tilgængelig fra alle Server Pro-instancer
* en central Redis-instans, der er tilgængelig fra alle Server Pro-instancer
* et centralt S3-kompatibelt lagringsbackend til projekt- og historikfiler
* en lokal disk på hver instans til flygtige filer
* en lokal disk på instansen, der hoster git-bridge-containeren, til git-bridge-data

#### Krav til load balanceren

* **Vedvarende routing**, f.eks. ved hjælp af en cookie

  Dette krav stammer fra disse komponenter:

  * Server Pro's realtidsredigeringsfunktion bruger WebSockets med fallback til XHR-polling. Hver redigeringssession har lokal tilstand på serversiden, og anmodningerne fra en given redigeringssession skal altid dirigeres til den samme Server Pro-instans. Samarbejdsfunktionen bruger Redis [Pub/Sub](https://redis.io/docs/latest/develop/interact/pubsub/) til at dele opdateringer mellem flere Server Pro-instancer.
  * LaTeX-kompileringen holder outputtet og kompileringscachen lokalt for optimal ydeevne. Når der sendes en kompileringsanmodning til én Server Pro-instans, skal de følgende PDF/log-downloadanmodninger dirigeres til den samme Server Pro-instans.
* **Lange anmodningstimeouts** for at understøtte kompilering af store LaTeX-dokumenter
* **WebSocket-understøttelse** for optimal ydeevne
* **POST-payloadstørrelse på 50 MB**
* **Keep-alive-timeout** skal være lavere end Server Pro's keep-alive-timeout

  Keep-alive-timeout i Server Pro kan konfigureres ved hjælp af miljøvariablen `NGINX_KEEPALIVE_TIMEOUT`. Standardværdien er 65 sek.

  Med standardindstillingen fungerer en keep-alive-timeout på 60 sek. i load balanceren.

  Med `NGINX_KEEPALIVE_TIMEOUT=120`, kunne load balanceren vælge 115 sek.
* **Klient-IP'er**

  Sæt anmodningsheaderen `X-Forwarded-For` til klientens IP.
* Når **SSL-terminering**

  Load balanceren skal tilføje anmodningsheaderen `X-Forwarded-Proto: https`.

<details>

<summary>Eksempel på HAProxy-konfiguration</summary>

```
global
  group haproxy
  user haproxy

  # Udførlig logning
  log stdout format raw local0 debug

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

  # Udførlig logning
  log                     global
  option                  httplog

  # Omdiriger til et andet backend, hvis den sticky server er nede
  option                  redispatch 1
  # Disse genforsøg gælder for TCP-forbindelsesfejl, ikke for HTTP-status 500-svar
  retries                 3

  # Sticky-session i 24 timers inaktivitet -- kompileringsoutput slettes efter 24 timer
  cookie                  server-pro-ha insert maxidle 24h

  # Forsøg at oprette forbindelse til ethvert backend i 1 min., og returner derefter 503
  timeout queue           1m
  # Giv Server Pro-instancer 15 sek. til at starte
  timeout connect         15s

  # Afbryd anmodninger fra meget langsomme klienter (tillad 1 min. inaktivitet ved læsning af en anmodning)
  timeout client          1m

  # Tillad langsomme kompileringer -- den hårdkodede grænse i clsi er 10 min
  timeout server          10m

  # Afbryd editoren efter 23 timer -- 1 time før deres sidste brug i går
  timeout tunnel          23h

  # Bemærk: Keepalive-adfærden i haproxy fungerer rigtig godt med standard-keepalive-opsætningen i Server Pro.
  #       Haproxy rydder op i forbindelser i baggrunden, og den vil omdirigere anmodninger efter behov.

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

  # Fortæl applikationen, at vi er bag https
  http-request set-header X-Forwarded-Proto https

  # Fortæl applikationen den faktiske klient-IP
  option forwardfor

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

  # Send git-trafik til git-bridge'ens søstercontainer
  use-server server-pro-ha-1 if { path_beg /git/ }

  # Fejlfinding
  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

**Hemmeligheder**

Server Pro-instancerne skal være enige om delte hemmeligheder:

* `WEB_API_PASSWORD` (web-api-godkendelse)
* `STAGING_PASSWORD` og `V1_HISTORY_PASSWORD` samme værdi (historik-godkendelse)
* `CRYPTO_RANDOM` (til sessionscookie)
* `OT_JWT_AUTH_KEY` (historik-godkendelse)

Alle disse hemmeligheder skal konfigureres med deres egen unikke værdi og deles mellem instanserne.

Når det ikke er konfigureret, og brugeranmodninger dirigeres til forskellige Server Pro-instancer, vil deres anmodning ikke bestå godkendelsestjek, og de bliver enten ofte videresendt til login-siden, eller deres handlinger i brugerfladen vil fejle på uventede måder.

Når det ikke er konfigureret, bruger Server Pro en ny tilfældig værdi for hver hemmelighed baseret på 32 tilfældige bytes fra `/dev/urandom` (256 tilfældige 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**

Peg `OVERLEAF_MONGO_URL` (`SHARELATEX_MONGO_URL` for versioner `4.x` og tidligere) til den centrale MongoDB-instans.

**Redis**

Peg `OVERLEAF_REDIS_HOST` (`SHARELATEX_REDIS_HOST` for versioner `4.x` og tidligere) og `REDIS_HOST` til den centrale Redis-instans.

**S3-kompatibel lagring til projekt- og historikfiler**

Se venligst dokumentationen om [S3-kompatibel lagring](/on-premises/da/konfiguration/overleaf-toolkit/s3.md) for detaljer.

**Flygtige filer**

Standard bind-mount af en lokal SSD til `/var/lib/overleaf` (`/var/lib/sharelatex` for versioner `4.x` og tidligere) vil være tilstrækkelig. Sørg for at pege `SANDBOXED_COMPILES_HOST_DIR` på mountpunktet på værten.

{% hint style="danger" %}
Vi anbefaler kraftigt at bruge en lokal disk. Brug af enhver form for netværksdisk (såsom NFS eller EBS) kan resultere i uventede kompileringsfejl og andre ydelsesproblemer.
{% endhint %}

**Proxykonfiguration**

* Sæt `OVERLEAF_BEHIND_PROXY=true` (`SHARELATEX_BEHIND_PROXY` for versioner `4.x` og tidligere) for præcise klient-IP'er.
* Sæt `TRUSTED_PROXY_IPS` til load balancerens IP (flere CIDR'er kan angives, adskilt af komma).

**Git-bridge-integration**

{% hint style="info" %}
Git-bridge er tilgængelig i Server Pro fra version 4.0.1.
{% endhint %}

Git-bridge-containeren har brug for en søstercontainer med Server Pro til at håndtere indkommende git-anmodninger. Denne søstercontainer kan også betjene almindelig brugtrafik. I eksempelkombinationen fungerer den første instans som søstercontainer for git-bridge, men enhver instans kunne i praksis fungere som sådan.

Hvorfor skal vi udpege én Server Pro-container som søster til git-bridge? Server Pro udleverer download-URL'er til historiktjenesten til git-bridge. Vi skal konfigurere disse historik-URL'er, så de er tilgængelige fra git-bridge-containeren.

Server Pro-containerkonfiguration:

* Sæt `GIT_BRIDGE_ENABLED` til `'true'`
* Sæt `GIT_BRIDGE_HOST` til `<git-bridge container name>` f.eks. `git-bridge`
* Sæt `GIT_BRIDGE_PORT` til `8000`
* Sæt `V1_HISTORY_URL` til `http://<server-pro sibling container name>:3100/api`.

  Bemærk: Dette er kun nødvendigt på søstercontaineren for git-bridge-containeren. De andre instanser kan bruge en localhost-URL, som er standard.

git-bridge-containerkonfiguration:

* Sæt `GIT_BRIDGE_API_BASE_URL` til `http://<server-pro sibling container name>/api/v0`, f.eks. `http://server-pro-ha-1/api/v0`
* Sæt `GIT_BRIDGE_OAUTH2_SERVER` til `http://<server-pro sibling container name>`, f.eks. `http://server-pro-ha-1`
* Sæt `GIT_BRIDGE_POSTBACK_BASE_URL` til `http://<git-bridge container name>:8000`, f.eks. `http://git-bridge:8000`
* Sæt `GIT_BRIDGE_ROOT_DIR` til den bind-mountede git-bridge-datadisk, f.eks. `/data/git-bridge`

<details>

<summary>Eksempel på docker-compose.yml-konfiguration</summary>

Følgende konfiguration viser en selvstændig opsætning. For at demoen kan fungere, skal du levere en gyldig SSL-nøgle/-certifikat og justere `OVERLEAF_SITE_URL` (`SHARELATEX_SITE_URL` for versioner `4.x` og tidligere). For en faktisk opsætning skal du erstatte de dummy-hemmeligheder med faktiske hemmeligheder som angivet inline. For en faktisk opsætning skal du flytte de enkelte containere til dedikerede noder og justere IP-adresserne til din lokale netværksopsætning.

```yaml
version: '2.2'

# Faktisk opsætning til horisontal skalering: vælg dit eget netværk og erstat IP'er i konfigurationen.
networks:
    default:
        ipam:
            config:
                # Dette subnet er en del af et reserveret subnet, der bruges til benchmarking
                # https://tools.ietf.org/html/rfc2544
                # Hele subnettet er 198.18.0.0/15
                # Brug 198.18.0.0/24 til lb og dbs
                # Brug 198.18.1.0/24 til server-pro
                # Brug 198.18.0.128/25 til den flygtige container
                - gateway: 198.18.0.1
                  ip_range: 198.18.0.128/25
                  subnet: 198.18.0.0/23

services:
    # Faktisk opsætning til horisontal skalering: kør haproxy uden for docker på en separat vært.
    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
        # Alternativ til "ports": brug værtsnetværk for at undgå overhead fra docker-proxy
        network_mode: host

        # Alternativ til "network_mode: host": brug docker-proxy til netværksisolering
        # ports:
        #     - "80:80"
        #     - "443:443"
        # networks:
        #     default:
        #         ipv4_address: 198.18.0.2

        # Faktisk opsætning til horisontal skalering: fjern disse, da de kører på andre værter.
        depends_on:
            server-pro-ha-1:
                condition: service_started
            server-pro-ha-2:
                condition: service_started
            server-pro-ha-3:
                condition: service_started

    # Faktisk opsætning til horisontal skalering: kør denne container ved siden af server-pro-ha-1.
    # For Server Pro 4.0 og frem.
    git-bridge:
        restart: always
        # Tagget skal matche container-tagget for `server-pro-ha-1`.
        image: quay.io/sharelatex/git-bridge:4.0.1
        volumes:
            # Faktisk opsætning til horisontal skalering: peg /data/git-bridge på en dedikeret lokal 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"]

        # Faktisk opsætning til horisontal skalering: kør på værten 198.18.0.6 og eksponér port
        # ports:
        #     - "8000:8000"
        networks:
            default:
                ipv4_address: 198.18.0.6

    # Faktisk opsætning til horisontal skalering: kør denne container på en separat vært.
    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:
            # Faktisk opsætning til horisontal skalering: behold denne post.
            git-bridge:
                condition: service_started

            # Faktisk opsætning til horisontal skalering: fjern de nedenstående, da de kører på andre værter.
            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
            # Faktisk opsætning til horisontal skalering: angiv dit eget domæne/appnavn.
            OVERLEAF_SITE_URL: 'https://overleaf.example.com'
            OVERLEAF_APP_NAME: Server Pro-demo for horisontal skalering

            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
            # Faktisk opsætning til horisontal skalering: vælg sikre legitimationsoplysninger.
            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
            # Kun nødvendig på den tilhørende git-bridge-instans
            V1_HISTORY_URL: "http://server-pro-ha-1:3100/api"
            # /git-bridge

            # Horisontal skalering
            # Faktisk opsætning til horisontal skalering: vælg sikre legitimationsoplysninger.
            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'
            # Faktisk opsætning til horisontal skalering: IP-adresser på load balancere
            TRUSTED_PROXY_IPS: 198.18.0.1,198.18.0.2
            # /Horisontal skalering

        # Faktisk opsætning til horisontal skalering: kør på vært 198.18.1.1 og eksponér porte
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.1

    # Faktisk opsætning til horisontal skalering: kør denne container på en separat vært.
    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"

        # Faktisk opsætning til horisontal skalering: kør på vært 198.18.1.2 og eksponér porte
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.2

    # Faktisk opsætning til horisontal skalering: kør denne container på en separat vært.
    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"

        # Faktisk opsætning til horisontal skalering: kør på vært 198.18.1.3 og eksponér porte
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.3

    # Faktisk opsætning til horisontal skalering: kør denne container på en separat vært.
    minio:
        image: minio/minio:RELEASE.2023-05-18T00-05-36Z
        container_name: minio
        command: server /data
        volumes:
            # Faktisk opsætning til horisontal skalering: kør minio med flere diske, se minio-dokumentationen.
            - ~/minio_data:/data
        environment:
            # Faktisk opsætning til horisontal skalering: vælg sikre legitimationsoplysninger.
            MINIO_ROOT_USER: MINIO_ROOT_USER
            MINIO_ROOT_PASSWORD: MINIO_ROOT_PASSWORD

        # Faktisk opsætning til horisontal skalering: kør på vært 198.18.0.5 og eksponér port
        # ports:
        #     - "9000:9000"
        networks:
            default:
                ipv4_address: 198.18.0.5

    # Faktisk opsætning til horisontal skalering: kør denne opsætning én gang på en separat vært.
    minio_setup:
        depends_on:
            - minio
        image: minio/mc:RELEASE.2023-05-18T16-59-00Z
        entrypoint: sh
        kommandoen:
            - '-c'
            # Faktisk opsætning til horisontal skalering: vælg sikre legitimationsoplysninger.
            - |
                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

                # Læg indholdet af politikken fra det foregående afsnit i policy-filestore.json
                # Husk at erstatte bucket-navnene tilsvarende.
                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

    # Faktisk opsætning til horisontal skalering: kør denne container på en separat vært.
    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

        # Faktisk opsætning til horisontal skalering: kør på vært 198.18.0.3 og eksponér 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
        kommandoen:
            - '-c'
            - |
                mongo 198.18.0.3 --eval "rs.initiate({ _id: \"overleaf\", members: [ { _id: 0, host: \"198.18.0.3:27017\" } ] })"

    # Faktisk opsætning til horisontal skalering: kør denne container på en separat vært.
    redis:
        restart: always
        image: redis:6.2
        container_name: redis
        expose:
            - 6379
        volumes:
            - ~/redis_data:/data

        # Faktisk opsætning til horisontal skalering: kør på vært 198.18.0.4 og eksponér port
        # ports:
        #     - "6379:6379"
        networks:
            default:
                ipv4_address: 198.18.0.4
```

</details>

#### Hardware

Vi anbefaler at bruge de samme hardwarespecifikationer for alle Server Pro-instanser, der deltager i horisontal skalering.

De generelle anbefalinger til [hardwarespecifikationer](/on-premises/da/kom-godt-i-gang/requirements/hardware-requirements.md) for Server Pro-instanser gælder.

#### Opgradering af Server Pro

Som en del af opgraderingsprocessen kører Server Pro automatisk database-migrationer. Disse migrationer er **ikke** designet til at kunne køres fra flere instanser parallelt.

Migrationerne skal være færdige, før den egentlige webapplikation startes. Du kan enten tjekke loggene for en linje med `Migrationer færdige` eller vente, indtil applikationen accepterer trafik.

Opgraderingsproceduren ser sådan ud:

1. Planlæg et vedligeholdelsesvindue
2. Stop alle instanser af Server Pro
3. Tag en konsistent sikkerhedskopi som beskrevet i [dokumentation](/on-premises/da/vedligeholdelse/data-and-backups.md#performing-a-consistent-backup)
4. Start en enkelt instans af Server Pro med den nye version
5. Valider, at den nye instans fungerer som forventet
6. Sæt de andre instanser op med den nye 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://overleaf-pro.ayaka.space/on-premises/da/vedligeholdelse/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.