Azure Virtual Desktop ibrido per VDI on-premises

Introduzione

Azure Virtual Desktop Hybrid offre alle organizzazioni un'altra via tra il VDI tradizionale on-premises e i desktop completamente ospitati su Azure. Questo articolo spiega come funziona l'architettura, come Azure Arc collega gli host di sessione locali ad AVD, quali cambiamenti ci sono per l'infrastruttura VDI esistente e quali limitazioni rimangono. Esamina anche quando Hybrid AVD ha senso e cosa i team IT dovrebbero valutare prima di adottarlo.

Cos'è Azure Virtual Desktop Hybrid?

Azure Virtual Desktop Hybrid è un modello di distribuzione in cui il servizio Azure Virtual Desktop è ancora ospitato e gestito da Microsoft in Azure, ma gli host di sessione Windows che forniscono i desktop e le app sono on-premises.

Microsoft utilizza Azure Arc per stabilire la connettività tra gli ambienti. Tutti i computer on-premises supportati saranno server abilitati ad Azure Arc. Successivamente, l'estensione Azure Virtual Desktop Arc installa i componenti AVD richiesti e registra questo computer come host di sessione in un pool di host AVD.

Tutto è più o meno lo stesso per l'utente finale come se stesse utilizzando AVD ospitato in Azure. Gli utenti accedono ai desktop o alle app assegnati tramite Windows App. Tuttavia, la differenza è che il carico di lavoro di Windows sarà fornito dall'infrastruttura del cliente e non dal calcolo di Azure.

Quindi c'è una separazione dell'infrastruttura dove:

Componente	Dove viene eseguito	Chi lo gestisce
servizio AVD e intermediazione	Azure	Microsoft
Pool di host, gruppi di applicazioni e assegnazioni	Azure	Il cliente li configura
Host di sessione Windows	In sede	Cliente
Hypervisor o infrastruttura fisica	In sede	Cliente
Sistema operativo e applicazioni dell'host di sessione	In sede	Cliente
Networking e archiviazione locale	In sede	Cliente
Integrazione di Azure Arc	Azure + in sede	Dipendenza condivisa

Il principale insegnamento qui è che "ibrido" è una descrizione della distribuzione di elementi distinti nell'architettura VDI. Azure Virtual Desktop, di per sé, non è mai diventato una soluzione completamente on-premises.

Come funziona Azure Virtual Desktop Hybrid?

L'architettura inizia con le macchine che forniscono desktop o applicazioni. Le organizzazioni forniscono macchine virtuali Windows supportate o dispositivi fisici headless supportati sulla propria infrastruttura.

L'agente Azure Connected Machine registra ogni host di sessione con Azure Arc. Un'estensione Azure Virtual Desktop Arc può quindi installare i componenti AVD richiesti e registrare la macchina con un pool di host AVD.

Azure Arc non fornisce né gestisce la macchina virtuale sottostante. L'host della sessione fa parte dell'infrastruttura locale dell'organizzazione, il che significa che il team IT dell'organizzazione è responsabile del ciclo di vita dell'host della sessione, della capacità e della piattaforma di virtualizzazione sottostante.

Quando un utente si connette, Azure Virtual Desktop fornisce le capacità lato servizio per scoprire risorse, autenticare l'accesso e mediare la sessione. Il carico di lavoro Windows effettivo viene eseguito sull'host di sessione locale.

Questa architettura separa il servizio AVD dagli host di sessione, differenziando AVD Ibrido da entrambi. VDI tradizionale on-premises e AVD ospitato su Azure standard: Microsoft gestisce il servizio cloud, ma il cliente continua a gestire l'infrastruttura di calcolo.

Come cambia l'AVD ibrido un ambiente VDI esistente on-premises?

Per gli ambienti VDI esistenti, la sfida non è solo se i server attuali possono essere mantenuti nel datacenter, ma quali livelli dell'architettura esistente sono stati mantenuti, quale AVD è stato sostituito e quali responsabilità operative sono state mantenute dall'organizzazione.

L'Existing Compute può rimanere in sede

A differenza di una migrazione completa di Azure AVD, in cui il calcolo dell'host di sessione viene spostato su Azure, questo non richiede modifiche agli host di sessione esistenti nel datacenter.

