Desktop virtuale Azure per le aziende

Microsoft Entra ID
Microsoft Entra
Rete virtuale di Azure
Desktop virtuale Azure

Desktop virtuale Azure è un servizio di virtualizzazione di applicazioni e desktop eseguito in Azure. Questo articolo ha lo scopo di aiutare gli architetti dell'infrastruttura desktop, gli architetti cloud, gli amministratori desktop e gli amministratori di sistema a esplorare Desktop virtuale Azure e creare soluzioni VDI (VirtualIzed Desktop Infrastructure) su scala aziendale. Le soluzioni su scala aziendale in genere coprono 1.000 o più desktop virtuali.

Architettura

Una configurazione architetturale tipica per Desktop virtuale Azure è illustrata nel diagramma seguente:

Diagramma di un'architettura del servizio Desktop virtuale Azure.

Scaricare un file di Visio di questa architettura.

Flusso di dati

Gli elementi del flusso di dati del diagramma sono descritti di seguito:

  • Gli endpoint dell'applicazione si trovano nella rete locale di un cliente. Azure ExpressRoute estende la rete locale in Azure e Microsoft Entra Connessione integra il Dominio di Active Directory Services (AD DS) del cliente con Microsoft Entra ID.

  • Il piano di controllo di Desktop virtuale Azure gestisce l'accesso Web, il gateway, il broker, la diagnostica e i componenti di estendibilità, ad esempio le API REST.

  • Il cliente gestisce Active Directory Domain Services e Microsoft Entra ID, sottoscrizioni di Azure, reti virtuali, File di Azure o Azure NetApp Files e pool di host e aree di lavoro di Desktop virtuale Azure.

  • Per aumentare la capacità, il cliente usa due sottoscrizioni di Azure in un'architettura hub-spoke e le connette tramite peering di rete virtuale.

Per altre informazioni sul contenitore di profili FSLogix - File di Azure e sulle procedure consigliate di Azure NetApp Files, vedere Esempi di configurazione di FSLogix.

Componenti

L'architettura del servizio Desktop virtuale Azure è simile a Servizi Desktop remoto di Windows Server. Anche se Microsoft gestisce i componenti di infrastruttura e brokering, i clienti aziendali gestiscono le proprie macchine virtuali host desktop, i dati e i client.

Componenti gestiti da Microsoft

Microsoft gestisce i servizi Desktop virtuale Azure seguenti come parte di Azure:

  • Accesso Web: usando il servizio Accesso Web all'interno di Desktop virtuale Azure è possibile accedere a desktop virtuali e app remote tramite un Web browser compatibile con HTML5 esattamente come si farebbe con un PC locale, ovunque e in qualsiasi dispositivo. È possibile proteggere l'accesso Web usando l'autenticazione a più fattori in Microsoft Entra ID.

  • Gateway: il servizio Gateway di connessione remota connette gli utenti remoti alle app e ai desktop di Desktop virtuale Azure da qualsiasi dispositivo connesso a Internet in grado di eseguire un client di Desktop virtuale Azure. Il client si connette a un gateway, che orchestra quindi una connessione da una macchina virtuale allo stesso gateway.

  • Gestore connessione: il servizio Gestore connessione gestisce le connessioni utente a desktop virtuali e app remote. Connessione ion Broker fornisce il bilanciamento del carico e la riconnessione alle sessioni esistenti.

  • Diagnostica: Diagnostica di Desktop remoto è un aggregatore basato su eventi che contrassegna ogni azione di utenti o amministratori nella distribuzione di Desktop virtuale Azure come riuscita o non riuscita. Gli amministratori possono eseguire query sull'aggregazione di eventi per identificare i componenti con errori.

  • Componenti di estendibilità: Desktop virtuale Azure include alcuni componenti di estendibilità. È possibile gestire Desktop virtuale Azure usando Windows PowerShell o con le API REST fornite, che consentono anche il supporto da strumenti di terze parti.

Componenti gestiti

