> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/server/it/knowledge-base/how-to-articles/deploy-in-a-high-availability-or-load-balancing-environment.md).
# Distribuire in un ambiente ad alta disponibilità o con bilanciamento del carico
{% hint style="info" %}
Il contenuto di questo articolo si applica esclusivamente ai sistemi operativi Windows.
{% endhint %}
Seguendo queste linee guida, può garantire una distribuzione ad alta disponibilità o con bilanciamento del carico robusta e sicura.
### Considerazioni principali
* **Allowlist e blocklist degli IP**: queste funzionalità richiedono la convalida dell'indirizzo IP del client per garantire sicurezza e conformità, solitamente con l'[header X-Forwarded-For](/server/it/knowledge-base/knowledge-base-articles/x-forwarded-for.md) che deve essere abilitato in ***Administration*** – ***Server settings*** – ***Security***.\
[Includa inoltre l'header X-Forwarded-For nei log di IIS](/server/it/knowledge-base/how-to-articles/add-x-forwarded-for-column-in-iis.md) per garantire un tracciamento accurato degli indirizzi IP dei client.
* **Header di risposta HTTP**: ogni nodo server dovrebbe aggiungere un identificatore univoco e non descrittivo agli header delle risposte HTTP. Questo identificatore, che potrebbe essere generico come "node1" o "node2", serve a tracciare il percorso delle richieste tra i diversi server senza divulgare dettagli sensibili del server, come il nome di dominio completo (FQDN). Questa pratica è fondamentale non solo per mappare il percorso della richiesta, ma anche per mantenere la sicurezza operativa, poiché limita l'esposizione dei dettagli dell'infrastruttura che potrebbero essere sfruttati. Le organizzazioni orientate a una maggiore sicurezza dovrebbero valutare precauzioni aggiuntive, come l'uso di valori casuali o con hash come identificatori, per offuscare ulteriormente le identità dei server.\
\
Ciò non è necessario per il funzionamento, e ogni bilanciatore di carico può avere il proprio metodo per ottenerlo. Tuttavia, identificare il server che ha risposto alla richiesta può essere un utile passaggio di risoluzione dei problemi.\
\
Consulti [Identificare il server che risponde in una topologia ad alta disponibilità](/server/it/knowledge-base/how-to-articles/identify-the-server-answering-on-a-high-availability-topology.md) per maggiori informazioni.
### Architettura
#### Bilanciatore di carico
* **X-Forwarded-For e certificati SSL**: quando implementa il bilanciamento del carico, tenga conto anche dei certificati SSL e dell'header [X-Forwarded-For](/server/it/knowledge-base/knowledge-base-articles/x-forwarded-for.md).\
Utilizzi qualsiasi tecnologia di bilanciamento del carico in grado di aggiungere l'header X-Forwarded-For tramite proxy o dispositivi intermedi. Questo header deve essere rimosso se ricevuto da un client e impostato solo dalle sue apparecchiature di rete.\
Una configurazione corretta di questi elementi garantisce connessioni sicure e un tracciamento accurato degli IP dei client su più server. Consulti le considerazioni principali sopra riguardo alle allowlist e blocklist degli IP.
* **Regole di affinità del client**: l'assegnazione di regole di affinità del client garantisce che, quando un client si connette per la prima volta, le richieste successive dello stesso client vengano indirizzate allo stesso server web, mantenendo la coerenza.
* **Opzioni di bilanciamento del carico**: se non utilizza un bilanciatore di carico virtuale o hardware dedicato davanti ai server web, il bilanciamento del carico DNS può essere un'alternativa pratica. Con questo approccio, vengono configurati più record DNS (A, AAAA o CNAME) per lo stesso dominio. Quando un client si connette, il provider DNS seleziona casualmente uno di questi record a cui rispondere.\
Ad esempio, se **devolutions-server.mycorp.com** ha due record A che puntano a IP diversi per ciascun server web, il DNS risponderà con uno di questi record, distribuendo di fatto il carico tra i server.\
Tuttavia, il bilanciamento del carico DNS presenta dei limiti. Poiché non dispone di controlli di integrità, se un server non è disponibile il provider DNS potrebbe comunque indirizzare il traffico al server offline, causando connessioni non riuscite. Questo esempio è spiegato in questo [articolo di Cloudflare sui record DNS](https://developers.cloudflare.com/load-balancing/load-balancers/dns-records/).
#### Server web / server applicativi
In una configurazione tipica, vengono impostati due server con IIS, ciascuno con un'istanza di Devolutions Server in esecuzione. Le considerazioni principali includono crittografia, inoltro IP, failover SQL e coerenza SSL.
* **Sincronizzazione delle chiavi di crittografia**: ogni server richiede chiavi di crittografia corrispondenti per decrittare i dati nel database condiviso. Dopo aver installato il primo server, esporti le sue chiavi di crittografia e le importi sul secondo server per garantire le corrette capacità di decrittazione.
* **Configurazione di X-Forwarded-For**: configuri l'[header X-Forwarded-For](/server/it/knowledge-base/knowledge-base-articles/x-forwarded-for.md) per mantenere informazioni accurate sull'IP del client tra i server. Ciò è essenziale a fini di tracciamento e sicurezza. Consulti le considerazioni principali sopra riguardo alle allowlist e blocklist degli IP.
* **Configurazione del failover del database SQL**: nella Devolutions Server Console, segua i passaggi seguenti per ogni istanza di Devolutions Server.
1. Selezioni l'istanza di Devolutions Server.
2. Vada in ***Server*** – ***Edit***.
3. In ***Database***, clicchi su ***Advanced settings***.
4. Clicchi su ***More settings***.
5. Imposti il ***Value*** dell'impostazione ***MultiSubnetFailover*** su ***True***.
6. Clicchi su ***Ok*** per salvare le modifiche e chiudere le finestre.
Questa impostazione consente all'applicazione di connettersi a più server di database SQL nel [gruppo di disponibilità Always On](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server), garantendo un failover rapido quando necessario.
* **Garantire la coerenza dei certificati SSL**: poiché entrambi i server IIS servono lo stesso URL attraverso un bilanciatore di carico (a meno che non utilizzi IIS ARR con un DNS round-robin o un altro schema di bilanciamento del carico), è fondamentale che tutti i certificati SSL corrispondano e siano serviti correttamente lungo l'intera catena. Si assicuri che il bilanciatore di carico ed entrambi i server IIS abbiano certificati SSL corrispondenti, per offrire ai client una connessione sicura e unificata.
#### Server di database
* **Configurazione dei server SQL in un gruppo di disponibilità Always On**: per garantire l'alta disponibilità, configuri due Microsoft SQL Server in un [gruppo di disponibilità Always On](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server). Questa configurazione segue un modello **Attivo → Passivo** con un quorum (o "witness") per monitorare lo stato dei server e attivare il failover se uno di essi diventa non disponibile.
* **Abilitazione della modalità contained database**: il database di Devolutions Server deve funzionare in [modalità contained](https://learn.microsoft.com/en-us/sql/relational-databases/databases/contained-databases), consentendo all'autenticazione di spostarsi insieme al database anziché essere gestita a livello di server. Segua questi passaggi per abilitare la modalità contained (può essere fatto anche tramite comandi T-SQL):
1. Apra Microsoft SQL Server Management Studio.
2. Clicchi con il tasto destro sul database di Devolutions Server e selezioni ***Properties***.
3. Vada in ***Options*** e imposti il ***Containment type*** su ***Partial***.
Questa impostazione consente agli utenti del database di spostarsi con il database tra i server del gruppo di disponibilità.
* **Creazione di utenti contained**: con la modalità contained abilitata sul database, può creare utenti direttamente associati ad esso.\
Possono essere:
* **Utenti SQL con password**: creati specificamente all'interno del contained database.
* **Utenti Windows**: integrati senza necessità di un login del server MSSQL associato al database master.
Per una maggiore sicurezza, si consiglia di utilizzare l'autenticazione Windows anziché utenti SQL con password. Tenga però presente che, se utilizza utenti Windows, la funzionalità infrastructure vault di Devolutions Server non sarà in grado di gestire tali utenti, poiché attualmente supporta solo utenti autenticati tramite SQL.
* **Client Remote Desktop Manager**: quando utilizza il client Remote Desktop Manager con un Microsoft SQL Server in una configurazione ad alta disponibilità (HA), abiliti la [configurazione multi-subnet failover](https://docs.devolutions.net/rdm/it/knowledge-base/knowledge-base-articles/sql-server-always-on-availability-groups). Questa impostazione è specificamente utile per le installazioni HA di Microsoft SQL Server e non è necessaria per Devolutions Server.\
Per configurare Multi-Subnet Failover in RDM:
1. In Remote Desktop Manager, vada in ***File*** – ***Workspaces***.
2. Selezioni lo spazio di lavoro Microsoft SQL Server nell'elenco degli spazi di lavoro, quindi clicchi su ***Edit workspace***.
3. Nella scheda ***Advanced***, clicchi su ***More settings***.
4. Imposti il ***Value*** dell'impostazione ***MultiSubnetFailover*** su ***True***.
5. Clicchi su ***Ok*** e ***Save*** per salvare le modifiche e chiudere le finestre.
Questa configurazione consente al client Remote Desktop Manager di gestire più subnet, garantendo un failover rapido tra i server SQL in un ambiente ad alta disponibilità.
### Processo di verifica
* **Convalida delle email**: verifichi che qualsiasi email generata dal sistema contenga l'URI pubblico corretto, anziché il nome del server. Ciò può essere controllato utilizzando la funzionalità di messaggistica di Devolutions Server.
* **Cronologia e tentativi di accesso**: la tabella ***LoginHistory*** contiene l'indirizzo IP del client, non quello di eventuali server intermedi. Anche la tabella ***LoginAttempts*** elenca l'indirizzo IP, ma include più scenari:
* Accessi non riusciti (ad esempio, credenziali errate)
* IP nella blocklist
* IP identificati come nodo di uscita TOR
---
# 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://docs.devolutions.net/server/it/knowledge-base/how-to-articles/deploy-in-a-high-availability-or-load-balancing-environment.md?ask=&goal=
```
`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.