Le organizzazioni possono sfruttare macchine virtuali Windows supportate sul loro hypervisor preferito nei loro datacenter on-premises. Questo può essere utile nei casi in cui esista un'infrastruttura di virtualizzazione sostanziale, o le applicazioni dipendono fortemente dai sistemi on-premises esistenti.

La presenza di hardware esistente non implica che l'ambiente VDI rimanga invariato, tuttavia. Gli host di sessione devono essere messi in conformità con specifiche di Microsoft e registrati come abilitati per Azure Arc prima di poter essere utilizzati con Azure Virtual Hybrid Desktop.

Il piano di controllo VDI si sposta su Azure

Le differenze architettoniche più significative appaiono sopra gli host di sessione.

Invece di gestire l'intero stack di distribuzione desktop internamente, l'organizzazione utilizza la piattaforma Azure Virtual Desktop. Microsoft espone i componenti principali del servizio per la scoperta delle risorse, il brokeraggio e la connettività del gateway.

Le organizzazioni mantengono la responsabilità di configurare i pool di host, i gruppi di applicazioni, gli spazi di lavoro e i diritti degli utenti, ma queste risorse fanno ora parte dell'architettura AVD. I broker, i gateway e i componenti di gestione on-premises precedenti potrebbero non dover più svolgere le stesse funzioni.

La gestione dell'infrastruttura locale rimane

Spostare il livello di servizio su Azure non rende l'infrastruttura di supporto gestita da Microsoft.

I team IT mantengono la responsabilità per la fornitura, la patching e la manutenzione dell'hardware locale, dei sistemi operativi, delle applicazioni, della rete, dello storage e della piattaforma di virtualizzazione sottostante. Microsoft documenta esplicitamente che Azure Virtual Desktop Hybrid non fornisce VM host di sessione on-premises né gestisce il loro stato di alimentazione.

Hybrid AVD dovrebbe essere inteso come una redistribuzione delle responsabilità VDI piuttosto che un passaggio dell'intero stack di soluzioni a Microsoft.

In quali casi ha senso mantenere gli host delle sessioni AVD in loco?

Se Azure fornisce già il servizio AVD, scegliere di mettere quell'host di sessione in Azure potrebbe sembrare il percorso più semplice. L'ibrido entra in gioco quando c'è una giustificazione tecnica, economica o operativa per mantenere i carichi di lavoro nel datacenter.

Applicazioni legacy e dipendenze locali

Le applicazioni che vengono virtualizzate sono spesso app Windows che si basano fortemente su database locali, condivisioni di file, servizi di autenticazione, periferiche o altri sistemi backend.

Non guadagni molto mettendo l'host della sessione in Azure ma lasciando le dipendenze dell'applicazione on-premises, poiché aggiungerai solo latenza di rete al mix. Rimanere vicino al back end evita di dover stravolgere l'architettura dell'applicazione solo per cambiare da dove si connettono gli utenti finali.

Questo è particolarmente vero per applicazioni legacy di business che sono stati progettati per funzionare in un ambiente di rete locale.

Requisiti di posizione dei dati e infrastruttura

Alcune aziende necessitano che determinati carichi di lavoro o dati risiedano su infrastrutture sotto il loro controllo per motivi normativi, contrattuali o operativi.

Hybrid AVD consente l'elaborazione di desktop e app di rimanere locale mentre utilizza Azure per il servizio di distribuzione desktop. I team IT dovrebbero comunque analizzare attentamente questa opzione architettonica rispetto ai loro requisiti di conformità poiché il modello ibrido si basa ancora su Microsoft Azure.

Investimento esistente nel datacenter

Le organizzazioni con capacità di riserva disponibile in server, storage e risorse di virtualizzazione potrebbero avere pochi incentivi immediati a cambiare.

L'AVD ibrido potrebbe consentire a tali aziende di acquisire nuova capacità a ondate, mentre le risorse di calcolo esistenti continuano a gestire i carichi di lavoro, mentre il piano di controllo viene trasformato attorno ad esso. L'architettura si presta anche a una modernizzazione iterativa, poiché diversi carichi di lavoro possono essere migrati a ritmi diversi.

