Considerazioni sulla rete e sulla connettività per i carichi di lavoro di Desktop virtuale Azure

Questo articolo illustra l'area di progettazione della rete e della connettività di un carico di lavoro di Desktop virtuale Azure. È fondamentale progettare e implementare funzionalità di rete di Azure per la zona di destinazione di Desktop virtuale Azure. Come base, questo articolo usa diversi principi e raccomandazioni per l'architettura della zona di destinazione su scala aziendale di Azure Well-Architected Framework. Basandosi su queste linee guida, questo articolo illustra come gestire la topologia di rete e la connettività su larga scala.

Latenza client

Impatto: Efficienza delle prestazioni

La latenza tra gli utenti finali e gli host di sessione è un aspetto chiave che influisce sull'esperienza utente di Desktop virtuale Azure. È possibile usare lo strumento di stima dell'esperienza desktop virtuale Azure per stimare i tempi di round trip di connessione (RTT). In particolare, questo strumento stima gli RTT dalle posizioni degli utenti tramite il servizio Desktop virtuale Azure in ogni area di Azure in cui si distribuiscono macchine virtuali (VM).

Per valutare la qualità dell'esperienza dell'utente finale:

• Testare latenze end-to-end negli ambienti di sviluppo, test e modello di verifica. Questo test deve tenere conto dell'esperienza effettiva degli utenti. Deve considerare fattori come le condizioni di rete, i dispositivi degli utenti finali e la configurazione delle macchine virtuali distribuite.
• Tenere presente che la latenza è solo un aspetto della connettività con i protocolli remoti. La larghezza di banda e il carico di lavoro dell'utente influiscono anche sull'esperienza dell'utente finale.

Consigli

• Usare Lo strumento di stima dell'esperienza desktop virtuale Azure per raccogliere i valori di latenza stimati.
• Testare le latenze dalle reti virtuali di Azure ai sistemi locali.
• Usare un tunnel diviso basato sul protocollo UDP (User Datagram Protocol) per i client che usano una connessione VPN da punto a sito (P2S).
• Usare Remote Desktop Protocol (RDP) Shortpath con una rete gestita per i client sul sito che usano una VPN o Azure ExpressRoute.

Connettività locale (rete ibrida)

Impatto: efficienza delle prestazioni, eccellenza operativa

Alcune organizzazioni usano modelli ibridi che includono risorse locali e cloud. In molti casi ibridi, i flussi di lavoro degli utenti finali eseguiti in Desktop virtuale Azure devono raggiungere risorse locali, ad esempio servizi condivisi o della piattaforma, dati o applicazioni.

Quando si implementa la rete ibrida, esaminare le procedure consigliate e le raccomandazioni nell'articolo Topologia e connettività di rete Cloud Adoption Framework.

È importante allinearsi al modello di ridimensionamento di Desktop virtuale Azure descritto in Integrare un carico di lavoro desktop virtuale Azure con le zone di destinazione di Azure. Per seguire questo modello:

• Valutare i requisiti di latenza e larghezza di banda dei flussi di lavoro di Desktop virtuale Azure che si connettono ai sistemi locali. Queste informazioni sono fondamentali quando si progetta l'architettura di rete ibrida.
• Assicurarsi che non siano presenti indirizzi IP sovrapposti tra le subnet di Desktop virtuale Azure e le reti locali. È consigliabile assegnare l'attività di indirizzamento IP agli architetti di rete proprietari della sottoscrizione di connettività.
• Assegnare a ogni area di destinazione di Desktop virtuale Azure la propria rete virtuale e la configurazione della subnet.
• Ridimensionare le subnet in modo appropriato considerando la potenziale crescita quando si determina la quantità di spazio indirizzi IP necessario.
• Usare la notazione CIDR (Smart IP Classless Inter-Domain Routing) per evitare di sprecare spazio indirizzi IP.

Consigli

• Esaminare le procedure consigliate per connettere le reti virtuali di Azure ai sistemi locali.
• Testare le latenze dalle reti virtuali di Azure ai sistemi locali.
• Assicurarsi che non vengano usati indirizzi IP sovrapposti nella zona di destinazione di Desktop virtuale Azure.
• Assegnare a ogni area di destinazione di Desktop virtuale Azure la propria rete virtuale e la configurazione della subnet.
• Prendere in considerazione la potenziale crescita quando si ridimensionano le subnet di Desktop virtuale Azure.

Connettività in più aree

Impatto: efficienza delle prestazioni, ottimizzazione dei costi

Per la distribuzione di Desktop virtuale Azure in più aree per offrire la migliore esperienza possibile agli utenti finali, la progettazione deve prendere in considerazione i fattori seguenti:

