Architettura di base di Azure Macchine virtuali

Questo articolo fornisce un'architettura di riferimento di base per un carico di lavoro distribuito in Azure Macchine virtuali.

Il carico di lavoro di esempio assunto da questa architettura è un'applicazione Web multilivello con connessione Internet distribuita in set separati di macchine virtuali. Il provisioning delle macchine virtuali viene eseguito come parte delle distribuzioni di Set di scalabilità di macchine virtuali di Azure. Questa architettura può essere usata per questi scenari:

• Applicazioni private. Queste applicazioni includono applicazioni line-of-business interne o soluzioni commerciali off-the-shelf.
• Applicazioni pubbliche. Queste applicazioni sono applicazioni con connessione Internet. Questa architettura non è destinata al calcolo ad alte prestazioni, ai carichi di lavoro cruciali, alle applicazioni altamente interessate dalla latenza o ad altri casi d'uso specializzati.

L'obiettivo principale di questa architettura non è l'applicazione. Questo articolo fornisce invece indicazioni per la configurazione e la distribuzione dei componenti dell'infrastruttura con cui interagisce l'applicazione. Questi componenti includono componenti di calcolo, archiviazione, rete e monitoraggio.

Questa architettura funge da punto di partenza per un carico di lavoro ospitato dall'infrastruttura distribuita come servizio (IaaS). Il livello dati è intenzionalmente escluso da queste linee guida per mantenere l'attenzione sull'infrastruttura di calcolo.

Layout articolo

Architettura	Decisione di progettazione	Approccio ben progettato per framework
▪ Diagramma dell'architettura ▪ Risorse del carico di lavoro ▪ Risorse di supporto ▪ Flussi utente	▪ Scelte di progettazione delle macchine virtuali ▪ Dischi ▪ Rete ▪ Monitoraggio ▪ Gestione aggiornamenti	▪ Affidabilità ▪ Sicurezza ▪ Ottimizzazione dei costi

Architettura

Scaricare un file di Visio di questa architettura.

Per informazioni su queste risorse, vedere la documentazione del prodotto Azure elencata in Risorse correlate.

Componenti

Questa architettura è costituita da diversi servizi di Azure sia per le risorse del carico di lavoro che per le risorse di supporto del carico di lavoro. I servizi per ognuno e i relativi ruoli sono descritti nelle sezioni seguenti.

Risorse del carico di lavoro

• Azure Macchine virtuali funge da risorsa di calcolo per l'applicazione e viene distribuito tra le zone di disponibilità. A scopo illustrativo, viene usata una combinazione di macchine virtuali Windows e Linux.

  Azure set di scalabilità di macchine virtuali in modalità di orchestrazione flessibile viene usato per effettuare il provisioning e gestire le macchine virtuali.

  L'applicazione di esempio può essere rappresentata in due livelli, ognuno dei quali richiede un proprio calcolo.

  • Il front-end esegue il server Web e riceve le richieste utente.
  • Il back-end esegue un altro server Web che funge da API Web che espone un singolo endpoint in cui viene eseguita la logica di business.

  Le macchine virtuali front-end hanno dischi dati (Premium_LRS) collegati, che possono essere usati per distribuire un'applicazione senza stato. Le macchine virtuali back-end persistono i dati in Premium_ZRS dischi locali come parte del relativo funzionamento. Questo layout può essere esteso per includere un livello di database per l'archiviazione dello stato dal calcolo front-end e back-end. Tale livello non rientra nell'ambito di questa architettura.

• Azure Rete virtuale fornisce una rete privata per tutte le risorse del carico di lavoro. La rete viene segmentata in subnet, che fungono da limiti di isolamento.

• app Azure lication Gateway è il singolo punto di ingresso che instrada le richieste ai server front-end. Lo SKU selezionato include web application firewall (WAF) di Azure integrato per una maggiore sicurezza.

• Azure Load Balancer interno instrada il traffico dal livello front-end ai server back-end.

• Lo SKU Standard di Azure Load Balancer fornisce l'accesso a Internet in uscita alle macchine virtuali usando tre indirizzi IP pubblici.

• Azure Key Vault archivia i certificati usati per la comunicazione TLS (Transport Layer Security) end-to-end. Può essere usato anche per i segreti dell'applicazione.

Risorse di supporto del carico di lavoro

• Azure Bastion fornisce l'accesso operativo alle macchine virtuali tramite protocolli sicuri.

• Application Insights raccoglie i log e le metriche dall'applicazione. Poiché l'applicazione non è l'obiettivo di questa architettura, la raccolta di log non viene illustrata nell'implementazione.

• Log Analytics è il sink di dati di monitoraggio che raccoglie log e metriche dalle risorse di Azure e Application Insights. Viene effettuato il provisioning di un account di archiviazione come parte dell'area di lavoro.

Flussi utenti

Esistono due tipi di utenti che interagiscono con le risorse del carico di lavoro: l'utente del carico di lavoro e l'operatore. I flussi per questi utenti sono illustrati nel diagramma dell'architettura precedente.

Utente del carico di lavoro

1. L'utente accede al sito Web usando l'indirizzo IP pubblico esposto di gateway applicazione.

2. gateway applicazione riceve il traffico HTTPS, decrittografa i dati usando un certificato esterno per l'ispezione WAF e lo crittografa nuovamente usando il certificato con caratteri jolly interni per il trasporto nel front-end.

3. gateway applicazione bilancia il traffico tra macchine virtuali front-end e inoltra la richiesta a una macchina virtuale front-end.

4. La macchina virtuale front-end selezionata comunica con una macchina virtuale back-end usando l'indirizzo IP privato del servizio di bilanciamento del carico, non l'INDIRIZZO IP di una singola macchina virtuale. Questa comunicazione viene crittografata anche usando il certificato con caratteri jolly interni.

5. La macchina virtuale back-end decrittografa la richiesta usando il certificato interno. Dopo che il back-end elabora la richiesta, restituisce il risultato al front-end, che restituisce il risultato al gateway applicazione e infine restituisce il risultato all'utente.

Operatore

Le macchine virtuali in questa architettura potrebbero richiedere l'accesso diretto da parte degli operatori, ma è consigliabile ridurre al minimo l'accesso remoto tramite l'automazione e l'accesso viene monitorato. L'accesso potrebbe essere per situazioni di correzione dell'interruzione, risoluzione dei problemi o parte di un processo di distribuzione automatizzato. Questa architettura non ha indirizzi IP pubblici per l'accesso al piano di controllo. Azure Bastion funge da gateway serverless, consentendo alle operazioni di accedere alle macchine virtuali tramite SSH o RDP. Questa configurazione garantisce una gestione degli accessi sicura ed efficiente.

1. L'operatore accede al portale di Azure o all'interfaccia della riga di comando di Azure.
2. L'operatore accede al servizio Azure Bastion e si connette in remoto alla macchina virtuale desiderata.

Scelte di progettazione delle macchine virtuali

Quando si selezionano SKU, è importante avere un'aspettativa di prestazioni di base. Diverse caratteristiche influenzano il processo decisionale, tra cui:

• Operazioni di input/output della CPU, della memoria e del disco al secondo (IOPS).
• Architettura dei processori.
• Dimensioni dell'immagine del sistema operativo.

Ad esempio, se si esegue la migrazione di un carico di lavoro da un ambiente locale che richiede computer processori Intel, scegliere SKU di macchine virtuali che supportano i processori Intel.

Per informazioni sugli SKU di macchine virtuali supportati, vedere Dimensioni per le macchine virtuali in Azure.

Bootstrap

È spesso necessario eseguire il bootstrap delle macchine virtuali, ovvero un processo in cui le macchine virtuali vengono preparate e ottimizzate per eseguire l'applicazione. Le attività di bootstrap comuni includono, l'installazione di certificati, la configurazione dell'accesso remoto, l'installazione di pacchetti, l'ottimizzazione e la protezione avanzata della configurazione del sistema operativo e la formattazione e il montaggio dei dischi dati. È importante automatizzare il processo di bootstrap il più possibile, in modo che l'applicazione possa essere avviata nella macchina virtuale senza ritardi o interventi manuali. Ecco le raccomandazioni per l'automazione:

• Estensioni macchina virtuale. Queste estensioni sono oggetti di Azure Resource Manager gestiti tramite la distribuzione IaC (Infrastructure-as-Code). In questo modo, qualsiasi errore viene segnalato come distribuzione non riuscita su cui è possibile intervenire. Se non è disponibile un'estensione per le esigenze di bootstrapping, creare script personalizzati. È consigliabile eseguire gli script tramite l'estensione script personalizzato di Azure.

  Ecco alcune altre estensioni che possono essere usate per installare o configurare automaticamente le funzionalità nelle macchine virtuali.

  • L'agente di Monitoraggio di Azure raccoglie i dati di monitoraggio dal sistema operativo guest e lo distribuisce a Monitoraggio di Azure.
  • L'estensione script personalizzato di Azure (Windows, Linux) versione 2 scarica ed esegue script in macchine virtuali di Azure. Questa estensione è utile per automatizzare la configurazione post-distribuzione, l'installazione del software o qualsiasi altra configurazione o attività di gestione.
  • L'estensione macchina virtuale di Azure Key Vault (Windows, Linux) fornisce l'aggiornamento automatico dei certificati archiviati in un insieme di credenziali delle chiavi rilevando le modifiche e installando i certificati corrispondenti.
  • L'estensione Integrità applicazioni con set di scalabilità di macchine virtuali è importante quando Azure set di scalabilità di macchine virtuali esegue aggiornamenti in sequenza automatici. Azure si basa sul monitoraggio dell'integrità delle singole istanze per eseguire gli aggiornamenti. È anche possibile usare l'estensione per monitorare l'integrità dell'applicazione di ogni istanza nel set di scalabilità ed eseguire le riparazioni delle istanze usando riparazioni automatiche dell'istanza.
  • Microsoft Entra ID e OpenSSH (Windows, Linux) si integrano con l'autenticazione di Microsoft Entra. È ora possibile usare Microsoft Entra ID come piattaforma di autenticazione principale e un'autorità di certificazione per SSH in una macchina virtuale Linux usando Microsoft Entra ID e l'autenticazione basata su certificati OpenSSH. Questa funzionalità consente di gestire l'accesso alle macchine virtuali con il controllo degli accessi in base al ruolo di Azure e i criteri di accesso condizionale.

• Configurazione basata su agente. Le macchine virtuali Linux possono usare una configurazione dello stato nativa leggera disponibile tramite cloud-init in varie immagini di macchine virtuali fornite da Azure. La configurazione viene specificata e con controllo delle versioni con gli artefatti IaC. L'uso di una soluzione di gestione della configurazione personalizzata è un altro modo. La maggior parte delle soluzioni segue un approccio dichiarativo-first al bootstrap, ma supporta script personalizzati per la flessibilità. Le scelte più comuni includono Desired State Configuration per Windows, Desired State Configuration per Linux, Ansible, Chef, Puppet e altri. Tutte queste soluzioni di configurazione possono essere abbinate alle estensioni della macchina virtuale per un'esperienza ottimale.

Nell'implementazione di riferimento, tutto il bootstrap viene eseguito tramite estensioni della macchina virtuale e script personalizzati, incluso uno script personalizzato per automatizzare la formattazione e il montaggio del disco dati.

