Eseguire una macchina virtuale Linux in Azure

Backup di Azure

Azure Bastion

Archiviazione BLOB di Azure

Azure Resource Manager

Archiviazione di Azure

Macchine virtuali di Azure

Il provisioning di una macchina virtuale (VM) in Azure richiede componenti aggiuntivi oltre alla macchina virtuale stessa, incluse le risorse di rete e archiviazione. Questo articolo illustra le procedure consigliate per l'esecuzione di una macchina virtuale Linux sicura in Azure.

Architettura

Scaricare un file Visio di questa architettura.

Flusso di lavoro

Questo esempio mostra una distribuzione di base usando una singola macchina virtuale con i componenti necessari. La macchina virtuale può eseguire carichi di lavoro, è gestibile e può comunicare con la rete Internet pubblica. È progettato per evitare l'esposizione diretta alle minacce esterne.

• Tutti i carichi di lavoro in esecuzione nella macchina virtuale non sono esposti esternamente e sono accessibili solo dall'interno della stessa rete virtuale o da una rete virtuale con peering, ad esempio in una configurazione hub-spoke.
• L'accesso alla macchina virtuale viene visualizzato usando Azure Bastion tramite Secure Shell (SSH) e non è consentito direttamente dalla rete Internet pubblica.
• L'accesso a Internet esterno in uscita viene fornito tramite l'uso del gateway NAT (Network Address Translation) e dell'indirizzo IP pubblico associato.

Components

Gruppo di risorse

Un gruppo risorso è un contenitore logico che contiene risorse Azure correlate. È generalmente necessario raggruppare le risorse in base alla loro durata e alle persone che le gestiranno.

Distribuire risorse strettamente associate che condividono lo stesso ciclo di vita nello stesso gruppo di risorse. I gruppi di risorse consentono di distribuire e monitorare le risorse come gruppo, tenendo traccia dei costi per ogni gruppo di risorse. È anche possibile eliminare un intero set di risorse, operazione molto utile nelle distribuzioni di prova. Assegnare nomi di risorsa significativi per semplificare l'individuazione di una risorsa specifica e comprenderne il ruolo. Per altre informazioni, vedere Recommended Naming Conventions for Azure Resources.

Macchina virtuale

È possibile eseguire il provisioning di una macchina virtuale da un elenco di immagini pubblicate o da un'immagine gestita personalizzata o disco rigido virtuale (VHD) caricato nell'archiviazione BLOB di Azure. Azure supporta l'esecuzione di varie distribuzioni Linux comuni, tra cui Debian, Red Hat Enterprise Linux (RHEL) e Ubuntu. Per altre informazioni, vedere Azure e Linux.

Azure offre molte dimensioni di macchine virtuali. Se si sposta un carico di lavoro esistente in Azure, iniziare con le dimensioni della macchina virtuale più vicine ai server locali. Misurare quindi le prestazioni del carico di lavoro effettivo in relazione alla CPU, alla memoria e alle operazioni di input/output al secondo (IOPS) del disco e regolare le dimensioni in base alle necessità.

In genere, scegliere un'area Azure più vicina agli utenti o ai clienti interni. Non tutte le dimensioni di macchina virtuale sono disponibili in tutte le aree. Per altre informazioni, vedere i servizi disponibili in base all'area. Per un elenco delle dimensioni delle macchine virtuali disponibili in un'area specifica, eseguire il comando seguente dal interfaccia della riga di comando di Azure:

az vm list-sizes --location <location>

Per informazioni sulla scelta di un'immagine di macchina virtuale pubblicata, vedere Come trovare immagini di macchine virtuali Linux.

Dischi

Per ottenere prestazioni ottimali di I/O del disco, è consigliabile usare unità SSD Premium che archiviano i dati su unità SSD (Solid State Drive). I costi dipendono dalla capacità del disco provisioning. Anche IOPS e velocità effettiva, ovvero la velocità di trasferimento dati, dipendono dalle dimensioni del disco. Quando si effettua il provisioning di un disco è quindi consigliabile tenere in considerazione tutti e tre i fattori, ovvero capacità, IOPS e velocità effettiva. Le unità SSD Premium offrono un bursting gratuito che, combinato con la comprensione dei modelli di carico di lavoro, offre una scelta efficace degli SKU e una strategia di ottimizzazione dei costi per l'infrastruttura IaaS. Ciò consente prestazioni elevate senza un provisioning eccessivo e riducendo al minimo il costo della capacità inutilizzata.

Nota

Attualmente, i dischi SSD Premium v2 e Ultra possono essere usati solo per i dischi dati. Non sono supportati per i dischi del sistema operativo.

Managed Disks semplificare la gestione del disco gestendo automaticamente l'archiviazione. Managed disks non richiedono un account di archiviazione. Si specificano le dimensioni e il tipo di disco e viene distribuito come risorsa a disponibilità elevata. Managed disks offrono anche l'ottimizzazione dei costi fornendo prestazioni desiderate senza la necessità di over-provisioning, tenendo conto dei modelli di carico di lavoro fluttuanti e riducendo al minimo la capacità di provisioning inutilizzata.

Per impostazione predefinita, il disco del sistema operativo è un disco gestito archiviato in archiviazione su disco di Azure, quindi persiste anche quando il computer host è inattivo. Nel caso di carichi di lavoro senza stato, dove si desidera un provisioning rapido e nessuna persistenza del sistema operativo, è consigliabile usare dischi del sistema operativo effimeri. Questi dischi posizionano l'immagine del SO nell'archiviazione locale dell'host della macchina virtuale invece di quella remota di Azure, riducendo la latenza di lettura, velocizzando il ripristino dell'immagine ed eliminando il costo del disco gestito. Tuttavia, tutti i dati in un disco temporaneo del sistema operativo vengono persi in caso di arresto (deallocazione), ricreazione dell'immagine o eventi di correzione della manutenzione host. I dischi temporanei del sistema operativo non supportano snapshot o Backup di Azure. Usare dischi effimeri del sistema operativo solo quando le macchine virtuali sono completamente ridistribuibili tramite automazione.

Molte immagini Linux non configurano lo spazio di scambio per impostazione predefinita. Se il carico di lavoro richiede lo scambio, crearlo nel disco temporaneo usando cloud-init anziché sul disco del sistema operativo o su un disco dati.

È consigliabile creare uno o più dischi dati per i dati dell'applicazione. I dischi dati sono dischi gestiti persistenti supportati da Archiviazione di Azure.

Quando si crea un disco, non è formattato. Accedere alla VM per formattare il disco. Nella shell Linux i dischi dati vengono visualizzati come /dev/sdc, /dev/sdde le lettere successive nella serie. È possibile eseguire lsblk per elencare i dispositivi a blocchi, ad esempio i dischi. Per usare un disco dati, creare una partizione e un file system, quindi montare il disco. Ad esempio:

# Create a partition.

sudo fdisk /dev/sdc     # Enter 'n' to partition, 'w' to write the change.

