Citrix DaaS™

Creare un catalogo di istanze gestite di Amazon WorkSpaces Core

Creare cataloghi di macchine descrive le procedure guidate per la creazione di un catalogo di macchine. Le seguenti informazioni riguardano i dettagli specifici delle istanze gestite di Amazon WorkSpaces Core.

Nota:

Attualmente, è supportata la creazione di cataloghi di VM sia persistenti che non persistenti (la proprietà CleanOnBoot è True o False).

Prerequisiti

Prima di creare un catalogo di istanze gestite di Amazon WorkSpaces Core, è necessario aver completato la creazione di:

  1. Una connessione alle istanze gestite di Amazon WorkSpaces Core. Vedere Connessione alle istanze gestite di Amazon WorkSpaces Core
  2. Un’immagine preparata. Vedere Creare un’immagine preparata per le istanze gestite di Amazon WorkSpaces Core.

Impostazioni di rete durante la preparazione dell’immagine

Durante la preparazione dell’immagine, viene creata una macchina virtuale (VM) di preparazione basata sulla VM originale. Questa VM di preparazione viene disconnessa dalla rete. Per disconnettere la rete dalla VM di preparazione, viene creato un gruppo di sicurezza di rete per negare tutto il traffico in entrata e in uscita. Questo gruppo di sicurezza di rete persiste e viene riutilizzato. Il nome del gruppo di sicurezza di rete è Citrix.XenDesktop.IsolationGroup-GUID, dove GUID viene generato casualmente.

Un catalogo di macchine basato su profilo macchina

È possibile utilizzare un profilo macchina per acquisire le proprietà hardware da un’istanza EC2 (VM) o da una versione di modello di avvio e applicarle alle macchine sottoposte a provisioning. Le proprietà acquisite possono includere, ad esempio, il tipo di tenancy, il tipo di istanza, i gruppi di sicurezza, le mappature di rete, le proprietà del volume EBS, l’ottimizzazione EBS, le opzioni CPU, la capacità di ibernazione e altre configurazioni AWS supportate.

È possibile utilizzare un’istanza AWS EC2 (VM) o una versione di modello di avvio AWS come input del profilo macchina.

  • Nota:

    • Le proprietà del volume EBS sono derivate solo da un profilo macchina.
    • È supportato solo il servizio di metadati dell’istanza (IMDS) V2 e non IMDS V1. Per informazioni, vedere How Instance Metadata Service Version 2 works.

Tenancy AWS

AWS offre le seguenti opzioni di tenancy: tenancy condivisa (il tipo predefinito) e tenancy dedicata. La tenancy condivisa significa che più istanze di Amazon WorkSpaces Core di clienti diversi potrebbero risiedere sullo stesso hardware fisico. La tenancy dedicata significa che le istanze di Amazon WorkSpaces Core vengono eseguite solo su hardware con altre istanze che sono state distribuite.

Nota:

  • Sono supportate solo le istanze dedicate (gli host dedicati non sono attualmente supportati). Altri clienti non utilizzano lo stesso hardware.

Il tipo di tenancy viene acquisito dal profilo macchina

  • Quando si utilizza MCS per creare un catalogo per il provisioning di macchine in AWS, il tipo di tenancy viene acquisito dal profilo macchina.

  • Hardware condiviso: questa impostazione è adatta per la maggior parte delle distribuzioni. Più clienti condividono parti di hardware anche se non interagiscono tra loro. L’utilizzo di hardware condiviso è l’opzione meno costosa per l’esecuzione delle istanze Amazon EC2.
  • Istanza dedicata: questa impostazione è più adatta per distribuzioni con requisiti specifici di sicurezza o conformità. Con un’istanza dedicata, si godono comunque i vantaggi di avere un host separato dagli altri clienti AWS, ma non si paga per l’intero host. Non è necessario preoccuparsi della capacità dell’host, ma viene addebitata una tariffa più alta per le istanze. Inoltre, le istanze dedicate forniscono un supporto limitato per Bring Your Own License (BYOL).

Fatturazione flessibile

Le istanze gestite di Amazon WorkSpaces Core supportano due modalità di fatturazione:

  • Modalità di fatturazione Descrizione
    Mensile Fatturazione fissa, a tariffa mensile. Ideale per desktop persistenti e carichi di lavoro prevedibili.
    Oraria Fatturazione a consumo. Questa è la configurazione predefinita di AWS se non viene specificata esplicitamente alcuna modalità di fatturazione.

Queste opzioni offrono flessibilità per la gestione dei costi di calcolo in base alla persistenza e ai modelli di utilizzo del carico di lavoro.

Questa funzionalità richiede l’uso del servizio di fatturazione di Amazon WorkSpaces. Per impostazione predefinita, MCS utilizza questo servizio per il provisioning e la gestione delle istanze, consentendo di beneficiare di prezzi a tariffa fissa più competitivi per i carichi di lavoro persistenti.

