Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Zone di disponibilità
Una zona di disponibilità
Amazon WorkSpaces Applications richiede solo una sottorete per il lancio di una flotta. La migliore pratica consiste nel configurare un minimo di due zone di disponibilità, una sottorete per ogni zona di disponibilità unica. Per ottimizzare la scalabilità automatica della flotta, utilizza più di due zone di disponibilità. La scalabilità orizzontale ha l'ulteriore vantaggio di aggiungere spazio IP nelle sottoreti per favorire la crescita, come illustrato nella seguente sezione sul dimensionamento delle sottoreti di questo documento. La Console di gestione AWS
Dimensionamento sottorete
Dedica le sottoreti alle flotte di WorkSpaces applicazioni per consentire flessibilità nelle politiche di routing e nella lista di controllo degli accessi alla rete. Gli stack avranno probabilmente requisiti di risorse separati. Ad esempio, WorkSpaces Applications Stacks può avere requisiti di isolamento che lasciano il posto a set di regole separati. Quando più flotte di Amazon WorkSpaces Applications utilizzano le stesse sottoreti, assicurati che la somma della capacità massima di tutte le flotte non superi il numero totale di indirizzi IP disponibili.
Se la capacità massima per tutte le flotte nella stessa sottorete può, o ha superato, il numero totale di indirizzi IP disponibili, migra le flotte verso sottoreti dedicate. In questo modo si evita che gli eventi di scalabilità automatica esauriscano lo spazio IP allocato. Se la capacità totale di una flotta supera lo spazio IP allocato delle sottoreti assegnate, utilizza l'API o la «flotta di aggiornamento» della AWS CLI per assegnare più sottoreti. Per ulteriori informazioni, consulta le quote di Amazon VPC e come aumentarle.
È consigliabile ridimensionare il numero di sottoreti, dimensionando le sottoreti di conseguenza e riservando la capacità di crescita del VPC. Inoltre, assicurati che il numero massimo di WorkSpaces applicazioni non superi lo spazio IP totale allocato dalle sottoreti. Per ogni sottorete in ingresso AWS, nel calcolo della quantità totale di spazio IP vengono riservati cinque indirizzi IP. L'utilizzo di più di due sottoreti e la scalabilità orizzontale offrono diversi vantaggi, ad esempio:
-
Maggiore resilienza in caso di guasto nella zona di disponibilità
-
Maggiore produttività grazie alla scalabilità automatica delle istanze del parco istanze
-
Utilizzo più efficiente degli indirizzi IP privati, evitando la masterizzazione degli IP
Nel dimensionare le sottoreti per Amazon WorkSpaces Applications, considera il numero totale di sottoreti e il picco di concorrenza previsto durante i picchi di utilizzo. Questo può essere monitorato utilizzando (InUseCapacity) più la capacità riservata () per una flotta. AvailableCapacity In Amazon WorkSpaces Applications, la somma delle istanze del parco di applicazioni utilizzate e disponibili per essere utilizzate è etichettata WorkSpaces . ActualCapacity Per dimensionare correttamente lo spazio IP totale, prevedi quello necessario e dividilo per il numero di sottoretiActualCapacity, meno una sottorete per la resilienza, assegnate alla flotta.
Ad esempio, se il numero massimo previsto di istanze del parco istanze nei momenti di picco è 1000 e il requisito aziendale è la resilienza in caso di guasto di una zona di disponibilità, 3 x/23 sottoreti soddisfano i requisiti tecnici e aziendali.
-
/23 = 512 host — 5 riservate = 507 istanze del parco istanze per sottorete
-
3 sottoreti — 1 sottorete = 2 sottoreti
-
2 sottoreti x 507 istanze di flotta per sottorete = 1.014 istanze di flotta al massimo
Esempio di dimensionamento di una sottorete
Anche se 2 sottoreti x/22 soddisferebbero anche la resilienza, considera quanto segue:
-
Invece di 1.536 indirizzi IP riservati, utilizzando due AZ si ottengono 2.048 indirizzi IP riservati, sprecando indirizzi IP che potrebbero essere utilizzati per altre funzioni.
-
Se una AZ diventa inaccessibile, la capacità di scalare orizzontalmente le istanze del parco istanze è limitata dalla velocità effettiva di una AZ. Ciò può prolungare la durata di.
PendingCapacity
Routing della sottorete
È consigliabile creare sottoreti private per WorkSpaces le istanze delle applicazioni, instradandole verso la rete Internet pubblica tramite un VPC centralizzato per il traffico in uscita. Il traffico in entrata per lo streaming della sessione WorkSpaces Applications viene gestito tramite il servizio Amazon WorkSpaces Applications tramite Streaming Gateways: per questo non è necessario configurare sottoreti pubbliche.
Intra-Region connettività
Per WorkSpaces le istanze della flotta di applicazioni unite a un dominio Active Directory, configura i controller di dominio Active Directory in un VPC di Shared Services in ciascuno di essi. Regione AWS Le fonti per Active Directory possono essere controller di dominio basati su Amazon EC2 o AWS Microsoft Managed AD. Il routing tra i servizi condivisi e i VPC WorkSpaces delle applicazioni può avvenire tramite una connessione peering VPC o un gateway di transito. Sebbene i gateway di transito risolvano la complessità del routing su larga scala, esistono diversi motivi per cui il peering VPC è preferibile nella maggior parte delle impostazioni:
-
Il peering VPC è una connessione diretta tra i due VPC (nessun hop aggiuntivo).
-
Non è prevista alcuna tariffa oraria, ma solo la velocità di trasferimento dati standard tra le zone di disponibilità.
-
Non ci sono limiti alla larghezza di banda.
-
Support per l'accesso ai gruppi di sicurezza tra VPC.
Ciò è particolarmente vero se WorkSpaces le istanze Applications si connettono ai and/or file server dell'infrastruttura applicativa con set di dati di grandi dimensioni in un VPC di servizio condiviso. Ottimizzando il percorso verso queste risorse a cui si accede comunemente, la connessione peering VPC è preferita, anche nei progetti in cui tutti gli altri VPC e il routing Internet vengono eseguiti tramite gateway di transito.
Traffico Internet in uscita
Sebbene il routing diretto verso i servizi condivisi sia per lo più ottimizzato tramite una connessione peering, il traffico in uscita per WorkSpaces le applicazioni può essere progettato creando un unico punto di uscita Internet da più VPC utilizzando Transit Gateway
Una volta centralizzato tutto il traffico Internet in uscita in un unico VPC, i gateway NAT o le istanze NAT sono una scelta di progettazione comune. Per determinare qual è la soluzione migliore per la tua organizzazione, consulta la guida amministrativa per confrontare i gateway NAT e le istanze NAT. AWS Network Firewall
On-premises
Quando è richiesta la connettività alle risorse locali, in particolare per WorkSpaces le istanze delle applicazioni unite ad Active Directory, stabilisci una connessione altamente resiliente