# Create a file system.

sudo mkfs -t ext3 /dev/sdc1

# Mount the drive.

sudo mkdir /data1
sudo mount /dev/sdc1 /data1

Quando si aggiunge un disco dati, al disco viene assegnato un ID numero di unità logica (LUN). Facoltativamente, è possibile specificare l'ID LUN, ad esempio se si sostituisce un disco e si vuole mantenere lo stesso ID LUN oppure si dispone di un'applicazione che cerca un ID LUN specifico. Tuttavia, tenere presente che gli ID LUN devono essere univoci per ogni disco.

È possibile modificare l'utilità di pianificazione di I/O per ottimizzare le prestazioni nelle unità SSD quando si usano dischi Archiviazione Premium. È consigliabile usare l'utilità di pianificazione No Operation (NOOP) per le unità SSD, ma è consigliabile usare uno strumento come iostat per monitorare le prestazioni di I/O del disco per il carico di lavoro.

Molte macchine virtuali vengono create con un disco temporaneo, archiviato in un'unità fisica nel computer host. Non è salvato in Archiviazione di Azure e potrebbe essere eliminato durante riavvii e altri eventi del ciclo di vita della macchina virtuale. Usare questo disco solo per dati temporanei, ad esempio file di paginazione o di scambio. Per le macchine virtuali Linux, il disco temporaneo è /dev/disk/azure/resource-part1 ed è montato in /mnt/resource o /mnt.

Rete

I componenti di rete includono le risorse seguenti:

• Rete virtuale. Ogni macchina virtuale viene distribuita in un virtual network che viene segmentato in subnet.

• Interfaccia di rete (NIC). La scheda di interfaccia di rete consente alla macchina virtuale di comunicare con il virtual network. Se sono necessarie più schede di interfaccia di rete per la macchina virtuale, viene definito un numero massimo di schede di interfaccia di rete per ogni dimensione della macchina virtuale.

• Indirizzo IP pubblico. Un indirizzo IP pubblico may essere usato per comunicare con la macchina virtuale dall'esterno Azure tramite SSH. Tuttavia, questo è sconsigliato perché è un potenziale rischio per la sicurezza.

  Avvertimento

  Il collegamento di un indirizzo IP pubblico rappresenta direttamente un potenziale rischio per la sicurezza. Deve essere eseguita solo in circostanze estreme e solo in combinazione con altri metodi di sicurezza, ad esempio il filtro del traffico tramite gruppi di sicurezza di rete.

  Per l'accesso di gestione a una macchina virtuale, è consigliabile usare Azure Bastion o internamente quando si è connessi tramite vpn o Azure ExpressRoute.

  • L'indirizzo IP pubblico può essere dinamico o statico. Per impostazione predefinita, è dinamico. Riservare un indirizzo IP statico se è necessario un indirizzo IP fisso che non cambia, ad esempio se è necessario creare un record DNS 'A' o aggiungere l'indirizzo IP a un elenco sicuro.
  • È inoltre possibile creare un nome di dominio completo (FQDN) per l'indirizzo IP. È quindi possibile registrare il record CNAME nel DNS che punta al FQDN. Per altre informazioni, vedere Creare un nome di dominio completo nel portale di Azure.

• Gruppo di sicurezza di rete. I gruppi di sicurezza di rete vengono usati per consentire o negare il traffico di rete alle macchine virtuali e/o alle subnet. Possono essere associati alle subnet o a singole schede di interfaccia di rete collegate alle macchine virtuali.

  • Tutti i gruppi di sicurezza di rete contengono un set di regole predefinite, inclusa una regola che blocca tutto il traffico Internet in ingresso. Le regole predefinite non possono essere eliminate, ma altre regole possono eseguirne l'override. Ad esempio, per abilitare il traffico Internet, creare regole che consentano il traffico in ingresso verso porte specifiche, ad esempio la porta 443 per HTTPS.

• Gateway Azure Network Address Translation (NAT). I gateway NAT (Network Address Translation) consentono a tutte le istanze di una subnet privata di connettersi verso l'esterno a Internet pur rimanendo completamente private. Solo i pacchetti che arrivano come pacchetti di risposta a una connessione in uscita possono passare attraverso un gateway NAT. Le connessioni in ingresso non richieste da Internet non sono consentite.

  Nota

  Per migliorare la sicurezza predefinita, l'accesso a Internet in uscita implicito è deprecato per tutte le nuove reti virtuali. La connettività Internet in uscita dovrà essere configurata in modo esplicito tramite l'uso di altre risorse, ad esempio gateway NAT, Azure load balancer Standard o firewall. Per informazioni dettagliate, vedere Accesso in uscita predefinita in Azure.

• Azure Bastion.Azure Bastion è una piattaforma distribuita come servizio completamente gestita che fornisce accesso sicuro alle macchine virtuali tramite indirizzi IP privati. Con questa configurazione, le macchine virtuali non necessitano di un indirizzo IP pubblico che li espone a Internet, aumentando così il comportamento di sicurezza. Azure Bastion fornisce connettività SSH o RDP (Secure Desktop remoto Protocol) alle macchine virtuali direttamente tramite TLS (Transport Layer Security) tramite vari metodi, tra cui il portale di Azure o i client SSH o RDP nativi.

Operazioni

SSH. Prima di creare una VM Linux, generare una coppia di chiavi RSA pubblica/privata a 2.048 bit. Quando si crea la VM, utilizzare il file di chiave pubblica. Per altre informazioni, vedere Come usare SSH con Linux e Mac in Azure.

Diagnostica. Abilitare il monitoraggio e la diagnostica, incluse le metriche di base sullo stato di salute, i log dell'infrastruttura di diagnostica e la diagnostica di avvio. La diagnostica di avvio permette di diagnosticare gli errori di avvio quando la VM passa a uno stato non avviabile. Creare un account Archiviazione di Azure per archiviare i log. Un account di archiviazione con ridondanza locale standard (LRS) è sufficiente per log di diagnostica. Per altre informazioni, vedere Abilitare il monitoraggio e la diagnostica.

Disponibilità. La macchina virtuale potrebbe essere interessata dalla manutenzione pianificata o dal tempo di inattività non pianificato. È possibile usare i log di riavvio della VM per determinare se un riavvio della VM è stato provocato da attività di manutenzione pianificata. Per una disponibilità più elevata, distribuire più macchine virtuali tra zone di disponibilità all'interno di un'area. In questo modo viene fornito un contratto di servizio (SLA) superiore. Se le zone di disponibilità non sono supportate, i set di disponibilità possono fornire protezione dagli errori dell'host o dagli aggiornamenti dell'host. Tuttavia, le zone di disponibilità sono l'opzione consigliata laddove possibile.