Carichi di lavoro sensibili alla latenza del backend

Per alcune applicazioni, la prossimità dell'host della sessione alle risorse che consuma è più importante della prossimità dell'host della sessione all'utente finale.

Le applicazioni che effettuano chiamate frequenti a database locali, sistemi di archiviazione o altre infrastrutture potrebbero non funzionare altrettanto bene se queste dipendenze sono distribuite su una WAN. Mantenendo la sessione di Windows locale, la prossimità a queste risorse può essere mantenuta.

Quando l'AVD ibrido potrebbe non essere la scelta giusta

Il valore di mantenere gli host di sessione in sede è ridotto se l'obiettivo dell'organizzazione è eliminare l'infrastruttura del datacenter piuttosto che mantenerla. In un tale scenario, l'uso di AVD ospitato su Azure potrebbe adattarsi meglio al modello operativo desiderato.

I team IT dovrebbero anche considerare se hanno realmente bisogno del modello di servizio Azure Virtual Desktop. Se il requisito principale è il pubblicazione sicura di applicazioni o desktop Windows centralizzati mentre si mantiene il controllo diretto dell'infrastruttura, un piano di controllo VDI dipendente da Azure potrebbe introdurre una complessità architettonica non necessaria.

L'Hybrid AVD elimina VPN e gateway RD?

Azure Virtual Desktop elimina molte delle complessità della connettività esterna consentendo alle organizzazioni di evitare di esporre singoli host di sessione a Internet o di implementare un Gateway Desktop Remoto (RD Gateway) per AVD.

AVD utilizza l'infrastruttura dei servizi di Microsoft per connettersi attraverso il servizio Microsoft. Il trasporto predefinito utilizza una connessione inversa basata su TCP, mentre RDP Shortpath può negoziare un trasporto basato su UDP se la rete e la configurazione lo supportano.

Per le organizzazioni che attualmente hanno un ambiente VDI che utilizza una connessione in ingresso al Protocollo Desktop Remoto (RDP) così come altri metodi come l'accesso VPN o gateway RD gestiti localmente per accesso remoto questo potrebbe cambiare significativamente l'architettura dell'accesso esterno.

I requisiti di connettività di rete non sono eliminati. Gli host di sessione on-premises devono comunque connettersi ai servizi Azure appropriati, mentre le applicazioni necessitano di un accesso affidabile alle dipendenze locali. Pertanto, considerazioni sulla connettività come DNS, identità, configurazione del firewall, routing e resilienza sono ancora elementi di design importanti.

Quali sono le limitazioni di Azure Virtual Desktop Hybrid?

Hybrid AVD offre flessibilità di distribuzione, ma ci sono alcune differenze importanti rispetto all'AVD ospitato su Azure che possono influenzare l'architettura e le operazioni.

Microsoft attualmente definisce diversi capacità di gestione degli host di sessione non supportato per Hybrid AVD:

• Gestione dell'alimentazione
• Azure Virtual Desktop Autoscale
• Avvia VM alla connessione
• Configurazione dell'Host di Sessione

Le imprese sarebbero responsabili della fornitura di queste capacità attraverso il loro hypervisor, script, automazione o altri strumenti.

Inoltre, il supporto del sistema operativo è diverso poiché non c'è supporto per Azure Virtual Desktop Hybrid con Windows 10 Enterprise multi-session e Windows 11 Enterprise multi-session. Questa è una differenza significativa perché i sistemi operativi client Windows multi-session sono una caratteristica chiave di AVD ospitato su Azure.

I requisiti di licenza devono essere esaminati attentamente considerando il sistema operativo e il caso d'uso previsti. Deve essere confermato se i requisiti per la licenza ibrida di Azure Virtual Desktop di Microsoft si applicano oltre alle licenze VDI, ai servizi di desktop remoto o alle licenze Microsoft 365 esistenti.

Infine, avere host di sessione locali non rende il deployment di AVD indipendente dal cloud, poiché il servizio Azure Virtual Desktop gestito da Microsoft continua a essere una parte integrante dell'architettura.