Prerequisiti e considerazioni

  • Configurazione dell’account AWS: l’account AWS deve essere configurato per utilizzare il servizio di fatturazione WorkSpaces. Sebbene gli account AWS siano attivati per impostazione predefinita, alcuni clienti potrebbero richiedere ad AWS di rimanere sul servizio di fatturazione EC2 legacy per l’utilizzo delle istanze gestite di WorkSpaces Core.

    Nota:

    Se l’account utilizza il servizio di fatturazione EC2 legacy, l’opzione di fatturazione Mensile non è disponibile.

  • Connessione host: la fatturazione flessibile è applicabile solo alle connessioni host di Amazon WorkSpaces Core. Non è supportata per le connessioni host AWS EC2 standard.
  • Istanze Spot: le istanze Spot non sono supportate con il servizio di fatturazione WorkSpaces.
  • Fatturazione mista: un account AWS deve utilizzare la fatturazione WorkSpaces o la fatturazione EC2 per le istanze gestite core. Una combinazione di entrambi all’interno di un singolo account non è supportata.
  • Compatibilità: solo tipi di istanza specifici, tipi di piattaforma (OS) e tipi di tenancy sono compatibili con determinate modalità di fatturazione. MCS esegue un controllo preliminare per garantire che le selezioni (Service Offering, Machine Profile e Prepared Image) corrispondano alla modalità di fatturazione scelta.

Vedere Creare un catalogo di macchine con una modalità di fatturazione specifica.

Per la creazione di cataloghi di istanze gestite di Amazon WorkSpaces Core sono necessari un’immagine preparata e un profilo macchina. È possibile utilizzare un’istanza VM AWS o una versione di modello di avvio AWS come input del profilo macchina.

È possibile creare un catalogo utilizzando:

  • Studio
  • PowerShell

  • Creare un catalogo utilizzando Studio

  • Creare un catalogo di macchine dal nodo Immagini

  • Utilizzare l’opzione Crea catalogo nel nodo Immagini per creare un catalogo utilizzando la versione dell’immagine.

In alternativa, è possibile selezionare la versione durante la creazione di un catalogo nel nodo Cataloghi macchine, collegandosi all’opzione immagine preparata nel flusso di lavoro di creazione del catalogo. Vedere Creare un catalogo macchine dal nodo Cataloghi macchine.

Per creare un catalogo macchine MCS dal nodo Immagini, procedere come segue:

  1. Selezionare una versione dell’immagine e fare clic su Crea catalogo. Fare clic su Avanti nella pagina Introduzione.
    1. Nelle pagine Gestione macchine e Immagine, le impostazioni sono preselezionate in base alla versione dell’immagine selezionata. Nella pagina Immagine, inserire una nota per l’immagine preparata selezionata.
  1. Completare le impostazioni nelle pagine seguenti.
  2. Nella pagina Riepilogo, controllare i dettagli del catalogo macchine. Inserire un nome e una descrizione per il catalogo macchine. Fare clic su Fine.
  3. Accedere al nodo Cataloghi macchine per visualizzare il catalogo macchine creato.

Creare un catalogo macchine dal nodo Cataloghi macchine

Per creare un catalogo macchine MCS dal nodo Cataloghi macchine, procedere come segue:

  1. Fare clic su Cataloghi macchine nel riquadro di navigazione a sinistra.
  2. Fare clic su Crea catalogo macchine. Viene visualizzata la pagina Configurazione catalogo macchine.
  3. Nella pagina Tipo di macchina, selezionare un tipo di macchina per il catalogo, ad esempio Sistema operativo multisessione.
  4. Nella pagina Gestione macchine, selezionare le seguenti impostazioni:

    1. Selezionare Macchine con gestione dell’alimentazione (ad esempio, macchine virtuali o PC blade).
    2. Selezionare Tecnologia di provisioning Citrix. Quindi, selezionare Citrix Machine Creation Services™.
    3. Nel campo Risorse, selezionare le risorse (Zona di disponibilità o Zona locale) configurate durante la creazione della connessione host e fare clic su Avanti.
  5. Nella pagina Esperienza desktop, selezionare un desktop casuale o statico che si desidera che gli utenti abbiano al momento dell’accesso. Se è selezionato un desktop statico, specificare ulteriormente se si desidera salvare le modifiche apportate dall’utente sul disco locale (persistente o non persistente).
  6. Nella pagina Immagine, fare clic su Seleziona un’immagine per selezionare un’immagine preparata per il catalogo macchine. Selezionare la versione preparata creata. Fare clic sul nome della versione dell’immagine. Per visualizzare maggiori dettagli sulla versione dell’immagine selezionata, fare clic sul numero di versione, che è sottolineato. Fare clic su Fine.

    Viene visualizzato il profilo macchina associato all’immagine preparata e le sue proprietà hardware (ad esempio, tipo di istanza, tipo di tenancy, mappature di rete, gruppi di sicurezza, proprietà del volume) vengono utilizzate per creare macchine nei cataloghi. Per modificare l’origine del profilo macchina in un’altra VM o versione del modello di avvio, fare clic sul pulsante di modifica.

  7. Nella pagina Macchine virtuali:

    1. Immettere il numero di VM per il catalogo.
    2. Viene visualizzata la specifica della macchina predefinita, basata sul profilo macchina. Per modificarla, selezionare l’icona di modifica e selezionare una specifica della macchina.
  8. Nella pagina NIC, selezionare le NIC (o ENI) per le VM.
  9. Nella pagina Identità macchina, configurare il tipo di identità macchina per le macchine nel catalogo:

    1. Per configurare macchine aggiunte a un dominio (Active Directory locale o Microsoft Entra ibrido), selezionare il dominio e creare nuovi account AD per le VM da creare in questo catalogo macchine. Le VM sottoposte a provisioning vengono aggiunte al dominio selezionato. Per eseguire il provisioning di macchine non aggiunte a un dominio, selezionare l’opzione di non aggiunta a un dominio.
    2. Specificare lo schema di denominazione dell’account per i nuovi account da creare per le VM.
  10. Nella pagina Credenziali di dominio, fare clic su Immetti credenziali per fornire le credenziali per il dominio selezionato. Immettere nome utente e password a livello di amministratore quando richiesto. È inoltre possibile utilizzare un account di servizio se sono state salvate in precedenza le credenziali di dominio seguendo la nostra documentazione del prodotto.
  11. Fare clic sulle pagine rimanenti fino alla pagina Riepilogo. Immettere un nome per il catalogo macchine e selezionare Fine per creare il catalogo macchine.

