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

# Horisontal skalering

Startende med 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" %}
Startende med Server CE/Server Pro `5.0.3` miljøvariablerne 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 i alt 1.000 brugere blevet sat op med succes ved hjælp af en enkelt server udstyret med to 4-kernede processorer og 32 GB systemhukommelse. Se [hardwarekrav](/on-premises/da/kom-godt-i-gang/requirements/hardware-requirements.md) dokumentationen for anbefalinger.

En udrulning af Server Pro med horisontal skalering involverer et sæt eksterne komponenter, såsom en load balancer og en S3-kompatibel lagerbackend.

Vi kan hjælpe med at fejlfinde fejl i Server Pro-containerne, som kan være et resultat 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 dækket af vores supportvilkår.

### Krav

#### Ekstern, central datalagring

Datalagringen i Server Pro kan opdeles i fire datalagre:

* **MongoDB**

  * Det meste af dataen 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 inden for AWS-infrastrukturen).<br>

  **Bemærk:** Desværre er der i øjeblikket ingen officiel understøttelse af 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 ventende dokumentopdateringer, før de flushes til MongoDB.
  * Redis bruges til at kommunikere dokumentopdateringer mellem forskellige tjenester og til at underrette editoren om tilstandsændringer i et givet projekt.
  * Redis bruges til at gemme brugersessionerne.
  * Vi understøtter enten en lokal instans eller en ekstern instans.<br>

  **Bemærk:** Desværre er der i øjeblikket ingen officiel understøttelse af Redis-kompatible key/value-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 historiksystem for projekter (Server Pro fra 3.5 og frem) gemmer også historikken uden for MongoDB.
  * For små enkeltinstanser understøtter vi enten et lokalt filsystem (som kan understøttes 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) kravafsnittet om skalering af lagring i Server Pro for flere detaljer.
* **Flygtige filer**
  * LaTeX-kompileringer skal køre på hurtige, lokale diske for optimal ydeevne. Outputtet af kompileringen behøver ikke at blive bevaret eller sikkerhedskopieret.
  * Buffering af nye filuploads og oprettelse 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-repositories gemmes lokalt på disken. Der er ingen replikeringsmuligheder tilgængelige. Git-bridge bør køres som en **enkeltinstans**. For optimal ydeevne anbefaler vi at bruge en lokal disk til git-bridge-data. Git-bridge-datadisk 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
* en central S3-kompatibel lagerbackend til projekt- og historikfiler
* en lokal disk på hver instans til flygtige filer
* en lokal disk på den instans, der hoster git-bridge-containeren, til git-bridge-data

#### Krav til load balancer

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

  Dette krav skyldes disse komponenter:

  * Redigering i realtid i Server Pro bruger WebSockets med fallback til XHR-polling. Hver redigeringssession har lokal tilstand på serversiden, og anmodningerne fra en given redigeringssession skal altid routes 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 output og kompileringscache lokalt for optimal ydeevne. Når der sendes en kompiléringsanmodning til én Server Pro-instans, skal de følgende PDF/log-downloadanmodninger routes til den samme Server Pro-instans.
* **Lange request-timeouts** 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 Pros keep-alive-timeout

  Keep-alive-timeout iServer 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 request-headeren `X-Forwarded-For` til klientens IP.
* Når **afslutning af SSL**

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

<details>

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