Backup. Per evitare perdite accidentali di dati, usare il servizio Backup di Azure per eseguire il backup delle macchine virtuali nell'archiviazione. A seconda dell'area, è possibile usare l'archiviazione con ridondanza geografica o con ridondanza della zona per i backup. Backup di Azure fornisce backup coerenti con l'applicazione. Per carichi di lavoro sensibili alle prestazioni o distribuzioni Linux specializzate che non supportano gli agenti di backup tradizionali, utilizzare la funzionalità di backup crash-consistente su più dischi senza agente che consente la protezione automatizzata dei dati di backup senza influire sulle prestazioni dell'applicazione.

Spegnimento di una VM. Azure distingue tra gli stati "arrestati" e "deallocati". L'addebito avviene quando lo stato della VM viene arrestato, ma non quando la VM viene deallocata. Nel portale di Azure, il pulsante Stop dealloca la macchina virtuale. Se si arresta il sistema operativo mentre si è connessi, la VM viene arrestata ma non deallocata, quindi si continuerà a essere addebitati.

Eliminazione di una VM. Se si elimina una macchina virtuale, è possibile eliminare o conservarne i dischi. È quindi possibile eliminare in modo sicuro la macchina virtuale senza perdere dati. Tuttavia, verranno comunque addebitati i costi per i dischi. È possibile eliminare i dischi gestiti esattamente come qualsiasi altra risorsa Azure. Per impedire l'eliminazione accidentale, usare un blocco di risorsa per bloccare l'intero gruppo di risorse o le singole risorse, ad esempio una macchina virtuale.

Alternative

• Set di scalabilità di macchine virtuali : i carichi di lavoro critici per le operazioni aziendali non devono mai dipendere da una singola macchina virtuale. I set di scalabilità offrono la possibilità di distribuire i carichi di lavoro tra i nodi e di espandere le istanze in periodi di traffico elevato o ridurre le istanze quando il traffico è minimo per ottimizzare i costi.

• Azure Load Balancer sarebbe utile per fornire il bilanciamento del carico tra più macchine virtuali o un set di scalabilità di macchine virtuali. Può anche essere usato come alternativa a un gateway NAT per consentire l'accesso a un carico di lavoro da Internet, supportando anche l'accesso in uscita.

• Application Gateway fornisce funzionalità di bilanciamento del carico ai Azure Load Balancer per i carichi di lavoro HTTP/HTTPS all'interno di un'area Azure.

• Per una distribuzione a livello aziendale, vedere "l'architettura di base di Macchine virtuali di Azure in un Azure landing zone."

Dettagli dello scenario

Nel diagramma precedente, questo scenario sarebbe utile per fornire un carico di lavoro non critico utile per gli utenti solo interni.

Casi d'uso potenziali

Una singola distribuzione di macchine virtuali può essere usata per ospitare una semplice applicazione che non deve essere esposta a Internet e può sopportare alcuni tempi di inattività. Ad esempio, può trattarsi di un'applicazione di report interna di base.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, ovvero un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'affidabilità.

Poiché questa architettura è solo un semplice esempio che usa una singola macchina virtuale, ha un livello minimo di affidabilità. Qualsiasi problema relativo alla macchina virtuale stessa o all'host in cui è in esecuzione causerà un'interruzione, causando l'indisponibilità di eventuali carichi di lavoro ospitati. Per qualsiasi carico di lavoro che richiede una disponibilità più elevata, è necessario distribuire più macchine virtuali che contengono lo stesso carico di lavoro, con tali istanze dietro una soluzione di bilanciamento del carico appropriata. Se si trovano all'interno della stessa area, tali macchine virtuali devono essere distribuite tra zone di disponibilità (se supportate) e aggiunte al back-end di un Azure Load Balancer Standard o di un gateway applicazione se il carico di lavoro è basato su HTTP/HTTPS. Ciò consente di rendere il carico di lavoro ancora disponibile se una singola macchina virtuale nel back-end dovesse essere inattiva.

I set di scalabilità di macchine virtuali sono un'altra opzione per semplificare la gestione dei carichi di lavoro multinodo che richiedono la possibilità di ridimensionare automaticamente il numero di istanze in o in base a una delle diverse metriche, ad esempio l'utilizzo di CPU e/o memoria.

Disponibilità elevata/ripristino di emergenza

Per un "raggio d'azione" ridotto, il carico di lavoro dovrebbe essere distribuito in più regioni e sfruttare le linee guida di Azure Landing Zone. Potrebbe trovarsi in una configurazione Active-Passive, con failover alla regione secondaria se la regione primaria non è più disponibile, o in un'architettura Active-Active in cui entrambe le regioni servono il traffico ai consumatori. Per un esempio, vedere Applicazione Web multilivello progettata per disponibilità elevata/ripristino di emergenza in Passaggi successivi di seguito.

L'esempio in questo articolo usa Azure Site Recovery per replicare i dischi di singole macchine virtuali in un'area secondaria, in cui è possibile usare Site Recovery per eseguire il failover di tali macchine virtuali nell'area secondaria con un Recovery Point Objective (RPO)/Recovery Time Objective (RTO) basso.

Assicurarsi di valutare l'architettura per soddisfare i requisiti di disponibilità elevata/ripristino di emergenza in tutti i componenti, non solo per le macchine virtuali. In tutte queste decisioni, includere considerazioni quali rete, identità e dati.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la sicurezza.

Usare Microsoft Defender per il cloud per ottenere una visualizzazione centrale dello stato di sicurezza delle risorse Azure. Defender per il cloud monitora potenziali problemi di sicurezza e offre un quadro completo sullo stato della sicurezza della distribuzione. Defender per il cloud è configurato per sottoscrizione Azure. Abilitare la raccolta dei dati di sicurezza come descritto in Connettere le sottoscrizioni Azure. Quando la raccolta dati è abilitata, Defender per il cloud analizza automaticamente tutte le macchine virtuali create in tale sottoscrizione.

Gestione delle patch. Se abilitata, Defender per il cloud verifica se mancano aggiornamenti critici e di sicurezza.

Antimalware. Se abilitata, Defender per il cloud controlla se è installato software antimalware. È anche possibile usare Defender per il cloud per installare software antimalware dall'interno del portale di Azure.

Controllo dell'accesso. Usare Azure controllo degli accessi basato sui ruoli (Azure RBAC) per controllare l'accesso alle risorse Azure. Azure Role-Based Access Control (RBAC) consente di assegnare ruoli ai membri del team DevOps. Ad esempio, il ruolo Lettore può visualizzare Azure risorse, ma non crearle, gestirle o eliminarle. Alcune autorizzazioni sono specifiche di un tipo di risorsa Azure. Ad esempio, il ruolo Collaboratore macchina virtuale può riavviare o deallocare una macchina virtuale, reimpostare la password dell'amministratore e creare una nuova macchina virtuale. Altri ruoli predefiniti che potrebbero essere utili per questa architettura includono l'utente di DevTest Labs e collaboratore alla rete.

Nota

Azure RBAC non limita le azioni che un utente connesso a una macchina virtuale può eseguire. Le autorizzazioni sono determinate dal tipo di account sul sistema operativo guest.

