> 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/no/vedlikehold/horizontal-scaling.md).

# Horisontal skalering

{% hint style="success" %}
Ayakaleaf Pro støtter horisontal skalering. Vi har testet og verifisert at det kjører riktig med flere replikaer.
{% endhint %}

Dette dokumentet lister de tekniske kravene og gir retningslinjer for å kjøre Ayakaleaf Pro på mer enn én node.

{% hint style="danger" %}
Fra og med Server CE/Server Pro `5.0.3` miljøvariabler har blitt omdøpt fra `SHARELATEX_*` til `OVERLEAF_*`.

Hvis du bruker en `4.x` versjon (eller tidligere), sørg for at variablene får riktig prefiks (f.eks. `SHARELATEX_SITE_URL` i stedet for `OVERLEAF_SITE_URL`)
{% endhint %}

Å sette opp horisontal skalering krever en betydelig innsats. Vi anbefaler å vurdere horisontal skalering **bare** når du når en viss skala. Som et eksempel har en Server Pro-installasjon for 1 000 totale brukere blitt satt opp vellykket ved hjelp av én enkelt server med to 4-kjerners prosessorer og 32 GB systemminne. Se [kravene til maskinvare](/on-premises/no/kom-i-gang/requirements/hardware-requirements.md) dokumentasjonen for anbefalinger.

En distribusjon av Server Pro med horisontal skalering innebærer et sett med eksterne komponenter, som en lastbalanserer og en S3-kompatibel lagringsbackend.

Vi kan hjelpe til med å feilsøke feil i Server Pro-containerne som kan skyldes feilkonfigurasjon, og gi generell rådgivning basert på dette dokumentet. Dessverre kan vi ikke hjelpe med konfigurering av tredjepartsapplikasjoner/-systemer.

Løsning av tekniske problemer som er spesifikke for maskinvaren/programvaren din, forutsatt at de eksterne komponentene ikke er dekket av våre støttevilkår.

### Krav

<figure><img src="/files/96f1cd7e97474d6d8514efd4a774c0d78f298339" alt=""><figcaption></figcaption></figure>

#### Ekstern, sentral datalagring

Datalagringen i Server Pro kan deles inn i fire datalagre:

