> ## Documentation Index
> Fetch the complete documentation index at: https://ayakaleaf-pro.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Scalabilità orizzontale

<Check>
  Ayakaleaf Pro supporta la scalabilità orizzontale. Abbiamo testato e verificato che funziona correttamente con più repliche.
</Check>

Questo documento elenca i requisiti tecnici e fornisce linee guida per eseguire Ayakaleaf Pro su più di un nodo.

<Danger>
  A partire da Server CE/Server Pro `5.0.3`, le variabili d'ambiente sono state rinominate da `SHARELATEX_*` a `OVERLEAF_*`.

  Se utilizzi una versione `4.x` (o precedente), assicurati che le variabili abbiano il prefisso corretto (ad es. `SHARELATEX_SITE_URL` invece di `OVERLEAF_SITE_URL`)
</Danger>

La configurazione della scalabilità orizzontale richiede uno sforzo considerevole. Ti consigliamo di prendere in considerazione la scalabilità orizzontale **solo** al raggiungimento di una certa scala. Ad esempio, un'installazione di Server Pro per 1.000 utenti totali è stata configurata con successo utilizzando un singolo server dotato di due processori a 4 core e 32GB di memoria di sistema. Consulta la documentazione sui [requisiti hardware](/it/on-premises/getting-started/requirements/hardware-requirements) per le raccomandazioni.

Un'installazione di Server Pro con scalabilità orizzontale richiede un insieme di componenti esterni, come un load balancer e un backend di storage compatibile con S3.

Possiamo aiutarti a risolvere gli errori nei container di Server Pro che potrebbero derivare da una configurazione errata e fornire consigli generali basati su questo documento. Purtroppo non siamo in grado di fornire assistenza nella configurazione di applicazioni/sistemi di terze parti.

La risoluzione di problemi tecnici specifici del tuo hardware/software per la fornitura dei componenti esterni non è coperta dai nostri termini di supporto.

### Requisiti

<Frame>
  <img src="https://mintcdn.com/ayakaleaf-pro/GmaXa-Cu4QQRFT4C/images/on-premises/img-f045c922.jpg?fit=max&auto=format&n=GmaXa-Cu4QQRFT4C&q=85&s=fc2eadc84a202a5ad07dd34ca6f903d4" alt="" width="2617" height="2319" data-path="images/on-premises/img-f045c922.jpg" />
</Frame>

#### Storage dei dati esterno e centralizzato

Lo storage dei dati in Server Pro può essere suddiviso in quattro archivi:

* **MongoDB**

  * La maggior parte dei dati viene resa persistente in MongoDB.
  * Supportiamo sia un'istanza locale sia un'istanza esterna, come [MongoDB](https://www.mongodb.com/atlas) Atlas (un servizio MongoDB completamente gestito che gira all'interno dell'infrastruttura AWS).<br />

  <strong>Nota:</strong> purtroppo al momento non esiste un supporto ufficiale per database compatibili con MongoDB come CosmoDB/DocumentDB, poiché non abbiamo testato Server Pro con essi. Sebbene installare Server Pro con database compatibili **possa** essere possibile, supportiamo ufficialmente solo le installazioni che utilizzano MongoDB.<br />
* **Redis**

  * Redis memorizza dati temporanei, come gli aggiornamenti dei documenti in sospeso prima che vengano scritti in MongoDB.
  * Redis viene utilizzato per comunicare gli aggiornamenti dei documenti tra i diversi servizi e per notificare all'editor i cambiamenti di stato in un determinato progetto.
  * Redis viene utilizzato per memorizzare le sessioni utente.
  * Supportiamo sia un'istanza locale sia un'istanza esterna.<br />

  <strong>Nota:</strong> purtroppo al momento non esiste un supporto ufficiale per key/value store compatibili con Redis come KeyDB/Valkey, poiché non abbiamo testato Server Pro con essi. Sebbene installare Server Pro con store compatibili **possa** essere possibile, supportiamo ufficialmente solo le installazioni che utilizzano Redis.<br />
* **File dei progetti e file della cronologia**

  * I file di progetto non modificabili sono memorizzati al di fuori di MongoDB.

    Anche il nuovo sistema di cronologia dei progetti (da Server Pro 3.5 in poi) memorizza la cronologia al di fuori di MongoDB.
  * Per piccole istanze singole supportiamo sia un file system locale (che potrebbe essere basato su un SSD locale, NFS o EBS) sia un [sistema di storage dei dati compatibile con S3](/it/on-premises/configuration/overleaf-toolkit/s3).
  * Per la scalabilità orizzontale supportiamo **solo** sistemi di storage dei dati compatibili con S3.<br />

  <strong>Importante:</strong> NFS/Amazon EFS/Amazon EBS **non** sono supportati per la scalabilità orizzontale. Consulta la sezione sui requisiti di [storage hardware](/it/on-premises/getting-started/requirements/hardware-requirements#storage) relativa alla scalabilità dello storage in Server Pro per maggiori dettagli.
* **File effimeri**
  * Le compilazioni LaTeX devono essere eseguite su dischi locali veloci per prestazioni ottimali. L'output della compilazione non deve essere reso persistente né sottoposto a backup.
  * Anche il buffering dei nuovi caricamenti di file e la creazione dei file zip dei progetti traggono vantaggio dall'uso di un disco locale.

<Danger>
  Ti consigliamo vivamente di utilizzare un disco locale. L'uso di qualsiasi tipo di disco di rete (come NFS o EBS) può causare errori di compilazione imprevisti e altri problemi di prestazioni.
</Danger>

#### **Git-bridge**

<Info>
  Git-bridge è disponibile in Server Pro a partire dalla versione 4.0.1.
</Info>

I repository git sono memorizzati localmente su disco. Non sono disponibili opzioni di replica. Git-bridge deve essere eseguito come **singleton**. Per prestazioni ottimali, ti consigliamo di utilizzare un disco locale per i dati di git-bridge. Il disco dei dati di git-bridge deve essere sottoposto regolarmente a backup.

Per lo storage dei dati con scalabilità orizzontale, hai bisogno di:

* un'istanza MongoDB centrale accessibile da tutte le istanze di Server Pro
* un'istanza Redis centrale accessibile da tutte le istanze di Server Pro
* un backend di storage centrale compatibile con S3 per i file dei progetti e della cronologia
* un disco locale su ogni istanza per i file effimeri
* un disco locale sull'istanza che ospita il container git-bridge per i dati di git-bridge

#### Requisiti del load balancer

* **Instradamento persistente**, ad es. tramite un cookie

  Questo requisito deriva dai seguenti componenti:

  * La funzionalità di modifica in tempo reale di Server Pro utilizza i WebSocket con fallback al polling XHR. Ogni sessione di modifica ha uno stato locale lato server e le richieste di una data sessione di modifica devono sempre essere instradate alla stessa istanza di Server Pro. La funzionalità di collaborazione utilizza il [Pub/Sub](https://redis.io/docs/latest/develop/interact/pubsub/) di Redis per condividere gli aggiornamenti tra più istanze di Server Pro.
  * La compilazione LaTeX conserva localmente l'output e la cache di compilazione per prestazioni ottimali. Dopo l'invio di una richiesta di compilazione a un'istanza di Server Pro, le successive richieste di download del PDF/log devono essere instradate alla stessa istanza di Server Pro.
* **Timeout delle richieste lunghi** per supportare la compilazione di documenti LaTeX di grandi dimensioni
* **Supporto WebSocket** per prestazioni ottimali
* **Dimensione del payload POST di 50MB**
* Il **timeout keep-alive** deve essere inferiore al timeout keep-alive di Server Pro

  Il timeout keep-alive in Server Pro può essere configurato con la variabile d'ambiente `NGINX_KEEPALIVE_TIMEOUT`. Il valore predefinito è 65s.

  Con il valore predefinito, un timeout keep-alive di 60s nel load balancer funziona.

  Con `NGINX_KEEPALIVE_TIMEOUT=120`, il load balancer potrebbe usare 115s.
* **IP dei client**

  Imposta l'header di richiesta `X-Forwarded-For` sull'IP del client.
* Quando si effettua la **terminazione SSL**

  Il load balancer deve aggiungere l'header di richiesta `X-Forwarded-Proto: https`.

<Accordion title="Configurazione HAProxy di esempio">
  ```text theme={null}
  global
    group haproxy
    user haproxy

    # Verbose logging
    log stdout format raw local0 debug

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

    # Verbose logging
    log                     global
    option                  httplog

    # Reroute to a different backend if the sticky one is down
    option                  redispatch 1
    # These retries are for TCP connect errors, not on HTTP status 500 responses
    retries                 3

    # Sticky session for 24h of inactivity -- compile output is deleted after 24h
    cookie                  server-pro-ha insert maxidle 24h

    # Try to connect to any backend for 1min, then return 503
    timeout queue           1m
    # Give Server Pro instances 15s to startup
    timeout connect         15s

    # Abort requests from very slow clients (allow 1min of inactivity when reading a request)
    timeout client          1m

    # Allow slow compiles -- hard-coded limit in clsi is 10min
    timeout server          10m

    # Disconnect the editor after 23h -- 1h ahead of their last use yesterday
    timeout tunnel          23h

    # Note: The keepalive behavior in haproxy works great with the default keepalive setup in Server Pro.
    #       Haproxy is cleaning up connections in the background and it will redispatch requests when needed.

  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

    # Tell the application that we are behind https
    http-request set-header X-Forwarded-Proto https

    # Tell the application the actual client ip
    option forwardfor

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

    # Route git traffic to the sibling container of the git-bridge
    use-server server-pro-ha-1 if { path_beg /git/ }

    # Debugging
    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
  ```
</Accordion>

#### Configurazione di Server Pro

**Segreti**

Le istanze di Server Pro devono condividere gli stessi segreti:

* `WEB_API_PASSWORD` (autenticazione web api)
* `STAGING_PASSWORD` e `V1_HISTORY_PASSWORD` con lo stesso valore (autenticazione della cronologia)
* `CRYPTO_RANDOM` (per il cookie di sessione)
* `OT_JWT_AUTH_KEY` (autenticazione della cronologia)

Ciascuno di questi segreti deve essere configurato con un proprio valore univoco e condiviso tra le istanze.

Se non sono configurati e le richieste degli utenti vengono instradate a istanze di Server Pro diverse, le loro richieste non supereranno i controlli di autenticazione e gli utenti verranno reindirizzati frequentemente alla pagina di accesso oppure le loro azioni nell'interfaccia falliranno in modi imprevisti.

Se non sono configurati, Server Pro utilizza un nuovo valore casuale per ciascun segreto, basato su 32 byte casuali da `/dev/urandom` (256 bit casuali).

```bash wrap theme={null}
# 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+/'
```

**MongoDB**

Punta `OVERLEAF_MONGO_URL` (`SHARELATEX_MONGO_URL` per le versioni `4.x` e precedenti) all'istanza MongoDB centrale.

**Redis**

Punta `OVERLEAF_REDIS_HOST` (`SHARELATEX_REDIS_HOST` per le versioni `4.x` e precedenti) e `REDIS_HOST` all'istanza Redis centrale.

**Storage compatibile con S3 per i file dei progetti e della cronologia**

Consulta la documentazione sullo [storage compatibile con S3](/it/on-premises/configuration/overleaf-toolkit/s3) per i dettagli.

**File effimeri**

Il bind-mount predefinito di un SSD locale su `/var/lib/overleaf` (`/var/lib/sharelatex` per le versioni `4.x` e precedenti) sarà sufficiente. Assicurati di puntare `SANDBOXED_COMPILES_HOST_DIR` al punto di mount sull'host.

<Danger>
  Ti consigliamo vivamente di utilizzare un disco locale. L'uso di qualsiasi tipo di disco di rete (come NFS o EBS) può causare errori di compilazione imprevisti e altri problemi di prestazioni.
</Danger>

**Configurazione del proxy**

* Imposta `OVERLEAF_BEHIND_PROXY=true` (`SHARELATEX_BEHIND_PROXY` per le versioni `4.x` e precedenti) per ottenere IP dei client accurati.
* Imposta `TRUSTED_PROXY_IPS` sull'IP del load balancer (è possibile specificare più CIDR, separati da una virgola).

**Integrazione Git-bridge**

<Info>
  Git-bridge è disponibile in Server Pro a partire dalla versione 4.0.1.
</Info>

Il container git-bridge necessita di un container Server Pro "gemello" per gestire le richieste git in arrivo. Questo container gemello può servire anche il normale traffico degli utenti. Nella configurazione di esempio, la prima istanza funge da container gemello per git-bridge, ma in realtà qualsiasi istanza potrebbe svolgere questo ruolo.

Perché dobbiamo designare un container Server Pro come gemello per git-bridge? Server Pro fornisce a git-bridge gli URL di download del servizio di cronologia. Dobbiamo configurare questi URL della cronologia in modo che siano accessibili dal container git-bridge.

Configurazione del container Server Pro:

* Imposta `GIT_BRIDGE_ENABLED` su `'true'`
* Imposta `GIT_BRIDGE_HOST` su `<git-bridge container name>`, ad es. `git-bridge`
* Imposta `GIT_BRIDGE_PORT` su `8000`
* Imposta `V1_HISTORY_URL` su `http://<server-pro sibling container name>:3100/api`.

  Nota: questo è necessario solo sul container gemello del container git-bridge. Le altre istanze possono usare un URL localhost, che è il valore predefinito.

Configurazione del container git-bridge:

* Imposta `GIT_BRIDGE_API_BASE_URL` su `http://<server-pro sibling container name>/api/v0`, ad es. `http://server-pro-ha-1/api/v0`
* Imposta `GIT_BRIDGE_OAUTH2_SERVER` su `http://<server-pro sibling container name>`, ad es. `http://server-pro-ha-1`
* Imposta `GIT_BRIDGE_POSTBACK_BASE_URL` su `http://<git-bridge container name>:8000`, ad es. `http://git-bridge:8000`
* Imposta `GIT_BRIDGE_ROOT_DIR` sul disco dei dati di git-bridge montato tramite bind-mount, ad es. `/data/git-bridge`

<Accordion title="Configurazione docker-compose.yml di esempio">
  La seguente configurazione mostra un setup autonomo. Perché la demo funzioni, devi fornire una chiave/certificato SSL valido e adattare `OVERLEAF_SITE_URL` (`SHARELATEX_SITE_URL` per le versioni `4.x` e precedenti). Per un setup reale, devi sostituire i segreti fittizi con segreti reali, come indicato nei commenti. Per un setup reale, devi spostare i singoli container su nodi dedicati e adattare gli indirizzi IP alla configurazione della tua rete locale.

  ```yaml theme={null}
  version: '2.2'

  # Actual horizontal scaling setup: pick your own network and replace IPs in config.
  networks:
      default:
          ipam:
              config:
                  # This subnet is part of a reserved subnet used for benchmarking
                  # https://tools.ietf.org/html/rfc2544
                  # The full subnet is 198.18.0.0/15
                  # Use 198.18.0.0/24 for lb and dbs
                  # Use 198.18.1.0/24 for server-pro
                  # Use 198.18.0.128/25 for ephemeral container
                  - gateway: 198.18.0.1
                    ip_range: 198.18.0.128/25
                    subnet: 198.18.0.0/23

  services:
      # Actual horizontal scaling setup: run haproxy outside docker on a separate host.
      lb:
          image: haproxy:2.6
          container_name: lb
          user: root
          logging:
              driver: local
              options:
                  max-size: 10g
                  max-file: '100'
          volumes:
              - ./haproxy.conf:/usr/local/etc/haproxy/haproxy.cfg
              # $ cat certificate.pem key.pem > ssl-key-and-certificate-bundle.pem
              - /path/to/ssl-key-and-certificate-bundle.pem:/etc/ssl/certs/ssl-key-and-certificate-bundle.pem
          # Alternative to "ports": use host network to avoid docker-proxy overhead
          network_mode: host

          # Alternative to "network_mode: host": use docker-proxy for network isolation
          # ports:
          #     - "80:80"
          #     - "443:443"
          # networks:
          #     default:
          #         ipv4_address: 198.18.0.2

          # Actual horizontal scaling setup: remove these as they run on other hosts.
          depends_on:
              server-pro-ha-1:
                  condition: service_started
              server-pro-ha-2:
                  condition: service_started
              server-pro-ha-3:
                  condition: service_started

      # Actual horizontal scaling setup: run this container next to server-pro-ha-1.
      # For Server Pro 4.0 onwards.
      git-bridge:
          restart: always
          # The tag should match the `server-pro-ha-1` container tag.
          image: quay.io/sharelatex/git-bridge:4.0.1
          volumes:
              # Actual horizontal scaling setup: point /data/git-bridge at a dedicated local 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"]

          # Actual horizontal scaling setup: run on host 198.18.0.6 and expose port
          # ports:
          #     - "8000:8000"
          networks:
              default:
                  ipv4_address: 198.18.0.6

      # Actual horizontal scaling setup: run this container on a separate host.
      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:
              # Actual horizontal scaling setup: keep this entry.
              git-bridge:
                  condition: service_started

              # Actual horizontal scaling setup: remove the ones below as they run on other hosts.
              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
              # Actual horizontal scaling setup: provide your own domain/app name.
              OVERLEAF_SITE_URL: 'https://overleaf.example.com'
              OVERLEAF_APP_NAME: Server Pro Horizontal Scaling Demo

              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
              # Actual horizontal scaling setup: pick secure credentials.
              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
              # Only needed on the sibling instance of git-bridge
              V1_HISTORY_URL: "http://server-pro-ha-1:3100/api"
              # /git-bridge

              # Horizontal scaling
              # Actual horizontal scaling setup: pick secure credentials.
              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'
              # Actual horizontal scaling setup: IPs of load balancers
              TRUSTED_PROXY_IPS: 198.18.0.1,198.18.0.2
              # /Horizontal scaling

          # Actual horizontal scaling setup: run on host 198.18.1.1 and expose ports
          # ports:
          #     - "80:80"
          networks:
              default:
                  ipv4_address: 198.18.1.1

      # Actual horizontal scaling setup: run this container on a separate host.
      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"

          # Actual horizontal scaling setup: run on host 198.18.1.2 and expose ports
          # ports:
          #     - "80:80"
          networks:
              default:
                  ipv4_address: 198.18.1.2

      # Actual horizontal scaling setup: run this container on a separate host.
      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"

          # Actual horizontal scaling setup: run on host 198.18.1.3 and expose ports
          # ports:
          #     - "80:80"
          networks:
              default:
                  ipv4_address: 198.18.1.3

      # Actual horizontal scaling setup: run this container on a separate host.
      minio:
          image: minio/minio:RELEASE.2023-05-18T00-05-36Z
          container_name: minio
          command: server /data
          volumes:
              # Actual horizontal scaling setup: run minio with multiple disks, see minio docs.
              - ~/minio_data:/data
          environment:
              # Actual horizontal scaling setup: pick secure credentials.
              MINIO_ROOT_USER: MINIO_ROOT_USER
              MINIO_ROOT_PASSWORD: MINIO_ROOT_PASSWORD

          # Actual horizontal scaling setup: run on host 198.18.0.5 and expose port
          # ports:
          #     - "9000:9000"
          networks:
              default:
                  ipv4_address: 198.18.0.5

      # Actual horizontal scaling setup: run this setup once on a separate host.
      minio_setup:
          depends_on:
              - minio
          image: minio/mc:RELEASE.2023-05-18T16-59-00Z
          entrypoint: sh
          command:
              - '-c'
              # Actual horizontal scaling setup: pick secure credentials.
              - |
                  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

                  # Put the contents of the policy from the previous section in policy-filestore.json
                  # Reminder: Replace the bucket names accordingly.
                  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

      # Actual horizontal scaling setup: run this container on a separate host.
      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

          # Actual horizontal scaling setup: run on host 198.18.0.3 and expose 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\" } ] })"

      # Actual horizontal scaling setup: run this container on a separate host.
      redis:
          restart: always
          image: redis:6.2
          container_name: redis
          expose:
              - 6379
          volumes:
              - ~/redis_data:/data

          # Actual horizontal scaling setup: run on host 198.18.0.4 and expose port
          # ports:
          #     - "6379:6379"
          networks:
              default:
                  ipv4_address: 198.18.0.4
  ```
</Accordion>

#### Hardware

Ti consigliamo di utilizzare le stesse specifiche hardware per tutte le istanze di Server Pro che partecipano alla scalabilità orizzontale.

Si applicano le raccomandazioni generali sulle [specifiche hardware](/it/on-premises/getting-started/requirements/hardware-requirements) per le istanze di Server Pro.

#### Aggiornare Server Pro

Durante il processo di aggiornamento, Server Pro esegue automaticamente le migrazioni del database. Queste migrazioni **non** sono progettate per essere eseguite da più istanze in parallelo.

Le migrazioni devono terminare prima che venga avviata l'applicazione web vera e propria. Puoi controllare nei log la presenza di una voce `Finished migrations` oppure attendere che l'applicazione accetti traffico.

La procedura di aggiornamento è la seguente:

1. Pianifica una finestra di manutenzione
2. Arresta tutte le istanze di Server Pro
3. Esegui un backup coerente come descritto nella [documentazione](/it/on-premises/maintenance/data-and-backups#performing-a-consistent-backup)
4. Avvia una singola istanza di Server Pro con la nuova versione
5. Verifica che la nuova istanza funzioni come previsto
6. Avvia le altre istanze con la nuova versione


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.