Log di controllo. Usare audit logs per visualizzare le azioni di provisioning e altri eventi della macchina virtuale.

Crittografia dei dati. Abilita la crittografia sull'host per ottenere la crittografia end-to-end per i dati della tua macchina virtuale, inclusi i dischi temporanei e le cache dei dischi. La crittografia nell'host gestisce la crittografia nell'infrastruttura host della macchina virtuale e non usa le risorse della CPU della macchina virtuale, a differenza della crittografia basata su guest. È possibile usare chiavi gestite da customer con Azure Key Vault per i dischi dati e del sistema operativo persistenti. I dischi temporanei e i dischi del sistema operativo ephemeral vengono crittografati con chiavi gestite dalla piattaforma. Verificare che le dimensioni VM selezionate supportino la crittografia in host prima di effettuare il provisioning della macchina virtuale.

Ottimizzazione costi

L'ottimizzazione dei costi consiste nell'esaminare i modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.

Sono disponibili diverse opzioni per le dimensioni delle macchine virtuali a seconda dell'utilizzo e del carico di lavoro. L'intervallo include l'opzione più economica della serie Bs alle macchine virtuali GPU più recenti ottimizzate per machine learning. Per informazioni sulle opzioni disponibili, vedere Azure prezzi delle macchine virtuali Linux.

Per i carichi di lavoro prevedibili, usare Azure Prenotazioni e Azure Piano di Risparmio per il Calcolo con un contratto annuale o triennale e ottenere risparmi significativi sui prezzi a consumo. Per i carichi di lavoro senza tempi prevedibili di completamento o consumo di risorse, prendere in considerazione l'opzione Pagamento in base al consumo .

Usare VM spot di Azure per eseguire i carichi di lavoro che possono essere interrotti e non richiedono il completamento entro un tempo predeterminato o uno SLA. Azure distribuisce macchine virtuali Spot se è disponibile capacità e le espelle quando deve recuperare la capacità. I costi associati alle virtual machines Spot sono significativamente inferiori. Prendere in considerazione le macchine virtuali spot per questi carichi di lavoro:

• Scenari di calcolo ad alte prestazioni (HPC), lavori di elaborazione batch o applicazioni di rendering visivo.
• Ambienti di test, tra cui l'integrazione continua e i carichi di lavoro di recapito continuo.
• Applicazioni senza stato su larga scala.

Usare Calcolatore dei prezzi di Azure per stimare i costi.

Per altre informazioni, vedere la sezione relativa ai costi in Microsoft Azure Well-Architected Framework.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e lo mantengono in esecuzione nell'ambiente di produzione. Per ulteriori informazioni, vedere Lista di controllo per la revisione del design per l'Eccellenza Operativa.

Usare i modelli IaC (Infrastructure-as-Code) per effettuare il provisioning di risorse Azure e delle relative dipendenze. Possono essere scritti usando Bicep, Azure Resource Manager modelli (modelli ARM) o Terraform, a seconda delle preferenze e delle scelte degli strumenti stabilite. Questi modelli consentono un processo di integrazione continua/distribuzione continua (CI/CD) come parte di una metodologia di distribuzione automatizzata per la distribuzione e la configurazione delle risorse. Questo approccio consente il controllo delle versioni delle architetture e garantisce la coerenza tra gli ambienti, nonché l'applicazione della riproducibilità, della sicurezza e della conformità.

Per facilitare il monitoraggio e la diagnosi dei problemi, assicurarsi che i log di diagnostica siano abilitati nelle risorse e siano resi disponibili per Monitoraggio di Azure per facilitare l'analisi e l'ottimizzazione delle risorse. Questi log possono essere usati per implementare avvisi e notifiche di eventi critici e in alcuni casi consentono la correzione automatica o la registrazione di un ticket nel sistema di gestione dei servizi IT ( ITSM).

Efficienza prestazionale

Efficienza delle prestazioni è incentrata sull'ottimizzazione dei carichi di lavoro cloud per velocità, velocità di risposta e scalabilità. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'efficienza delle prestazioni.

Alcuni obiettivi chiave includono la riduzione della latenza, garantire architetture scalabili, ottimizzare l'utilizzo delle risorse e migliorare continuamente le prestazioni del sistema.

Come accennato in precedenza, le decisioni prese in merito all'architettura del carico di lavoro, alle configurazioni di SKU e dischi delle macchine virtuali possono avere un impatto notevole sulle prestazioni del carico di lavoro. Le scelte corrette potrebbero impedire la necessità di ri-progettare la soluzione in futuro, aggiungendo flessibilità e risparmio sui costi.

Quando si sviluppa l'architettura, tenere presente questi punti:

• Usare i set di scalabilità di macchine virtuali se il carico di lavoro è variabile. Ad esempio, aumentare il numero di istanze durante i periodi di traffico intenso e quindi ridurre il numero di istanze quando il traffico diminuisce. Ciò garantirà una potenza di elaborazione adeguata mantenendo comunque sotto controllo i costi.
• Scegliere le VM e gli SKU del disco appropriati per soddisfare le operazioni di I/O al secondo necessarie durante l'elaborazione. Configurare la memorizzazione nella cache per migliorare ulteriormente le prestazioni.
• Se il carico di lavoro è insolitamente sensibile alla latenza, usare gruppi di posizionamento di prossimità per assicurarsi che più macchine virtuali si trovino fisicamente vicine tra loro per ottenere prestazioni migliori. I gruppi di posizionamento di prossimità (PPG) possono essere usati anche insieme agli insiemi di disponibilità per combinare l'alta disponibilità e la bassa latenza all'interno di un singolo centro dati fisico.
• Se possibile, abilitare la rete accelerata per ridurre al minimo la latenza tra i componenti.
• Progettare un'architettura di rete per ridurre al minimo gli hop non necessari.
• Usare Monitoraggio di Azure, VM Insights e altri strumenti per analizzare le metriche continuamente e creare basi di riferimento delle prestazioni aggiornate. Usare le informazioni sulle prestazioni per determinare dove implementare le modifiche e quindi eseguire il test su tali baseline.

Contributors

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

• Donnie Trumpower | Senior Cloud & AI Solutions Architect

Passaggi successivi

• Per creare una macchina virtuale Linux, vedere Quickstart: Creare una macchina virtuale Linux nel portale di Azure.
• Per installare un driver NVIDIA in una macchina virtuale Linux, vedere Installare i driver GPU NVIDIA in macchine virtuali serie N che eseguono Linux.
• Per effettuare il provisioning di una macchina virtuale Linux, vedere Creare e gestire macchine virtuali Linux con interfaccia della riga di comando di Azure.
• Accesso in uscita predefinito in Azure.
• Per un esempio di architettura più complessa, vedere architettura di riferimento Macchine virtuali di Azure in una landing zone di Azure.
• Per distribuire un'applicazione Web tra aree, vedere Applicazione Web multilivello creata per disponibilità elevata/ripristino di emergenza.

