Architettura e resilienza del servizio Desktop virtuale Azure

Desktop virtuale Azure è progettato per offrire un servizio resiliente, affidabile e sicuro per organizzazioni e utenti. L'architettura di Desktop virtuale Azure comprende molti componenti che costituiscono il servizio che connette gli utenti ai desktop e alle app. La maggior parte dei componenti è gestita da Microsoft, ma alcune sono gestite dal cliente o gestite dai partner.

Microsoft fornisce i componenti VDI (Virtual Desktop Infrastructure) per la funzionalità di base distribuita come servizio. Questi componenti includono:

• Servizio Web: il sito Web e l'endpoint rivolti all'utente e restituisce le informazioni di connessione al dispositivo dell'utente.
• Servizio Broker: orchestra le connessioni in ingresso.
• Servizio gateway: un servizio Websocket che fornisce la connettività RDP (Remote Desktop Protocol) dal dispositivo di un utente ovunque si connetta da agli host di sessione che forniscono desktop e app.
• Directory delle risorse: fornisce informazioni per indicare al servizio Web quale dei più database geografici ospita le informazioni di connessione necessarie per ogni utente.
• Database geografico: contiene i file di connessione (.rdp) e le icone per ogni risorsa di cui è stato effettuato il provisioning.

Desktop virtuale Azure usa anche altri servizi globali di Azure, ad esempio Gestione traffico di Azure e Frontdoor di Azure per indirizzare gli utenti ai punti di ingresso di Desktop virtuale Azure più vicini.

L'utente è responsabile della creazione e della gestione degli host sessione, incluse le personalizzazioni e le applicazioni delle immagini del sistema operativo, la connettività di rete virtuale, la resilienza e il backup e il ripristino di tali host di sessione. È anche possibile fornire e gestire le identità utente e controllare l'accesso al servizio. È possibile usare altri servizi di Azure per soddisfare i requisiti, ad esempio:

• Zone di disponibilità di Azure per distribuire gli host di sessione in posizioni dei data center fisicamente separate all'interno di un'area di Azure, ognuna con alimentazione, raffreddamento e rete indipendenti.
• Backup di Azure eseguire il backup e il ripristino degli host di sessione.
• Azure Site Recovery per replicare gli host di sessione in un'altra area di Azure.
• Azure Advisor consente di ottimizzare le risorse di Azure.

Questo diagramma generale illustra i componenti e le responsabilità:

Connessioni utente

Quando un utente vuole accedere ai desktop e alle app in Desktop virtuale Azure, più componenti sono coinvolti nell'esecuzione di tale connessione. Esistono due sequenze separate:

1. Individuazione feed. Il feed è l'elenco di desktop e app disponibili per l'utente.
2. Connessione tramite Remote Desktop Protocol a un host di sessione.

Individuazione feed

Durante l'individuazione dei feed, i desktop e le app disponibili per l'utente vengono popolati nell'app nel dispositivo locale. Il feed contiene tutte le informazioni necessarie per la connessione.

Il processo di individuazione dei feed è il seguente:

1. L'utente potrebbe trovarsi in qualsiasi punto del mondo. Gestione traffico di Azure instrada il dispositivo dell'utente all'istanza più vicina del servizio Web Desktop virtuale Azure in base al metodo di routing del traffico geografico, che usa l'indirizzo IP di origine del dispositivo dell'utente.

2. Il servizio Web si connette al servizio Broker di Desktop virtuale Azure nella stessa area di Azure per recuperare i file RDP e le icone dell'applicazione per il feed dell'utente. Il servizio Broker si connette al database geografico e alla directory delle risorse di Desktop virtuale Azure nella stessa area per recuperare le informazioni.

3. Il servizio broker restituisce i file RDP e le icone dell'applicazione al servizio Web, che restituisce le informazioni al dispositivo dell'utente.

   Di seguito è riportato un diagramma generale che mostra il processo di individuazione dei feed in una singola area di Azure:

   

   Il database geografico contiene solo le informazioni necessarie per desktop e app dai pool di host nelle stesse aree di Azure coperte dall'area geografica. Se l'utente viene assegnato a desktop o app da un pool di host coperto da un'area geografica diversa, la directory delle risorse indica al servizio Web di connettersi al servizio Broker e al database geografico nell'area di Azure corretta.

   Ecco un diagramma generale che mostra il processo di individuazione dei feed per un pool di host in un'area di Azure coperta da un'area geografica diversa:

   

Connessione RDP

Quando un utente si connette a un desktop o a un'app dal feed, la connessione RDP viene stabilita come segue:

1. Tutte le sessioni remote iniziano con una connessione a Frontdoor di Azure, che fornisce il punto di ingresso globale a Desktop virtuale Azure. Frontdoor di Azure determina il servizio gateway Desktop virtuale Azure con la latenza più bassa per il dispositivo dell'utente e indirizza la connessione a essa

