> 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/sv/underhall/horizontal-scaling.md).

# Horisontell skalning

Från och med version 3.5.6 stöder Server Pro horisontell skalning.

Detta dokument listar de tekniska kraven och ger riktlinjer för att köra Server Pro i fler än en nod.

{% hint style="danger" %}
Från och med Server CE/Server Pro `5.0.3` miljövariabler har bytt namn från `SHARELATEX_*` till `OVERLEAF_*`.

Om du använder en `4.x` version (eller tidigare) ska du se till att variablerna har rätt prefix (t.ex. `SHARELATEX_SITE_URL` i stället för `OVERLEAF_SITE_URL`)
{% endhint %}

Att konfigurera horisontell skalning kräver en betydande insats. Vi rekommenderar att överväga horisontell skalning **endast** när en viss skala uppnås. Som exempel har en Server Pro-installation för totalt 1 000 användare konfigurerats framgångsrikt med en enda server utrustad med två 4-kärniga processorer och 32 GB systemminne. Se [hårdvarukraven](/on-premises/sv/komma-igang/requirements/hardware-requirements.md) dokumentationen för rekommendationer.

En driftsättning av Server Pro med horisontell skalning omfattar ett antal externa komponenter, såsom en lastbalanserare och en S3-kompatibel lagringsbackend.

Vi kan hjälpa till att felsöka fel i Server Pro-containrarna som kan bero på felkonfiguration och ge allmänna råd baserat på detta dokument. Tyvärr kan vi inte ge hjälp med att konfigurera tredjepartsprogram/-system.

Att lösa tekniska problem som är specifika för din hårdvara/mjukvara, förutsatt att de externa komponenterna tillhandahålls, omfattas inte av våra supportvillkor.

### Krav

#### Extern, central datalagring

Datalagringen i Server Pro kan delas upp i fyra datalager:

* **MongoDB**

  * Det mesta av datan lagras i MongoDB.
  * Vi stöder antingen en lokal instans eller en extern instans, såsom [MongoDB](https://www.mongodb.com/atlas) Atlas (en helt hanterad MongoDB-tjänst som körs inom AWS-infrastrukturen).<br>

  **Obs:** Tyvärr finns det för närvarande inget officiellt stöd för MongoDB-kompatibla databaser såsom CosmoDB/DocumentDB, eftersom vi inte har testat Server Pro med dem. Även om det kan **kan** vara möjligt att driftsätta Server Pro med kompatibla databaser, stöder vi endast officiellt driftsättningar som använder MongoDB.<br>
* **Redis**

  * Redis lagrar temporär data, såsom väntande dokumentuppdateringar innan de skrivs till MongoDB.
  * Redis används för att kommunicera dokumentuppdateringar mellan olika tjänster och för att meddela redigeraren om tillståndsändringar i ett givet projekt.
  * Redis används för att lagra användarsessionerna.
  * Vi stöder antingen en lokal instans eller en extern instans.<br>

  **Obs:** Tyvärr finns det för närvarande inget officiellt stöd för Redis-kompatibla nyckel-/värdelager såsom KeyDB/Valkey, eftersom vi inte har testat Server Pro med dem. Även om det kan **kan** vara möjligt att driftsätta Server Pro med kompatibla lager, stöder vi endast officiellt driftsättningar som använder Redis.<br>
* **Projektfiler och historikfiler**

  * Icke-redigerbara projektfiler lagras utanför MongoDB.

    Det nya systemet för projekthistorik (från och med Server Pro 3.5) lagrar även historiken utanför MongoDB.
  * För små enskilda instanser stöder vi antingen ett lokalt filsystem (som kan stödjas av en lokal SSD, NFS eller EBS) eller ett [S3-kompatibelt datalagringssystem](/on-premises/sv/konfiguration/overleaf-toolkit/s3.md).
  * För horisontell skalning **endast** stöder vi S3-kompatibla datalagringssystem.<br>

  **Viktigt:** NFS/Amazon EFS/Amazon EBS är **inte** stöds för horisontell skalning. Se [lagringshårdvarans](/on-premises/sv/komma-igang/requirements/hardware-requirements.md#storage) kravavsnittet om att skala lagring i Server Pro för mer information.
* **Tillfälliga filer**
  * LaTeX-kompileringar måste köras på snabba, lokala diskar för optimal prestanda. Kompileringens utdata behöver inte lagras permanent eller säkerhetskopieras.
  * Buffring av nya filuppladdningar och skapandet av projekt-zipfiler gynnas också av att använda en lokal disk.

{% hint style="danger" %}
Vi rekommenderar starkt att använda en lokal disk. Att använda någon typ av nätverksdisk (såsom NFS eller EBS) kan leda till oväntade kompileringsfel och andra prestandaproblem.
{% endhint %}

#### **Git-bridge**

{% hint style="info" %}
Git-bridge finns tillgängligt i Server Pro från och med version 4.0.1.
{% endhint %}

Git-repositorierna lagras lokalt på disk. Det finns inga replikeringsalternativ tillgängliga. Git-bridge bör köras som en **singleton**. För optimal prestanda rekommenderar vi att använda en lokal disk för git-bridge-data. Git-bridge-datadisken bör säkerhetskopieras regelbundet.

För datalagring med horisontell skalning behöver du:

* en central MongoDB-instans som är åtkomlig från alla Server Pro-instanser
* en central Redis-instans som är åtkomlig från alla Server Pro-instanser
* en central S3-kompatibel lagringsbackend för projekt- och historikfiler
* en lokal disk på varje instans för tillfälliga filer
* en lokal disk på instansen som hostar git-bridge-containern för git-bridge-data

#### Krav på lastbalanserare

* **Beständig routning**, t.ex. med hjälp av en cookie

  Detta krav härrör från följande komponenter:

  * Server Pros redigeringsfunktion i realtid använder WebSockets med fallback till XHR-polling. Varje redigeringssession har lokalt tillstånd på serversidan och begäran från en given redigeringssession måste alltid routas till samma Server Pro-instans. Samarbetsfunktionen använder Redis [Pub/Sub](https://redis.io/docs/latest/develop/interact/pubsub/) för att dela uppdateringar mellan flera Server Pro-instanser.
  * LaTeX-kompileringen håller utdata och kompileringscachen lokalt för optimal prestanda. När en kompileringsbegäran skickas till en Server Pro-instans måste följande PDF-/loggnedladdningsbegäran routas till samma Server Pro-instans.
* **Långa timeouttider för begäran** för att stödja kompilering av stora LaTeX-dokument
* **WebSocket-stöd** för optimal prestanda
* **POST-payloadstorlek på 50 MB**
* **Keep-alive-timeout** måste vara lägre än Server Pro:s keep-alive-timeout

  Keep-alive-timeout i Server Pro kan konfigureras med hjälp av miljövariabeln `NGINX_KEEPALIVE_TIMEOUT`. Standardvärdet är 65 s.

  Med standardvärdet fungerar en keep-alive-timeout på 60 s i lastbalanseraren.

  Med `NGINX_KEEPALIVE_TIMEOUT=120`kan lastbalanseraren välja 115 s.
* **Klient-IP-adresser**

  Ange begärandehuvudet `X-Forwarded-For` till klientens IP-adress.
* När **SSL-avslut**

  Lastbalanseraren behöver lägga till begärandehuvudet `X-Forwarded-Proto: https`.

<details>

<summary>Exempelkonfiguration för HAProxy</summary>

```
global
  group haproxy
  user haproxy

  # Utförlig loggning
  log stdout format raw local0 debug

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

  # Utförlig loggning
  log                     global
  option                  httplog

  # Omdirigera till en annan backend om den sticky sessionen är nere
  option                  redispatch 1
  # Dessa omförsök gäller TCP-anslutningsfel, inte HTTP-svar med status 500
  retries                 3

  # Sticky-session i 24 timmars inaktivitet -- kompileringsutdata tas bort efter 24 h
  cookie                  server-pro-ha insert maxidle 24h

  # Försök ansluta till valfri backend i 1 min, returnera sedan 503
  timeout queue           1m
  # Ge Server Pro-instanser 15 s att starta
  timeout connect         15s

  # Avbryt begäran från mycket långsamma klienter (tillåt 1 min inaktivitet vid läsning av en begäran)
  timeout client          1m

  # Tillåt långsamma kompileringar -- hårdkodad gräns i clsi är 10 min
  timeout server          10m

  # Koppla från redigeraren efter 23 h -- 1 h före gårdagens senaste användning
  timeout tunnel          23h

  # Obs: Keepalive-beteendet i haproxy fungerar utmärkt med standardinställningen för keepalive i Server Pro.
  #       Haproxy städar upp anslutningar i bakgrunden och kommer att omdirigera begäran vid 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

  # Tala om för applikationen att vi ligger bakom https
  http-request set-header X-Forwarded-Proto https

  # Tala om för applikationen den faktiska klient-IP-adressen
  option forwardfor

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

  # Routa git-trafik till syskoncontainern till git-bridge
  use-server server-pro-ha-1 if { path_beg /git/ }

  # Felsökning
  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

**Hemligheter**

Server Pro-instanserna måste vara överens om delade hemligheter:

* `WEB_API_PASSWORD` (autentisering för webb-API)
* `STAGING_PASSWORD` och `V1_HISTORY_PASSWORD` samma värde (historikautentisering)
* `CRYPTO_RANDOM` (för sessionscookie)
* `OT_JWT_AUTH_KEY` (historikautentisering)

Alla dessa hemligheter måste konfigureras med egna unika värden och delas mellan instanserna.

Om detta inte konfigureras och användarbegäran routas till olika Server Pro-instanser kommer deras begäran att misslyckas i autentiseringskontrollerna och de kommer antingen att ofta skickas vidare till inloggningssidan eller så kommer deras åtgärder i användargränssnittet att misslyckas på oväntade sätt.

Om detta inte konfigureras använder Server Pro ett nytt slumpmässigt värde för varje hemlighet baserat på 32 slumpmässiga byte från `/dev/urandom` (256 slumpmässiga bitar).

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

Peka `OVERLEAF_MONGO_URL` (`SHARELATEX_MONGO_URL` för versioner `4.x` och tidigare) till den centrala MongoDB-instansen.

**Redis**

Peka `OVERLEAF_REDIS_HOST` (`SHARELATEX_REDIS_HOST` för versioner `4.x` och tidigare) och `REDIS_HOST` till den centrala Redis-instansen.

**S3-kompatibel lagring för projekt- och historikfiler**

Se dokumentationen om [S3-kompatibel lagring](/on-premises/sv/konfiguration/overleaf-toolkit/s3.md) för detaljer.

**Tillfälliga filer**

Standardmonteringen av en lokal SSD till `/var/lib/overleaf` (`/var/lib/sharelatex` för versioner `4.x` och tidigare) kommer att räcka. Se till att peka `SANDBOXED_COMPILES_HOST_DIR` på monteringspunkten på värden.

{% hint style="danger" %}
Vi rekommenderar starkt att använda en lokal disk. Att använda någon typ av nätverksdisk (såsom NFS eller EBS) kan leda till oväntade kompileringsfel och andra prestandaproblem.
{% endhint %}

**Proxykonfiguration**

* Ställ in `OVERLEAF_BEHIND_PROXY=true` (`SHARELATEX_BEHIND_PROXY` för versioner `4.x` och tidigare) för korrekta klient-IP-adresser.
* Ställ in `TRUSTED_PROXY_IPS` till lastbalanserarens IP-adress (flera CIDR-intervall kan anges, separerade med komma).

**Integration med Git-bridge**

{% hint style="info" %}
Git-bridge finns tillgängligt i Server Pro från och med version 4.0.1.
{% endhint %}

git-bridge-containern behöver en syskoncontainer för Server Pro för att hantera inkommande git-begäran. Denna syskoncontainer kan även betjäna vanlig användartrafik. I exempelkonfigurationen fungerar den första instansen som syskoncontainer för git-bridge, men egentligen skulle vilken instans som helst kunna göra det.

Varför behöver vi utse en Server Pro-container som syskon för git-bridge? Server Pro ger nedladdnings-URL:er för historiktjänsten till git-bridge. Vi behöver konfigurera dessa historik-URL:er så att de är åtkomliga från git-bridge-containern.

Konfiguration för Server Pro-containern:

* Ställ in `GIT_BRIDGE_ENABLED` till `'true'`
* Ställ in `GIT_BRIDGE_HOST` till `<git-bridge container name>` t.ex. `git-bridge`
* Ställ in `GIT_BRIDGE_PORT` till `8000`
* Ställ in `V1_HISTORY_URL` till `http://<server-pro sibling container name>:3100/api`.

  Obs: Detta behövs endast på syskoncontainern för git-bridge-containern. De andra instanserna kan använda en localhost-URL, vilket är standard.

Konfiguration för git-bridge-containern:

* Ställ in `GIT_BRIDGE_API_BASE_URL` till `http://<server-pro sibling container name>/api/v0`, t.ex. `http://server-pro-ha-1/api/v0`
* Ställ in `GIT_BRIDGE_OAUTH2_SERVER` till `http://<server-pro sibling container name>`, t.ex. `http://server-pro-ha-1`
* Ställ in `GIT_BRIDGE_POSTBACK_BASE_URL` till `http://<git-bridge container name>:8000`, t.ex. `http://git-bridge:8000`
* Ställ in `GIT_BRIDGE_ROOT_DIR` till den bind-monterade git-bridge-datadisken, t.ex. `/data/git-bridge`

<details>

<summary>Exempelkonfiguration för docker-compose.yml</summary>

Följande konfiguration visar en fristående installation. För att demon ska fungera behöver du tillhandahålla en giltig SSL-nyckel/certifikat och justera `OVERLEAF_SITE_URL` (`SHARELATEX_SITE_URL` för versioner `4.x` och tidigare). För en faktisk installation måste du ersätta platshållarhemligheterna med riktiga hemligheter enligt anmärkningarna i texten. För en faktisk installation måste du flytta de enskilda containrarna till dedikerade noder och justera IP-adresserna efter din lokala nätverkskonfiguration.

```yaml
version: '2.2'

# Faktisk installation med horisontell skalning: välj ditt eget nätverk och ersätt IP-adresserna i konfigurationen.
networks:
    default:
        ipam:
            config:
                # Detta subnät är en del av ett reserverat subnät som används för benchmarking
                # https://tools.ietf.org/html/rfc2544
                # Det fulla subnätet är 198.18.0.0/15
                # Använd 198.18.0.0/24 för lb och dbs
                # Använd 198.18.1.0/24 för server-pro
                # Använd 198.18.0.128/25 för den tillfälliga containern
                - gateway: 198.18.0.1
                  ip_range: 198.18.0.128/25
                  subnet: 198.18.0.0/23

services:
    # Faktisk installation med horisontell skalning: kör haproxy utanför Docker på en separat värd.
    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 till "ports": använd värdnätverk för att undvika docker-proxy-overhead
        network_mode: host

        # Alternativ till "network_mode: host": använd docker-proxy för nätverksisolering
        # ports:
        #     - "80:80"
        #     - "443:443"
        # networks:
        #     default:
        #         ipv4_address: 198.18.0.2

        # Faktisk installation med horisontell skalning: ta bort dessa eftersom de körs på andra värdar.
        depends_on:
            server-pro-ha-1:
                condition: service_started
            server-pro-ha-2:
                condition: service_started
            server-pro-ha-3:
                condition: service_started

    # Faktisk installation med horisontell skalning: kör den här containern bredvid server-pro-ha-1.
    # Från och med Server Pro 4.0.
    git-bridge:
        restart: always
        # Taggen ska matcha containertaggen för `server-pro-ha-1`.
        image: quay.io/sharelatex/git-bridge:4.0.1
        volumes:
            # Faktisk installation med horisontell skalning: peka /data/git-bridge på en dedikerad 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 installation med horisontell skalning: kör på värd 198.18.0.6 och exponera port
        # ports:
        #     - "8000:8000"
        networks:
            default:
                ipv4_address: 198.18.0.6

    # Faktisk installation med horisontell skalning: kör den här containern på en separat värd.
    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 installation med horisontell skalning: behåll denna post.
            git-bridge:
                condition: service_started

            # Faktisk installation med horisontell skalning: ta bort raderna nedan eftersom de körs på andra värdar.
            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 installation med horisontell skalning: ange din egen domän/applikationsnamn.
            OVERLEAF_SITE_URL: 'https://overleaf.example.com'
            OVERLEAF_APP_NAME: Server Pro-demo för horisontell skalning

            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 installation med horisontell skalning: välj säkra inloggningsuppgifter.
            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
            # Behövs bara på syskoninstansen av git-bridge
            V1_HISTORY_URL: "http://server-pro-ha-1:3100/api"
            # /git-bridge

            # Horisontell skalning
            # Faktisk installation med horisontell skalning: välj säkra inloggningsuppgifter.
            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 konfiguration för horisontell skalning: IP-adresser för lastbalanserare
            TRUSTED_PROXY_IPS: 198.18.0.1,198.18.0.2
            # /Horisontell skalning

        # Faktisk konfiguration för horisontell skalning: kör på värd 198.18.1.1 och exponera portar
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.1

    # Faktisk installation med horisontell skalning: kör den här containern på en separat värd.
    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 konfiguration för horisontell skalning: kör på värd 198.18.1.2 och exponera portar
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.2

    # Faktisk installation med horisontell skalning: kör den här containern på en separat värd.
    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 konfiguration för horisontell skalning: kör på värd 198.18.1.3 och exponera portar
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.3

    # Faktisk installation med horisontell skalning: kör den här containern på en separat värd.
    minio:
        image: minio/minio:RELEASE.2023-05-18T00-05-36Z
        container_name: minio
        command: server /data
        volumes:
            # Faktisk konfiguration för horisontell skalning: kör minio med flera diskar, se minios dokumentation.
            - ~/minio_data:/data
        environment:
            # Faktisk installation med horisontell skalning: välj säkra inloggningsuppgifter.
            MINIO_ROOT_USER: MINIO_ROOT_USER
            MINIO_ROOT_PASSWORD: MINIO_ROOT_PASSWORD

        # Faktisk konfiguration för horisontell skalning: kör på värd 198.18.0.5 och exponera port
        # ports:
        #     - "9000:9000"
        networks:
            default:
                ipv4_address: 198.18.0.5

    # Faktisk konfiguration för horisontell skalning: kör denna konfiguration en gång på en separat värd.
    minio_setup:
        depends_on:
            - minio
        image: minio/mc:RELEASE.2023-05-18T16-59-00Z
        entrypoint: sh
        kommandot:
            - '-c'
            # Faktisk installation med horisontell skalning: välj säkra inloggningsuppgifter.
            - |
                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ägg innehållet i policyn från föregående avsnitt i policy-filestore.json
                # Påminnelse: ersätt bucketnamnen i enlighet med detta.
                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 installation med horisontell skalning: kör den här containern på en separat värd.
    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 konfiguration för horisontell skalning: kör på värd 198.18.0.3 och exponera 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
        kommandot:
            - '-c'
            - |
                mongo 198.18.0.3 --eval "rs.initiate({ _id: \"overleaf\", members: [ { _id: 0, host: \"198.18.0.3:27017\" } ] })"

    # Faktisk installation med horisontell skalning: kör den här containern på en separat värd.
    redis:
        restart: always
        image: redis:6.2
        container_name: redis
        expose:
            - 6379
        volumes:
            - ~/redis_data:/data

        # Faktisk konfiguration för horisontell skalning: kör på värd 198.18.0.4 och exponera port
        # ports:
        #     - "6379:6379"
        networks:
            default:
                ipv4_address: 198.18.0.4
```

</details>

#### Hårdvara

Vi rekommenderar att använda samma hårdvaruspecifikationer för alla Server Pro-instansar som deltar i horisontell skalning.

De allmänna rekommendationerna om [hårdvaruspecifikationer](/on-premises/sv/komma-igang/requirements/hardware-requirements.md) för Server Pro-instansar gäller.

#### Uppgradering av Server Pro

Som en del av uppgraderingsprocessen kör Server Pro automatiskt databasmigreringar. Dessa migreringar är **inte** utformade för att köras från flera instanser parallellt.

Migreringarna måste vara klara innan själva webbapplikationen startas. Du kan antingen kontrollera loggarna efter en rad med `Migreringarna slutförda` eller vänta tills applikationen tar emot trafik.

Uppgraderingsproceduren ser ut så här:

1. Schemalägg ett underhållsfönster
2. Stoppa alla Server Pro-instansar
3. Ta en konsekvent säkerhetskopia enligt [dokumentationen](/on-premises/sv/underhall/data-and-backups.md#performing-a-consistent-backup)
4. Starta en enda Server Pro-instans med den nya versionen
5. Verifiera att den nya instansen fungerar som förväntat
6. Starta upp de andra instanserna med den nya versionen


---

# 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/sv/underhall/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.