• Servizi della piattaforma, ad esempio identità, risoluzione dei nomi, connettività ibrida e servizi di archiviazione. La connettività dagli host di sessione di Desktop virtuale Azure a questi servizi è fondamentale per il funzionamento del servizio. Di conseguenza, la progettazione ideale mira a ridurre la latenza dalle subnet della zona di destinazione di Desktop virtuale Azure a questi servizi. È possibile raggiungere questo obiettivo replicando i servizi in ogni area o rendendoli disponibili tramite la connessione con la latenza più bassa possibile.
• Latenza dell'utente finale. Quando si selezionano le posizioni da usare per una distribuzione in più aree di Desktop virtuale Azure, è importante tenere conto della latenza che gli utenti riscontrano quando si connettono al servizio. È consigliabile raccogliere i dati di latenza dal popolamento degli utenti finali usando lo strumento di stima dell'esperienza desktop virtuale Azure quando si selezionano le aree di Azure in cui distribuire gli host di sessione.

Considerare anche i fattori seguenti:

• Dipendenze dell'applicazione tra aree.
• Disponibilità dello SKU della macchina virtuale.
• Costi di rete associati a internet in uscita, traffico tra aree e traffico ibrido (locale) richiesto dall'applicazione o dalle dipendenze del carico di lavoro.
• Carico aggiuntivo che la funzionalità cache cloud FSLogix inserisce nella rete. Questo fattore è rilevante solo se si usa questa funzionalità per replicare i dati del profilo utente tra aree diverse. Considerare anche il costo dell'aumento del traffico di rete e dell'archiviazione usati da questa funzionalità.

Se possibile, usare GLI SKU delle macchine virtuali che offrono una rete accelerata. Nei carichi di lavoro che usano una larghezza di banda elevata, la rete accelerata può ridurre l'utilizzo e la latenza della CPU.

La larghezza di banda disponibile della rete influisce notevolmente sulla qualità delle sessioni remote. Di conseguenza, è consigliabile valutare i requisiti di larghezza di banda di rete per gli utenti per garantire che sia disponibile una larghezza di banda sufficiente per le dipendenze locali.

Consigli

• Replicare la piattaforma e i servizi condivisi in ogni area ogni volta che i criteri interni consentono di.
• Se possibile, usare GLI SKU delle macchine virtuali che offrono una rete accelerata.
• Includere le stime della latenza dell'utente finale nel processo di selezione dell'area.
• Prendere in considerazione i tipi di carico di lavoro quando si stimano i requisiti di larghezza di banda e monitorare le connessioni utente reali.

Sicurezza di rete

Impatto: sicurezza, ottimizzazione dei costi, eccellenza operativa

Tradizionalmente, la sicurezza di rete è stata il fulcro delle attività di sicurezza aziendali. Tuttavia, il cloud computing ha aumentato la necessità che i perimetri di rete siano più poro e molti utenti malintenzionati hanno imparato l'arte degli attacchi sugli elementi del sistema di gestione delle identità. I punti seguenti offrono una panoramica dei requisiti minimi del firewall per la distribuzione di Desktop virtuale Azure. Questa sezione fornisce anche consigli per la connessione a un firewall e il raggiungimento delle app che richiedono questo servizio.

• I controlli di rete tradizionali basati su un approccio Intranet attendibile non forniscono in modo efficace garanzie di sicurezza per le applicazioni cloud.
• L'integrazione dei log dai dispositivi di rete e dal traffico di rete non elaborato offre visibilità sulle potenziali minacce alla sicurezza.
• La maggior parte delle organizzazioni finisce per aggiungere più risorse alle reti rispetto a quanto inizialmente pianificato. Di conseguenza, è necessario effettuare il refactoring degli schemi di indirizzo IP e subnet per supportare le risorse aggiuntive. Questo processo richiede un utilizzo intensivo del lavoro. Esiste un valore di sicurezza limitato nella creazione di un numero elevato di subnet di piccole dimensioni e quindi nel tentativo di eseguire il mapping dei controlli di accesso alla rete, ad esempio i gruppi di sicurezza, a ognuno di essi.

Per informazioni generali sulla protezione degli asset inserendo controlli sul traffico di rete, vedere Raccomandazioni per la rete e la connettività.

Consigli

• Comprendere le configurazioni necessarie per usare Firewall di Azure nella distribuzione. Per altre informazioni, vedere Usare Firewall di Azure per proteggere le distribuzioni di Desktop virtuale Azure.
• Creare gruppi di sicurezza di rete e gruppi di sicurezza delle applicazioni per segmentare il traffico di Desktop virtuale Azure. Questa procedura consente di isolare le subnet controllando i flussi di traffico.
• Usare i tag del servizio invece di indirizzi IP specifici per i servizi di Azure. Poiché gli indirizzi cambiano, questo approccio riduce al minimo la complessità dell'aggiornamento frequente delle regole di sicurezza di rete.
• Acquisire familiarità con gli URL necessari per Desktop virtuale Azure.
• Usare una tabella di route per consentire al traffico di Desktop virtuale Azure di ignorare le regole di tunneling forzate usate per instradare il traffico a un firewall o a un'appliance virtuale di rete. In caso contrario, il tunneling forzato può influire sulle prestazioni e sull'affidabilità della connettività dei client.
• Usare gli endpoint privati per proteggere soluzioni PaaS (Platform as a Service), ad esempio File di Azure e Azure Key Vault. Si consideri tuttavia il costo dell'uso di endpoint privati.
• Modificare le opzioni di configurazione per collegamento privato di Azure. Quando si usa questo servizio con Desktop virtuale Azure, è possibile disabilitare gli endpoint pubblici per i componenti del piano di controllo di Desktop virtuale Azure e usare endpoint privati per evitare di usare indirizzi IP pubblici.
• Implementare criteri firewall rigorosi se si usano Active Directory Domain Services (AD DS). Basare i criteri sul traffico richiesto all'interno del dominio.
• È consigliabile usare Firewall di Azure o filtro Web dell'appliance virtuale di rete per proteggere l'accesso degli utenti finali a Internet dagli host di sessione di Desktop virtuale Azure.