Risorsa correlata

• Eseguire una macchina virtuale Windows in Azure

Il provisioning di una macchina virtuale (VM) in Azure richiede componenti aggiuntivi oltre alla macchina virtuale stessa, incluse le risorse di rete e archiviazione. Questo articolo illustra le procedure consigliate per l'esecuzione di una macchina virtuale Linux sicura in Azure.

Architettura

Scaricare un file Visio di questa architettura.

Flusso di lavoro

Questo esempio mostra una distribuzione di base usando una singola macchina virtuale con i componenti necessari. La macchina virtuale può eseguire carichi di lavoro, è gestibile e può comunicare con la rete Internet pubblica. È progettato per evitare l'esposizione diretta alle minacce esterne.

• Tutti i carichi di lavoro in esecuzione nella macchina virtuale non sono esposti esternamente e sono accessibili solo dall'interno della stessa rete virtuale o da una rete virtuale con peering, ad esempio in una configurazione hub-spoke.
• L'accesso alla macchina virtuale viene visualizzato usando Azure Bastion tramite Secure Shell (SSH) e non è consentito direttamente dalla rete Internet pubblica.
• L'accesso a Internet esterno in uscita viene fornito tramite l'uso del gateway NAT (Network Address Translation) e dell'indirizzo IP pubblico associato.

Components

Gruppo di risorse

Un gruppo risorso è un contenitore logico che contiene risorse Azure correlate. È generalmente necessario raggruppare le risorse in base alla loro durata e alle persone che le gestiranno.

Distribuire risorse strettamente associate che condividono lo stesso ciclo di vita nello stesso gruppo di risorse. I gruppi di risorse consentono di distribuire e monitorare le risorse come gruppo, tenendo traccia dei costi per ogni gruppo di risorse. È anche possibile eliminare un intero set di risorse, operazione molto utile nelle distribuzioni di prova. Assegnare nomi di risorsa significativi per semplificare l'individuazione di una risorsa specifica e comprenderne il ruolo. Per altre informazioni, vedere Recommended Naming Conventions for Azure Resources.

Macchina virtuale

È possibile eseguire il provisioning di una macchina virtuale da un elenco di immagini pubblicate o da un'immagine gestita personalizzata o disco rigido virtuale (VHD) caricato nell'archiviazione BLOB di Azure. Azure supporta l'esecuzione di varie distribuzioni Linux comuni, tra cui Debian, Red Hat Enterprise Linux (RHEL) e Ubuntu. Per altre informazioni, vedere Azure e Linux.

Azure offre molte dimensioni di macchine virtuali. Se si sposta un carico di lavoro esistente in Azure, iniziare con le dimensioni della macchina virtuale più vicine ai server locali. Misurare quindi le prestazioni del carico di lavoro effettivo in relazione alla CPU, alla memoria e alle operazioni di input/output al secondo (IOPS) del disco e regolare le dimensioni in base alle necessità.

In genere, scegliere un'area Azure più vicina agli utenti o ai clienti interni. Non tutte le dimensioni di macchina virtuale sono disponibili in tutte le aree. Per altre informazioni, vedere i servizi disponibili in base all'area. Per un elenco delle dimensioni delle macchine virtuali disponibili in un'area specifica, eseguire il comando seguente dal interfaccia della riga di comando di Azure:

az vm list-sizes --location <location>

Per informazioni sulla scelta di un'immagine di macchina virtuale pubblicata, vedere Come trovare immagini di macchine virtuali Linux.

Dischi

Per ottenere prestazioni ottimali di I/O del disco, è consigliabile usare unità SSD Premium che archiviano i dati su unità SSD (Solid State Drive). I costi dipendono dalla capacità del disco provisioning. Anche IOPS e velocità effettiva, ovvero la velocità di trasferimento dati, dipendono dalle dimensioni del disco. Quando si effettua il provisioning di un disco è quindi consigliabile tenere in considerazione tutti e tre i fattori, ovvero capacità, IOPS e velocità effettiva. Le unità SSD Premium offrono un bursting gratuito che, combinato con la comprensione dei modelli di carico di lavoro, offre una scelta efficace degli SKU e una strategia di ottimizzazione dei costi per l'infrastruttura IaaS. Ciò consente prestazioni elevate senza un provisioning eccessivo e riducendo al minimo il costo della capacità inutilizzata.

Nota

Attualmente, i dischi SSD Premium v2 e Ultra possono essere usati solo per i dischi dati. Non sono supportati per i dischi del sistema operativo.

Managed Disks semplificare la gestione del disco gestendo automaticamente l'archiviazione. Managed disks non richiedono un account di archiviazione. Si specificano le dimensioni e il tipo di disco e viene distribuito come risorsa a disponibilità elevata. Managed disks offrono anche l'ottimizzazione dei costi fornendo prestazioni desiderate senza la necessità di over-provisioning, tenendo conto dei modelli di carico di lavoro fluttuanti e riducendo al minimo la capacità di provisioning inutilizzata.

Per impostazione predefinita, il disco del sistema operativo è un disco gestito archiviato in archiviazione su disco di Azure, quindi persiste anche quando il computer host è inattivo. Nel caso di carichi di lavoro senza stato, dove si desidera un provisioning rapido e nessuna persistenza del sistema operativo, è consigliabile usare dischi del sistema operativo effimeri. Questi dischi posizionano l'immagine del SO nell'archiviazione locale dell'host della macchina virtuale invece di quella remota di Azure, riducendo la latenza di lettura, velocizzando il ripristino dell'immagine ed eliminando il costo del disco gestito. Tuttavia, tutti i dati in un disco temporaneo del sistema operativo vengono persi in caso di arresto (deallocazione), ricreazione dell'immagine o eventi di correzione della manutenzione host. I dischi temporanei del sistema operativo non supportano snapshot o Backup di Azure. Usare dischi effimeri del sistema operativo solo quando le macchine virtuali sono completamente ridistribuibili tramite automazione.

Molte immagini Linux non configurano lo spazio di scambio per impostazione predefinita. Se il carico di lavoro richiede lo scambio, crearlo nel disco temporaneo usando cloud-init anziché sul disco del sistema operativo o su un disco dati.

È consigliabile creare uno o più dischi dati per i dati dell'applicazione. I dischi dati sono dischi gestiti persistenti supportati da Archiviazione di Azure.

Quando si crea un disco, non è formattato. Accedere alla VM per formattare il disco. Nella shell Linux i dischi dati vengono visualizzati come /dev/sdc, /dev/sdde le lettere successive nella serie. È possibile eseguire lsblk per elencare i dispositivi a blocchi, ad esempio i dischi. Per usare un disco dati, creare una partizione e un file system, quindi montare il disco. Ad esempio:

# Create a partition.

sudo fdisk /dev/sdc     # Enter 'n' to partition, 'w' to write the change.

# Create a file system.

sudo mkfs -t ext3 /dev/sdc1

