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

Per effettuare il provisioning di una macchina virtuale (VM) in Azure, sono necessari più componenti rispetto alla macchina virtuale stessa. Una distribuzione completa include risorse di rete e archiviazione. Questo articolo descrive 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 che usa i componenti necessari per una singola macchina virtuale. La macchina virtuale può eseguire carichi di lavoro e raggiungere la rete Internet pubblica evitando l'esposizione diretta alle minacce esterne. In questa architettura:

I carichi di lavoro nella macchina virtuale non hanno esposizione diretta a Internet. L'accesso è limitato alle risorse all'interno della stessa rete virtuale o a una rete virtuale con peering, ad esempio in una configurazione hub-spoke.
La macchina virtuale viene gestita usando Azure Bastion tramite Secure Shell (SSH). Non esiste accesso diretto dalla rete Internet pubblica alla macchina virtuale per la gestione.
Il gateway NAT (Network Address Translation) e l'indirizzo IP pubblico associato forniscono l'accesso a Internet esterno in uscita.

Components

Questa architettura usa i componenti seguenti.

Gruppo di risorse

Un gruppo risorso è un contenitore logico che contiene risorse Azure correlate. I gruppi di risorse consentono di distribuire, monitorare ed eliminare le risorse correlate insieme e tenere traccia dei costi come unità.

In generale, raggruppare le risorse in base al ciclo di vita condiviso e alla proprietà. Usare nomi descrittivi coerenti per le risorse per semplificare l'identificazione e la comprensione. Per altre informazioni, vedere Definire la convenzione di denominazione.

Macchina virtuale

È possibile effettuare il provisioning di una macchina virtuale da un elenco di immagini pubblicate, un'immagine gestita personalizzata o un disco rigido virtuale (VHD) caricato in Archiviazione BLOB di Azure. Azure supporta le distribuzioni Linux più diffuse, tra cui Debian, Red Hat Enterprise Linux (RHEL) e Ubuntu. Per altre informazioni, vedere Distribuzioni Linux approvate.

Azure offre molte dimensioni di macchina virtuale diverse. Se si sposta un carico di lavoro esistente in Azure, iniziare con le dimensioni della macchina virtuale più strettamente corrispondenti ai server locali. Dopo aver distribuito la macchina virtuale, misurare le prestazioni del carico di lavoro effettivo in termini di operazioni di CPU, memoria e output del disco al secondo (IOPS) e regolare le dimensioni in base alle esigenze.

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 maggiori informazioni, vedere Azure geographies. 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 VM pubblicata, vedere Trovare informazioni sulle immagini di Azure Marketplace.

Dischi

Per ottenere prestazioni ottimali per l'output di input del disco (I/O), è consigliabile usare unità SSD Premium che archiviano i dati su unità SSD (Solid State Drive). La capacità del disco di cui è stato effettuato il provisioning determina i costi, le operazioni di I/O al secondo e la velocità effettiva (velocità di trasferimento dei dati). Prendere in considerazione tutti e tre i fattori quando si seleziona una dimensione del disco. Le unità SSD Premium includono il bursting gratuito, che consente di soddisfare il picco della domanda senza effettuare il provisioning eccessivo e riduce il costo della capacità inutilizzata in combinazione con la comprensione dei modelli di carico di lavoro.

Nota

I dischi SSD Premium v2 e Ultra possono essere usati solo per i dischi dati. Non sono supportati per i dischi del sistema operativo (OS).

Managed disks semplifica la gestione del disco gestendo lo spazio di archiviazione per te. 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. I dischi gestiti riducono anche i costi offrendo le prestazioni necessarie senza il provisioning eccessivo, evitando così di pagare 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. Per i carichi di lavoro senza stato, in cui è necessario un provisioning rapido e non è richiesta la persistenza del sistema operativo, usare dischi temporanei del sistema operativo. Questi dischi collocano l'immagine del sistema operativo nell'archiviazione locale dell'host della macchina virtuale anziché nell'archiviazione remota di Azure, riducendo la latenza di lettura, velocizzando il ripristino dell'immagine ed eliminando i costi dei dischi gestiti. 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.