Endpoint privati (collegamento privato)

Impatto: Sicurezza

Per impostazione predefinita, le connessioni alle risorse di Desktop virtuale Azure vengono stabilite tramite un endpoint accessibile pubblicamente. In alcuni scenari, il traffico deve usare connessioni private. Questi scenari possono usare collegamento privato per connettersi privatamente alle risorse desktop virtuale Azure remote. Per altre informazioni, vedere collegamento privato di Azure con Desktop virtuale Azure. Quando si crea un endpoint privato, il traffico tra la rete virtuale e il servizio rimane nella rete Microsoft. Il servizio non è esposto alla rete Internet pubblica.

È possibile usare gli endpoint privati di Desktop virtuale Azure per supportare gli scenari seguenti:

• I client o gli utenti finali e le macchine virtuali host sessione usano entrambe le route private.
• I client o gli utenti finali usano route pubbliche mentre le macchine virtuali host di sessione usano route private.

Gli host di sessione di Desktop virtuale Azure hanno gli stessi requisiti di risoluzione dei nomi di qualsiasi altro carico di lavoro IaaS (Infrastructure as a Service). Di conseguenza, gli host di sessione richiedono la connettività ai servizi di risoluzione dei nomi configurati per risolvere gli indirizzi IP dell'endpoint privato. Di conseguenza, quando si usano endpoint privati, è necessario configurare impostazioni DNS specifiche. Per informazioni dettagliate, vedere Configurazione DNS dell'endpoint privato di Azure.

collegamento privato è disponibile anche per altri servizi di Azure che funzionano insieme a Desktop virtuale Azure, ad esempio File di Azure e Key Vault. È consigliabile implementare anche endpoint privati per questi servizi per mantenere privato il traffico.

Consigli

• Informazioni sul funzionamento collegamento privato con Desktop virtuale Azure. Per altre informazioni, vedere collegamento privato di Azure con Desktop virtuale Azure.
• Informazioni sulle configurazioni DNS necessarie per gli endpoint privati di Azure. Per altre informazioni, vedere Configurazione DNS dell'endpoint privato di Azure.

RDP Shortpath

Impatto: efficienza delle prestazioni, ottimizzazione dei costi

RDP Shortpath è una funzionalità di Desktop virtuale Azure disponibile per le reti gestite e non gestite.

• Per le reti gestite, RDP Shortpath stabilisce una connessione diretta tra un client desktop remoto e un host di sessione. Il trasporto è basato su UDP. Rimuovendo punti di inoltro aggiuntivi, RDP Shortpath riduce il tempo di round trip, migliorando l'esperienza utente nelle applicazioni sensibili alla latenza e nei metodi di input. Per supportare RDP Shortpath, un client desktop virtuale Azure necessita di una linea diretta di visualizzazione all'host sessione. Il client deve anche installare il client Desktop di Windows ed eseguire Windows 11 o Windows 10.
• Per le reti non gestite, sono possibili due tipi di connessione:
  • La connettività diretta viene stabilita tra il client e l'host sessione. L'attraversamento semplice sotto STUN (Network Address Translation) e lo stabilimento di connettività interattiva (ICE) vengono usati per stabilire la connessione. Questa configurazione migliora l'affidabilità del trasporto per Desktop virtuale Azure. Per altre informazioni, vedere Funzionamento di Shortpath RDP.
  • Viene stabilita una connessione UDP indiretta. Supera le limitazioni NAT (Network Address Translation) usando il protocollo NAT (Traversal Using Relay NAT) con un inoltro tra il client e l'host di sessione.

Con il trasporto basato sul protocollo TCP (Transmission Control Protocol), il traffico in uscita da una macchina virtuale a un client RDP passa attraverso un gateway Desktop virtuale Azure. Con RDP Shortpath, il traffico in uscita passa direttamente tra l'host sessione e il client RDP tramite Internet. Questa configurazione consente di eliminare un hop e migliorare la latenza e l'esperienza dell'utente finale.

Consigli

• Usare RDP Shortpath per migliorare la latenza e l'esperienza dell'utente finale.
• Tenere presente la disponibilità dei modelli di connessione Shortpath RDP.
• Tenere presente l'addebito di shortpath RDP.

Passaggi successivi

Dopo aver esaminato la rete e la connettività in Desktop virtuale Azure, esaminare le procedure consigliate per il monitoraggio dell'infrastruttura e del carico di lavoro.

Usare lo strumento di valutazione per valutare le scelte di progettazione.