# Mount the drive.

sudo mkdir /data1
sudo mount /dev/sdc1 /data1

Quando si aggiunge un disco dati, al disco viene assegnato un ID numero di unità logica (LUN). Facoltativamente, è possibile specificare l'ID LUN, ad esempio se si sostituisce un disco e si vuole mantenere lo stesso ID LUN oppure si dispone di un'applicazione che cerca un ID LUN specifico. Tuttavia, tenere presente che gli ID LUN devono essere univoci per ogni disco.

È possibile modificare l'utilità di pianificazione di I/O per ottimizzare le prestazioni nelle unità SSD quando si usano dischi Archiviazione Premium. È consigliabile usare l'utilità di pianificazione No Operation (NOOP) per le unità SSD, ma è consigliabile usare uno strumento come iostat per monitorare le prestazioni di I/O del disco per il carico di lavoro.

Molte macchine virtuali vengono create con un disco temporaneo, archiviato in un'unità fisica nel computer host. Non è salvato in Archiviazione di Azure e potrebbe essere eliminato durante riavvii e altri eventi del ciclo di vita della macchina virtuale. Usare questo disco solo per dati temporanei, ad esempio file di paginazione o di scambio. Per le macchine virtuali Linux, il disco temporaneo è /dev/disk/azure/resource-part1 ed è montato in /mnt/resource o /mnt.

Rete

I componenti di rete includono le risorse seguenti:

• Rete virtuale. Ogni macchina virtuale viene distribuita in un virtual network che viene segmentato in subnet.

• Interfaccia di rete (NIC). La scheda di interfaccia di rete consente alla macchina virtuale di comunicare con il virtual network. Se sono necessarie più schede di interfaccia di rete per la macchina virtuale, viene definito un numero massimo di schede di interfaccia di rete per ogni dimensione della macchina virtuale.

• Indirizzo IP pubblico. Un indirizzo IP pubblico may essere usato per comunicare con la macchina virtuale dall'esterno Azure tramite SSH. Tuttavia, questo è sconsigliato perché è un potenziale rischio per la sicurezza.

  Avvertimento

  Il collegamento di un indirizzo IP pubblico rappresenta direttamente un potenziale rischio per la sicurezza. Deve essere eseguita solo in circostanze estreme e solo in combinazione con altri metodi di sicurezza, ad esempio il filtro del traffico tramite gruppi di sicurezza di rete.

  Per l'accesso di gestione a una macchina virtuale, è consigliabile usare Azure Bastion o internamente quando si è connessi tramite vpn o Azure ExpressRoute.

  • L'indirizzo IP pubblico può essere dinamico o statico. Per impostazione predefinita, è dinamico. Riservare un indirizzo IP statico se è necessario un indirizzo IP fisso che non cambia, ad esempio se è necessario creare un record DNS 'A' o aggiungere l'indirizzo IP a un elenco sicuro.
  • È inoltre possibile creare un nome di dominio completo (FQDN) per l'indirizzo IP. È quindi possibile registrare il record CNAME nel DNS che punta al FQDN. Per altre informazioni, vedere Creare un nome di dominio completo nel portale di Azure.

• Gruppo di sicurezza di rete. I gruppi di sicurezza di rete vengono usati per consentire o negare il traffico di rete alle macchine virtuali e/o alle subnet. Possono essere associati alle subnet o a singole schede di interfaccia di rete collegate alle macchine virtuali.

  • Tutti i gruppi di sicurezza di rete contengono un set di regole predefinite, inclusa una regola che blocca tutto il traffico Internet in ingresso. Le regole predefinite non possono essere eliminate, ma altre regole possono eseguirne l'override. Ad esempio, per abilitare il traffico Internet, creare regole che consentano il traffico in ingresso verso porte specifiche, ad esempio la porta 443 per HTTPS.

• Gateway Azure Network Address Translation (NAT). I gateway NAT (Network Address Translation) consentono a tutte le istanze di una subnet privata di connettersi verso l'esterno a Internet pur rimanendo completamente private. Solo i pacchetti che arrivano come pacchetti di risposta a una connessione in uscita possono passare attraverso un gateway NAT. Le connessioni in ingresso non richieste da Internet non sono consentite.

  Nota

  Per migliorare la sicurezza predefinita, l'accesso a Internet in uscita implicito è deprecato per tutte le nuove reti virtuali. La connettività Internet in uscita dovrà essere configurata in modo esplicito tramite l'uso di altre risorse, ad esempio gateway NAT, Azure load balancer Standard o firewall. Per informazioni dettagliate, vedere Accesso in uscita predefinita in Azure.

• Azure Bastion.Azure Bastion è una piattaforma distribuita come servizio completamente gestita che fornisce accesso sicuro alle macchine virtuali tramite indirizzi IP privati. Con questa configurazione, le macchine virtuali non necessitano di un indirizzo IP pubblico che li espone a Internet, aumentando così il comportamento di sicurezza. Azure Bastion fornisce connettività SSH o RDP (Secure Desktop remoto Protocol) alle macchine virtuali direttamente tramite TLS (Transport Layer Security) tramite vari metodi, tra cui il portale di Azure o i client SSH o RDP nativi.

Operazioni

SSH. Prima di creare una VM Linux, generare una coppia di chiavi RSA pubblica/privata a 2.048 bit. Quando si crea la VM, utilizzare il file di chiave pubblica. Per altre informazioni, vedere Come usare SSH con Linux e Mac in Azure.

Diagnostica. Abilitare il monitoraggio e la diagnostica, incluse le metriche di base sullo stato di salute, i log dell'infrastruttura di diagnostica e la diagnostica di avvio. La diagnostica di avvio permette di diagnosticare gli errori di avvio quando la VM passa a uno stato non avviabile. Creare un account Archiviazione di Azure per archiviare i log. Un account di archiviazione con ridondanza locale standard (LRS) è sufficiente per log di diagnostica. Per altre informazioni, vedere Abilitare il monitoraggio e la diagnostica.

Disponibilità. La macchina virtuale potrebbe essere interessata dalla manutenzione pianificata o dal tempo di inattività non pianificato. È possibile usare i log di riavvio della VM per determinare se un riavvio della VM è stato provocato da attività di manutenzione pianificata. Per una disponibilità più elevata, distribuire più macchine virtuali tra zone di disponibilità all'interno di un'area. In questo modo viene fornito un contratto di servizio (SLA) superiore. Se le zone di disponibilità non sono supportate, i set di disponibilità possono fornire protezione dagli errori dell'host o dagli aggiornamenti dell'host. Tuttavia, le zone di disponibilità sono l'opzione consigliata laddove possibile.

Backup. Per evitare perdite accidentali di dati, usare il servizio Backup di Azure per eseguire il backup delle macchine virtuali nell'archiviazione. A seconda dell'area, è possibile usare l'archiviazione con ridondanza geografica o con ridondanza della zona per i backup. Backup di Azure fornisce backup coerenti con l'applicazione. Per carichi di lavoro sensibili alle prestazioni o distribuzioni Linux specializzate che non supportano gli agenti di backup tradizionali, utilizzare la funzionalità di backup crash-consistente su più dischi senza agente che consente la protezione automatizzata dei dati di backup senza influire sulle prestazioni dell'applicazione.