Limitazioni sulla creazione di un catalogo macchine in una zona locale AWS

  • Alcune zone locali supportano solo determinate configurazioni hardware (ad esempio, la zona locale di Perth non supporta i volumi GP3, solo GP2).
  • Poiché solo gp2 è universalmente supportato in tutte le zone locali e non tutte supportano gp3, la creazione del disco ID per impostazione predefinita utilizza il tipo di volume gp2.
  • È necessario selezionare un profilo macchina con specifiche hardware supportate nella zona locale desiderata.
  • Le snapshot AMI di immagini preparate e le snapshot di dischi ID per impostazione predefinita vengono posizionate nella regione, anziché nella zona locale (a causa delle limitazioni di AWS relative alla visibilità del supporto delle snapshot EBS nelle zone locali).
  • Sono supportate solo le zone locali che supportano i servizi EC2 ed EBS completi.

  • Creare un catalogo utilizzando PowerShell

Creare un catalogo utilizzando una specifica della versione dell’immagine preparata e un profilo macchina

  • Creare un catalogo macchine MCS non persistente dalla specifica della versione dell’immagine preparata utilizzando il comando New-ProvScheme. Ad esempio,

    
     New-ProvScheme -ProvisioningSchemeName <string> -ImageVersionSpecUid <Guid> -HostingUnitUid <Guid> -IdentityPoolUid <Guid> [-CleanOnBoot $true] [-MachineProfile <string>] [-ProvisioningSchemeType “MCS”]
    
     <!--NeedCopy-->
    
  • Creare un catalogo macchine MCS persistente dalla specifica della versione dell’immagine preparata utilizzando il comando New-ProvScheme. Ad esempio,

    
     New-ProvScheme -ProvisioningSchemeName <string> -ImageVersionSpecUid <Guid> -HostingUnitUid <Guid> -IdentityPoolUid <Guid> [-CleanOnBoot $false] [-MachineProfile <string>] [-ProvisioningSchemeType “MCS”] 
    
     <!--NeedCopy-->
    

Esempio del set completo di comandi PowerShell per creare un catalogo:


$Catalog = New-BrokerCatalog  -AllocationType "Random"  -IsRemotePC $False  -MinimumFunctionalLevel "L7_20" -Name "wsccatalog" -PersistUserChanges "Discard" -ProvisioningType "MCS" -Scope @() -SessionSupport "MultiSession"

$IdentityPool = New-AcctIdentityPool  -AllowUnicode  -Domain "domainname" -IdentityPoolName "wsccatalog" -IdentityType "ActiveDirectory"  -NamingScheme "aws##" -NamingSchemeType "Numeric" -Scope @()

$PreparedImageVersionSpec = Get-ProvImageVersionSpec -ImageDefinitionName image1 -ImageVersionNumber 1 -Filter "PreparationType -eq 'Mcs'"

$Task = New-ProvScheme -ProvisioningSchemeName wsccatalog -ImageVersionSpecUid $PreparedImageVersionSpec.ImageVersionSpecUid -HostingUnitName wsc -IdentityPoolName wsccatalog -CleanOnBoot -Scope @() -SecurityGroup @() -MachineProfile 'XdHyp:\HostingUnits\cvad-test-scalestress\us-east-1a.availabilityzone\machine-profile-instance i (i-0xxxxxxxx).vm' -RunAsynchronously

Get-ProvTask -TaskId $Task.TaskId
$ProvScheme = Get-ProvScheme -ProvisioningSchemeName wsccatalog

Set-BrokerCatalog -Name $Catalog.Name -ProvisioningSchemeId $ProvScheme.ProvisioningSchemeUid

<!--NeedCopy-->

Aggiornare il profilo macchina

Per aggiornare il profilo macchina su un catalogo inizialmente sottoposto a provisioning con un profilo macchina, procedere come segue. È inoltre possibile modificare il tipo di tenancy e la capacità di ibernazione dell’origine del profilo macchina durante la modifica di un catalogo macchine MCS.

    1. Eseguire il comando Set-ProvScheme. Ad esempio,
    
     Set-ProvScheme `
     -ProvisioningSchemeUid "<ID" `
     -MachineProfile "XDHyp:\HostingUnits\abc\us-east-1a.availabilityzone\citrix-cvad-machineprofile-instance (i-0xxxxxxxx).vm"
    
     <!--NeedCopy-->
    

Creare un catalogo macchine con una modalità di fatturazione specifica

Attualmente è possibile specificare la modalità di fatturazione durante la creazione di un catalogo macchine utilizzando solo PowerShell.

Utilizzare PowerShell

Per specificare la modalità di fatturazione tramite PowerShell, utilizzare il parametro CustomProperties nel comando New-ProvScheme.


$custprop = "BillingMode,Monthly" 
 