Per impostazione predefinita, molte immagini Linux non configurano lo spazio di scambio. Se il carico di lavoro richiede lo scambio, crearlo sul 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 basati su Storage.

Quando si crea un disco, non è formattato. Accedere alla macchina virtuale 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). È anche possibile specificare l'ID LUN se, ad esempio, 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, gli ID LUN devono essere univoci per ogni disco.

Per i dischi di archiviazione Premium, è possibile modificare l'utilità di pianificazione di I/O per ottimizzare le prestazioni nelle unità SSD. È 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 nello storage e potrebbe essere eliminato durante i riavvii e altri eventi del ciclo di vita della VM. 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 una rete virtuale che viene segmentata in subnet.
Scheda di interfaccia di rete (NIC): La scheda di interfaccia di rete connette la macchina virtuale alla rete virtuale e gestisce tutto il traffico in ingresso e in uscita. Ogni dimensione della macchina virtuale definisce un numero massimo di schede di interfaccia di rete.
Indirizzo IP pubblico: Un indirizzo IP pubblico può essere usato per comunicare con la macchina virtuale dall'esterno Azure tramite SSH. Tuttavia, questa opzione è sconsigliata perché è un potenziale rischio per la sicurezza.

Avvertimento

Evitare di collegare un indirizzo IP pubblico direttamente a una macchina virtuale. Eseguire questa operazione solo in circostanze estreme e includere altre misure di sicurezza, ad esempio l'uso di gruppi di sicurezza di rete (NSG) per filtrare il traffico.

Per l'accesso di gestione a una macchina virtuale, usare Azure Bastion per l'accesso SSH basato su browser o connettersi privatamente tramite una VPN o Azure ExpressRoute.
- L'indirizzo IP pubblico può essere dinamico o statico. Per impostazione predefinita, è dinamico. Riservare un indirizzo IP statico quando è 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 per una macchina virtuale.
NSG: Usare NSG per consentire o negare il traffico di rete verso le macchine virtuali e le subnet. Associarli alle subnet o alle singole schede di interfaccia di rete collegate alle macchine virtuali.

Tutti i gruppi di sicurezza di rete contengono un set di regole di sicurezza predefinite, inclusa una regola che blocca tutto il traffico Internet in ingresso. Non è possibile eliminare le regole predefinite, ma è possibile eseguirne l'override con altre regole. Ad esempio, è possibile creare regole che consentono il traffico Internet in ingresso verso porte specifiche, ad esempio la porta 443 per HTTPS.
Azure gateway NAT (Network Address Translation):Gateway NAT di Azure consente a tutte le istanze di una subnet privata di connettersi in uscita 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. È necessario configurare in modo esplicito la connettività Internet in uscita usando altre risorse, ad esempio gateway NAT, Azure Load Balancer Standard o firewall. Per altre informazioni, vedere Accesso in uscita predefinita in Azure.
Azure Bastion:Azure Bastion è una soluzione PaaS (Platform as a Service) 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à RDP (Secure Desktop remoto Protocol) o SSH alle macchine virtuali direttamente tramite Transport Layer Security (TLS) usando vari metodi, tra cui il portale di Azure, o client SSH o RDP nativi.

Operazioni

Questa sezione illustra le procedure operative principali per la gestione di una macchina virtuale Linux in Azure.

