Microsoft AZ-104: Macchine virtuali di Azure e Compute — Guida allo studio
Fa parte della Microsoft Azure Administrator Associate AZ-104 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.
Panoramica
Le Macchine Virtuali (VM) di Azure forniscono capacità di calcolo elastica per workload Windows e Linux con un controllo granulare su dimensioni, storage, disponibilità, networking, sicurezza e gestione del ciclo di vita. Gli amministratori devono comprendere le famiglie di dimensionamento, i costrutti di disponibilità, l’automazione della scalabilità, la capacità spot, le estensioni, i modelli di storage, gli host dedicati, il backup e i pattern di accesso sicuro per raggiungere gli obiettivi di affidabilità, performance e costo.
Opzioni di Calcolo e Dimensionamento
Le famiglie di dimensioni delle VM si rivolgono a profili di workload specifici. Le VM per uso generico (serie Dv, Ev, B burstable) bilanciano i rapporti vCPU-memoria per web server, database di piccole dimensioni e server applicativi. Le VM ottimizzate per il calcolo (Fsv2, HB/HBv2 per HPC CPU-bound) massimizzano le vCPU per GB e sono ottimizzate per un’alta velocità di clock, avvantaggiando livelli di API stateless, worker di elaborazione batch e server di gioco. Le VM ottimizzate per la memoria (Ev5, Mv2/Mv3) offrono una maggiore quantità di memoria per vCPU e supportano cache in-memory, motori di analisi e database di grandi dimensioni. Le VM con GPU (NV, NVv4 per la visualizzazione; NC/ND per il training e l’inferenza CUDA/AI) includono GPU NVIDIA con partizionamento vGPU su alcune SKU per densità ed efficienza dei costi; la compatibilità di driver e framework dovrebbe essere validata e fissata tramite estensioni.
Le operazioni di aggiornamento e ridimensionamento sono vincolate dalla disponibilità hardware nel cluster di destinazione; il ridimensionamento di una VM in un set di disponibilità può fallire con errori di allocazione se la capacità è limitata. La deallocazione di tutte le VM nel set e il successivo ridimensionamento spesso hanno successo, consentendo il posizionamento su hardware diverso. Quando sono richiesti indirizzi IP interni statici, questi vengono assegnati nella configurazione della NIC in Azure, non all’interno del sistema operativo guest.
Azure Dedicated Hosts posiziona le tue VM su server fisici single-tenant per garantire isolamento a livello di host, conformità e prevedibilità. I gruppi di host definiscono una collezione di host in una regione e possono estendersi su più zone di disponibilità e domini di errore dell’host per distribuire il rischio di guasti e manutenzione dell’host. I domini di errore (fault domain) degli host all’interno di un gruppo di host assicurano che le VM siano distribuite su rack fisici diversi. I vantaggi di licenza includono la possibilità di utilizzare licenze Windows Server/SQL Server con Software Assurance o Azure Hybrid Benefit e l’opzione di concedere in licenza per host (utile per SQL Enterprise/Windows Datacenter) anziché per VM, riducendo potenzialmente i costi per una consolidazione densa.
Disponibilità, Scalabilità e Ottimizzazione dei Costi
I set di disponibilità (Availability set) proteggono dai guasti hardware e dalla manutenzione pianificata all’interno di un data center. Le VM sono distribuite tra domini di errore (fault domain - alimentazione/rack distinti) e domini di aggiornamento (update domain - ondate di manutenzione). I limiti tipici sono fino a 3 domini di errore e 20 domini di aggiornamento; è necessario distribuire almeno due istanze per ottenere lo SLA del 99,95%. Le zone di disponibilità (Availability zone) forniscono una resilienza superiore posizionando le risorse in edifici di data center fisicamente separati all’interno di una regione; la distribuzione di due o più VM tra le zone garantisce uno SLA del 99,99% per le VM. Le zone richiedono risorse “zone-aware” e il traffico tra zone utilizza un Load Balancer o un Application Gateway di SKU Standard; è necessario pianificare l’egresso dei dati all’interno di una regione.
I Virtual Machine Scale Sets (VMSS) orchestrano flotte di VM identiche o eterogenee con scalabilità automatica e gestione dello stato di integrità integrate. L’orchestrazione Uniform utilizza un modello di set di scalabilità con un unico profilo di VM e si integra nativamente con Azure Load Balancer o Application Gateway. L’orchestrazione Flexible supporta SKU di VM diverse e l’individualità delle istanze, si combina con set/zone di disponibilità ed è adatta per ruoli stateful o misti. Le modalità di aggiornamento (Upgrade mode) determinano il comportamento del rollout: Manuale (l’amministratore avvia gli aggiornamenti), Automatico (la piattaforma aggiorna tutte le istanze quando il modello cambia) e Rolling (in batch con health probe, pausa tra i batch e soglie di errore). Le policy di scalabilità automatica (Autoscale) reagiscono a metriche (CPU, memoria tramite AMA, lunghezza della coda, metriche personalizzate), a pianificazioni o a entrambe; definiscono la capacità minima/massima/desiderata, i cooldown e le policy di scale-in (ad es., prima la VM più recente) per controllare il “churn”. Per la gestione in ingresso su larga scala, utilizzare i pool NAT in ingresso del Load Balancer Standard pubblico o interno. Gli health probe dovrebbero puntare alla porta e al protocollo del servizio effettivo; per SQL Always On con un load balancer interno, utilizzare un probe TCP sulla porta del listener anziché HTTP.
Le VM Spot di Azure sfruttano la capacità di Azure non utilizzata a sconti elevati senza garanzie di disponibilità. L’eviction (rimozione) si verifica quando la capacità viene reclamata o il prezzo di mercato supera il prezzo massimo impostato; è possibile impostare la policy di eviction su Deallocate (conserva il disco per un riavvio successivo quando disponibile) o Delete (distrugge l’istanza all’eviction). Si integrano con VMSS e Standard Load Balancer per la scalabilità stateless. I casi d’uso adatti includono l’elaborazione batch, i runner CI/CD, il rendering, il fuzzing e web farm stateless su larga scala che possono tollerare interruzioni. Evitare le istanze Spot per ambienti di produzione a singola istanza o per livelli stateful senza meccanismi di checkpointing. I tetti di prezzo (price cap) impediscono di pagare più della soglia impostata; se la domanda aumenta bruscamente, aspettarsi tassi di eviction più elevati.
Gestione di Storage, Backup e Immagini
Ogni VM ha un disco del sistema operativo (disco gestito, con caching ottimizzato per l’avvio) e dischi dati opzionali per lo storage delle applicazioni. Il disco temporaneo (D: su Windows, spesso /dev/sdb su Linux) risiede sull’host e non è persistente; utilizzarlo solo per cache effimere o file di paging/swap. I dischi gestiti (managed disk) astraggono gli account di storage, forniscono opzioni di ridondanza a livello di zona/regione, semplificano la scalabilità e migliorano la distribuzione negli availability set. I dischi non gestiti (unmanaged disk), collocati negli account di storage del cliente, sono considerati legacy e dovrebbero essere evitati a causa dei limiti di scalabilità e throttling. Selezionare gli SKU dei dischi in base a prestazioni e costi: Premium SSD e Premium SSD v2 per carichi di lavoro transazionali a bassa latenza, Ultra Disk per throughput/IOPS estremi con prestazioni regolabili, Standard SSD per uso generico e Standard HDD per carichi di lavoro ‘cold’.
Scollegare un disco dati da una VM prima di collegarlo a un’altra minimizza i tempi di inattività e preserva la coerenza dei dati. Le operazioni di ridimensionamento sui dischi richiedono tipicamente l’espansione della partizione/filesystem all’interno del sistema operativo guest; modifiche importanti alla dimensione della VM possono richiedere la deallocazione.
Azure Backup protegge le VM utilizzando un vault di Recovery Services. Abilitare il backup sulla VM o su larga scala tramite l’assegnazione di policy. Le policy di backup definiscono le pianificazioni (giornaliere/settimanali), la conservazione (a breve e lungo termine) e i parametri di Ripristino Immediato (Instant Restore) (conserva snapshot localmente per un rapido recupero dei file). I backup coerenti con l’applicazione (application-consistent) sono disponibili tramite VSS per Windows o script pre/post su Linux. I ripristini possono avere come destinazione un’intera VM (tipicamente su una nuova VM), dischi (per ricollegarli o per un recupero rapido) o file (ripristino a livello di file su qualsiasi VM nella sottoscrizione con montaggio sicuro). I backup funzionano per VM in esecuzione e arrestate (incluse quelle deallocate). Assicurare la compatibilità della crittografia: le chiavi gestite dalla piattaforma (Platform-managed keys) sono supportate per impostazione predefinita, mentre Azure Disk Encryption richiede passaggi aggiuntivi per il backup. Considerare il ripristino tra regioni (cross-region restore) se il vault ha lo storage geo-ridondante abilitato e se la propria postura di conformità lo consente.
Per le immagini ‘golden’, utilizzare Azure Compute Gallery per versionare e replicare le immagini tra le regioni; gli upload di VHD generalizzati on-premise possono essere eseguiti con strumenti come Add-AzVhd e poi catturati nella gallery per un provisioning coerente.
Networking, Accesso e Osservabilità
Ogni VM richiede almeno un’interfaccia di rete (NIC), che contiene una o più configurazioni IP. Una singola NIC può avere un IP privato primario e ulteriori IP privati secondari; associare un IP pubblico a una configurazione IP per esporre i servizi. La maggior parte dei carichi di lavoro necessita di una sola NIC per VM; le dimensioni della VM determinano i limiti delle NIC. Quando si distribuiscono cinque VM che necessitano ciascuna sia di un IP pubblico che privato con una postura di sicurezza identica, creare una NIC per ogni VM e un singolo Network Security Group applicato alla subnet (o alla NIC) per imporre regole di ingresso/uscita uniformi. L’assegnazione dell’IP privato dovrebbe essere statica a livello della NIC in Azure per mantenere la continuità dell’indirizzo; non impostare IP statici all’interno del sistema operativo guest. Gli IP pubblici dovrebbero utilizzare lo SKU Standard per il supporto a zone e scale set; abbinarli a un Standard Load Balancer per l’ambiente di produzione.
L’Accelerated Networking utilizza SR-IOV per bypassare il datapath dell’host e ridurre latenza, jitter e overhead della CPU. È supportato su determinate dimensioni di VM e immagini del sistema operativo e richiede una vNIC compatibile al momento della creazione (o un arresto/deallocazione per abilitarlo). Utilizzarlo per servizi ad alto throughput e bassa latenza e per livelli di gateway molto trafficati.
Azure Bastion fornisce accesso sicuro RDP/SSH su TLS direttamente dal portale di Azure o da un client nativo, senza esporre indirizzi IP pubblici sulle VM. Distribuire un host Bastion nella rete virtuale di destinazione, in una subnet dedicata chiamata AzureBastionSubnet con un prefisso /26 o superiore, e associare un IP pubblico Standard alla risorsa Bastion. Gli SKU includono Basic e Standard; lo SKU Standard aggiunge funzionalità come la scalabilità manuale (istanze), connessioni basate su IP (verso qualsiasi IP privato raggiungibile, anche attraverso VNet in peering), supporto per client nativo, integrazione con la registrazione delle sessioni e link condivisibili. Utilizzare Bastion per soddisfare i requisiti di accesso amministrativo zero-trust, evitando al contempo endpoint pubblici per singola VM e regole NAT in ingresso.
Le estensioni VM (VM extensions) automatizzano la configurazione e la telemetria. La Custom Script Extension esegue script PowerShell o Bash durante o dopo il provisioning per effettuare il bootstrap del software o iniettare file di configurazione; progettare script idempotenti e archiviare gli artefatti in uno storage sicuro con token SAS. L’estensione PowerShell DSC applica la Desired State Configuration per far convergere i nodi Windows allo stato dichiarato; utilizzare pull server o Azure Automation State Configuration per la gestione su larga scala. L’Azure Monitor Agent (installato tramite estensione) invia in streaming le metriche e i log del sistema guest agli workspace di Log Analytics secondo le Data Collection Rules; preferire l’AMA rispetto all’agente legacy di Log Analytics/MMA per un routing granulare dei dati, il multihoming e la scalabilità.
Costrutti di Disponibilità in Pratica e SLA
Scegliere i set di disponibilità quando è necessaria una ridondanza intra-datacenter con backend di archiviazione condivisi e non si richiede un posizionamento zonale. Scegliere le zone di disponibilità per i servizi mission-critical che richiedono un isolamento dai guasti a livello di edificio e uno SLA più elevato. Per i servizi a scalabilità orizzontale (scale-out), combinare i VMSS con le zone per una distribuzione uniforme e un ripristino automatico; associare i probe di integrità alle porte del carico di lavoro e sfruttare gli aggiornamenti in sequenza (rolling upgrade) per mitigare i rischi. Comprendere che le singole VM, anche con SSD Premium, offrono uno SLA inferiore rispetto alle distribuzioni multi-istanza. Per i livelli stateless sensibili ai costi, integrare un pool di VM Spot dietro un Load Balancer Standard e impostare criteri di rimozione (eviction) e di riduzione (scale-in) conservativi per proteggere la capacità di base.
Scenario di Problema Pratico
Contoso Ltd. gestisce un’applicazione web multi-livello con un’API stateless, una cache Redis stateful e un gruppo di disponibilità Always On di SQL Server. Deve migliorare la resilienza alle interruzioni di zona, ridurre i costi di calcolo per il livello API, proteggere l’accesso amministrativo senza IP pubblici e standardizzare il monitoraggio e i backup.
Creare tre subnet in una topologia hub-spoke: una subnet di gestione condivisa (hub), una subnet web/API (spoke) e una subnet dati (spoke). Distribuire Azure Bastion Standard nella AzureBastionSubnet (/26) dell’hub con un IP pubblico Standard. Motivo: Bastion abilita RDP/SSH su TLS senza esporre IP pubblici su alcuna VM, e lo SKU Standard supporta connessioni basate su IP tra VNet in peering, centralizzando l’accesso amministrativo.
Distribuire il livello API come un VM Scale Set (Uniform) attraverso le Zone di Disponibilità 1, 2 e 3 con un Load Balancer Standard. Abilitare la rete accelerata e impostare regole di scalabilità automatica per aggiungere istanze quando la CPU media è > 65% per 10 minuti e rimuoverle quando è < 35% con un periodo di attesa (cooldown). Aggiungere un pool secondario di VM Spot all’interno dello stesso set di scalabilità utilizzando l’orchestrazione Flessibile o un set di scalabilità complementare, configurando un prezzo massimo e il criterio di rimozione (eviction) Deallocate. Motivo: VMSS più le zone offre uno SLA del 99,99% e un ripristino automatico; la capacità Spot riduce i costi per i carichi di picco (burst) mentre il criterio Deallocate preserva i dischi per un rapido riutilizzo.
Distribuire le VM della cache Redis in un set di disponibilità con 2+ istanze e SSD Premium. Associare i domini di errore a 2 e fare affidamento sui 20 domini di aggiornamento della piattaforma. Motivo: la cache è stateful ma può essere replicata; i set di disponibilità forniscono isolamento a livello di rack e di manutenzione senza penalità di latenza tra zone.
Distribuire due VM SQL Server per zona (Zone 1 e 2) che partecipano a un gruppo di disponibilità Always On. Posizionarle su Host Dedicati di Azure all’interno di un gruppo di host che si estende su due zone e due domini di errore dell’host. Configurare un Load Balancer Standard interno con un probe TCP sulla porta del listener (es. 1433) per il listener del gruppo di disponibilità (AG). Motivo: gli Host Dedicati forniscono isolamento a livello di host ed efficienza delle licenze (licenze SQL per host), mentre il posizionamento zonale e il sondaggio di integrità TCP si allineano con i requisiti del listener SQL.
Standardizzare le immagini tramite Azure Compute Gallery contenente immagini OS con hardening. Utilizzare l’estensione Custom Script per installare i prerequisiti dell’applicazione e l’estensione DSC per imporre lo stato delle funzionalità di Windows e le baseline del registro. Motivo: le immagini della Gallery assicurano un provisioning coerente; le estensioni abilitano una configurazione ripetibile e il controllo della deriva (drift).
Configurare l’Agente di Monitoraggio di Azure tramite le Regole di Raccolta Dati per inviare metriche e log del sistema operativo guest a un’area di lavoro Log Analytics. Abilitare il monitoraggio delle connessioni e le mappe delle dipendenze secondo necessità. Motivo: AMA è l’agente attuale, supporta il routing granulare ed è richiesto per le moderne funzionalità di monitoraggio e per la scalabilità automatica dei VMSS basata su metriche diverse dalla CPU.
Proteggere tutte le VM con Azure Backup in un insieme di credenziali di Servizi di ripristino utilizzando due criteri: un criterio di livello 1 (Tier-1) con backup giornalieri e conservazione di 30 giorni per API/cache, e un criterio di livello 0 (Tier-0) con conservazione giornaliera più settimanale/mensile per SQL con snapshot coerenti con l’applicazione. Testare i ripristini eseguendo un ripristino a livello di file su una jump VM e un ripristino completo della VM su una rete di staging. Motivo: criteri separati si adattano alla criticità dei dati e agli RPO/RTO; il ripristino a livello di file e il ripristino della VM coprono scenari di ransomware e disastro.
Assegnare IP privati statici alle NIC di SQL e Redis a livello di NIC di Azure; mantenere le istanze API dinamiche dietro il load balancer. Applicare un singolo NSG a ogni subnet per imporre regole uniformi. Abilitare la rete accelerata sui livelli più trafficati. Motivo: l’assegnazione statica a livello di NIC preserva gli indirizzi per i livelli stateful; gli NSG a livello di subnet minimizzano la proliferazione delle regole; la rete accelerata riduce la latenza e l’overhead della CPU.
Questo progetto soddisfa gli obiettivi di disponibilità, costo, sicurezza e operatività combinando appropriatamente zone e set di disponibilità, sfruttando le VM Spot per la scalabilità stateless, imponendo un accesso amministrativo zero-trust con Bastion e standardizzando la configurazione, il monitoraggio e il backup su tutti i livelli.
← Sottoscrizioni di Azure · Tutti i domini · Reti virtuali di Azure →
Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Supera l'esame →