New-ProvScheme -ProvisioningSchemeName "MyCatalog" ` 
-ImageVersionSpecUid $ImageVersionSpecUid ` 
-HostingUnitName "wsc-unit" ` 
-IdentityPoolName "MyIdentityPool" ` 
-MachineProfile "XdHyp:\HostingUnits\wsc-unit\machine-profile lt-123.launchtemplate\lt-123 (1).launchtemplateversion" ` 
-CustomProperties $custprop ` 
-CleanOnBoot

<!--NeedCopy-->

Nota:

Se la proprietà BillingMode viene omessa, il catalogo assume per impostazione predefinita la modalità Hourly.

Modificare la modalità di fatturazione di un catalogo esistente

È possibile convertire un catalogo esistente da Monthly a Hourly o viceversa. Questa modifica può essere applicata sia alle VM nuove che a quelle esistenti nel catalogo.

Considerazioni importanti per gli aggiornamenti

  • Finestra di servizio: le VM esistenti devono essere sottoposte a una finestra di servizio o a un ciclo di alimentazione per applicare la modifica della fatturazione.
  • Convalida: MCS convalida che i tipi di istanza e le piattaforme esistenti siano compatibili con la nuova modalità di fatturazione prima di applicare la modifica.

Aggiornamento tramite PowerShell

  • Per aggiornare la modalità di fatturazione solo delle nuove VM aggiunte a un catalogo, aggiornare la proprietà personalizzata della modalità di fatturazione dello schema di provisioning:

    
     $custprop = "BillingMode,Hourly" 
    
     Set-ProvScheme -ProvisioningSchemeName "MyCatalog" -CustomProperties $custprop
    
     <!--NeedCopy-->
    
  • Per aggiornare la modalità di fatturazione delle VM nuove ed esistenti in un catalogo, creare una nuova versione dello schema di provisioning con la proprietà personalizzata aggiornata e applicare la nuova versione a tutte le VM:

    
     $custprop = "BillingMode,Hourly" 
    
     New-ProvSchemeVersion -ProvisioningSchemeName "MyCatalog" -CustomProperties $custprop
    
     New-ProvSchemeHardwareUpdate -ProvisioningSchemeVersion 2 ` 
     -StartsNow -AllVMs ` 
     -MaxDurationInMinutes 100 ` 
     -ProvisioningSchemeName "MyCatalog"
    
     <!--NeedCopy-->
    
  • Monitorare le informazioni di fatturazione

È possibile verificare la modalità di fatturazione per i cataloghi e le singole macchine virtuali.

Eseguire i seguenti comandi PowerShell per verificare l’idoneità alla fatturazione del proprio account:

  • Restituisce BillingMode come parte delle CustomProperties

    
     -  Get-ProvScheme –ProvisioningSchemeName “"MyCatalog" "  | Select  ProvisioningSchemeName,  CustomProperties
    
     <!--NeedCopy-->
    
    • Restituisce BillingMode come parte delle VMInfo
    
     Get-ProvVMDetails –ProvisioningSchemeName “"MyCatalog" "  | Select-Object  -ExpandProperty VMInfo 
    
     <!--NeedCopy-->
    

Risoluzione dei problemi e convalida

MCS include controlli preliminari per prevenire configurazioni incompatibili. È possibile che si verifichino i seguenti errori durante la creazione o la modifica del catalogo:

-  **NoInstanceConfigFoundForBillingMode**: Si verifica se l'offerta di servizio selezionata (tipo di istanza), la tenancy e il tipo di piattaforma non sono supportati per la modalità di fatturazione scelta.

-  **Spot Instance Not Supported**: Se si tenta di utilizzare istanze Spot con una connessione host WorkSpaces, la convalida fallisce.
-  **Restrizione di fatturazione EC2**: Se il proprio account AWS utilizza il modello di fatturazione EC2 legacy, il tentativo di impostare una modalità di fatturazione mensile comporta un errore di convalida.

Creare un catalogo con la versione del modello di avvio tramite PowerShell

È possibile creare un catalogo di macchine MCS con una versione del modello di avvio come input del profilo macchina. È anche possibile aggiornare l’input di un catalogo di profili macchina da una VM a una versione del modello di avvio e da una versione del modello di avvio a una VM.

Nella console AWS EC2, è possibile fornire le informazioni di configurazione dell’istanza di un modello di avvio insieme al numero di versione. Quando si specifica la versione del modello di avvio come input del profilo macchina durante la creazione o l’aggiornamento di un catalogo di macchine, le proprietà di quella versione del modello di avvio vengono copiate nelle VM VDA di cui è stato eseguito il provisioning.

Le seguenti proprietà possono essere fornite utilizzando l’input del profilo macchina o esplicitamente come parametri nei comandi New-ProvScheme o Set-ProvScheme. Se vengono fornite nei comandi New-ProvScheme o Set-ProvScheme, hanno la precedenza sui valori del profilo macchina di queste proprietà.

  • Offerta di servizio
  • Reti

Nota:

-  > Se l'offerta di servizio non è fornita nel modello di avvio del profilo macchina o come parametro nel comando `New-ProvScheme`, si riceverà un errore appropriato.

Per creare un catalogo utilizzando la versione del modello di avvio come input del profilo macchina:

    1. Aprire una finestra PowerShell.
  1. Eseguire asnp citrix* per caricare i moduli PowerShell specifici di Citrix.
    1. Ottenere l’elenco delle versioni del modello di avvio di un modello di avvio. Ad esempio:
    
     XDHyp:\HostingUnits\test\test-mp-sard (lt-01xxxxx).launchtemplate> ls | Select FullPath
    
     <!--NeedCopy-->
    
  1. Creare un pool di identità se non è stato creato. Ad esempio:

    
    New-AcctIdentityPool `
    -IdentityPoolName "abc11" `
    -NamingScheme "abc1-##" `
    -NamingSchemeType Numeric `
    -Domain "citrix-xxxxxx.local" `
    -ZoneUid "xxxxxxxx" `
    
    <!--NeedCopy-->
    
    1. Creare uno schema di provisioning con una versione del modello di avvio come input del profilo macchina. Ad esempio:
    
     New-ProvScheme `
     -ProvisioningSchemeName "MPLT1" `
     -HostingUnitUid "c7f71f6a-3f45-4xxx-xxxx-xxxxxxxxxx" `
     -IdentityPoolUid "bf3a6ba2-1f80-4xxx-xxxx-xxxxxxxxx" `
     -ImageVersionSpecUid '24dfb047-e867-527g-896c-25664xxxxx1t' `
     -CleanOnBoot `
     -MachineProfile "XDHyp:\HostingUnits\xxxx-ue1a\machineprofiletest (lt-01xxxxx).launchtemplate\lt-01xxxxx (1).launchtemplateversion"
    
     <!--NeedCopy-->
    
    1. Registrare uno schema di provisioning come catalogo broker. Ad esempio:
    
     New-BrokerCatalog -Name "MPLT1" `
     -AllocationType Random `
     -Description "Machine profile catalog" `
     -ProvisioningSchemeId fe7df345-244e-4xxxx-xxxxxxxxx `
     -ProvisioningType Mcs `
     -SessionSupport MultiSession `
     -PersistUserChanges Discard
    
     <!--NeedCopy-->
    
  1. Completare la creazione del catalogo.

Aggiornare l’origine del profilo macchina

È anche possibile aggiornare l’input di un catalogo di profili macchina da una VM a una versione del modello di avvio e da una versione del modello di avvio a una VM. Ad esempio:

  • Per aggiornare l’input di un catalogo di profili macchina da una VM a una versione del modello di avvio:

    
     Set-ProvScheme -ProvisioningSchemeName "CloudServiceOfferingTest" `
     -MachineProfile "XDHyp:\HostingUnits\xxxx-ue1a\machineprofiletest (lt-0bxxxxxxxxxxxx).launchtemplate\lt-0bxxxxxxxxxxxx (1).launchtemplateversion"
    
     <!--NeedCopy-->
    
  • Per aggiornare l’input di un catalogo di profili macchina da una versione di modello di avvio a una VM:

       
     Set-ProvScheme -ProvisioningSchemeName "CloudServiceOfferingTest" 
     MachineProfile "XDHyp:\HostingUnits\sard-ue1a\us-east-1a.availabilityzone\apollo-non-persistent-vda-win2022-2 (i-08xxxxxxxxx).vm"
    
     <!--NeedCopy-->
    

