Architettura dei Servizi Desktop Remoto

Servizi Desktop remoto offre una piattaforma flessibile per l'hosting di applicazioni e desktop Windows nel cloud o in locale. Questo articolo descrive le architetture di distribuzione di Servizi Desktop remoto comuni e illustra come integrare Servizi Desktop remoto con i servizi di Azure per soddisfare le esigenze dell'organizzazione.

Usare questi diagrammi di architettura per comprendere:

• Funzionamento dei ruoli in Servizi Desktop Remoto in diversi scenari di distribuzione.
• Opzioni per configurazioni RdS di base e a disponibilità elevata.
• Modelli di integrazione con le offerte PaaS (Platform as a Service) di Azure.

Indipendentemente dal fatto che si stia pianificando una nuova distribuzione di Servizi Desktop remoto o modernizzarne una esistente, queste architetture forniscono modelli collaudati per semplificare la progettazione di una soluzione che soddisfi i requisiti per prestazioni, disponibilità e sicurezza.

I diagrammi dell'architettura in questo articolo illustrano l'uso di RDS in Azure. Tuttavia, poiché Servizi Desktop remoto è un ruolo in Windows Server, è possibile distribuirlo in locale e in altri cloud. Questi diagrammi hanno lo scopo principale di illustrare come i ruoli dei Servizi Desktop Remoto siano collocati insieme e utilizzino altri servizi.

Architetture di distribuzione RDS standard

Servizi Desktop remoto presenta due architetture standard:

• Distribuzione di base: contiene il numero minimo di server per creare un ambiente Servizi Desktop remoto completamente efficace, ma senza ridondanza.

• Distribuzione ad alta disponibilità: contiene tutti i componenti necessari per garantire il tempo di attività massimo per l'ambiente Servizi Desktop Remoto.

Le sezioni seguenti illustrano i componenti di ogni architettura e il modo in cui interagiscono. I diagrammi mostrano anche in che modo i ruoli di Servizi Desktop remoto vengono raggruppati nei server, una pratica comune per ridurre i costi e la complessità.

Distribuzione di base

Questa architettura illustra una distribuzione di Servizi Desktop remoto di base in Azure che fornisce l'accesso remoto a desktop e applicazioni tramite una singola area di Azure. La distribuzione usa un bilanciatore di carico esterno per distribuire le connessioni entranti da Internet sull'infrastruttura RDS.

I ruoli fondamentali di Servizi Desktop Remoto sono distribuiti su più macchine virtuali all'interno di un unico gruppo di risorse. Il Gestore connessione Desktop remoto (RDCB) e il Server di licenze Desktop remoto (RDLS) condividono una macchina virtuale, mentre i componenti Gateway Desktop remoto (RDGW) e Accesso Web Desktop remoto (RDWeb) vengono distribuiti su una macchina virtuale separata. L'infrastruttura di supporto include un controller di dominio Active Directory e un file server per i dischi dei profili utente e l'archiviazione condivisa. Il server Host Sessione Desktop Remoto, distribuito nella propria macchina virtuale, fornisce le sessioni desktop e le applicazioni effettive agli utenti finali.

Tutte le macchine virtuali comunicano tramite una rete virtuale di Azure, che fornisce connettività di rete sicura tra i componenti di Servizi Desktop remoto isolando la distribuzione da altre risorse di Azure. Questa architettura offre un punto di partenza conveniente per le organizzazioni che cercano di eseguire la migrazione dell'hosting desktop in Azure, con la flessibilità necessaria per ridimensionare i singoli componenti man mano che aumenta l'utilizzo.

Distribuzione a disponibilità elevata

Questa architettura illustra una distribuzione di Servizi Desktop remoto che integra le offerte PaaS (Platform as a Service) di Azure per migliorare la scalabilità e ridurre il sovraccarico di gestione. La differenza principale rispetto a una distribuzione di Servizi Desktop remoto di base è la sostituzione di una macchina virtuale di SQL Server tradizionale con il database SQL di Azure per l'archiviazione dei dati di configurazione e sessione utente di Servizi Desktop remoto.

I ruoli RDS mantengono lo stesso modello di distribuzione, ma con più istanze di ognuno; il Gestore Connessione Desktop Remoto (RDCB) e il Server licenze Desktop remoto (RDLS) condividono un set di macchine virtuali, mentre i componenti Gateway Desktop Remoto (RDGW) e Accesso Web Desktop Remoto (RDWeb) vengono distribuiti in un set separato di macchine virtuali. Gli Host sessione di Desktop remoto continuano a fornire sessioni desktop e applicazioni dai macchine virtuali dedicate. L'infrastruttura di supporto include un controller di dominio Active Directory e un file server per i profili utente e l'archiviazione condivisa.

Usando il database SQL di Azure anziché un'istanza di SQL Server autogestito, questa architettura offre disponibilità elevata predefinita, backup automatici e gestione semplificata dei database. Il database SQL di Azure gestisce i requisiti del database del Gestore connessione RDS, eliminando la necessità di gestire, applicare patch e monitorare un server di database separato. Questo approccio ibrido combina la flessibilità dell'infrastruttura distribuita come servizio (IaaS) per i ruoli di Servizi Desktop remoto con i vantaggi gestiti di PaaS per il livello di database, con conseguente riduzione della complessità operativa e maggiore affidabilità.

Diagramma che mostra una distribuzione ad alta disponibilità di Servizi Desktop Remoto in Azure, con più istanze di ruoli di servizi di RDS, Azure SQL Database per disponibilità elevata, controller di dominio di Active Directory, file server e connettività con Rete Virtuale di Azure.

Architetture di Servizi Desktop remoto con ruoli PaaS di Azure univoci

Sebbene le architetture di distribuzione di Servizi Desktop remoto standard si adattino alla maggior parte degli scenari, Azure continua a investire in soluzioni PaaS proprietarie di valore per i clienti. Le architetture seguenti mostrano come si integrano con RDS.

Distribuzione di RDS con Microsoft Entra Domain Services

I due diagrammi di architettura standard si basano su un'istanza tradizionale di Active Directory (AD) distribuita in una macchina virtuale Windows Server. Tuttavia, se non si dispone di un AD tradizionale e si ha solo un tenant di Microsoft Entra, ad esempio tramite servizi come Microsoft 365, ma si desidera comunque utilizzare i Servizi Desktop Remoto, è possibile utilizzare Microsoft Entra Domain Services per creare un dominio completamente gestito nell'ambiente IaaS di Azure che utilizza gli stessi utenti esistenti nel tenant di Microsoft Entra. Questa opzione rimuove la complessità della sincronizzazione manuale degli utenti e della gestione di più macchine virtuali. Microsoft Entra Domain Services può essere usato in una distribuzione di base o a disponibilità elevata.

Distribuzione RDS con Microsoft Entra application proxy

I due diagrammi di architettura standard utilizzano i server RD Web/Gateway come punto di ingresso dal lato Internet nel sistema Servizi Desktop Remoto (RDS). Per alcuni ambienti, gli amministratori preferiscono rimuovere i propri server dal perimetro e usare invece tecnologie che forniscono sicurezza aggiuntiva tramite tecnologie proxy inversi. Il ruolo PaaS Microsoft Entra Application Proxy si adatta perfettamente a questo scenario.

Per le configurazioni supportate e come creare questa configurazione, vedere Pubblicare Desktop remoto con il proxy dell'applicazione Microsoft Entra.