> 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 Distribuisca Devolutions Server in un ambiente ad alta disponibilità o con bilanciamento del carico su Windows, con inoltro IP, sincronizzazione delle chiavi di crittografia e failover SQL. {% hint style="info" %} Il contenuto di questo articolo si applica esclusivamente ai sistemi operativi Windows. {% endhint %} Seguendo queste linee guida, può garantire una distribuzione robusta e sicura ad alta disponibilità o con bilanciamento del carico. In una configurazione tipica, i dispositivi client (desktop, portatili e dispositivi mobili) si connettono tramite internet a un firewall, che inoltra il traffico a un bilanciatore del carico. Il bilanciatore del carico distribuisce quindi le richieste tra due (o più) nodi Devolutions Server. Ad esempio: * Firewall: `10.10.10.10` * Bilanciatore del carico: `10.11.11.11` * Nodo Devolutions Server A: `10.12.12.50` * Nodo Devolutions Server B: `10.12.12.51` ### Considerazioni principali * **Elenchi di IP consentiti e bloccati**: 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***.\ Inoltre, [includa 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 delle risposte HTTP**: ogni nodo del 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 attraverso 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 di 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 hash come identificatori, per offuscare ulteriormente l'identità dei server.\ \ Ciò non è necessario per il funzionamento e ogni bilanciatore del carico può avere un proprio metodo per ottenerlo. Tuttavia, identificare il server che ha risposto alla richiesta può essere un utile passaggio di risoluzione dei problemi.\ \ Consulti [Identify the server answering on a high-availability topology](/server/it/knowledge-base/how-to-articles/identify-the-server-answering-on-a-high-availability-topology.md) per maggiori informazioni. ### Architettura #### Bilanciatore del 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 dovrebbe essere rimosso se ricevuto da un client e impostato esclusivamente 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 riguardanti gli elenchi di IP consentiti e bloccati. * **Regole di affinità client**: l'assegnazione di regole di affinità 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 del carico dedicato, virtuale o hardware, davanti ai server web, il bilanciamento del carico tramite 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 per rispondere.\ Ad esempio, se **devolutions-server.mycorp.com** ha due record A che puntano a IP differenti 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 tramite DNS presenta dei limiti. Poiché non dispone di controlli di integrità, se un server non è disponibile il provider DNS potrebbe comunque indirizzare il traffico verso il 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 predisposti due server con IIS, ciascuno con un'istanza di Devolutions Server in esecuzione. Le considerazioni principali includono la crittografia, l'inoltro IP, il failover SQL e la coerenza SSL. * **Sincronizzazione delle chiavi di crittografia**: ogni server richiede chiavi di crittografia corrispondenti per decrittografare i dati nel database condiviso. Dopo aver installato il primo server, esporti le sue chiavi di crittografia e le importi nel secondo server per garantire adeguate capacità di decrittografia. * **Configurazione di X-Forwarded-For**: imposti 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. Questo è essenziale a fini di tracciamento e sicurezza. Consulti le considerazioni principali sopra riguardanti gli elenchi di IP consentiti e bloccati. * **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 del carico (a meno che non utilizzi IIS ARR con 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 del carico ed entrambi i server IIS dispongano di certificati SSL corrispondenti, per fornire ai client una connessione sicura e unificata. #### Server di database * **Configurazione dei SQL Server 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") che monitora lo stato dei server e attiva il failover se uno di essi non è più 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 (è possibile farlo 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 ***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 collegati ad esso.\ Questi possono essere: * **Utenti SQL con password**: creati specificamente all'interno del contained database. * **Utenti Windows**: integrati senza la 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 potrà gestirli, 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 è utile specificamente per le installazioni HA di Microsoft SQL Server e non è richiesta per Devolutions Server.\ Per configurare il 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. Può verificarlo 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 sono previsti più scenari: * Accessi non riusciti (ad esempio, credenziali errate) * IP inseriti nell'elenco bloccati * 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.