Vedere Well-Architected Framework: RE:02 - Recommendations for automation design (Framework ben progettato: RE:02 - Raccomandazioni per la progettazione dell'automazione).

Connettività della macchina virtuale

Per abilitare la comunicazione privata tra una macchina virtuale e altri dispositivi in una determinata rete virtuale, la scheda di interfaccia di rete (NIC) della macchina virtuale è connessa a una delle subnet della rete virtuale. Se sono necessarie più schede di interfaccia di rete per la macchina virtuale, è necessario sapere che per ogni dimensione della macchina virtuale è definito un numero massimo di schede di interfaccia di rete.

Se il carico di lavoro richiede una comunicazione a bassa latenza tra macchine virtuali nella rete virtuale, prendere in considerazione la rete accelerata, supportata dalle schede di interfaccia di rete delle macchine virtuali di Azure. Per altre informazioni, vedere Vantaggi della rete accelerata.

set di scalabilità di macchine virtuali con orchestrazione flessibile

Il provisioning delle macchine virtuali viene eseguito come parte di set di scalabilità di macchine virtuali con orchestrazione flessibile. set di scalabilità di macchine virtuali sono raggruppamenti logici di macchine virtuali usate per soddisfare le esigenze aziendali. I tipi di macchine virtuali in un raggruppamento possono essere identici o diversi. Consentono di gestire il ciclo di vita di computer, interfacce di rete e dischi usando LE API e i comandi standard delle macchine virtuali di Azure.

La modalità di orchestrazione flessibile facilita le operazioni su larga scala e consente di prendere decisioni di ridimensionamento granulari.

La configurazione del dominio di errore è necessaria per limitare l'effetto di errori hardware fisici, interruzioni di rete o interruzioni dell'alimentazione. Con i set di scalabilità, Azure distribuisce uniformemente le istanze tra domini di errore per la resilienza rispetto a un singolo problema di hardware o infrastruttura.

È consigliabile eseguire l'offload dell'allocazione del dominio di errore in Azure per la distribuzione massima delle istanze, migliorando la resilienza e la disponibilità.

Dischi

Per eseguire i componenti del sistema operativo e dell'applicazione, i dischi di archiviazione vengono collegati alla macchina virtuale. Prendere in considerazione l'uso di dischi temporanei per il sistema operativo e i dischi gestiti per l'archiviazione dei dati.

Azure offre un'ampia gamma di opzioni in termini di prestazioni, versatilità e costi. Iniziare con SSD Premium per la maggior parte dei carichi di lavoro di produzione. La scelta dipende dallo SKU della macchina virtuale. Gli SKU che supportano SSD Premium contengono un valore s nel nome della risorsa, ad esempio Dsv4 ma non Dv4.

Per altre informazioni sulle opzioni del disco con metriche, ad esempio capacità, operazioni di I/O al secondo e velocità effettiva, vedere Confronto tra tipi di disco.

Prendere in considerazione le caratteristiche del disco e le aspettative sulle prestazioni quando si seleziona un disco.

• Limitazioni dello SKU della macchina virtuale. I dischi operano all'interno della macchina virtuale a cui sono collegati, con limiti di I/O al secondo e velocità effettiva. Assicurarsi che il disco non limiti i limiti della macchina virtuale e viceversa. Selezionare le dimensioni del disco, le prestazioni e le funzionalità della macchina virtuale (core, CPU, memoria) che eseguono in modo ottimale il componente dell'applicazione. Evitare il provisioning eccessivo perché influisce sui costi.

• Modifiche alla configurazione. È possibile modificare alcune configurazioni di prestazioni e capacità del disco durante l'esecuzione di una macchina virtuale. Tuttavia, molte modifiche possono richiedere il provisioning e la ricompilazione del contenuto del disco, che influiscono sulla disponibilità del carico di lavoro. Pertanto, pianificare attentamente la selezione dello SKU del disco e della macchina virtuale per ridurre al minimo l'impatto e la rielaborazione della disponibilità.

• Dischi temporanei del sistema operativo. Effettuare il provisioning dei dischi del sistema operativo come dischi temporanei. Usare i dischi gestiti solo se è necessario rendere persistenti i file del sistema operativo. Evitare di usare dischi temporanei per l'archiviazione dei componenti e dello stato dell'applicazione.

  La capacità dei dischi del sistema operativo temporaneo dipende dallo SKU di macchina virtuale scelto. Verificare che le dimensioni del disco dell'immagine del sistema operativo siano inferiori alla cache disponibile dello SKU o al disco temporaneo. È possibile usare lo spazio rimanente per l'archiviazione temporanea.

• Prestazioni del disco. Lo spazio su disco di pre-provisioning basato sul carico di picco è comune, ma può portare a risorse sottoutilizzate perché la maggior parte dei carichi di lavoro non supporta il carico di picco.

  Monitorare i modelli di utilizzo del carico di lavoro, notare i picchi o le operazioni di lettura elevata sostenute e considerare questi modelli nella selezione della MACCHINA virtuale e dello SKU del disco gestito.

  È possibile modificare le prestazioni su richiesta modificando i livelli di prestazioni o usando le funzionalità di bursting offerte in alcuni SKU del disco gestito.

  Mentre l'overprovisioning riduce la necessità di bursting, può causare capacità inutilizzata per cui si paga. Idealmente, combinare entrambe le funzionalità per ottenere risultati ottimali.

• Ottimizzare la memorizzazione nella cache per il carico di lavoro. Configurare le impostazioni della cache per tutti i dischi in base all'utilizzo dei componenti dell'applicazione.

  I componenti che eseguono principalmente operazioni di lettura non richiedono coerenza transazionale su disco elevato. Questi componenti possono trarre vantaggio dalla memorizzazione nella cache di sola lettura. I componenti con un numero elevato di operazioni di scrittura che richiedono coerenza transazionale su disco elevato spesso hanno disabilitato la memorizzazione nella cache.

  L'uso della memorizzazione nella cache in lettura/scrittura può causare la perdita di dati se la macchina virtuale si arresta in modo anomalo e non è consigliata per la maggior parte degli scenari dei dischi dati.

In questa architettura:

• I dischi del sistema operativo di tutte le macchine virtuali sono temporanei e si trovano nel disco della cache.

  L'applicazione del carico di lavoro nel front-end (Linux) e nel back-end (Windows Server) è tollerante per singoli errori di macchina virtuale ed entrambi usano immagini di piccole dimensioni (circa 30 GB). Tali attributi li rendono idonei per l'uso di dischi temporanei del sistema operativo creati come parte dell'archiviazione locale della macchina virtuale (partizione della cache) anziché del disco del sistema operativo persistente salvato nelle risorse di archiviazione di Azure remote. Questa situazione non comporta costi di archiviazione per i dischi del sistema operativo e migliora anche le prestazioni fornendo latenze inferiori e riducendo il tempo di distribuzione della macchina virtuale.

• Ogni macchina virtuale ha un proprio disco gestito P1 SSD Premium, fornendo una velocità effettiva con provisioning di base adatta al carico di lavoro.

Layout di rete

Questa architettura distribuisce il carico di lavoro in una singola rete virtuale. I controlli di rete sono una parte significativa di questa architettura e sono descritti nella sezione Sicurezza .

Questo layout può essere integrato con una topologia aziendale. Questo esempio è illustrato nell'architettura di base della macchina virtuale in una zona di destinazione di Azure.

Rete virtuale

Una delle decisioni iniziali relative al layout di rete è correlata all'intervallo di indirizzi di rete. Tenere presente la crescita della rete prevista durante la fase di pianificazione della capacità. La rete dovrebbe essere sufficientemente grande da sostenere la crescita, che potrebbe richiedere costrutti di rete aggiuntivi. Ad esempio, la rete virtuale deve avere la capacità di contenere le altre macchine virtuali risultanti da un'operazione di ridimensionamento.

Viceversa, dimensioni corrette dello spazio indirizzi. Una rete virtuale eccessivamente grande può portare a sottoutilizzo. È importante notare che una volta creata la rete virtuale, l'intervallo di indirizzi non può essere modificato.

In questa architettura, lo spazio indirizzi è impostato su /21, una decisione basata sulla crescita prevista.

Considerazioni sulla subnet

All'interno della rete virtuale, le subnet sono suddivise in base alle funzionalità e ai requisiti di sicurezza, come descritto di seguito:

• Subnet per ospitare il gateway applicazione, che funge da proxy inverso. gateway applicazione richiede una subnet dedicata.
• Una subnet per ospitare il servizio di bilanciamento del carico interno per la distribuzione del traffico alle macchine virtuali back-end.
• Subnet per ospitare le macchine virtuali del carico di lavoro, una per il front-end e una per il back-end. Queste subnet vengono create in base ai livelli dell'applicazione.
• Una subnet per l'host Azure Bastion per facilitare l'accesso operativo alle macchine virtuali del carico di lavoro. Per impostazione predefinita, l'host Azure Bastion richiede una subnet dedicata.
• Una subnet per ospitare endpoint privati creati per accedere ad altre risorse di Azure tramite collegamento privato di Azure. Anche se le subnet dedicate non sono obbligatorie per questi endpoint, è consigliabile usarle.

Analogamente alle reti virtuali, le subnet devono essere ridimensionate correttamente. Ad esempio, è possibile applicare il limite massimo di macchine virtuali supportate dall'orchestrazione flessibile per soddisfare le esigenze di scalabilità dell'applicazione. Le subnet del carico di lavoro devono essere in grado di soddisfare tale limite.

Un altro caso d'uso da considerare è l'aggiornamento del sistema operativo della macchina virtuale, che potrebbe richiedere indirizzi IP temporanei. Il ridimensionamento corretto offre il livello di segmentazione desiderato assicurandosi che le risorse simili siano raggruppate in modo che le regole di sicurezza significative tramite i gruppi di sicurezza di rete (NSG) possano essere applicate ai limiti della subnet. Per altre informazioni, vedere Sicurezza: Segmentazione.

Traffico in ingresso

Per i flussi in ingresso vengono usati due indirizzi IP pubblici. Un indirizzo è per gateway applicazione che funge da proxy inverso. Gli utenti si connettono usando tale indirizzo IP pubblico. Il proxy inverso bilancia il traffico in ingresso verso gli INDIRIZZI IP privati delle macchine virtuali. L'altro indirizzo è per l'accesso operativo tramite Azure Bastion.

Scaricare un file di Visio di questa architettura.

Traffico in uscita

Questa architettura usa Load Balancer SKU standard con regole in uscita definite dalle istanze della macchina virtuale. Load Balancer è stato scelto perché è ridondante per la zona.

Scaricare un file di Visio di questa architettura.

Questa configurazione consente di usare gli indirizzi IP pubblici del servizio di bilanciamento del carico per fornire connettività Internet in uscita per le macchine virtuali. Le regole in uscita consentono di definire in modo esplicito le porte SNAT (Source Network Address Translation). Le regole consentono di ridimensionare e ottimizzare questa capacità tramite l'allocazione manuale delle porte. Allocare manualmente la porta SNAT in base alle dimensioni del pool back-end e al numero di frontendIPConfigurations può aiutare a evitare l'esaurimento SNAT.

È consigliabile allocare porte in base al numero massimo di istanze back-end. Se vengono aggiunte più istanze rispetto alle porte SNAT rimanenti consentite, set di scalabilità di macchine virtuali operazioni di ridimensionamento potrebbero essere bloccate o le nuove macchine virtuali non ricevono porte SNAT sufficienti.

Calcolare le porte per istanza come: Number of front-end IPs * 64K / Maximum number of back-end instances.

È possibile usare altre opzioni, ad esempio la distribuzione di una risorsa gateway NAT di Azure collegata alla subnet. Un'altra opzione consiste nell'usare Firewall di Azure o un'altra appliance virtuale di rete con una route definita dall'utente personalizzata come hop successivo attraverso il firewall. Questa opzione viene visualizzata nell'architettura di base della macchina virtuale in una zona di destinazione di Azure.

Risoluzione DNS

DNS di Azure viene usato come servizio di base per tutti i casi d'uso di risoluzione, ad esempio la risoluzione dei nomi di dominio completi (FQDN) associati alle macchine virtuali del carico di lavoro. In questa architettura le macchine virtuali usano i valori DNS impostati nella configurazione della rete virtuale, ovvero DNS di Azure.

Le zone DNS private di Azure vengono usate per risolvere le richieste agli endpoint privati usati per accedere alle risorse di collegamento privato denominate.

Monitoraggio

Questa architettura ha uno stack di monitoraggio separato dall'utilità del carico di lavoro. L'attenzione riguarda principalmente le origini dati e gli aspetti della raccolta.

Le metriche e i log vengono generati in varie origini dati, fornendo informazioni dettagliate sull'osservabilità a diverse altitudini:

• L'infrastruttura e i componenti sottostanti vengono considerati, ad esempio macchine virtuali, reti virtuali e servizi di archiviazione. I log della piattaforma Azure forniscono informazioni sulle operazioni e sulle attività all'interno della piattaforma Azure.

• Il livello dell'applicazione fornisce informazioni dettagliate sulle prestazioni e sul comportamento delle applicazioni in esecuzione nel sistema.

L'area di lavoro Log Analytics è il sink di dati di monitoraggio consigliato usato per raccogliere log e metriche dalle risorse di Azure e Da Application Insights.

Questa immagine mostra lo stack di monitoraggio per la linea di base con i componenti per la raccolta di dati dall'infrastruttura e dall'applicazione, dai sink di dati e dai vari strumenti di utilizzo per l'analisi e la visualizzazione. L'implementazione distribuisce alcuni componenti, ad esempio Application Insights, diagnostica di avvio della macchina virtuale e Log Analytics. Altri componenti sono illustrati per mostrare le opzioni di estendibilità, ad esempio dashboard e avvisi.

Scaricare un file di Visio di questa architettura.

Monitoraggio a livello di infrastruttura

Questa tabella è collegata a log e metriche raccolte da Monitoraggio di Azure. Gli avvisi disponibili consentono di risolvere in modo proattivo i problemi prima che influiscano sugli utenti.

Risorsa di Azure	Metriche e log	Avvisi
Gateway applicazione	gateway applicazione descrizione delle metriche e dei log	avvisi di gateway applicazione
Application Insights	Api di registrazione e metriche di Application Insights	avvisi di Application Insights
Azure Bastion	Metriche di Azure Bastion
Insieme di credenziali delle chiavi di	Metriche e descrizioni dei log di Key Vault	Avvisi di Key Vault
Load Balancer standard	Log e metriche del servizio di bilanciamento del carico	Avvisi di Load Balancer
Indirizzo IP pubblico	Descrizione delle metriche e dei log degli indirizzi IP pubblici	Avvisi delle metriche degli indirizzi IP pubblici
Rete virtuale	Informazioni di riferimento su metriche e log di rete virtuale	Avvisi di rete virtuale
Macchine virtuali e set di scalabilità di macchine virtuali	Informazioni di riferimento sulle metriche e i log delle macchine virtuali	Avvisi ed esercitazioni delle macchine virtuali
Web application firewall	Descrizione delle metriche e dei log di Web Application Firewall	Avvisi di Web Application Firewall

Per altre informazioni sul costo della raccolta di metriche e log, vedere Calcoli e opzioni dei costi di Log Analytics e Prezzi per l'area di lavoro Log Analytics. La natura del carico di lavoro e la frequenza e il numero di metriche e log raccolti influisce notevolmente sui costi di metrica e raccolta dei log.

Macchine virtuali

La diagnostica di avvio di Azure è abilitata per osservare lo stato delle macchine virtuali durante l'avvio raccogliendo informazioni e screenshot del log seriale. In questa architettura è possibile accedere ai dati tramite portale di Azure e il comando get-boot-log della macchina virtuale dell'interfaccia della riga di comando di Azure. I dati sono gestiti da Azure e non si ha alcun controllo o accesso alla risorsa di archiviazione sottostante. Tuttavia, se i requisiti aziendali richiedono un maggiore controllo, è possibile effettuare il provisioning del proprio account di archiviazione per archiviare la diagnostica di avvio.

Le informazioni dettagliate sulle macchine virtuali offrono un modo efficiente per monitorare le macchine virtuali e i set di scalabilità. Raccoglie i dati dalle aree di lavoro Log Analytics e fornisce cartelle di lavoro predefinite per la tendenza dei dati sulle prestazioni. Questi dati possono essere visualizzati per macchina virtuale o aggregati in più macchine virtuali.

gateway applicazione e il servizio di bilanciamento del carico interno usano probe di integrità per rilevare lo stato dell'endpoint delle macchine virtuali prima di inviare il traffico.

Rete

In questa architettura, i dati di log vengono raccolti da diversi componenti di rete che partecipano al flusso. Questi componenti includono gateway applicazione, servizi di bilanciamento del carico e Azure Bastion. Includono anche componenti di sicurezza di rete, ad esempio reti virtuali, gruppi di sicurezza di rete, indirizzi IP pubblici e collegamento privato.

Dischi gestiti

Le metriche del disco dipendono dal carico di lavoro, richiedendo una combinazione di metriche chiave. Il monitoraggio deve combinare queste prospettive per isolare i problemi di velocità effettiva del sistema operativo o dell'applicazione.

• La prospettiva della piattaforma Azure rappresenta le metriche che indicano il servizio di Azure, indipendentemente dal carico di lavoro a cui è connessa. Le metriche delle prestazioni del disco (operazioni di I/O al secondo e velocità effettiva) possono essere visualizzate singolarmente o collettivamente per tutti i dischi collegati alle macchine virtuali. Usare le metriche di utilizzo di I/O di archiviazione per la risoluzione dei problemi o gli avvisi relativi al limite potenziale del disco. Se si usa il bursting per l'ottimizzazione dei costi, monitorare le metriche relative alla percentuale di crediti per identificare le opportunità per un'ulteriore ottimizzazione.

• La prospettiva del sistema operativo guest rappresenta le metriche visualizzate dall'operatore del carico di lavoro, indipendentemente dalla tecnologia del disco sottostante. Le informazioni dettagliate sulle macchine virtuali sono consigliate per le metriche chiave nei dischi collegati, ad esempio lo spazio su disco logico usato e la prospettiva del kernel del sistema operativo sulle operazioni di I/O al secondo e sulla velocità effettiva del disco.

Monitoraggio a livello di applicazione

Anche se l'implementazione di riferimento non la usa, Application Insights viene sottoposto a provisioning come Application Performance Management (APM) per scopi di estendibilità. Application Insights raccoglie i dati da un'applicazione e li invia all'area di lavoro Log Analytics. Può anche visualizzare i dati dalle applicazioni del carico di lavoro.

L'estensione dell'integrità dell'applicazione viene distribuita nelle macchine virtuali per monitorare lo stato di integrità binaria di ogni istanza del set di scalabilità nel set di scalabilità ed eseguire le riparazioni delle istanze, se necessario, usando il ripristino automatico dell'istanza del set di scalabilità. Verifica lo stesso file del gateway applicazione e del probe di integrità interno del servizio di bilanciamento del carico di Azure per verificare se l'applicazione è reattiva.

Gestione aggiornamenti

Le macchine virtuali devono essere aggiornate e applicate regolarmente patch in modo che non indebolino il comportamento di sicurezza del carico di lavoro. È consigliabile eseguire valutazioni automatiche e periodiche delle macchine virtuali per l'individuazione anticipata e l'applicazione delle patch.

Aggiornamenti dell'infrastruttura

Azure aggiorna periodicamente la piattaforma per migliorare l'affidabilità, le prestazioni e la sicurezza dell'infrastruttura host per le macchine virtuali. Questi aggiornamenti includono l'applicazione di patch ai componenti software nell'ambiente di hosting, l'aggiornamento di componenti di rete o la rimozione delle autorizzazioni hardware e altro ancora. Per informazioni sul processo di aggiornamento, vedere Manutenzione per le macchine virtuali in Azure.

Se un aggiornamento non richiede un riavvio, la macchina virtuale viene sospesa mentre l'host viene aggiornato o la macchina virtuale viene migrata in tempo reale in un host già aggiornato. Se la manutenzione richiede un riavvio, si riceve una notifica della manutenzione pianificata. Azure offre anche un intervallo di tempo in cui è possibile avviare la manutenzione, per comodità. Per informazioni sulla finestra di manutenzione automatica e su come configurare le opzioni disponibili, vedere Gestione delle notifiche di manutenzione pianificata.

Alcuni carichi di lavoro potrebbero non tollerare nemmeno pochi secondi di blocco o disconnessione di una macchina virtuale per la manutenzione. Per un maggiore controllo su tutte le attività di manutenzione, inclusi gli aggiornamenti senza riavvio e a impatto zero, vedere Configurazioni di manutenzione. La creazione di una configurazione di manutenzione consente di ignorare tutti gli aggiornamenti della piattaforma e di applicare gli aggiornamenti per comodità. Quando questa configurazione personalizzata è impostata, Azure ignora tutti gli aggiornamenti senza impatto zero, inclusi gli aggiornamenti senza riavvio. Per altre informazioni, vedere Gestione degli aggiornamenti della piattaforma con configurazioni di manutenzione

Aggiornamenti delle immagini del sistema operativo

Quando si eseguono aggiornamenti del sistema operativo, è disponibile un'immagine d'oro testata. È consigliabile usare Azure Raccolta immagini condivise e Azure Compute Gallery per pubblicare le immagini personalizzate. È necessario disporre di un processo che aggiorna batch di istanze in modo in sequenza ogni volta che viene pubblicata una nuova immagine dall'editore.

Ritirare le immagini delle macchine virtuali prima di raggiungere la fine del ciclo di vita per ridurre la superficie di attacco.

Il processo di automazione deve tenere conto dell'overprovisioning con capacità aggiuntiva.

È possibile usare Gestione aggiornamenti di Azure per gestire gli aggiornamenti del sistema operativo per le macchine virtuali Windows e Linux in Azure.Azure Update Manager offre una soluzione SaaS per gestire e gestire gli aggiornamenti software nei computer Windows e Linux in ambienti Azure, locali e multicloud.

Applicazione di patch al sistema operativo guest

Le macchine virtuali di Azure offrono l'opzione di applicazione automatica di patch guest alle macchine virtuali. Quando questo servizio è abilitato, le macchine virtuali vengono valutate periodicamente e le patch disponibili vengono classificate. È consigliabile abilitare la modalità di valutazione per consentire la valutazione giornaliera per le patch in sospeso. È tuttavia possibile eseguire una valutazione su richiesta che non attiva l'applicazione di patch. Se la modalità di valutazione non è abilitata, è possibile rilevare manualmente gli aggiornamenti in sospeso.

Solo le patch classificate come critiche o di sicurezza vengono applicate automaticamente in tutte le aree di Azure. Definire processi di gestione degli aggiornamenti personalizzati che applicano altre patch.

Per la governance, prendere in considerazione l'applicazione di patch richiedi l'applicazione automatica dell'immagine del sistema operativo in set di scalabilità di macchine virtuali Criteri di Azure.

L'applicazione automatica delle patch può comportare un carico sul sistema e può causare interruzioni perché le macchine virtuali usano risorse e possono essere riavviate durante gli aggiornamenti. Il provisioning eccessivo è consigliato per la gestione del carico. Distribuire macchine virtuali in zone di disponibilità diverse per evitare aggiornamenti simultanei e gestire almeno due istanze per zona per la disponibilità elevata. Le macchine virtuali nella stessa area potrebbero ricevere patch diverse, che devono essere riconciliate nel tempo.

Tenere presente il compromesso sui costi associati all'overprovisioning.

I controlli di integrità sono inclusi nell'ambito dell'applicazione automatica di patch guest alle macchine virtuali. Questi controlli verificano la corretta applicazione patch e rilevano i problemi.

Se sono presenti processi personalizzati per l'applicazione di patch, usare repository privati per le origini patch. In questo modo è possibile controllare meglio i test delle patch per assicurarsi che l'aggiornamento non influisca negativamente sulle prestazioni o sulla sicurezza.

Per altre informazioni, vedere Applicazione automatica di patch guest alle macchine virtuali per le macchine virtuali di Azure.

Affidabilità

Questa architettura usa le zone di disponibilità come elemento fondamentale per risolvere i problemi di affidabilità.

In questa configurazione le singole macchine virtuali sono associate a una singola zona. Se si verifica un errore, queste macchine virtuali possono essere sostituite facilmente con altre istanze di macchina virtuale usando set di scalabilità di macchine virtuali.

Tutti gli altri componenti di questa architettura sono i seguenti:

• Ridondanza della zona, ovvero vengono replicate in più zone per la disponibilità elevata, ad esempio gateway applicazione o indirizzi IP pubblici.
• Resilienza della zona, che implica che possono resistere a errori di zona, ad esempio Key Vault.
• Risorse internazionali o globali disponibili in diverse aree o a livello globale, ad esempio Microsoft Entra ID.

La progettazione del carico di lavoro deve incorporare garanzie di affidabilità nel codice dell'applicazione, nell'infrastruttura e nelle operazioni. Le sezioni seguenti illustrano alcune strategie per assicurarsi che il carico di lavoro sia resiliente agli errori ed è in grado di eseguire il ripristino in caso di interruzioni a livello di infrastruttura.

Le strategie usate nell'architettura si basano sull'elenco di controllo di revisione della progettazione dell'affidabilità fornito in Azure Well-Architected Framework. Le sezioni sono annotate con le raccomandazioni di tale elenco di controllo.

Poiché non viene distribuita alcuna applicazione, la resilienza nel codice dell'applicazione esula dall'ambito di questa architettura. È consigliabile esaminare tutte le raccomandazioni nell'elenco di controllo e adottarle nel carico di lavoro, se applicabile.

Classificare in ordine di priorità le garanzie di affidabilità per ogni flusso utente

Nella maggior parte delle progettazioni sono presenti più flussi utente, ognuno con un proprio set di requisiti aziendali. Non tutti questi flussi richiedono il massimo livello di garanzie, quindi la segmentazione è consigliata come strategia di affidabilità. Ogni segmento può essere gestito in modo indipendente, assicurandosi che un segmento non influisca sugli altri e fornisca il livello di resilienza corretto in ogni livello. Questo approccio rende anche flessibile il sistema.

In questa architettura i livelli applicazione implementano la segmentazione. Viene effettuato il provisioning di set di scalabilità separati per i livelli front-end e back-end. Questa separazione consente la scalabilità indipendente di ogni livello, consentendo l'implementazione di modelli di progettazione in base ai requisiti specifici, tra gli altri vantaggi.

Vedere Well-Architected Framework: RE:02 - Recommendations for identification and rating flows (Framework ben progettato: RE:02 - Raccomandazioni per l'identificazione e la classificazione dei flussi).

Identificare i potenziali punti di errore

Ogni architettura è soggetta a errori. L'esercizio dell'analisi della modalità di errore consente di prevedere gli errori ed essere preparati con le mitigazioni. Ecco alcuni potenziali punti di errore in questa architettura:

Componente	Rischio	Probabilità	Effetto/Mitigazione/Nota	Outage
Microsoft Entra ID	Errore di configurazione	Medio	Gli utenti Ops non sono in grado di accedere. Nessun effetto downstream. L'help desk segnala il problema di configurazione al team di identità.	None
Gateway applicazione	Errore di configurazione	Medio	Le configurazioni errate devono essere rilevate durante la distribuzione. Se questi errori si verificano durante un aggiornamento della configurazione, il team devOps deve eseguire il rollback delle modifiche. Per la maggior parte delle distribuzioni che usano lo SKU v2 sono necessari circa 6 minuti per il provisioning. Tuttavia, può essere necessario più tempo a seconda del tipo di distribuzione. Ad esempio, le distribuzioni in più zone di disponibilità con molte istanze possono richiedere più di 6 minuti.	Completo
Gateway applicazione	Attacco DDoS	Medio	Potenziale interruzione. Microsoft gestisce la protezione DDoS (L3 e L4). Potenziale rischio di effetto da attacchi L7.	Completo
Set di scalabilità di macchine virtuali	Interruzione del servizio	Basso	Potenziale interruzione del carico di lavoro se sono presenti istanze di macchine virtuali non integre che attivano l'associazione automatica. Dipendente da Microsoft per la correzione.	Potenziale interruzione
Set di scalabilità di macchine virtuali	Interruzione della zona di disponibilità	Basso	Nessun effetto. I set di scalabilità vengono distribuiti come ridondanti della zona.	None

Vedere Well-Architected Framework: RE:03 - Recommendations for performing failure mode analysis (Framework ben progettato: RE:03 - Raccomandazioni per l'esecuzione dell'analisi della modalità di errore).

Obiettivi di affidabilità

Per prendere decisioni di progettazione, è importante calcolare gli obiettivi di affidabilità, ad esempio gli obiettivi del livello di servizio compositi del carico di lavoro. In questo modo è necessario comprendere i contratti di servizio forniti dai servizi di Azure usati nell'architettura. I contratti di servizio del carico di lavoro non devono essere superiori ai contratti di servizio garantiti da Azure. Esaminare attentamente ogni componente, dalle macchine virtuali e dalle relative dipendenze, funzionalità di rete e opzioni di archiviazione.

Ecco un esempio di calcolo in cui l'obiettivo principale è fornire un SLO composito approssimativo. Anche se si tratta di una linea guida approssimativa, si dovrebbe arrivare a qualcosa di simile. Non è consigliabile ottenere uno SLO composito più alto per gli stessi flussi, a meno che non si apportano modifiche all'architettura.

Flusso dell'operazione

Componente	SLO
Microsoft Entra ID	99,99%
Azure Bastion	99,95%

SLO composito: 99,94% | Tempo di inattività all'anno: 0d 5h 15m 20s

Flusso utente dell'app

Componente	SLO
Gateway applicazione	99,95%
Azure Load Balancer (interno)	99,99%
Macchine virtuali front-end che usano l'archiviazione Premium (SLO composito)	99.70%
Macchine virtuali back-end che usano l'archiviazione Premium (SLO composito)	99.70%

SLO composito: 99,34% | Tempo di inattività all'anno: 2d 9h 42m 18s

Nell'esempio precedente viene inclusa l'affidabilità delle macchine virtuali e delle dipendenze, ad esempio i dischi associati alle macchine virtuali. I contratti di servizio associati all'archiviazione su disco influisce sull'affidabilità complessiva.

Esistono alcune sfide durante il calcolo dell'SLO composito. È importante notare che diversi livelli di servizio possono essere dotati di contratti di servizio diversi e spesso includono garanzie supportate finanziariamente che impostano obiettivi di affidabilità. Infine, potrebbero essere presenti componenti dell'architettura che non dispongono di contratti di servizio definiti. Ad esempio, in termini di rete, schede di interfaccia di rete e reti virtuali non hanno contratti di servizio propri.

I requisiti aziendali e i relativi obiettivi devono essere chiaramente definiti e inseriti nel calcolo. Tenere presenti i limiti del servizio e altri vincoli imposti dall'organizzazione. La condivisione della sottoscrizione con altri carichi di lavoro potrebbe influire sulle risorse disponibili per le macchine virtuali. Il carico di lavoro potrebbe essere autorizzato a usare un numero limitato di core disponibili per le macchine virtuali. Comprendere l'utilizzo delle risorse della sottoscrizione consente di progettare le macchine virtuali in modo più efficace.

Vedere Well-Architected Framework: RE:04 - Recommendations for defining reliability targets (Framework ben progettato: RE:04 - Raccomandazioni per la definizione degli obiettivi di affidabilità).

Ridondanza

Questa architettura usa la ridondanza della zona per diversi componenti. Ogni zona è costituita da uno o più data center dotati di impianti indipendenti per l'alimentazione, il raffreddamento e la connettività di rete. La presenza di istanze eseguite in zone separate protegge l'applicazione da errori del data center.

• set di scalabilità di macchine virtuali alloca un numero specificato di istanze e le distribuisce uniformemente tra zone di disponibilità e domini di errore. Questa distribuzione viene ottenuta tramite la funzionalità di distribuzione massima consigliata. La distribuzione di istanze di macchine virtuali tra domini di errore garantisce che tutte le macchine virtuali non vengano aggiornate contemporaneamente.

  Si consideri uno scenario in cui sono presenti tre zone di disponibilità. Se sono presenti tre istanze, ogni istanza viene allocata a una zona di disponibilità diversa e inserita in un dominio di errore diverso. Azure garantisce che un solo dominio di errore venga aggiornato alla volta in ogni zona di disponibilità. Tuttavia, potrebbe verificarsi una situazione in cui tutti e tre i domini di errore che ospitano le macchine virtuali nelle tre zone di disponibilità vengono aggiornati contemporaneamente. Tutte le zone e i domini sono interessati. La presenza di almeno due istanze in ogni zona fornisce un buffer durante gli aggiornamenti.

• I dischi gestiti possono essere collegati solo a una macchina virtuale nella stessa area. La disponibilità influisce in genere sulla disponibilità della macchina virtuale. Per le distribuzioni a singola area, i dischi possono essere configurati per la ridondanza in modo da resistere agli errori di zona. In questa architettura, i dischi dati sono configurati per l'archiviazione con ridondanza della zona nelle macchine virtuali back-end. Richiede una strategia di ripristino per sfruttare i vantaggi delle zone di disponibilità. La strategia di ripristino consiste nel ridistribuire la soluzione. Idealmente, eseguire il pre-provisioning delle risorse di calcolo in zone di disponibilità alternative pronte per il ripristino da un errore di zona.

• Un gateway applicazione con ridondanza della zona o un servizio di bilanciamento del carico standard può instradare il traffico alle macchine virtuali tra zone usando un singolo indirizzo IP, garantendo la continuità anche se si verificano errori di zona. Questi servizi usano probe di integrità per verificare la disponibilità delle macchine virtuali. Finché una zona nell'area rimane operativa, il routing continua nonostante potenziali errori in altre zone. Tuttavia, il routing tra zone potrebbe avere una latenza superiore rispetto al routing all'interno della zona.

  Tutti gli INDIRIZZI IP pubblici usati in questa architettura sono ridondanti della zona.

• Azure offre servizi resilienti per la zona per migliorare l'affidabilità, ad esempio Key Vault.

• Le risorse globali di Azure sono sempre disponibili e possono passare a un'altra area, se necessario, ad esempio il provider di identità di base, l'ID Microsoft Entra.

Vedere Well-Architected Framework: RE:05 - Recommendations for designing for redundancy (Framework ben progettato: RE:05 - Raccomandazioni per la progettazione per la ridondanza).

Strategia di ridimensionamento

Per evitare la riduzione del livello di servizio e gli errori, assicurarsi che le operazioni di scalabilità siano affidabili. Ridimensionare il carico di lavoro orizzontalmente (scalabilità orizzontale), verticalmente (aumento delle prestazioni) o usare una combinazione di entrambi gli approcci. Usare la scalabilità automatica di Monitoraggio di Azure per effettuare il provisioning di risorse sufficienti per supportare la domanda sull'applicazione senza allocare più capacità del necessario e incorrere in costi non necessari.

La scalabilità automatica consente di definire profili diversi in base a tipi di evento diversi, ad esempio ora, pianificazione o metriche. I profili basati su metriche possono usare metriche predefinite (basate su host) o metriche più dettagliate (metriche delle macchine virtuali guest) che richiedono l'installazione dell'agente di Monitoraggio di Azure per raccoglierle. Ogni profilo contiene regole per l'aumento del numero di istanze (aumento) e la riduzione (riduzione). Prendere in considerazione l'esplorazione di tutti i diversi scenari di ridimensionamento in base ai profili progettati e valutarli per potenziali condizioni del ciclo che possono causare una serie di eventi di scalabilità opposti. Monitoraggio di Azure tenterà di attenuare questa situazione attendendo il periodo di raffreddamento prima che venga ridimensionato di nuovo.

Anche se Azure set di scalabilità di macchine virtuali in modalità flessibile supporta ambienti eterogenei, la scalabilità automatica di più profili non è supportata. Valutare la possibilità di creare set di scalabilità diversi per gestirli separatamente se si prevede di usare la scalabilità automatica con più di un tipo di macchina virtuale.

Prendere in considerazione altri aspetti, ad esempio il bootstrap, gli arresti normale, l'installazione del carico di lavoro e tutte le relative dipendenze e la gestione del disco durante la creazione o l'eliminazione di istanze di macchine virtuali.

I carichi di lavoro con stato potrebbero richiedere una gestione aggiuntiva per i dischi gestiti che devono vivere oltre un'istanza del carico di lavoro. Progettare il carico di lavoro per la gestione dei dati in eventi di ridimensionamento per coerenza, sincronizzazione, replica e integrità dei dati del carico di lavoro. Per questi scenari, è consigliabile aggiungere dischi prepopolati ai set di scalabilità. Per i casi d'uso in cui viene usata la scalabilità per evitare colli di bottiglia durante l'accesso ai dati, pianificare il partizionamento e il partizionamento orizzontale. Per altre informazioni, vedere Procedure consigliate per la scalabilità automatica.

Vedere Well-Architected Framework: RE:06 - Recommendations for designing a reliable scaling strategy (Framework ben progettato: RE:06 - Raccomandazioni per la progettazione di una strategia di scalabilità affidabile).

Riparazione automatica e recuperabilità

Le riparazioni automatiche delle istanze sono abilitate nella set di scalabilità di macchine virtuali per automatizzare il ripristino da errori delle macchine virtuali. L'estensione di integrità dell'applicazione viene distribuita nelle macchine virtuali per supportare il rilevamento di macchine virtuali e applicazioni che non rispondono. Per tali istanze, le azioni di ripristino vengono attivate automaticamente.

Vedere Well-Architected Framework: Recommendations for self-healing and self-preservation (Framework ben progettato: raccomandazioni per la riparazione automatica e la conservazione automatica).

Sicurezza

Questa architettura illustra alcune delle garanzie di sicurezza fornite nell'elenco di controllo di revisione della progettazione della sicurezza fornito in Azure Well-Architected Framework. Le sezioni sono annotate con le raccomandazioni di tale elenco di controllo.

La sicurezza non si riferisce solo ai controlli tecnici. È consigliabile seguire l'intero elenco di controllo per comprendere gli aspetti operativi del pilastro Sicurezza.

Segmentazione

• Segmentazione di rete. Le risorse del carico di lavoro vengono inserite in una rete virtuale, che fornisce l'isolamento da Internet. All'interno della rete virtuale, le subnet possono essere usate come limiti di attendibilità. Colocare le risorse correlate necessarie per gestire una transazione in una subnet. In questa architettura la rete virtuale è suddivisa in subnet in base al raggruppamento logico dell'applicazione e allo scopo di vari servizi di Azure usati come parte del carico di lavoro.

  Il vantaggio della segmentazione della subnet è che è possibile posizionare i controlli di sicurezza nel perimetro che controlla il flusso del traffico in ingresso e in uscita dalla subnet, limitando così l'accesso alle risorse del carico di lavoro.

• Segmentazione delle identità. Assegnare ruoli distinti a identità diverse con autorizzazioni just-enough per svolgere l'attività. Questa architettura usa le identità gestite da Microsoft Entra ID per segmentare l'accesso alle risorse.

• Segmentazione delle risorse. L'applicazione viene segmentata in base ai livelli in set di scalabilità separati, che garantisce che i componenti dell'applicazione non siano raggruppati.

Vedere Well-Architected Framework: SE:04 - Recommendations for building a segmentation strategy (Framework ben progettato: SE:04 - Raccomandazioni per la creazione di una strategia di segmentazione).

Gestione delle identità e dell'accesso

È consigliabile usare Microsoft Entra ID per l'autenticazione e l'autorizzazione di utenti e servizi.

L'accesso alle macchine virtuali richiede un account utente, controllato dall'autenticazione con ID Entra Di Microsoft e supportato dai gruppi di sicurezza. Questa architettura offre supporto distribuendo l'estensione di autenticazione ID Entra Di Microsoft in tutte le macchine virtuali. È consigliabile che gli utenti umani usino le identità aziendali nel tenant microsoft Entra ID dell'organizzazione. Assicurarsi anche che qualsiasi accesso basato su entità servizio non sia condiviso tra le funzioni.

Le risorse del carico di lavoro, ad esempio le macchine virtuali, si autenticano usando le identità gestite assegnate ad altre risorse. Queste identità, basate sulle entità servizio Microsoft Entra ID, vengono gestite automaticamente.

Ad esempio, le estensioni di Key Vault vengono installate nelle macchine virtuali, che avviano le macchine virtuali con certificati sul posto. In questa architettura, le identità gestite assegnate dall'utente vengono usate da gateway applicazione, macchine virtuali front-end e macchine virtuali back-end per accedere a Key Vault. Tali identità gestite vengono configurate durante la distribuzione e usate per l'autenticazione in Key Vault. I criteri di accesso in Key Vault sono configurati per accettare solo le richieste provenienti dalle identità gestite precedenti.

L'architettura di base usa una combinazione di identità gestite assegnate dal sistema e assegnate dall'utente. Queste identità sono necessarie per usare l'ID Entra di Microsoft per scopi di autorizzazione durante l'accesso ad altre risorse di Azure.

Vedere Well-Architected Framework: SE:05 - Recommendations for identity and access management (Framework ben progettato: SE:05 - Raccomandazioni per la gestione delle identità e degli accessi).

Controlli di rete

• Traffico in ingresso. Le macchine virtuali del carico di lavoro non sono esposte direttamente a Internet pubblico. Ogni macchina virtuale ha un indirizzo IP privato. Gli utenti del carico di lavoro si connettono usando l'indirizzo IP pubblico di gateway applicazione.

  Maggiore sicurezza viene fornita tramite Web Application Firewall integrato con gateway applicazione. Dispone di regole che controllano il traffico in ingresso e possono intervenire in modo appropriato. WAF tiene traccia delle vulnerabilità OWASP (Open Web Application Security Project) che impediscono attacchi noti.

• Traffico in uscita. Non sono presenti controlli sul traffico in uscita, ad eccezione delle regole del gruppo di sicurezza di rete in uscita nelle subnet della macchina virtuale. È consigliabile che tutto il traffico Internet in uscita passi attraverso un singolo firewall. Questo firewall è in genere un servizio centrale fornito da un'organizzazione. Questo caso d'uso viene illustrato nell'architettura di base della macchina virtuale in una zona di destinazione di Azure.

• Traffico est-ovest. Il flusso di traffico tra le subnet è limitato applicando regole di sicurezza granulari.

  I gruppi di sicurezza di rete (NSG) vengono posizionati per limitare il traffico tra subnet in base a parametri quali intervallo di indirizzi IP, porte e protocolli. I gruppi di sicurezza delle applicazioni vengono posizionati nelle macchine virtuali front-end e back-end. Vengono usati con i gruppi di sicurezza di rete per filtrare il traffico da e verso le macchine virtuali.

• Traffico operativo. È consigliabile fornire l'accesso operativo sicuro a un carico di lavoro tramite Azure Bastion, che rimuove la necessità di un indirizzo IP pubblico. In questa architettura, la comunicazione avviene tramite SSH ed è supportata dalle macchine virtuali Windows e Linux. Microsoft Entra ID è integrato con SSH per entrambi i tipi di macchine virtuali usando l'estensione vm corrispondente. Tale integrazione consente l'autenticazione e l'autorizzazione dell'identità di un operatore tramite Microsoft Entra ID.

  In alternativa, usare una macchina virtuale separata come jump box, distribuita nella propria subnet, in cui è possibile installare la scelta degli strumenti di amministrazione e risoluzione dei problemi. L'operatore accede al jump box tramite l'host Azure Bastion. Accedono quindi alle macchine virtuali dietro il servizio di bilanciamento del carico dalla jump box.

  In questa architettura, il traffico operativo è protetto usando regole del gruppo di sicurezza di rete per limitare il traffico e l'accesso JIT alle macchine virtuali è abilitato nelle macchine virtuali. Questa funzionalità di Microsoft Defender per il cloud consente l'accesso in ingresso temporaneo alle porte selezionate.

  Per una maggiore sicurezza, usare Microsoft Entra Privileged Identity Management (PIM).For enhanced security, use Microsoft Entra Privileged Identity Management (PIM). PIM è un servizio in Microsoft Entra ID che consente di gestire, controllare e monitorare l'accesso a risorse importanti nell'organizzazione. PIM consente l'attivazione del ruolo basata sul tempo e sull'approvazione per attenuare i rischi di autorizzazioni di accesso eccessive, non necessarie o usate in modo improprio per le risorse più importanti.

• Connettività privata ai servizi PaaS (Platform as a Service). La comunicazione tra le macchine virtuali e l'insieme di credenziali delle chiavi è collegamento privato. Questo servizio richiede endpoint privati, che vengono inseriti in una subnet separata.

• Protezione DDoS. Valutare la possibilità di abilitare protezione DDoS di Azure negli indirizzi IP pubblici esposti da gateway applicazione e dall'host Azure Bastion per rilevare le minacce. Protezione DDoS fornisce anche avvisi, dati di telemetria e analisi tramite Monitoraggio. Per altre informazioni, vedere Procedure consigliate per Protezione DDoS di Azure e architetture di riferimento.

Vedere Well-Architected Framework: SE:06 - Recommendations for networking and connectivity (Framework ben progettato: SE:06 - Raccomandazioni per la rete e la connettività).

Crittografia

• Dati in transito. Il traffico utente tra gli utenti e l'indirizzo IP pubblico gateway applicazione viene crittografato usando il certificato esterno. Il traffico tra il gateway applicazione e le macchine virtuali front-end e tra le macchine virtuali front-end e back-end viene crittografato usando un certificato interno. Entrambi i certificati vengono archiviati in Key Vault:

  • app.contoso.com: certificato esterno usato dai client e gateway applicazione per proteggere il traffico Internet pubblico.
  • *.workload.contoso.com: certificato con caratteri jolly usato dai componenti dell'infrastruttura per proteggere il traffico interno.

• Dati inattivi. I dati di log vengono archiviati in un disco gestito collegato alle macchine virtuali. Questi dati vengono crittografati automaticamente usando la crittografia fornita dalla piattaforma in Azure.

Fare riferimento a Well-Architected Framework: SE:07 - Raccomandazioni per la crittografia dei dati.

Gestione dei segreti

Scaricare un file di Visio di questa architettura.

Key Vault offre una gestione sicura dei segreti, inclusi i certificati TLS. In questa architettura i certificati TLS vengono archiviati nell'insieme di credenziali delle chiavi e recuperati durante il processo di provisioning dalle identità gestite di gateway applicazione e dalle macchine virtuali. Dopo l'installazione iniziale, queste risorse accedono a Key Vault solo quando i certificati vengono aggiornati.

Le macchine virtuali usano l'estensione della macchina virtuale Key Vault per aggiornare automaticamente i certificati monitorati. Se vengono rilevate modifiche nell'archivio certificati locale, l'estensione recupera e installa i certificati corrispondenti da Key Vault. L'estensione supporta i tipi di contenuto certificato PKCS #12 e PEM.

Fare riferimento a Well-Architected Framework: SE:09 - Raccomandazioni per la protezione dei segreti dell'applicazione.

Ottimizzazione dei costi

I requisiti del carico di lavoro devono essere soddisfatti tenendo presenti i vincoli di costo. Le strategie usate nell'architettura si basano sull'elenco di controllo di revisione della progettazione di Ottimizzazione costi fornito in Azure Well-Architected Framework. Questa sezione descrive alcune opzioni per ottimizzare i costi ed è annotata con le raccomandazioni di tale elenco di controllo.

Costo componente

Selezionare immagini vm ottimizzate per il carico di lavoro invece di usare immagini per utilizzo generico. In questa architettura vengono scelte immagini di vm relativamente piccole sia per Windows che per Linux, che sono 30 GB ciascuno. Con immagini più piccole, anche gli SKU delle macchine virtuali con dischi sono più piccoli, riducendo i costi, riducendo il consumo delle risorse e velocizzando i tempi di distribuzione e avvio. Un vantaggio è una maggiore sicurezza a causa della superficie ridotta.

L'implementazione della rotazione dei log con limiti di dimensioni è un'altra strategia di risparmio dei costi. Consente l'uso di dischi dati di piccole dimensioni, che possono comportare costi inferiori. L'implementazione di questa architettura usa dischi da 4 GB.

L'uso di dischi del sistema operativo temporanei può anche comportare risparmi sui costi e prestazioni migliorate. Questi dischi sono progettati per usare le risorse di macchina virtuale già pagate perché sono installate nel disco della cache di cui è stato effettuato il provisioning con la macchina virtuale. Elimina i costi di archiviazione associati ai dischi persistenti tradizionali. Poiché questi dischi sono temporanei, non sono previsti costi associati all'archiviazione dei dati a lungo termine.

Vedere Well-Architected Framework: CO:07 - Recommendations for ottimizzazione dei costi dei componenti.

Costo del flusso

Scegliere le risorse di calcolo in base alla criticità del flusso. Per i flussi progettati per tollerare una lunghezza indeterminato, è consigliabile usare macchine virtuali spot con set di scalabilità di macchine virtuali modalità di orchestrazione flessibile. Questo approccio può essere efficace per l'hosting di flussi con priorità bassa nelle macchine virtuali con priorità inferiore. Questa strategia consente l'ottimizzazione dei costi pur rispettando i requisiti dei diversi flussi.

Vedere Well-Architected Framework: CO:09 - Recommendations for optimizing flow costs (Framework ben progettato: CO:09 - Raccomandazioni per l'ottimizzazione dei costi del flusso).

Ridimensionamento dei costi

Se il driver di costo principale è il numero di istanze, potrebbe essere più conveniente aumentare le prestazioni aumentando le dimensioni o le prestazioni delle macchine virtuali. Questo approccio può portare a risparmi sui costi in diverse aree:

• Licenze software. Le macchine virtuali di dimensioni maggiori possono gestire più carichi di lavoro, riducendo potenzialmente il numero di licenze software necessarie.
• Tempo di manutenzione: meno macchine virtuali di dimensioni maggiori possono ridurre i costi operativi.
• Bilanciamento del carico: un minor numero di macchine virtuali può comportare costi inferiori per il bilanciamento del carico. In questa architettura, ad esempio, sono presenti più livelli di bilanciamento del carico, ad esempio un gateway applicazione all'inizio e un servizio di bilanciamento del carico interno al centro. I costi di bilanciamento del carico aumentano se è necessario gestire un numero maggiore di istanze.
• Archiviazione su disco. Se sono presenti applicazioni con stato, più istanze necessitano di più dischi gestiti collegati, aumentando i costi di archiviazione.

Vedere Well-Architected Framework: CO:12 - Recommendations for optimizing scaling costs (Framework ben progettato: CO:12 - Raccomandazioni per l'ottimizzazione dei costi di ridimensionamento).

Costi operativi

L'applicazione automatica di patch guest alle macchine virtuali riduce il sovraccarico dell'applicazione di patch manuali e dei costi di manutenzione associati. Questa azione non solo consente di rendere il sistema più sicuro, ma ottimizza anche l'allocazione delle risorse, contribuendo all'efficienza complessiva dei costi.

Fare riferimento a Well-Architected Framework: CO:13 - Raccomandazioni per ottimizzare il tempo del personale.

Distribuire lo scenario

Una distribuzione di questa architettura di riferimento è disponibile in GitHub.

Risorse correlate

Per informazioni dettagliate sui servizi di Azure specifici, vedere la documentazione del prodotto:

• Macchine virtuali di Azure
• Set di scalabilità di macchine virtuali di Azure
• Rete virtuale di Azure
• app Azure lication Gateway Standard_v2
• Azure Load Balancer
• Azure Key Vault
• Azure Bastion
• Application Insights
• Log Analytics

Passaggio successivo

Esaminare le architetture di riferimento IaaS che mostrano le opzioni per il livello dati:

• Applicazione a più livelli windows con SQL Server in Azure