Considerazioni sull'organizzazione delle risorse per Desktop virtuale Azure

La struttura dell'archiviazione delle risorse determina direttamente le opzioni per l'implementazione della gestione e della governance delle risorse. Questo articolo contiene considerazioni e consigli utili per progettare la struttura di un'organizzazione.

Usare le indicazioni fornite in questa sezione per garantire l'organizzazione delle risorse e la segmentazione tra:

• gerarchie dei gruppi di gestione
• sottoscrizioni
• resource groups
• di destinazione sicure

Prendere in considerazione l'uso di strategie di assegnazione di tag per organizzare le risorse.

Considerazioni relative alla progettazione

Le sezioni seguenti elencano gli aspetti da considerare quando si pianifica la struttura di Desktop virtuale Azure dell'organizzazione.

Numero di macchine virtuali

Quante macchine virtuali (VM) di Desktop virtuale Azure sono necessarie per l'organizzazione?

Non distribuire più di 5.000 macchine virtuali in una singola area. È possibile gestire sessioni utente aggiuntive aumentando le singole risorse della macchina virtuale dell'host sessione.

Se invece si gestisce un ambiente aziendale con più di 5.000 macchine virtuali per sottoscrizione in una singola area, è necessario creare più sottoscrizioni di Azure. Inserire queste sottoscrizioni in un'architettura hub-spoke e connetterle tramite il peering di rete virtuale. È possibile aumentare il numero di macchine virtuali distribuendo macchine virtuali in un'area diversa della stessa sottoscrizione.

Aree per la distribuzione host

Quando si distribuiscono host, quali aree è necessario scegliere?

In genere è consigliabile archiviare tutte le risorse nella stessa area di Azure della distribuzione di Desktop virtuale Azure. Le risorse principali coinvolte sono:

• Metadati (oggetti servizi), ad esempio pool di host, gruppi di applicazioni e aree di lavoro
• Calcolo degli host di sessione (Desktop virtuali), ad esempio macchine virtuali, dischi e interfacce di rete.
• Reti virtuali (la rete virtuale in cui gli host sessione sono connessi direttamente)
• Archiviazione (per i profili utente FSLogix)
• Altre risorse, ad esempio raccolte di calcolo di Azure, insiemi di credenziali delle chiavi o immagini.

Altre considerazioni

• La distribuzione di host di sessione nelle aree di Azure più vicine agli utenti riduce i problemi di connettività e latenza di rete e può migliorare le prestazioni.
• Considerare sempre i requisiti di conformità e residenza dei dati a livello di area prima di scegliere un'area specifica.
• Se si eseguono applicazioni in host di sessione in un'area di Azure (come l'India centrale) e devono raggiungere i servizi in un'altra area di Azure (ad esempio Stati Uniti centrali), la latenza delle applicazioni aumenta spesso. Se gli host di sessione sono invece più vicini all'area di Azure con le risorse necessarie (nell'esempio corrente, Stati Uniti centrali), è molto meno probabile che la latenza dell'applicazione aumenti.
• Poiché non è possibile assegnare utenti a un host di sessione in un'area di Azure specifica, non combinare gli host di sessione situati in aree di Azure diverse ( ad esempio, India centrale e Stati Uniti centrali) nello stesso pool di host. Creare invece host di sessione separati per ogni area di Azure.

Suggerimenti per la progettazione

Le sezioni seguenti offrono raccomandazioni per l'etichettatura e l'organizzazione delle risorse in Desktop virtuale Azure.

Denominazione e applicazione di tag

I nomi e gli standard di assegnazione di tag consentono di organizzare le risorse e semplificare la gestione delle risorse, il rilevamento dei costi e la governance.

Mantenere la coerenza tra le risorse per identificare eventuali deviazioni dai criteri concordati. Le linee guida prescrittive per l'assegnazione di tag alle risorse descrivono come uno dei modelli seguenti sia utile per la distribuzione delle procedure di governance. Sono disponibili modelli simili per l'uso dei tag per valutare la conformità alle normative.

Una convenzione di denominazione standardizzata è il punto di partenza per organizzare le risorse ospitate nel cloud. I sistemi di denominazione strutturati correttamente consentono l'identificazione rapida delle risorse sia a scopo di gestione che di contabilità. Se si seguono le convenzioni di denominazione IT esistenti in altre parti dell'organizzazione, valutare se allineare le convenzioni di denominazione del cloud o rendere univoche e separate le convenzioni di denominazione del cloud.

Gruppi di gestione e sottoscrizioni

Raggruppare le risorse in modo logico nei gruppi di gestione in modo da poter impostare come destinazione le assegnazioni di criteri e iniziative con Criteri di Azure.

Creare gruppi di gestione nel gruppo di gestione a livello radice per rappresentare i tipi di carichi di lavoro (archetipi) ospitati e i gruppi di gestione in base alle esigenze di sicurezza, conformità, connettività e funzionalità. Se si usa questa struttura di raggruppamento, è possibile applicare un set di criteri di Azure a livello di gruppo di gestione per tutti i carichi di lavoro che richiedono le stesse impostazioni di sicurezza, conformità, connettività e funzionalità.

Le sottoscrizioni fungono da unità di scala in modo che i carichi di lavoro dei componenti possano essere ridimensionati entro i limiti delle sottoscrizioni della piattaforma. Ricordarsi di prendere in considerazione i limiti delle risorse della sottoscrizione durante le sessioni di progettazione del carico di lavoro.

Le sottoscrizioni specificano un limite di gestione per governance e isolamento, che consente una netta separazione delle problematiche. I diagrammi seguenti illustrano la struttura e i gruppi di risorse che è consigliabile creare e usare come domini amministrativi e scopi del ciclo di vita per ogni area di Azure distribuita.

    - Azure Virtual Desktop Service Objects:  Create a Resource Group for Azure Virtual Desktop Service Objects from Host Pool VMs.  Service objects like Workspaces, Host Pools and Application Groups.  
    - Networking:  Generally created as part of the Cloud Adoption Framework Landing zone
    - Storage:  If not already created as part of Cloud Adoption Framework, create a resource group for storage accounts
    - Session hosts compute: Create a Resource Group for Virtual Machines, Disks and Network Interfaces. These have a different life cycle than the Azure Virtual Desktop Service Objects. 
    - Shared Resources:  Create a Resource Group for shared resources like custom VM images, this encourages self-service so you could have a subscription for each business line, for instance.
    
    - Basic Structure:
        - Subscription (AVD-Shared-Resources)
            - rg-<Azure-Region>-avd-shared-resources
        - Subscription (AVD)
            - rg-<Azure-Region>-avd-<Workload>-service-objects
            - rg-<Azure-Region>-avd-<Workload>-network
            - rg-<Azure-Region>-avd-<Workload>-pool-compute
            - rg-<Azure-Region>-avd-<Workload>-storage

Di seguito è riportato un esempio della struttura consigliata precedente per le risorse di Desktop virtuale Azure già distribuite.

Materiale sussidiario ed esempi aggiuntivi

• Organizzazione delle risorse di Desktop virtuale Azure
• Denominazione e assegnazione di tag in Azure

Passaggi successivi

Informazioni sulla gestione e il monitoraggio per uno scenario su scala aziendale di Desktop virtuale Azure.

Gestione e monitoraggio