Azure-Hosted AVD vs Hybrid AVD vs Traditional On-Premises VDI

Versione finale della frase (riscritta, utilizzando parole diverse, con alcune frasi cambiate nella struttura o nella lunghezza):

	VDI tradizionale on-premises	Desktop Virtuale Ibrido Azure	Azure-Hosted AVD
Host di sessione	In sede	In sede	Azure
servizio VDI/piano di controllo	Di solito infrastruttura cliente/fornitore	Microsoft AVD in Azure	Microsoft AVD in Azure
Hypervisor locale richiesto	Tipicamente sì	Sì per host basati su VM	No
Gestione locale dei computer	Cliente	Cliente	Non applicabile al calcolo locale
Funzionalità del ciclo di vita delle VM AVD native	No	Limitato	Supporto più ampio
Prossimità alle applicazioni locali	Alto	Alto	Dipende dal design della rete
dipendenza da Azure	Dipendente dal prodotto	Sì	Sì
Consumo di calcolo Azure	No	Non per host di sessione locali	Sì

Pertanto, l'AVD ibrido ha un'architettura di compromesso, in cui i carichi di lavoro vengono forniti dal cloud (gestito da Microsoft), ma il calcolo locale è gestito dal cliente.

Tale scelta architettonica è giustificabile solo se c'è un vantaggio nel mantenere i carichi di lavoro locali.

Come dovrebbero i team IT valutare un passaggio a AVD ibrido?

Una valutazione AVD ibrida dovrebbe iniziare non con Azure, ma con carichi di lavoro e dipendenze.

Identificare quali applicazioni e desktop devono essere mantenuti in sede e documentare le loro dipendenze da database, servizi di file, sistemi di identità, periferiche, archiviazione e altre infrastrutture. Questo rende possibile stabilire se mantenere gli host di sessione in sede abbia qualche merito architettonico.

Lo stato attuale dello stack VDI dovrebbe essere mappato al modello AVD. Quali broker, gateway e servizi di gestione saranno sostituiti da Azure Virtual Desktop? Quali responsabilità operative rimarranno?

La gestione del ciclo di vita degli host di sessione è una considerazione chiave. Se la piattaforma VDI esistente include provisioning automatico, avvio/arresto o scalabilità delle VM, valuta se tali capacità sono disponibili in Hybrid AVD piuttosto che presumere che il piano di controllo di Azure le sostituirà.

Identità, networking, licensing, resilienza e responsabilità operative devono essere valutate come un gruppo. L'obiettivo non è solo determinare se le macchine esistenti possono essere registrate con Azure Virtual Desktop, ma se separare l'infrastruttura VDI tra Azure e il datacenter produrrà un ambiente più semplice e sostenibile.

Cerchi un modo più semplice per fornire applicazioni e desktop Windows?

L'AVD ibrido può avere senso quando un'organizzazione desidera specificamente Azure Virtual Desktop mantenendo i server di sessione in sede. Ma non ogni organizzazione ha bisogno di suddividere la propria architettura di distribuzione desktop tra un servizio gestito da Azure e un'elaborazione gestita localmente.

Dove il requisito è principalmente quello di pubblicare applicazioni Windows o desktop completi in modo sicuro dall'infrastruttura Windows esistente, TSplus Remote Access fornisce un'alternativa più diretta. Le organizzazioni possono fornire applicazioni e desktop tramite accesso compatibile con RDP o basato su browser HTML5, mantenendo il controllo su dove viene eseguita l'infrastruttura di supporto.

Conclusione

Azure Virtual Desktop Hybrid offre un compromesso tra VDI tradizionale on-premises e AVD ospitato su Azure. Sposta i servizi chiave di distribuzione desktop su Azure, consentendo ai server di sessione Windows e ai loro carichi di lavoro di rimanere all'interno dell'infrastruttura esistente.

Il fattore decisivo è se mantenere quei carichi di lavoro locali fornisce un chiaro vantaggio tecnico o operativo. I team IT dovrebbero valutare insieme le dipendenze delle applicazioni, la gestione dell'infrastruttura, il networking, la licenza e la dipendenza da Azure prima di decidere se Hybrid AVD semplifica realmente il loro ambiente VDI.