SSH: Prima di creare una macchina virtuale Linux, generare una coppia di chiavi pubblica-privata RSA a 2048 bit. Quando si crea la VM, utilizzare il file di chiave pubblica. Per altre informazioni, vedere Creare e usare una coppia di chiavi SSH pubblica-privata.
Diagnostica: Abilitare il monitoraggio e la diagnostica, incluse le metriche di base sull'integrità, i log dell'infrastruttura di diagnostica e la diagnostica di avvio. La diagnostica di avvio consente di diagnosticare l'errore di avvio se la macchina virtuale entra in uno stato non avviabile. Archiviare i log di diagnostica in un account di archiviazione. Un account di archiviazione con ridondanza locale standard (LRS) è sufficiente per log di diagnostica. Per altre informazioni, vedere Procedure consigliate per il monitoraggio e la diagnostica.
Disponibilità: lamanutenzione pianificata o il tempo di inattività non pianificato potrebbe influire sulla macchina virtuale. È possibile usare i log di riavvio della macchina virtuale per determinare se la manutenzione pianificata ha causato un riavvio della macchina virtuale. Per una disponibilità più elevata, distribuire più macchine virtuali tra zone di disponibilità all'interno di un'area. Questa distribuzione offre 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 proteggersi da 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 l'archiviazione 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 i tradizionali agenti di backup, utilizza la funzionalità di backup coerente in caso di arresto anomalo multidisco senza agente per automatizzare la protezione tramite backup senza influire sulle prestazioni dell'applicazione.
Arresto di una macchina virtuale: Azure distingue gli stati arrestati e deallocati. L'addebito viene addebitato quando lo stato della macchina virtuale viene arrestato, ma non quando la macchina virtuale viene deallocata. Nel portale di Azure, il pulsante Stop dealloca la macchina virtuale. Se si arresta la macchina virtuale tramite il sistema operativo mentre si è connessi, la macchina virtuale viene arrestata ma non viene deallocata, quindi si continua a pagare.
Eliminazione di una macchina virtuale: Se si elimina una macchina virtuale, è possibile scegliere di eliminare o conservarne i dischi, che consente di conservare i dati. Tuttavia, si paga ancora per i dischi. È possibile eliminare dischi gestiti 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 di Azure offrire la possibilità di distribuire i carichi di lavoro tra i nodi. I carichi di lavoro fondamentali per le operazioni aziendali non devono mai dipendere da una singola macchina virtuale. È possibile aggiungere o rimuovere automaticamente istanze di macchine virtuali in base alla richiesta e aumentare il numero di istanze in tempi di traffico più elevati o aumentare il numero di istanze quando il traffico è inferiore per ridurre al minimo i costi.
Azure Load Balancer distribuisce il traffico 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 ad Azure Load Balancer per i workload HTTP/HTTPS all'interno di una regione di Azure.
Per una distribuzione a livello aziendale, vedi Architettura di base di Macchine virtuali di Azure in una landing zone di Azure.

Dettagli dello scenario

Il diagramma precedente illustra una distribuzione di base di una singola macchina virtuale in una rete virtuale. Questo scenario è utile per fornire un carico di lavoro non critico per gli utenti solo interni.

Casi d'uso potenziali

Questa architettura è adatta a una semplice applicazione che non richiede l'esposizione a Internet pubblica e può tollerare tempi di inattività occasionali. Uno strumento di report interno di base è un caso d'uso tipico.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere 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à.

Questa architettura di esempio usa una singola macchina virtuale, quindi offre un livello minimo di affidabilità. Qualsiasi problema con la macchina virtuale o con l'host in cui viene eseguito causa un'interruzione e rende i carichi di lavoro ospitati non disponibili. Per qualsiasi carico di lavoro che richiede una disponibilità più elevata, distribuire più macchine virtuali che contengono lo stesso carico di lavoro e posizionare tali istanze dietro una soluzione di bilanciamento del carico appropriata. Se si trovano nella stessa area geografica, distribuire queste macchine virtuali nelle varie zone di disponibilità, se supportate, e aggiungerle al pool back-end di Azure Load Balancer Standard o di Application Gateway, se il carico di lavoro è basato su HTTP/HTTPS. Questa architettura consente al carico di lavoro di rimanere disponibile se una singola macchina virtuale nel back-end diventa inattiva.

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

Disponibilità elevata e ripristino di emergenza

Per ridurre il raggio di esplosione e migliorare la resilienza, distribuire il carico di lavoro in più aree e usare le linee guida Azure zona di destinazione. Questa implementazione potrebbe essere in una configurazione attiva-passiva, con failover verso l'area secondaria se l'area primaria diventa indisponibile, oppure in un'architettura attiva-attiva in cui entrambe le aree gestiscono il traffico per gli utenti.

Per un esempio, vedere Applicazione Web multilicenza creata per la disponibilità elevata e il ripristino di emergenza. L'esempio in questo articolo usa Azure Site Recovery per replicare i dischi di singole macchine virtuali in un'area secondaria. È possibile usare Site Recovery per eseguire il failover di tali macchine virtuali nell'area geografica secondaria utilizzando un obiettivo del punto di ripristino (RPO) ridotto e un obiettivo del tempo di ripristino (RTO) ridotto.

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