È possibile gestire i componenti seguenti delle soluzioni Desktop virtuale Azure:

  • Azure Rete virtuale: con Azure Rete virtuale, le risorse di Azure, ad esempio le macchine virtuali, possono comunicare privatamente tra loro e con Internet. La connessione dei pool di host di Desktop virtuale Azure a un dominio di Active Directory consente di definire la topologia di rete per accedere a desktop virtuali e app virtuali da Intranet o Internet in base ai criteri dell'organizzazione. È possibile connettere un'istanza di Desktop virtuale Azure a una rete locale usando una rete privata virtuale (VPN) oppure è possibile usare Azure ExpressRoute per estendere la rete locale in Azure tramite una connessione privata.

  • Microsoft Entra ID: Desktop virtuale Azure usa Microsoft Entra ID per la gestione delle identità e degli accessi. L'integrazione di Microsoft Entra applica funzionalità di sicurezza di Microsoft Entra, ad esempio l'accesso condizionale, l'autenticazione a più fattori e Intelligent Security Graph, e consente di mantenere la compatibilità delle app nelle macchine virtuali aggiunte a un dominio.

  • servizi Dominio di Active Directory (facoltativo): le macchine virtuali di Desktop virtuale Azure possono essere aggiunte a un dominio a un servizio Active Directory Domain Services o usare Distribuire macchine virtuali aggiunte a Microsoft Entra in Desktop virtuale Azure

    • Quando si usa un dominio di Active Directory Domain Services, il dominio deve essere sincronizzato con l'ID Microsoft Entra per associare gli utenti tra i due servizi. È possibile usare Microsoft Entra Connessione per associare Active Directory Domain Services all'ID Microsoft Entra.
    • Quando si usa l'aggiunta a Microsoft Entra, esaminare le configurazioni supportate per assicurarsi che lo scenario sia supportato.
  • Host di sessione di Desktop virtuale Azure: gli host di sessione sono macchine virtuali a cui gli utenti si connettono per desktop e applicazioni. Sono supportate diverse versioni di Windows ed è possibile creare immagini con le applicazioni e le personalizzazioni. È possibile scegliere le dimensioni delle macchine virtuali, incluse le macchine virtuali abilitate per GPU. Ogni host di sessione ha un agente host di Desktop virtuale Azure, che registra la macchina virtuale come parte dell'area di lavoro o del tenant di Desktop virtuale Azure. Ogni pool di host può avere uno o più gruppi di app, ovvero raccolte di applicazioni remote o sessioni desktop a cui è possibile accedere. Per vedere quali versioni di Windows sono supportate, vedi Sistemi operativi e licenze.

  • Area di lavoro desktop virtuale Azure: l'area di lavoro o il tenant di Desktop virtuale Azure è un costrutto di gestione per la gestione e la pubblicazione delle risorse del pool di host.

Dettagli dello scenario

Potenziali casi d'uso

La più grande richiesta di soluzioni desktop virtuali aziendali proviene da:

  • Applicazioni di sicurezza e regolamentazione, ad esempio servizi finanziari, sanità e enti pubblici.

  • Esigenze della forza lavoro elastica, ad esempio lavoro remoto, fusioni e acquisizioni, dipendenti a breve termine, terzisti e accesso ai partner.

  • Dipendenti specifici, ad esempio bring your own device (BYOD) e utenti mobili, call center e branch worker.

  • Carichi di lavoro specializzati, ad esempio progettazione e progettazione, app legacy e test di sviluppo software.

Desktop personali e in pool

Usando soluzioni desktop personali, talvolta denominate desktop permanenti, gli utenti possono sempre connettersi allo stesso host di sessione specifico. Gli utenti possono in genere modificare l'esperienza desktop per soddisfare le preferenze personali e possono salvare i file nell'ambiente desktop. Le soluzioni desktop personali:

  • Consentire agli utenti di personalizzare l'ambiente desktop, incluse le applicazioni installate dall'utente, e gli utenti possono salvare i file all'interno dell'ambiente desktop.
  • Consentire l'assegnazione di risorse dedicate a utenti specifici, che possono essere utili per alcuni casi d'uso di produzione o sviluppo.