Catalogo abilitato per MCSIO

  • MCS Storage Optimization (MCSIO) migliora le prestazioni della VM memorizzando nella cache le operazioni su disco, sia in memoria che su un disco piccolo e ad alta velocità. È possibile creare un catalogo non persistente abilitato per MCSIO utilizzando i comandi PowerShell. Per creare un catalogo di questo tipo, è necessario installare il driver MCSIO durante l’installazione o l’aggiornamento del VDA, durante la preparazione dell’istanza AMI. Per impostazione predefinita, tale driver non è installato.

Dopo aver preparato un’AMI MCSIO (durante l’installazione del VDA, selezionare l’opzione per includere il driver MCSIO nell’installazione), è possibile creare un catalogo non persistente abilitato per MCSIO.

Nota:

L’opzione per configurare MCSIO con la sola cache su disco (senza cache in memoria) tramite Studio è stata rimossa da tutti gli hypervisor e gli ambienti di servizi cloud.

Creare un catalogo abilitato per MCSIO

I quattro parametri aggiunti al comando PowerShell New-ProvScheme sono:

  • UseWriteBackCache: Attiva la memorizzazione nella cache (cache write-back) per lo schema di provisioning specificato
  • WriteBackCacheDiskSize: Specifica la dimensione in GB del disco temporaneo utilizzato per la memorizzazione nella cache
  • WriteBackCacheMemorySize: Specifica la quantità di memoria in MB da utilizzare per la memorizzazione nella cache. Questo è un parametro facoltativo.

Nota:

  • Il valore di WriteBackCacheDiskSize deve essere maggiore di zero, poiché è richiesto almeno 1 GB di spazio di archiviazione su disco per la cache. La dimensione del disco della cache non deve essere maggiore della dimensione del disco del sistema operativo.
  • Il valore di WriteBackCacheMemorySize deve essere diverso da zero e inferiore alla dimensione della memoria del catalogo macchine.

Le proprietà personalizzate che influiscono su MCSIO sono:

  • WBCDiskStorageType: Definisce il tipo di volume, utilizzato per il disco temporaneo nelle istanze gestite di Amazon WorkSpaces Core. Questo parametro accetta un argomento stringa nel formato volume-type[:iops][:throughput]. Di seguito sono riportati i tipi di volume:

    • gp2: Non utilizzare i parametri iops e throughput per questo tipo di volume
    • gp3: Utilizzare i parametri iops e throughput per questo tipo di volume
    • io1: Utilizzare solo il parametro iops per questo tipo di volume
    • io2: Utilizzare solo il parametro iops per questo tipo di volume
  • Il tipo di volume predefinito è gp2.

  • PersistWBC: Controlla se mantenere o eliminare il disco della cache ogni volta che le istanze gestite di Amazon WorkSpaces Core vengono spente. Se impostato su true, il disco della cache viene mantenuto. Se impostato su false (impostazione predefinita), il disco della cache viene creato e mantenuto solo quando l’istanza AMI è accesa.
  • PersistOSDisk: Controlla se mantenere o eliminare il disco del sistema operativo ogni volta che le istanze gestite di Amazon WorkSpaces Core vengono spente. Se impostato su true, il disco del sistema operativo viene mantenuto. Se impostato su false (impostazione predefinita), il disco del sistema operativo viene creato e mantenuto solo quando l’istanza AMI è accesa.