Sicurezza

La sicurezza fornisce protezioni contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la sicurezza.

Considerare questi punti quando si sviluppa l'architettura:

Usare Microsoft Defender per il cloud per ottenere una visualizzazione centrale dello stato di sicurezza delle risorse Azure. Defender per il cloud monitora i potenziali problemi di sicurezza e fornisce un quadro completo dell'integrità della sicurezza della distribuzione. Configurare Defender per il cloud per sottoscrizione Azure e abilitare la raccolta dei dati di sicurezza. Defender per il cloud analizza automaticamente le macchine virtuali create in tale sottoscrizione.
- Gestione delle patch: Se abilitata, Defender per il cloud identifica gli aggiornamenti critici e della sicurezza mancanti.
- Antimalware: Se abilitata, Defender per il cloud controlla se è installato software antimalware. È anche possibile usare Defender per il cloud per installare software antimalware direttamente dal portale di Azure.
Usare Azure controllo degli accessi basato sui ruoli (Azure RBAC) per controllare l'accesso alle risorse Azure. Con Azure RBAC, è possibile concedere agli utenti solo le autorizzazioni necessarie per svolgere il loro lavoro. Ad esempio, il ruolo Lettore può visualizzare Azure risorse, ma non può 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 che ha effettuato l'accesso a una VM può eseguire. Il tipo di account nel sistema operativo guest determina tali autorizzazioni.
Usare audit logs per visualizzare le azioni di provisioning e altri eventi della macchina virtuale.
Abilitare la crittografia nell'host per ottenere la crittografia end-to-end per i dati della 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 temporanei del sistema operativo 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

Ottimizzazione costi è incentrata sulla ricerca di 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 carichi di lavoro prevedibili, usa Azure Reservations e Azure savings plan for compute. Un contratto di un anno o tre anni può ridurre notevolmente i costi di calcolo rispetto alle tariffe con pagamento in base al 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 .

Macchine virtuali Spot di Azure sfruttano la capacità Azure inutilizzata a tariffe notevolmente ridotte. Azure può sfrattare le VM Spot con breve preavviso quando ha nuovamente bisogno della capacità, quindi sono adatte solo per carichi di lavoro tolleranti agli errori senza tempi di completamento rigorosi. Prendere in considerazione le macchine virtuali spot per:

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 il calcolatore dei prezzi di Azure per stimare i costi.

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 delle risorse Azure e delle relative dipendenze. È possibile scrivere questi modelli usando Bicep, Azure Resource Manager o Terraform. Questi modelli possono essere usati come parte di una pipeline di integrazione continua e distribuzione continua (CI/CD) tramite la distribuzione automatica. Questo approccio fornisce il controllo della versione sull'architettura, garantisce la coerenza tra gli ambienti e applica riproducibilità, sicurezza e conformità.

Per monitorare e diagnosticare i problemi, abilitare i log di diagnostica sulle risorse e inviarli a Monitoraggio di Azure per l'analisi e l'ottimizzazione. È possibile usare questi log per implementare avvisi e notifiche di eventi critici e, in alcuni casi, consentire la correzione automatica o la registrazione dei ticket nel sistema di gestione dei servizi IT .

Efficienza prestazionale

L'efficienza delle prestazioni si riferisce alla capacità del carico di lavoro di ridimensionarsi per soddisfare in modo efficiente le esigenze degli utenti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'efficienza delle prestazioni.

L'efficienza delle prestazioni consente di ridurre al minimo la latenza, ottenere architetture scalabili, ottimizzare l'utilizzo delle risorse e migliorare continuamente le prestazioni del sistema. Le decisioni prese in merito all'architettura del carico di lavoro, alle dimensioni delle macchine virtuali e alle configurazioni del disco possono influire notevolmente sulle prestazioni del carico di lavoro. Fare le scelte giuste può impedire la necessità di riprogettare la soluzione in futuro, aggiungere flessibilità e risparmiare sui costi.