Le soluzioni desktop in pool, dette anche desktop non persistenti, assegnano gli utenti a qualsiasi host di sessione attualmente disponibile, a seconda dell'algoritmo di bilanciamento del carico. Poiché gli utenti non tornano sempre allo stesso host di sessione ogni volta che si connettono, hanno una capacità limitata di personalizzare l'ambiente desktop e in genere non hanno accesso amministratore.

Manutenzione pacchetti Windows

Sono disponibili diverse opzioni per l'aggiornamento delle istanze di Desktop virtuale Azure. La distribuzione di un'immagine aggiornata ogni mese garantisce la conformità e lo stato.

Relazioni tra componenti logici chiave

Le relazioni tra pool di host, aree di lavoro e altri componenti logici chiave variano. Vengono riepilogati nel diagramma seguente:

Diagramma che illustra le relazioni tra i componenti logici chiave.

I numeri nelle descrizioni seguenti corrispondono a quelli del diagramma precedente.

  • (1) Un gruppo di applicazioni che contiene un desktop pubblicato può contenere solo pacchetti MSIX montati nel pool di host (i pacchetti saranno disponibili nel menu Start dell'host sessione), non può contenere altre risorse pubblicate ed è denominato gruppo di applicazioni desktop.
  • (2) I gruppi di applicazioni assegnati allo stesso pool di host devono essere membri della stessa area di lavoro.
  • (3) Un account utente può essere assegnato a un gruppo di applicazioni direttamente o tramite un gruppo Microsoft Entra. È possibile assegnare nessun utente a un gruppo di applicazioni, ma non può essere risolto.
  • (4) È possibile avere un'area di lavoro vuota, ma non può gestire gli utenti.
  • (5) È possibile avere un pool di host vuoto, ma non può essere ospitato dagli utenti.
  • (6) È possibile che a un pool di host non siano assegnati gruppi di applicazioni, ma non può essere gestito dagli utenti.
  • (7) Microsoft Entra ID è obbligatorio per Desktop virtuale Azure. Ciò è dovuto al fatto che gli account utente e i gruppi di Microsoft Entra devono essere sempre usati per assegnare gli utenti ai gruppi di applicazioni Desktop virtuale Azure. Microsoft Entra ID viene usato anche per autenticare gli utenti nel servizio Desktop virtuale Azure. Gli host di sessione di Desktop virtuale Azure possono anche essere membri di un dominio Microsoft Entra e in questa situazione anche le applicazioni pubblicate da Desktop virtuale Azure e le sessioni desktop verranno avviate ed eseguite (non solo assegnate) usando gli account Microsoft Entra.
    • (7) In alternativa, gli host di sessione di Desktop virtuale Azure possono essere membri di un dominio di Active Directory Domain Services e in questa situazione le applicazioni pubblicate da Desktop virtuale Azure e le sessioni desktop verranno avviate ed eseguite (ma non assegnate) usando gli account di Active Directory Domain Services. Per ridurre il sovraccarico amministrativo e dell'utente, è possibile sincronizzare Active Directory Domain Services con Microsoft Entra ID tramite Microsoft Entra Connessione.
    • (7) Infine, gli host di sessione di Desktop virtuale Azure possono, invece, essere membri di un dominio di Microsoft Entra Domain Services e in questa situazione le applicazioni pubblicate e le sessioni desktop pubblicate da Desktop virtuale Azure verranno avviate ed eseguite (ma non assegnate) usando gli account microsoft Entra Domain Services. Microsoft Entra ID viene sincronizzato automaticamente con Microsoft Entra Domain Services, da Microsoft Entra ID solo a Microsoft Entra Domain Services.
Conto risorse Scopo Relazioni logiche
Desktop pubblicato Un ambiente desktop Di Windows in esecuzione negli host di sessione di Desktop virtuale Azure e viene distribuito agli utenti in rete Membro di un solo gruppo di applicazioni (1)
Applicazione pubblicata Un'applicazione Windows in esecuzione negli host sessione di Desktop virtuale Azure e viene distribuita agli utenti in rete Membro di un solo gruppo di applicazioni
Gruppo di applicazioni Un raggruppamento logico di applicazioni pubblicate o un desktop pubblicato - Contiene un desktop pubblicato (1) o una o più applicazioni pubblicate
- Assegnato a uno e a un solo pool di host (2)
- Membro di un'unica area di lavoro (2)
- A uno o più account utente o gruppi di Microsoft Entra vengono assegnati (3)
Account utente/gruppo Microsoft Entra Identifica gli utenti autorizzati ad avviare applicazioni o desktop pubblicati - Membro di uno e solo un ID Microsoft Entra
- Assegnato a uno o più gruppi di applicazioni (3)
MICROSOFT Entra ID (7) Provider di identità - Contiene uno o più account utente o gruppi, che devono essere usati per assegnare utenti ai gruppi di applicazioni e possono essere usati anche per accedere agli host di sessione
- Può contenere le appartenenze degli host di sessione
- Può essere sincronizzato con Servizi di dominio Active Directory o Microsoft Entra Domain Services
Active Directory Domain Services (7) Provider di servizi di gestione delle identità e directory - Contiene uno o più account utente o gruppi, che possono essere usati per accedere agli host di sessione
- Può contenere le appartenenze degli host di sessione
- Può essere sincronizzato con Microsoft Entra ID
Servizi di dominio Microsoft Entra (7) Provider di identità e servizi directory basato su Piattaforma distribuita come servizio (PaaS) - Contiene uno o più account utente o gruppi, che possono essere usati per accedere agli host di sessione
- Può contenere le appartenenze degli host di sessione
- Sincronizzato con Microsoft Entra ID
Area di lavoro Raggruppamento logico di gruppi di applicazioni Contiene uno o più gruppi di applicazioni (4)
Pool di host Gruppo di host di sessione identici che hanno uno scopo comune - Contiene uno o più host di sessione (5)
- A uno o più gruppi di applicazioni sono assegnati (6)
Host di sessione Una macchina virtuale che ospita desktop o applicazioni pubblicati Membro di un solo pool di host

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.

I numeri nelle sezioni seguenti sono approssimativi. Si basano su un'ampia gamma di distribuzioni di clienti di grandi dimensioni e sono soggette a modifiche nel tempo.

Notare anche che:

  • Non è possibile creare più di 500 gruppi di applicazioni per singolo tenant di Microsoft Entra*.
  • È consigliabile non pubblicare più di 50 applicazioni per gruppo di applicazioni.

Limitazioni di Desktop virtuale Azure

Analogamente ad Azure, Desktop virtuale Azure presenta alcune limitazioni del servizio di cui è necessario tenere conto. Per evitare di dover apportare modifiche nella fase di ridimensionamento, è consigliabile risolvere alcune di queste limitazioni nella fase di progettazione.

Oggetto di Desktop virtuale Azure Per oggetto contenitore padre Limite del servizio
Area di lavoro Tenant di Microsoft Entra 1300
Pool di host Area di lavoro 400
Gruppo di applicazioni Tenant di Microsoft Entra 500*
RemoteApp Gruppo di applicazioni 500
Assegnazione di ruolo Qualunque oggetto di Desktop virtuale Azure 200
Host di sessione Pool di host 10,000

*Se sono necessari più di 500 gruppi di applicazioni, inviare un ticket di supporto tramite il portale di Azure.

  • È consigliabile distribuire un massimo di 5.000 macchine virtuali per ogni sottoscrizione di Azure per area. Questa raccomandazione è applicabile ai pool di host personali e in pool basati su Windows Enterprise a sessione singola e multisessione. La maggior parte dei clienti usa Windows Enterprise multisessione, che consente a più utenti di accedere a ogni macchina virtuale. È possibile incrementare le risorse delle singole macchine virtuali host di sessione per includere più sessioni utente.
  • Per gli strumenti di ridimensionamento automatico degli host di sessione, i limiti prevedono circa 2.500 macchine virtuali per sottoscrizione di Azure per area, perché l'interazione dello stato della macchina virtuale utilizza più risorse.
  • Per gestire gli ambienti aziendali con più di 5.000 macchine virtuali per sottoscrizione di Azure nella stessa area, è possibile creare più sottoscrizioni di Azure in un'architettura hub-spoke e connetterle tramite peering di reti virtuali, usando una sottoscrizione per spoke. È anche possibile distribuire macchine virtuali in un'area diversa nella stessa sottoscrizione per incrementare il numero di macchine virtuali.
  • I limiti di limitazione dell'API di sottoscrizione di Azure Resource Manager (ARM) non consentono più di 600 riavvii di macchine virtuali di Azure all'ora tramite il portale di Azure. È possibile riavviare contemporaneamente tutti i computer tramite il sistema operativo, che non consuma alcuna chiamata API di sottoscrizione di Azure Resource Manager. Per altre informazioni sul conteggio e sulla risoluzione dei problemi dei limiti di limitazione in base alla sottoscrizione di Azure, vedere Risolvere gli errori di limitazione delle API.
  • Attualmente è possibile distribuire fino a 132 macchine virtuali in un'unica distribuzione del modello di ARM nel portale di Desktop virtuale Azure. Per creare più di 132 macchine virtuali, eseguire più volte la distribuzione del modello di ARM nel portale di Desktop virtuale Azure.
  • I prefissi dei nomi di host di sessione delle macchine virtuali di Azure non possono includere più di 11 caratteri a causa dell'assegnazione automatica dei nomi di istanza e del limite NetBIOS di 15 caratteri per account di computer.
  • Per impostazione predefinita, è possibile distribuire fino a 800 istanze della maggior parte dei tipi di risorse in un gruppo di risorse. Calcolo di Azure non presenta questo limite.

Per altre informazioni sulle limitazioni delle sottoscrizioni di Azure, vedere Sottoscrizione di Azure e limiti, quote e vincoli dei servizi.

Dimensioni di VM

Linee guida per il dimensionamento delle macchine virtuali indica il numero massimo suggerito di utenti per vCPU (virtual Central Processing Unit) e le configurazioni di macchina virtuale minime per i diversi carichi di lavoro. Questi dati consentono di stimare le macchine virtuali necessarie nel pool di host.

Usare gli strumenti di simulazione per testare le distribuzioni con test di stress e simulazioni di utilizzo reale. Assicurarsi che il sistema sia reattivo e resiliente abbastanza per soddisfare le esigenze degli utenti e ricordare di variare le dimensioni del carico durante i test.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

È possibile progettare la soluzione Desktop virtuale Azure per ottenere risparmi sui costi. Di seguito sono riportate cinque opzioni diverse per semplificare la gestione dei costi per le aziende:

  • Windows 10 multisessione: offrendo un'esperienza desktop multisessione per gli utenti con requisiti di calcolo identici, è possibile consentire a più utenti di accedere a una singola macchina virtuale contemporaneamente, un approccio che può comportare un notevole risparmio sui costi.
  • Vantaggio Azure Hybrid: se è disponibile Software Assurance, è possibile usare il Vantaggio Azure Hybrid per Windows Server per risparmiare sul costo dell'infrastruttura di Azure.
  • Istanze di macchina virtuale riservate di Azure: è possibile pagare in anticipo l'utilizzo della macchina virtuale e risparmiare denaro. Combinare istanze di macchina virtuale riservate di Azure con Vantaggio Azure Hybrid per un risparmio fino all'80% rispetto ai prezzi di listino.
  • Bilanciamento del carico dell'host sessione: quando si configurano host di sessione, la modalità in ampiezza , che distribuisce gli utenti in modo casuale tra gli host di sessione, è la modalità predefinita standard. In alternativa, è possibile usare la modalità depth-first per riempire un server host sessione con il numero massimo di utenti prima di passare all'host sessione successivo. È possibile modificare questa impostazione per ottenere i vantaggi massimi in termini di costi.

Distribuire lo scenario

Usare i modelli di ARM per automatizzare la distribuzione dell'ambiente di Desktop virtuale Azure. Questi modelli di ARM supportano solo gli oggetti di Desktop virtuale Azure di Azure Resource Manager. Questi modelli di ARM non supportano Desktop virtuale Azure (versione classica).

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

  • Tom Hickling | Senior Product Manager, Progettazione di Desktop virtuale Azure

Altro collaboratore:

Passaggi successivi