Eseguire i seguenti passaggi nella finestra di PowerShell per creare un catalogo non persistente abilitato per MCSIO:

  1. Aprire la finestra di PowerShell.
    1. Eseguire asnp citrix* per caricare i moduli PowerShell specifici di Citrix.
  1. Creare un catalogo broker e un pool di identità.
  2. Creare lo schema di provisioning. Ad esempio:

    
    $HostingUnitUid = '0xxxx1d9-bbfc-xxxf-bxxb-exxxxxe008b2'
    $MasterImageVM = 'XDHyp:\HostingUnits\ctx-test\aws-apollo-non-persistent-multi-mcsio-vda-win2022 (ami-0bf1810488acbxxxb).template'
    $NetworkMap = @{ 'NetworkPath' = 'XDHyp:\HostingUnits\ctx-test\us-east-1a.availabilityzone\10.0.128.0`/17 (vpc-0fa6e41d72507fxxx).network' }
    $SecurityGroup = $( 'XDHyp:\HostingUnits\ctx-test\us-east-1a.availabilityzone\private.securitygroup' )
    $ServiceOffering = 'XDHyp:\HostingUnits\ctx-test\T3 Medium Instance.serviceoffering'
    -  $CustomProperties = 'WBCDiskStorageType,gp3:6000:250;PersistWBC,false'
    
    $provScheme = New-ProvScheme -ProvisioningSchemeName $CatalogName -HostingUnitUid $HostingUnitUid `
    -IdentityPoolUid $acctPool.IdentityPoolUid -CleanOnBoot `
    -  MasterImageVM $MasterImageVM `
    -NetworkMap $NetworkMap `
    -ServiceOffering $ServiceOffering `
    -SecurityGroup $SecurityGroup `
    -CustomProperties $CustomProperties `
    -UseWriteBackCache -WriteBackCacheDiskSize 16 -WriteBackCacheMemorySize 256
    
    <!--NeedCopy-->
    
  3. Aggiungere VM al catalogo.

Migliorare le prestazioni di avvio con MCSIO

È possibile migliorare le prestazioni di avvio delle VM se si abilita MCSIO e si impostano le proprietà personalizzate PersistWBC e PersistOSDisk su true. Con tale impostazione, le VM possono avviarsi più velocemente perché non devono inizializzare un nuovo disco della cache o ricreare un disco radice dal loro modello.

Crittografare i dischi del sistema operativo e di identità

È possibile creare un catalogo di VM con chiavi AWS KMS (chiave gestita dal cliente e chiave gestita da AWS) che possono essere utilizzate per crittografare il disco del sistema operativo e il disco di identità (ID).

  • Le chiavi gestite da AWS vengono ruotate automaticamente ogni anno.
    • Le chiavi gestite dal cliente sono facoltative per la rotazione automatica e possono essere gestite manualmente.

    • Per ulteriori informazioni sulle chiavi KMS, consultare i seguenti documenti AWS:

  • Concetti di AWS KMS
  • Come funziona la rotazione automatica delle chiavi

  • Per la crittografia dei dischi del sistema operativo e di identità, configurare una delle seguenti opzioni:

  • Utilizzare un’immagine preparata che sia crittografata (ad esempio, un’AMI creata da un’istanza o uno snapshot che contiene un volume root EBS crittografato con chiave KMS)
  • Utilizzare una sorgente di profilo macchina (VM o modello di avvio) che contenga un volume root EBS crittografato.

Limitazioni

Considerare le seguenti limitazioni:

  • MCS attualmente supporta un solo disco su AMI di immagine preparata.
  • Non è possibile crittografare direttamente volumi o snapshot EBS esistenti non crittografati, né modificare la chiave KMS di un volume crittografato esistente. Per farlo, è necessario:

    1. Creare un nuovo snapshot di quel volume.
    2. Creare un nuovo volume da quello snapshot.
    3. Crittografare il nuovo volume.

Consultare i seguenti documenti AWS:

Creare un catalogo con crittografia del disco

È possibile creare un catalogo di macchine MCS con crittografia del disco utilizzando:

  • Immagine preparata (creata tramite la gestione delle immagini da un’immagine master con disco crittografato)
  • Profilo macchina

Considerazioni sull’utilizzo dell’input del profilo macchina:

  • La chiave KMS dell’input del profilo macchina ha la precedenza sulla chiave KMS dell’immagine preparata.
  • Se non viene fornito alcun input di profilo macchina, la chiave KMS dell’AMI dell’immagine preparata viene utilizzata per crittografare i dischi delle VM del catalogo.
  • Se il profilo macchina contiene mappature di dispositivi a blocchi, i dispositivi a blocchi presenti nel modello di immagine preparata (AMI) e nel profilo macchina devono corrispondere. Ad esempio, se l’AMI ha un dispositivo definito su /dev/sda1, anche il profilo macchina deve avere un dispositivo definito su /dev/sda1.
  • Se non è presente alcuna chiave nell’origine del profilo macchina e l’immagine preparata non è crittografata, i dischi delle VM del catalogo non vengono crittografati.
  • Quando l’immagine preparata è crittografata, una VM di origine del profilo macchina o un modello di avvio deve avere un volume root crittografato per essere considerato un input valido.

Modificare un catalogo esistente

È possibile modificare un catalogo esistente utilizzando il comando PowerShell Set-ProvScheme per avere:

  • Un input di profilo macchina con un volume contenente una nuova chiave KMS.
  • Un’immagine preparata creata dall’immagine master con AMI crittografata utilizzando la gestione delle immagini.

Considerazioni importanti:

  • I volumi delle nuove VM aggiunte al catalogo vengono crittografati con la nuova chiave KMS.
  • Per aggiornare le impostazioni di crittografia quando esiste un profilo macchina, eseguire Set-ProvScheme con un nuovo profilo macchina.
  • Non è possibile modificare un catalogo esistente da volumi crittografati a volumi non crittografati. Non è possibile eseguire un aggiornamento dell’immagine da un’AMI di immagine preparata crittografata a un’AMI di immagine preparata non crittografata.

Abilitare NitroTPM e l’avvio protetto UEFI per le istanze VM

Quando si crea un catalogo, è ora possibile selezionare un’immagine preparata (AMI) con NitroTPM e/o avvio protetto UEFI abilitati. Di conseguenza, anche le VM sottoposte a provisioning nel catalogo vengono abilitate con NitroTPM e/o avvio protetto UEFI. Questa implementazione garantisce che le VM siano protette e affidabili. Per maggiori informazioni su NitroTPM e l’avvio protetto UEFI, consultare la documentazione Amazon.

Limitazioni

  • È possibile utilizzare NitroTPM e l’avvio protetto attualmente in tutte le regioni AWS (incluse le regioni AWS GovCloud (US)) ad eccezione della Cina.
  • Non è possibile abilitare NitroTPM e l’avvio protetto UEFI sui cataloghi esistenti. Se si desidera un catalogo con NitroTPM e avvio protetto UEFI abilitati, creare un nuovo catalogo.

Passaggi chiave

  1. Configurare l’ambiente AWS.
  2. Creare una connessione ad AWS.
  3. Creare un’immagine master (AMI) abilitata con NitroTPM e/o avvio protetto UEFI.
  4. Creare un’immagine preparata dall’immagine master. Vedere Creare un’immagine preparata per le istanze gestite di Amazon WorkSpaces Core.
  5. Creare un catalogo di macchine selezionando l’immagine preparata con NitroTPM e avvio protetto UEFI abilitati nel menu di creazione del catalogo di Citrix Studio o durante la creazione di uno schema di provisioning utilizzando i comandi PowerShell.

Le VM aggiunte al catalogo creato hanno NitoTPM e l’avvio protetto UEFI abilitati.

Creare un’AMI che supporti NitroTPM e l’avvio protetto UEFI

  1. È possibile creare un’AMI da una VM che ha NitroTPM e/o l’avvio protetto UEFI abilitati.

    1. Creare l’istanza utilizzando le immagini del marketplace AWS. Ad esempio, cercare TPM-Windows_Server-2022-English-Full-Base on the aws-marketplace.
    2. Scaricare VDA a sessione singola o multipla.
    3. Creare un’AMI da quella VM.
  2. Utilizzare il comando register-image:

    
    --boot-mode (string)
    --tpm-support (string)
    
    <!--NeedCopy-->
    

    Per maggiori informazioni, vedere register-image.

Vedere i seguenti documenti AWS:

È possibile aprire una finestra PowerShell dall’host del Delivery Controller™ per verificare se uno specifico:

  • servizio offerto supporta NitroTPM o l’avvio protetto UEFI

    
     (Get-Item -Path “XDHyp:\HostingUnits\aws\T3 Medium Instance.serviceoffering”).AdditionalData.BootMode
     (Get-Item -Path “XDHyp:\HostingUnits\aws\T3 Medium Instance.serviceoffering”).AdditionalData.NitroTpmSupportVersions
    
     <!--NeedCopy-->
    
  • modello supporta NitroTPM o l’avvio protetto UEFI

    
     (Get-HypInventoryItem -LiteralPath “XDHyp:\HostingUnits\aws” -ResourceType “template -Id “ID”).AdditionalData.BootMode
    
     (Get-HypInventoryItem -LiteralPath “XDHyp:\HostingUnits\aws” -ResourceType “template -Id “ID”).AdditionalData.TpmSupport
    
     <!--NeedCopy-->
    

Aggiornare l’offerta di servizio del catalogo esistente

È possibile modificare l’offerta di servizio di un catalogo esistente utilizzando Set-ProvScheme. La modifica si applica alle VM appena aggiunte. Tuttavia, si verificano errori nei seguenti scenari:

Modalità di avvio AMI L’AMI supporta Nitro TPM? L’offerta di servizio supporta NitroTPM e l’avvio protetto UEFI?
UEFI No No
BIOS legacy No
UEFI No
UEFI preferito No

Copiare i tag sulle VM

È possibile copiare i tag su NIC e dischi (disco di identità, disco di cache di scrittura e disco del sistema operativo) specificati nel profilo macchina nelle VM appena create in un catalogo di macchine MCS. È possibile specificare questi tag in una qualsiasi delle origini del profilo macchina (istanza VM AWS o versione del modello di avvio AWS). Questa funzionalità è applicabile ai cataloghi di macchine e alle VM persistenti e non persistenti.

Nota:

  • Sulla console AWS EC2, non è possibile visualizzare i valori di Tag Network Interfaces sotto Launch Template Version Resource Tags. Tuttavia, è possibile eseguire il comando PowerShell aws ec2 describe-launch-template-versions --launch-template-id lt-0bb652503d45dcbcd --versions 12 per visualizzare le specifiche dei tag.
  • Se un’origine del profilo macchina (VM o versione del modello di avvio) ha due interfacce di rete (eni-1 ed eni-2), e eni-1 ha il tag t1 ed eni-2 ha il tag t2, allora la VM ottiene i tag di entrambe le interfacce di rete.

Filtrare le istanze VM usando PowerShell

Un’istanza VM AWS utilizzata come VM del profilo macchina deve essere compatibile affinché il catalogo macchine possa essere creato e funzionare correttamente. Per elencare le istanze VM AWS che possono essere utilizzate come VM di input del profilo macchina, è possibile utilizzare il comando Get-HypInventoryItem. Il comando può impaginare e filtrare l’inventario delle VM disponibili su un’unità di hosting.

Impaginazione:

Get-HypInventoryItem supporta due modalità di impaginazione:

  • La modalità di impaginazione utilizza i parametri -MaxRecords e -Skip per restituire set di elementi:
    • -MaxRecords: Il valore predefinito è 1. Questo controlla quanti elementi restituire.
    • -Skip: Il valore predefinito è 0. Questo controlla quanti elementi saltare dall’inizio assoluto (o dalla fine assoluta) dell’elenco nell’hypervisor.
  • La modalità di scorrimento utilizza i parametri -MaxRecords, -ForwardDirection e -ContinuationToken per consentire lo scorrimento dei record:
    • -ForwardDirection: Il valore predefinito è True. Questo viene utilizzato insieme a -MaxRecords per restituire il set successivo di record corrispondenti o il set precedente di record corrispondenti.
    • -ContinuationToken: Restituisce gli elementi immediatamente dopo (o prima se ForwardDirection è false) ma non include l’elemento specificato in ContinuationToken.

Esempi di impaginazione:

  • Per restituire un singolo record del modello macchina con il nome più basso. Il campo AdditionalData contiene TotalItemsCount e TotalFilteredItemsCount:

    
     Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template
    
     <!--NeedCopy-->
    
  • Per restituire 10 record del modello macchina con il nome più basso:

    
     Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template -MaxRecords 10 | select Name
    
     <!--NeedCopy-->
    
  • Per restituire un array di record che terminano con il nome più alto:

    
     Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template -ForwardDirection $False -MaxRecords 10 | select Name
    
     <!--NeedCopy-->
    
  • Per restituire un array di record a partire dal modello macchina associato al ContinuationToken specificato:

    
     Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template -ContinuationToken "ami-07xxxxxxxxxx" -MaxRecords 10
    
     <!--NeedCopy-->
    

Filtro:

Per il filtro sono supportati i seguenti parametri opzionali aggiuntivi. È possibile combinare questi parametri con le opzioni di impaginazione.

  • -ContainsName "my_name": Se la stringa specificata corrisponde a una parte di un nome AMI, l’AMI viene inclusa nel risultato Get. Ad esempio:

    
     Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template -MaxRecords 100 -ContainName ‘apollo’ | select Name
    
     <!--NeedCopy-->
    
  • -Tags '{ "Key0": "Value0", "Key1": "Value1", "Key2": "Value2" }': Se un’AMI ha almeno uno di questi tag, viene inclusa nel risultato Get. Ad esempio:

    
     Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template -MaxRecords 100 -Tags '{"opex owner": "Not tagged"}' | select Name
    
     <!--NeedCopy-->
    

    Nota:

    Sono supportati due valori di tag. Il valore di tag Non taggato corrisponde agli elementi che non hanno il tag specificato nel loro elenco di tag. Il valore di tag Tutti i valori corrisponde agli elementi che hanno il tag indipendentemente dal valore del tag. Altrimenti, la corrispondenza avviene solo se l’elemento ha il tag e il valore è uguale a quello specificato nel filtro.

  • -Id "ami-0a2d913927e0352f3": Se l’AMI corrisponde all’ID specificato, viene inclusa nel risultato Get. Ad esempio:

    
     Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template -Id ami-xxxxxxxxxxxxx
    
     <!--NeedCopy-->
    

Filtro sul parametro AdditionalData:

Il parametro di filtro AdditionalData elenca i modelli o le VM in base alla loro capacità, all’offerta di servizi o a qualsiasi proprietà presente in AdditionalData. Ad esempio:


(Get-HypInventoryItem -ResourceType "launchtemplateversion" -LiteralPath "XDHyp:\HostingUnits\aws" -MaxRecords 200).AdditionalData

<!--NeedCopy-->

È inoltre possibile aggiungere un parametro -Warn per indicare le VM incompatibili. Le VM sono incluse con un campo AdditionalData denominato Warning. Ad esempio:


(Get-HypInventoryItem -ResourceType "launchtemplateversion" -LiteralPath "XDHyp:\HostingUnits\aws" -MaxRecords 200 -Template "ami-015xxxxxxxxx" -Warn $true).AdditionalData

<!--NeedCopy-->

Dove andare dopo

Ulteriori informazioni