* **MongoDB**

  * Det meste av dataene lagres i MongoDB.
  * Vi støtter enten en lokal instans eller en ekstern instans, som for eksempel [MongoDB](https://www.mongodb.com/atlas) Atlas (en fullstendig administrert MongoDB-tjeneste som kjører i AWS-infrastrukturen).<br>

  **Merk:** Dessverre finnes det foreløpig ingen offisiell støtte for MongoDB-kompatible databaser som CosmoDB/DocumentDB, siden vi ikke har testet Server Pro med dem. Selv om det å distribuere Server Pro med kompatible databaser **kan** være mulig, støtter vi bare offisielt distribusjoner som bruker MongoDB.<br>
* **Redis**

  * Redis lagrer midlertidige data, som ventende dokumentoppdateringer før de skrives til MongoDB.
  * Redis brukes til å kommunisere dokumentoppdateringer mellom ulike tjenester og varsle editoren om tilstandsendringer i et gitt prosjekt.
  * Redis brukes til å lagre brukerøktene.
  * Vi støtter enten en lokal instans eller en ekstern instans.<br>

  **Merk:** Dessverre finnes det foreløpig ingen offisiell støtte for Redis-kompatible nøkkel-/verdilagre som KeyDB/Valkey, siden vi ikke har testet Server Pro med dem. Selv om det å distribuere Server Pro med kompatible lagre **kan** være mulig, støtter vi bare offisielt distribusjoner som bruker Redis.<br>
* **Prosjektfiler og historikkfiler**

  * Ikke-redigerbare prosjektfiler lagres utenfor MongoDB.

    Det nye systemet for prosjekt-historikk (fra og med Server Pro 3.5) lagrer også historikken utenfor MongoDB.
  * For små enkeltinstanser støtter vi enten et lokalt filsystem (som kan støttes av en lokal SSD, NFS eller EBS) eller et [S3-kompatibelt lagringssystem](/on-premises/no/konfigurasjon/overleaf-toolkit/s3.md).
  * For horisontal skalering **bare** støtter vi S3-kompatible lagringssystemer.<br>

  **Viktig:** NFS/Amazon EFS/Amazon EBS er **ikke** støttet for horisontal skalering. Se [kravene til maskinvarelagring](/on-premises/no/kom-i-gang/requirements/hardware-requirements.md#storage) avsnittet om skalering av lagring i Server Pro for mer informasjon.
* **Midlertidige filer**
  * LaTeX-kompileringer må kjøres på raske, lokale disker for optimal ytelse. Resultatet av kompileringen trenger ikke å persisteres eller sikkerhetskopieres.
  * Bufring av nye filopplastinger og opprettelsen av prosjekt-zip-filer har også fordel av å bruke en lokal disk.

{% hint style="danger" %}
Vi anbefaler sterkt å bruke en lokal disk. Bruk av en hvilken som helst nettverksdisk (som NFS eller EBS) kan føre til uventede kompileringsfeil og andre ytelsesproblemer.
{% endhint %}

#### **Git-bridge**

{% hint style="info" %}
Git-bridge er tilgjengelig i Server Pro fra og med versjon 4.0.1.
{% endhint %}

Git-repositoriene lagres lokalt på disk. Det finnes ingen replikeringsalternativer. Git-bridge bør kjøres som en **singleton**. For optimal ytelse anbefaler vi å bruke en lokal disk for git-bridge-data. git-bridge-datadisken bør sikkerhetskopieres regelmessig.

For datalagringen med horisontal skalering trenger du:

* en sentral MongoDB-instans som er tilgjengelig fra alle Server Pro-instansene
* en sentral Redis-instans som er tilgjengelig fra alle Server Pro-instansene
* en sentral S3-kompatibel lagringsbackend for prosjekt- og historikkfiler
* en lokal disk på hver instans for midlertidige filer
* en lokal disk på instansen som er vert for git-bridge-containeren, for git-bridge-data

#### Krav til lastbalanserer

* **Vedvarende ruting**, f.eks. ved hjelp av en cookie

  Dette kravet stammer fra disse komponentene:

  * Sanntidsredigeringsfunksjonen i Server Pro bruker WebSockets med et XHR-polling-fallback. Hver redigeringsøkt har lokal tilstand på serversiden, og forespørslene fra en gitt redigeringsøkt må alltid rutes til samme Server Pro-instans. Samarbeidsfunksjonen bruker Redis [Pub/Sub](https://redis.io/docs/latest/develop/interact/pubsub/) for å dele oppdateringer mellom flere Server Pro-instansene.
  * LaTeX-kompileringen beholder utdata og kompileringscache lokalt for optimal ytelse. Når en kompileringsforespørsel sendes til én Server Pro-instans, må de følgende forespørslene om PDF-/loggnedlasting rutes til samme Server Pro-instans.
* **Lange forespørselstidsavbrudd** for å støtte kompilering av store LaTeX-dokumenter
* **Støtte for WebSocket** for optimal ytelse
* **POST-payloadstørrelse på 50 MB**
* **Keep-alive-tidsavbrudd** må være lavere enn Server Pro sitt keep-alive-tidsavbrudd

  Keep-alive-tidsavbruddet i Server Pro kan konfigureres ved hjelp av miljøvariabelen `NGINX_KEEPALIVE_TIMEOUT`. Standardverdien er 65 s.

  Med standardverdien fungerer et keep-alive-tidsavbrudd på 60 s i lastbalansereren.

  Med `NGINX_KEEPALIVE_TIMEOUT=120`kan lastbalansereren bruke 115 s.
* **Klient-IP-er**

  Sett forespørselsheaderen `X-Forwarded-For` til klient-IP-en.
* Når du **avslutter SSL**

  må lastbalansereren legge til forespørselsheaderen `X-Forwarded-Proto: https`.

<details>

<summary>Eksempelkonfigurasjon for HAProxy</summary>

```
global
  group haproxy
  user haproxy

  # Utførlig logging
  log stdout format raw local0 debug

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

  # Utførlig logging
  log                     global
  option                  httplog

  # Omdiriger til en annen backend hvis den faste er nede
  option                  redispatch 1
  # Disse forsøkene gjelder TCP-tilkoblingsfeil, ikke HTTP-status 500-svar
  retries                 3

  # Fast økt i 24 t med inaktivitet -- kompileringsutdata slettes etter 24 t
  cookie                  server-pro-ha insert maxidle 24h

  # Prøv å koble til en hvilken som helst backend i 1 minutt, og returner deretter 503
  timeout queue           1m
  # Gi Server Pro-instansene 15 sekunder til oppstart
  timeout connect         15s

  # Avbryt forespørsler fra svært trege klienter (tillat 1 minutt med inaktivitet når en forespørsel leses)
  timeout client          1m

  # Tillat trege kompileringer -- den hardkodede grensen i clsi er 10 min
  timeout server          10m

  # Koble fra editoren etter 23 t -- 1 t foran deres siste bruk i går
  timeout tunnel          23h

  # Merk: Keepalive-oppførselen i haproxy fungerer utmerket med standard keepalive-oppsett i Server Pro.
  #       Haproxy rydder opp tilkoblinger i bakgrunnen, og den vil omdirigere forespørsler ved 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

  # Fortell applikasjonen at vi er bak https
  http-request set-header X-Forwarded-Proto https

  # Fortell applikasjonen den faktiske klient-IP-en
  option forwardfor

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

  # Ruter git-trafikk til søskencontaineren til git-bridge
  use-server server-pro-ha-1 if { path_beg /git/ }

  # Feilsøking
  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-konfigurasjon

**Hemmeligheter**

Server Pro-instansene må være enige om delte hemmeligheter:

* `WEB_API_PASSWORD` (web-API-autentisering)
* `STAGING_PASSWORD` og `V1_HISTORY_PASSWORD` samme verdi (historieautentisering)
* `CRYPTO_RANDOM` (for sesjonscookie)
* `OT_JWT_AUTH_KEY` (historieautentisering)

Alle disse hemmelighetene må konfigureres med sin egen unike verdi og deles mellom instansene.

Når dette ikke er konfigurert og brukerforespørsler rutes til forskjellige Server Pro-instansene, vil forespørslene deres feile autentiseringskontroller, og de blir enten ofte omdirigert til innloggingssiden eller handlingene deres i brukergrensesnittet vil feile på uventede måter.

Når dette ikke er konfigurert, bruker Server Pro en ny tilfeldig verdi for hver hemmelighet basert på 32 tilfeldige bytes fra `/dev/urandom` (256 tilfeldige biter).

{% 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**

Pek `OVERLEAF_MONGO_URL` (`SHARELATEX_MONGO_URL` for versjoner `4.x` og tidligere) ved den sentrale MongoDB-instansen.

**Redis**

Pek `OVERLEAF_REDIS_HOST` (`SHARELATEX_REDIS_HOST` for versjoner `4.x` og tidligere) og `REDIS_HOST` ved den sentrale Redis-instansen.

**S3-kompatibel lagring for prosjekt- og historikkfiler**

Se dokumentasjonen om [S3-kompatibel lagring](/on-premises/no/konfigurasjon/overleaf-toolkit/s3.md) for detaljer.

**Midlertidige filer**

Standard bind-mount av en lokal SSD til `/var/lib/overleaf` (`/var/lib/sharelatex` for versjoner `4.x` og tidligere) vil være tilstrekkelig. Sørg for å peke `SANDBOXED_COMPILES_HOST_DIR` til monteringspunktet på verten.

{% hint style="danger" %}
Vi anbefaler sterkt å bruke en lokal disk. Bruk av en hvilken som helst nettverksdisk (som NFS eller EBS) kan føre til uventede kompileringsfeil og andre ytelsesproblemer.
{% endhint %}

**Proxykonfigurasjon**

* Sett `OVERLEAF_BEHIND_PROXY=true` (`SHARELATEX_BEHIND_PROXY` for versjoner `4.x` og tidligere) for korrekte klient-IP-er.
* Sett `TRUSTED_PROXY_IPS` til IP-adressen til lastbalansereren (flere CIDR-er kan angis, adskilt med komma).

**Git-bridge-integrasjon**

{% hint style="info" %}
Git-bridge er tilgjengelig i Server Pro fra og med versjon 4.0.1.
{% endhint %}

git-bridge-containeren trenger en søskencontainer av Server Pro for å håndtere innkommende git-forespørsler. Denne søskencontaineren kan også håndtere vanlig brukertrafikk. I eksempelkonfigurasjonen fungerer den første instansen som søskencontainer for git-bridge, men egentlig kunne hvilken som helst instans gjort det.

Hvorfor må vi utpeke én Server Pro-container som søsken for git-bridge? Server Pro deler ut nedlastings-URL-er for historietjenesten til git-bridge. Vi må konfigurere disse historikk-URL-ene slik at de er tilgjengelige fra git-bridge-containeren.

Server Pro-containerkonfigurasjon:

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

  Merk: Dette er bare nødvendig på søskencontaineren for git-bridge-containeren. De andre instansene kan bruke en localhost-URL, som er standard.

git-bridge-containerkonfigurasjon:

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

<details>

<summary>Eksempelkonfigurasjon for docker-compose.yml</summary>

Følgende konfigurasjon viser et selvstendig oppsett. For at demoen skal fungere, må du skaffe en gyldig SSL-nøkkel/-sertifikat og justere `OVERLEAF_SITE_URL` (`SHARELATEX_SITE_URL` for versjoner `4.x` og tidligere). For et faktisk oppsett må du erstatte dummy-hemmelighetene med ekte hemmeligheter som angitt i linjen. For et faktisk oppsett må du flytte de enkelte containerne til dedikerte noder og justere IP-adressene til ditt lokale nettverksoppsett.

```yaml
version: '2.2'

# Faktisk oppsett for horisontal skalering: velg ditt eget nettverk og erstatt IP-ene i konfigurasjonen.
networks:
    default:
        ipam:
            config:
                # Dette subnettet er en del av et reservert subnett brukt til benchmarking
                # https://tools.ietf.org/html/rfc2544
                # Hele subnettet er 198.18.0.0/15
                # Bruk 198.18.0.0/24 for lb og db-er
                # Bruk 198.18.1.0/24 for server-pro
                # Bruk 198.18.0.128/25 for den midlertidige containeren
                - gateway: 198.18.0.1
                  ip_range: 198.18.0.128/25
                  subnet: 198.18.0.0/23

services:
    # Faktisk oppsett for horisontal skalering: kjør haproxy utenfor docker på en separat vert.
    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": bruk vertsnettverk for å unngå overhead fra docker-proxy
        network_mode: host

        # Alternativ til "network_mode: host": bruk docker-proxy for nettverksisolasjon
        # ports:
        #     - "80:80"
        #     - "443:443"
        # networks:
        #     default:
        #         ipv4_address: 198.18.0.2

        # Faktisk oppsett for horisontal skalering: fjern disse ettersom de kjører på andre verter.
        depends_on:
            server-pro-ha-1:
                condition: service_started
            server-pro-ha-2:
                condition: service_started
            server-pro-ha-3:
                condition: service_started

    # Faktisk oppsett for horisontal skalering: kjør denne containeren ved siden av server-pro-ha-1.
    # For Server Pro 4.0 og nyere.
    git-bridge:
        restart: always
        # Taggen bør samsvare med container-taggen for `server-pro-ha-1`.
        image: quay.io/sharelatex/git-bridge:4.0.1
        volumes:
            # Faktisk oppsett for horisontal skalering: pek /data/git-bridge til en dedikert 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 oppsett for horisontal skalering: kjør på vert 198.18.0.6 og eksponer port
        # ports:
        #     - "8000:8000"
        networks:
            default:
                ipv4_address: 198.18.0.6

    # Faktisk oppsett for horisontal skalering: kjør denne containeren på en separat vert.
    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 oppsett for horisontal skalering: behold denne oppføringen.
            git-bridge:
                condition: service_started

            # Faktisk oppsett for horisontal skalering: fjern oppføringene nedenfor ettersom de kjører på andre verter.
            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 oppsett for horisontal skalering: angi ditt eget domene/appnavn.
            OVERLEAF_SITE_URL: 'https://overleaf.example.com'
            OVERLEAF_APP_NAME: Demo for horisontal skalering av Server Pro

            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 oppsett for horisontal skalering: velg sikre påloggingsopplysninger.
            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
            # Trengs bare på søsterinstansen av git-bridge
            V1_HISTORY_URL: "http://server-pro-ha-1:3100/api"
            # /git-bridge

            # Horisontal skalering
            # Faktisk oppsett for horisontal skalering: velg sikre påloggingsopplysninger.
            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 oppsett for horisontal skalering: IP-ene til lastbalansererne
            TRUSTED_PROXY_IPS: 198.18.0.1,198.18.0.2
            # /Horisontal skalering

        # Faktisk oppsett for horisontal skalering: kjør på vert 198.18.1.1 og eksponer porter
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.1

    # Faktisk oppsett for horisontal skalering: kjør denne containeren på en separat vert.
    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 oppsett for horisontal skalering: kjør på vert 198.18.1.2 og eksponer porter
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.2

    # Faktisk oppsett for horisontal skalering: kjør denne containeren på en separat vert.
    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 oppsett for horisontal skalering: kjør på vert 198.18.1.3 og eksponer porter
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.3

    # Faktisk oppsett for horisontal skalering: kjør denne containeren på en separat vert.
    minio:
        image: minio/minio:RELEASE.2023-05-18T00-05-36Z
        container_name: minio
        command: server /data
        volumes:
            # Faktisk oppsett for horisontal skalering: kjør minio med flere disker, se minio-dokumentasjonen.
            - ~/minio_data:/data
        environment:
            # Faktisk oppsett for horisontal skalering: velg sikre påloggingsopplysninger.
            MINIO_ROOT_USER: MINIO_ROOT_USER
            MINIO_ROOT_PASSWORD: MINIO_ROOT_PASSWORD

        # Faktisk oppsett for horisontal skalering: kjør på vert 198.18.0.5 og eksponer port
        # ports:
        #     - "9000:9000"
        networks:
            default:
                ipv4_address: 198.18.0.5

    # Faktisk oppsett for horisontal skalering: kjør dette oppsettet én gang på en egen vert.
    minio_setup:
        depends_on:
            - minio
        image: minio/mc:RELEASE.2023-05-18T16-59-00Z
        entrypoint: sh
        command:
            - '-c'
            # Faktisk oppsett for horisontal skalering: velg sikre påloggingsopplysninger.
            - |
                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

                # Sett inn innholdet i policyen fra forrige seksjon i policy-filestore.json
                # Påminnelse: Erstatt bøttenavnene 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 oppsett for horisontal skalering: kjør denne containeren på en separat vert.
    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 oppsett for horisontal skalering: kjør på vert 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
        command:
            - '-c'
            - |
                mongo 198.18.0.3 --eval "rs.initiate({ _id: \"overleaf\", members: [ { _id: 0, host: \"198.18.0.3:27017\" } ] })"

    # Faktisk oppsett for horisontal skalering: kjør denne containeren på en separat vert.
    redis:
        restart: always
        image: redis:6.2
        container_name: redis
        expose:
            - 6379
        volumes:
            - ~/redis_data:/data

        # Faktisk oppsett for horisontal skalering: kjør på vert 198.18.0.4 og eksponer port
        # ports:
        #     - "6379:6379"
        networks:
            default:
                ipv4_address: 198.18.0.4
```

</details>

#### Maskinvare

Vi anbefaler å bruke de samme maskinvarespesifikasjonene for alle Server Pro-instansene som deltar i horisontal skalering.

De generelle anbefalingene for [maskinvarespesifikasjoner](/on-premises/no/kom-i-gang/requirements/hardware-requirements.md) for Server Pro-instansene gjelder.

#### Oppgradering av Server Pro

Som en del av oppgraderingsprosessen kjører Server Pro automatisk databasemigreringer. Disse migreringene er **ikke** utformet for å kjøres fra flere instanser parallelt.

Migreringene må fullføres før selve webapplikasjonen startes. Du kan enten sjekke loggene for en oppføring med `Migreringer fullført` eller vente til applikasjonen tar imot trafikk.

Oppgraderingsprosedyren ser slik ut:

1. Planlegg et vedlikeholdsvindu
2. Stopp alle instansene av Server Pro
3. Ta en konsistent sikkerhetskopi som beskrevet i [dokumentasjonen](/on-premises/no/vedlikehold/data-and-backups.md#performing-a-consistent-backup)
4. Start én Server Pro-instans med den nye versjonen
5. Kontroller at den nye instansen fungerer som forventet
6. Start de andre instansene med den nye versjonen


---

# 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/no/vedlikehold/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.