Spegnimento di una VM. Azure distingue tra gli stati "arrestati" e "deallocati". L'addebito avviene quando lo stato della VM viene arrestato, ma non quando la VM viene deallocata. Nel portale di Azure, il pulsante Stop dealloca la macchina virtuale. Se si arresta il sistema operativo mentre si è connessi, la VM viene arrestata ma non deallocata, quindi si continuerà a essere addebitati.

Eliminazione di una VM. Se si elimina una macchina virtuale, è possibile eliminare o conservarne i dischi. È quindi possibile eliminare in modo sicuro la macchina virtuale senza perdere dati. Tuttavia, verranno comunque addebitati i costi per i dischi. È possibile eliminare i dischi gestiti esattamente come qualsiasi altra risorsa Azure. Per impedire l'eliminazione accidentale, usare un blocco di risorsa per bloccare l'intero gruppo di risorse o le singole risorse, ad esempio una macchina virtuale.

Alternative

• Set di scalabilità di macchine virtuali : i carichi di lavoro critici per le operazioni aziendali non devono mai dipendere da una singola macchina virtuale. I set di scalabilità offrono la possibilità di distribuire i carichi di lavoro tra i nodi e di espandere le istanze in periodi di traffico elevato o ridurre le istanze quando il traffico è minimo per ottimizzare i costi.

• Azure Load Balancer sarebbe utile per fornire il bilanciamento del carico tra più macchine virtuali o un set di scalabilità di macchine virtuali. Può anche essere usato come alternativa a un gateway NAT per consentire l'accesso a un carico di lavoro da Internet, supportando anche l'accesso in uscita.

• Application Gateway fornisce funzionalità di bilanciamento del carico ai Azure Load Balancer per i carichi di lavoro HTTP/HTTPS all'interno di un'area Azure.

• Per una distribuzione a livello aziendale, vedere "l'architettura di base di Macchine virtuali di Azure in un Azure landing zone."

Dettagli dello scenario

Nel diagramma precedente, questo scenario sarebbe utile per fornire un carico di lavoro non critico utile per gli utenti solo interni.

Casi d'uso potenziali

Una singola distribuzione di macchine virtuali può essere usata per ospitare una semplice applicazione che non deve essere esposta a Internet e può sopportare alcuni tempi di inattività. Ad esempio, può trattarsi di un'applicazione di report interna di base.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, ovvero un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'affidabilità.

Poiché questa architettura è solo un semplice esempio che usa una singola macchina virtuale, ha un livello minimo di affidabilità. Qualsiasi problema relativo alla macchina virtuale stessa o all'host in cui è in esecuzione causerà un'interruzione, causando l'indisponibilità di eventuali carichi di lavoro ospitati. Per qualsiasi carico di lavoro che richiede una disponibilità più elevata, è necessario distribuire più macchine virtuali che contengono lo stesso carico di lavoro, con tali istanze dietro una soluzione di bilanciamento del carico appropriata. Se si trovano all'interno della stessa area, tali macchine virtuali devono essere distribuite tra zone di disponibilità (se supportate) e aggiunte al back-end di un Azure Load Balancer Standard o di un gateway applicazione se il carico di lavoro è basato su HTTP/HTTPS. Ciò consente di rendere il carico di lavoro ancora disponibile se una singola macchina virtuale nel back-end dovesse essere inattiva.

I set di scalabilità di macchine virtuali sono un'altra opzione per semplificare la gestione dei carichi di lavoro multinodo che richiedono la possibilità di ridimensionare automaticamente il numero di istanze in o in base a una delle diverse metriche, ad esempio l'utilizzo di CPU e/o memoria.

Disponibilità elevata/ripristino di emergenza

Per un "raggio d'azione" ridotto, il carico di lavoro dovrebbe essere distribuito in più regioni e sfruttare le linee guida di Azure Landing Zone. Potrebbe trovarsi in una configurazione Active-Passive, con failover alla regione secondaria se la regione primaria non è più disponibile, o in un'architettura Active-Active in cui entrambe le regioni servono il traffico ai consumatori. Per un esempio, vedere Applicazione Web multilivello progettata per disponibilità elevata/ripristino di emergenza in Passaggi successivi di seguito.

L'esempio in questo articolo usa Azure Site Recovery per replicare i dischi di singole macchine virtuali in un'area secondaria, in cui è possibile usare Site Recovery per eseguire il failover di tali macchine virtuali nell'area secondaria con un Recovery Point Objective (RPO)/Recovery Time Objective (RTO) basso.

Assicurarsi di valutare l'architettura per soddisfare i requisiti di disponibilità elevata/ripristino di emergenza in tutti i componenti, non solo per le macchine virtuali. In tutte queste decisioni, includere considerazioni quali rete, identità e dati.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la sicurezza.

Usare Microsoft Defender per il cloud per ottenere una visualizzazione centrale dello stato di sicurezza delle risorse Azure. Defender per il cloud monitora potenziali problemi di sicurezza e offre un quadro completo sullo stato della sicurezza della distribuzione. Defender per il cloud è configurato per sottoscrizione Azure. Abilitare la raccolta dei dati di sicurezza come descritto in Connettere le sottoscrizioni Azure. Quando la raccolta dati è abilitata, Defender per il cloud analizza automaticamente tutte le macchine virtuali create in tale sottoscrizione.

Gestione delle patch. Se abilitata, Defender per il cloud verifica se mancano aggiornamenti critici e di sicurezza.

Antimalware. Se abilitata, Defender per il cloud controlla se è installato software antimalware. È anche possibile usare Defender per il cloud per installare software antimalware dall'interno del portale di Azure.

Controllo dell'accesso. Usare Azure controllo degli accessi basato sui ruoli (Azure RBAC) per controllare l'accesso alle risorse Azure. Azure Role-Based Access Control (RBAC) consente di assegnare ruoli ai membri del team DevOps. Ad esempio, il ruolo Lettore può visualizzare Azure risorse, ma non crearle, gestirle o eliminarle. Alcune autorizzazioni sono specifiche di un tipo di risorsa Azure. Ad esempio, il ruolo Collaboratore macchina virtuale può riavviare o deallocare una macchina virtuale, reimpostare la password dell'amministratore e creare una nuova macchina virtuale. Altri ruoli predefiniti che potrebbero essere utili per questa architettura includono l'utente di DevTest Labs e collaboratore alla rete.

Nota

Azure RBAC non limita le azioni che un utente connesso a una macchina virtuale può eseguire. Le autorizzazioni sono determinate dal tipo di account sul sistema operativo guest.

Log di controllo. Usare audit logs per visualizzare le azioni di provisioning e altri eventi della macchina virtuale.