2. Il servizio gateway si connette al servizio broker nella stessa area di Azure. Il servizio gateway consente agli host di sessione di trovarsi in qualsiasi area e di essere comunque accessibili agli utenti.

3. Il servizio broker acquisisce e orchestra la connessione tra il dispositivo dell'utente e l'host sessione. Il servizio broker indica all'agente Desktop virtuale Azure in esecuzione nell'host di sessione di connettersi allo stesso servizio gateway connesso al dispositivo dell'utente.

4. A questo punto viene eseguito uno dei due tipi di connessione, a seconda della configurazione e dei protocolli di rete disponibili:

   1. Trasporto con connessione inversa: dopo che sia l'host client che l'host sessione sono connessi al servizio gateway, avvia l'inoltro del traffico RDP usando Transmission Control Protocol (TCP) tra il client e l'host sessione. Il trasporto con connessione inversa è il tipo di connessione predefinito.

   2. RDP Shortpath: viene creato un trasporto diretto basato su USER Datagram Protocol (UDP) tra il dispositivo dell'utente e l'host sessione, ignorando il servizio gateway.

Ecco un diagramma generale che illustra il processo di connessione RDP:

Suggerimento

Per informazioni tecniche più dettagliate sulla connettività di rete, vedere Informazioni sulla connettività di rete di Desktop virtuale Azure e RDP Shortpath per Desktop virtuale Azure.

Resilienza del servizio

Desktop virtuale Azure è progettato per essere resiliente agli errori e offrire agli utenti un servizio affidabile. Il servizio è progettato per essere resiliente agli errori dei singoli componenti e per poter eseguire rapidamente il ripristino da errori.

I componenti gestiti da Microsoft di Desktop virtuale Azure si trovano attualmente in circa 40 aree di Azure per essere più vicini agli utenti e fornire un servizio resiliente. La resilienza è stata implementata a livello globale, geografico e all'interno di un'area di Azure nei modi seguenti:

• Gestione traffico di Azure indirizza il traffico per il servizio Web e Frontdoor di Azure indirizza il traffico per il servizio gateway. Se si verifica un'interruzione che causa un'interruzione del servizio Web o del gateway non disponibile da un'area di Azure o un'interruzione completa dell'area, il traffico viene reindirizzato alla successiva istanza disponibile più vicina nell'area più vicina. Il reindirizzamento del traffico consente agli utenti di stabilire ancora nuove connessioni.

• Il database geografico usa database SQL di Azure funzionalità di failover e replica dei dati all'interno di ogni area geografica. Se si verifica un'interruzione del database, il database esegue il failover nella replica secondaria e viene ripresa la normale operazione. Durante il failover, si verifica un breve periodo di tempo in cui le nuove connessioni non riescono fino al completamento del failover, ma questo failover non influisce sulle connessioni esistenti.

• La directory delle risorse, il servizio Broker, il servizio Web e il servizio gateway sono tutti disponibili in ognuna delle aree di Azure in cui si trovano i componenti gestiti da Microsoft per Desktop virtuale Azure. Ogni componente ha più istanze in modo che non vi sia un singolo punto di errore. All'interno di ogni area di Azure sono presenti almeno sei istanze distinte e separate o cluster di ogni componente che opera in modo indipendente per resistere agli errori dell'istanza.

  Ad esempio, un'area ha istanze sufficienti del servizio gateway per soddisfare la domanda, ma anche con capacità sufficiente per gestire anche gli errori di tali istanze. Se un'istanza del servizio gateway ha esito negativo, vengono eliminate tutte le connessioni RDP basate su TCP inoltrate tramite tale particolare istanza del servizio gateway. Quando questi utenti disconnessi si riconnettono, le istanze rimanenti gestiscono le richieste e riconnettono ogni utente alla sessione esistente. Tutte le altre sessioni gestite da altre istanze del servizio gateway non sono interessate.

Ecco un diagramma generale che illustra come i componenti gestiti da Microsoft sono interconnessi:

Gli altri servizi di Azure su cui si basa Desktop virtuale Azure sono progettati per essere resilienti e affidabili. Per altre informazioni, vedere Gestione traffico di Azure e Frontdoor di Azure.

Portata globale

Desktop virtuale Azure è un servizio che consente alle organizzazioni di adattarsi alle esigenze dei lavoratori, in particolare lavorando in remoto. Offre un modo sicuro, affidabile e flessibile per distribuire desktop e applicazioni praticamente ovunque. Desktop virtuale Azure è progettato per essere resiliente, usando funzionalità e servizi di Azure che consentono di garantire un servizio a disponibilità elevata per i carichi di lavoro.

Ecco una mappa che illustra la portata globale di Desktop virtuale Azure:

Contenuto correlato

Per informazioni sui percorsi archiviati da Desktop virtuale Azure per gli oggetti servizio, vedere Posizioni dei dati per Desktop virtuale Azure.