```
global
  group haproxy
  user haproxy

  # Detaljeret logning
  log stdout format raw local0 debug

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

  # Detaljeret logning
  log                     global
  option                  httplog

  # Omdiriger til en anden backend, hvis den sticky er nede
  option                  redispatch 1
  # Disse retries er til TCP-forbindelsesfejl, ikke ved HTTP-status 500-svar
  retries                 3

  # Sticky session i 24 timer uden aktivitet -- output fra kompilering slettes efter 24 timer
  cookie                  server-pro-ha insert maxidle 24h

  # Prøv at oprette forbindelse til enhver backend i 1 min., og returnér derefter 503
  timeout queue           1m
  # Giv Server Pro-instancer 15 sek. til opstart
  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 foran deres sidste brug i går
  timeout tunnel          23h

  # Bemærk: keepalive-adfærden i haproxy fungerer glimrende med standard-keepalive-opsætningen i Server Pro.
  #       Haproxy rydder forbindelser op 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;"

  # Ruter git-trafik til søstercontaineren til git-bridge
  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 rutes til forskellige Server Pro-instancer, vil deres anmodning fejle autentificeringskontrollerne, og de bliver enten ofte omdirigeret til login-siden, eller deres handlinger i brugergrænsefladen 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**

Angiv `OVERLEAF_MONGO_URL` (`SHARELATEX_MONGO_URL` for versioner `4.x` og tidligere) på den centrale MongoDB-instans.

**Redis**

Angiv `OVERLEAF_REDIS_HOST` (`SHARELATEX_REDIS_HOST` for versioner `4.x` og tidligere) og `REDIS_HOST` på 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ækkeligt. Sørg for at pege `SANDBOXED_COMPILES_HOST_DIR` på mount-punktet 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 %}

**Proxy-konfiguration**

* Sæt `OVERLEAF_BEHIND_PROXY=true` (`SHARELATEX_BEHIND_PROXY` for versioner `4.x` og tidligere) for korrekte klient-IP'er.
* Sæt `TRUSTED_PROXY_IPS` til IP'en på load balanceren (flere CIDR'er kan angives adskilt med et 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 tilhørende Server Pro-container til håndtering af indgående git-anmodninger. Denne tilhørende container kan også betjene almindelig brugertrafik. I eksempelkonfigurationen fungerer den første instans som tilhørende container for git-bridge, men enhver instans kunne i virkeligheden fungere som det.

Hvorfor er vi nødt til at udpege én Server Pro-container som tilhørende for git-bridge? Server Pro giver download-URL'er for 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 `<navn på git-bridge-container>` f.eks. `git-bridge`
* Sæt `GIT_BRIDGE_PORT` til `8000`
* Sæt `V1_HISTORY_URL` til `http://<navn på server-pros tilhørende container>:3100/api`.

  Bemærk: Dette er kun nødvendigt på den tilhørende container for git-bridge-containeren. De andre instanser kan bruge en localhost-URL, som er standarden.

git-bridge-containerkonfiguration:

* Sæt `GIT_BRIDGE_API_BASE_URL` til `http://<navn på server-pros tilhørende container>/api/v0`, f.eks. `http://server-pro-ha-1/api/v0`
* Sæt `GIT_BRIDGE_OAUTH2_SERVER` til `http://<navn på server-pros tilhørende container>`, f.eks. `http://server-pro-ha-1`
* Sæt `GIT_BRIDGE_POSTBACK_BASE_URL` til `http://<navn på git-bridge-container>: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>

Den 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 egentlig opsætning skal du erstatte dummy-hemmelighederne med faktiske hemmeligheder som angivet inline. For en egentlig opsætning skal du flytte de enkelte containere over på 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
                # Det fulde subnet er 198.18.0.0/15
                # Brug 198.18.0.0/24 til lb og db'er
                # Brug 198.18.1.0/24 til server-pro
                # Brug 198.18.0.128/25 til flygtig 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 host-netvæ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.
    # Fra og med Server Pro 4.0.
    git-bridge:
        restart: always
        # Taggen skal matche container-taggen `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ært 198.18.0.6 og eksponer 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 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/app-navn.
            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 tilstødende instans af git-bridge
            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: load balancernes IP-adresser
            TRUSTED_PROXY_IPS: 198.18.0.1,198.18.0.2
            # /Horisontal skalering

        # Faktisk opsætning til horisontal skalering: kør på værten 198.18.1.1 og eksponer 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ærten 198.18.1.2 og eksponer 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ærten 198.18.1.3 og eksponer 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ærten 198.18.0.5 og eksponer 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

                # Indsæt indholdet af politikken fra forrige sektion i policy-filestore.json
                # Husk: Erstat 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ærten 198.18.0.3 og eksponer 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ærten 198.18.0.4 og eksponer port
        # ports:
        #     - "6379:6379"
        networks:
            default:
                ipv4_address: 198.18.0.4
```

</details>

#### Hardware

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

De generelle anbefalinger om [hardware-specifikationer](/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 databasemigreringer. Disse migreringer er **ikke** beregnet til at blive kørt fra flere instanser parallelt.

Migreringerne skal være færdige, før selve webapplikationen startes. Du kan enten tjekke loggene for en post med `Færdige migreringer` eller vente, indtil applikationen accepterer trafik.

Opgraderingsproceduren ser sådan ud:

1. Planlæg et vedligeholdelsesvindue
2. Stop alle Server Pro-instanserne
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. Kontrollér, at den nye instans fungerer som forventet
6. Start de øvrige instanser 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://ayakaleaf-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.