Crittografia dei dati. Abilita la crittografia sull'host per ottenere la crittografia end-to-end per i dati della tua macchina virtuale, inclusi i dischi temporanei e le cache dei dischi. La crittografia nell'host gestisce la crittografia nell'infrastruttura host della macchina virtuale e non usa le risorse della CPU della macchina virtuale, a differenza della crittografia basata su guest. È possibile usare chiavi gestite da customer con Azure Key Vault per i dischi dati e del sistema operativo persistenti. I dischi temporanei e i dischi del sistema operativo ephemeral vengono crittografati con chiavi gestite dalla piattaforma. Verificare che le dimensioni VM selezionate supportino la crittografia in host prima di effettuare il provisioning della macchina virtuale.

Ottimizzazione costi

L'ottimizzazione dei costi consiste nell'esaminare i modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.

Sono disponibili diverse opzioni per le dimensioni delle macchine virtuali a seconda dell'utilizzo e del carico di lavoro. L'intervallo include l'opzione più economica della serie Bs alle macchine virtuali GPU più recenti ottimizzate per machine learning. Per informazioni sulle opzioni disponibili, vedere Azure prezzi delle macchine virtuali Linux.

Per i carichi di lavoro prevedibili, usare Azure Prenotazioni e Azure Piano di Risparmio per il Calcolo con un contratto annuale o triennale e ottenere risparmi significativi sui prezzi a consumo. Per i carichi di lavoro senza tempi prevedibili di completamento o consumo di risorse, prendere in considerazione l'opzione Pagamento in base al consumo .

Usare VM spot di Azure per eseguire i carichi di lavoro che possono essere interrotti e non richiedono il completamento entro un tempo predeterminato o uno SLA. Azure distribuisce macchine virtuali Spot se è disponibile capacità e le espelle quando deve recuperare la capacità. I costi associati alle virtual machines Spot sono significativamente inferiori. Prendere in considerazione le macchine virtuali spot per questi carichi di lavoro:

• Scenari di calcolo ad alte prestazioni (HPC), lavori di elaborazione batch o applicazioni di rendering visivo.
• Ambienti di test, tra cui l'integrazione continua e i carichi di lavoro di recapito continuo.
• Applicazioni senza stato su larga scala.

Usare Calcolatore dei prezzi di Azure per stimare i costi.

Per altre informazioni, vedere la sezione relativa ai costi in Microsoft Azure Well-Architected Framework.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e lo mantengono in esecuzione nell'ambiente di produzione. Per ulteriori informazioni, vedere Lista di controllo per la revisione del design per l'Eccellenza Operativa.

Usare i modelli IaC (Infrastructure-as-Code) per effettuare il provisioning di risorse Azure e delle relative dipendenze. Possono essere scritti usando Bicep, Azure Resource Manager modelli (modelli ARM) o Terraform, a seconda delle preferenze e delle scelte degli strumenti stabilite. Questi modelli consentono un processo di integrazione continua/distribuzione continua (CI/CD) come parte di una metodologia di distribuzione automatizzata per la distribuzione e la configurazione delle risorse. Questo approccio consente il controllo delle versioni delle architetture e garantisce la coerenza tra gli ambienti, nonché l'applicazione della riproducibilità, della sicurezza e della conformità.

Per facilitare il monitoraggio e la diagnosi dei problemi, assicurarsi che i log di diagnostica siano abilitati nelle risorse e siano resi disponibili per Monitoraggio di Azure per facilitare l'analisi e l'ottimizzazione delle risorse. Questi log possono essere usati per implementare avvisi e notifiche di eventi critici e in alcuni casi consentono la correzione automatica o la registrazione di un ticket nel sistema di gestione dei servizi IT ( ITSM).

Efficienza prestazionale

Efficienza delle prestazioni è incentrata sull'ottimizzazione dei carichi di lavoro cloud per velocità, velocità di risposta e scalabilità. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'efficienza delle prestazioni.

Alcuni obiettivi chiave includono la riduzione della latenza, garantire architetture scalabili, ottimizzare l'utilizzo delle risorse e migliorare continuamente le prestazioni del sistema.

Come accennato in precedenza, le decisioni prese in merito all'architettura del carico di lavoro, alle configurazioni di SKU e dischi delle macchine virtuali possono avere un impatto notevole sulle prestazioni del carico di lavoro. Le scelte corrette potrebbero impedire la necessità di ri-progettare la soluzione in futuro, aggiungendo flessibilità e risparmio sui costi.

Quando si sviluppa l'architettura, tenere presente questi punti:

• Usare i set di scalabilità di macchine virtuali se il carico di lavoro è variabile. Ad esempio, aumentare il numero di istanze durante i periodi di traffico intenso e quindi ridurre il numero di istanze quando il traffico diminuisce. Ciò garantirà una potenza di elaborazione adeguata mantenendo comunque sotto controllo i costi.
• Scegliere le VM e gli SKU del disco appropriati per soddisfare le operazioni di I/O al secondo necessarie durante l'elaborazione. Configurare la memorizzazione nella cache per migliorare ulteriormente le prestazioni.
• Se il carico di lavoro è insolitamente sensibile alla latenza, usare gruppi di posizionamento di prossimità per assicurarsi che più macchine virtuali si trovino fisicamente vicine tra loro per ottenere prestazioni migliori. I gruppi di posizionamento di prossimità (PPG) possono essere usati anche insieme agli insiemi di disponibilità per combinare l'alta disponibilità e la bassa latenza all'interno di un singolo centro dati fisico.
• Se possibile, abilitare la rete accelerata per ridurre al minimo la latenza tra i componenti.
• Progettare un'architettura di rete per ridurre al minimo gli hop non necessari.
• Usare Monitoraggio di Azure, VM Insights e altri strumenti per analizzare le metriche continuamente e creare basi di riferimento delle prestazioni aggiornate. Usare le informazioni sulle prestazioni per determinare dove implementare le modifiche e quindi eseguire il test su tali baseline.

Contributors

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

• Donnie Trumpower | Senior Cloud & AI Solutions Architect

Passaggi successivi

• Per creare una macchina virtuale Linux, vedere Quickstart: Creare una macchina virtuale Linux nel portale di Azure.
• Per installare un driver NVIDIA in una macchina virtuale Linux, vedere Installare i driver GPU NVIDIA in macchine virtuali serie N che eseguono Linux.
• Per effettuare il provisioning di una macchina virtuale Linux, vedere Creare e gestire macchine virtuali Linux con interfaccia della riga di comando di Azure.
• Accesso in uscita predefinito in Azure.
• Per un esempio di architettura più complessa, vedere architettura di riferimento Macchine virtuali di Azure in una landing zone di Azure.
• Per distribuire un'applicazione Web tra aree, vedere Applicazione Web multilivello creata per disponibilità elevata/ripristino di emergenza.

Risorsa correlata

• Eseguire una macchina virtuale Windows in Azure