Google ACE: Compute Engine e operazioni sulle macchine virtuali — Guida allo studio

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Fa parte della Google Associate Cloud Engineer — Guida allo studio. Esercitati con risposte verificate nel centro esami Google, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Compute Engine fornisce macchine virtuali flessibili e ad alte prestazioni e primitive di orchestrazione per eseguire carichi di lavoro generici e specializzati. L’eccellenza operativa su Compute Engine si traduce nella scelta della famiglia di macchine e del disco corretti, nella definizione del ciclo di vita delle istanze con modelli e gruppi di istanze, nell’implementazione di meccanismi robusti di autoriparazione (autohealing) e scalabilità automatica (autoscaling), nel rafforzamento dei percorsi di accesso e nella preparazione alle modalità di guasto con procedure di ripristino ripetibili. Questa sezione illustra le scelte progettuali, i compromessi e i pattern operativi che riducono al minimo il lavoro manuale (toil) e massimizzano l’affidabilità e l’efficienza dei costi.

Tipi di Macchine, Dimensionamento e Ciclo di Vita dell’Istanza

Famiglie di macchine

Uso generico: E2 (ottimizzate per i costi), N2 (bilanciate), N2D (basate su AMD), Tau T2D/T2A (elevato rapporto prezzo/prestazioni per lo scale-out), adatte alla maggior parte dei carichi di lavoro.
Ottimizzate per il calcolo: C3 per attività CPU-bound; da scegliere quando sono necessarie elevate prestazioni per-core.
Ottimizzate per la memoria: serie M per database in-memory e analisi.
GPU e acceleratori: da collegare alle famiglie supportate quando è necessaria l’accelerazione CUDA o ML; assicurarsi che l’inizializzazione dei driver sia inclusa nei processi di avvio.

Tipi di macchine personalizzati

Utilizzare vCPU e memoria personalizzate per dimensionare correttamente i carichi di lavoro e ridurre gli sprechi, specialmente per esigenze asimmetriche (ad es. molta memoria ma CPU moderata).
Per i servizi CPU-bound, preferire un numero maggiore di vCPU; per quelli memory-bound, aumentare la RAM e assicurarsi che i garbage collector e le cache siano ottimizzati.
Prestare attenzione ai modelli di licenza legati al numero di core; i tipi personalizzati aiutano a evitare core con licenza non necessari.

Dimensionamento del carico di lavoro

Partire dai profili di risorse misurati in ambienti di sviluppo o precedenti: utilizzo della CPU al P95, picco massimo di memoria (high-water mark), throughput/IOPS del disco, larghezza di banda della rete.
Per traffico con picchi (bursty), pianificare un margine (headroom) o usare l’autoscaling; per carichi a regime (steady-state), puntare a un’utilizzazione del 60-70% al picco per bilanciare costi e resilienza.
Valutare le VM Spot (preemptible) per job batch e fault-tolerant; possono essere terminate in qualsiasi momento, quindi progettarle prevedendo checkpoint e tentativi (retry).

Risorse del ciclo di vita dell’istanza

Istanze VM: la risorsa di calcolo atomica. Usare etichette e una nomenclatura coerente per guidare l’automazione.
Modelli di istanza: modelli (blueprint) immutabili che definiscono tipo di macchina, dischi, account di servizio, metadati e script di avvio; sono la base per i gruppi di istanze gestite e garantiscono deployment ripetibili.
Gruppi di istanze gestite (MIG): forniscono dimensione dichiarativa, autoscaling, autoriparazione, aggiornamenti progressivi (rolling update), posizionamento a livello di regione (multi-zona) e configurazione per istanza. Preferire i MIG per pattern stateless e stateful (i MIG stateful conservano dischi/IP selezionati).
Gruppi di istanze non gestite: semplici raccolte per il bilanciamento del carico di set legacy; mancano di autoscaling/autoriparazione. Da usare solo quando è necessario registrare VM gestite in modo indipendente.

Disponibilità, Autoscaling e Manutenzione

Autoscaling

Segnali: utilizzo della CPU, richieste al secondo per istanza del bilanciatore di carico HTTP, metriche di Cloud Monitoring e profondità della coda. Scegliere un segnale strettamente correlato alla saturazione; la CPU è una buona base per carichi di lavoro omogenei e CPU-bound.
Periodi di attesa (cooldown) e stabilizzazione: configurarli per prevenire oscillazioni incontrollate (thrashing). Se l’applicazione impiega minuti per avviarsi (warm up), aumentare il ritardo iniziale del MIG e impostare un cooldown di autoscaling appropriato.
Pattern ’exact-one’ (istanza singola): per forzare la presenza di una sola VM, impostare min=1 e max=1 per l’autoscaling su un MIG. Ciò preserva l’integrità abilitando al contempo l’autoriparazione.

Autoriparazione e controlli di integrità

Controlli di integrità (Health check): usare controlli HTTP(S) per la verifica dell’attività (liveness) dell’applicazione; il TCP valida solo l’accettazione del socket. Implementare un endpoint di health che eserciti le dipendenze critiche.
Soglie e intervalli: ottimizzare l’intervallo di controllo e le soglie per rilevare rapidamente i guasti senza falsi positivi.
Ritardo iniziale: impostare il ritardo iniziale dell’autoriparazione del MIG abbastanza a lungo da consentire l’avvio e il riscaldamento (warm-up), per evitare sostituzioni premature di istanze integre in fase di avvio.
Modalità di guasto: endpoint di health configurati in modo errato e ritardi iniziali troppo brevi causano instabilità (flapping) e overprovisioning.

MIG regionali e posizionamento

I MIG regionali distribuiscono le istanze su più zone all’interno di una regione, fornendo tolleranza ai guasti di zona. Scegliere il numero di repliche target per zona in base alla pianificazione della capacità.
Usare configurazioni per istanza (per-instance config) e policy stateful quando è necessario conservare dischi o IP; tenere presente che la sostituzione delle VM può essere più lenta a causa della riconciliazione dello stato.

Manutenzione, migrazione live e prenotazioni

Migrazione live: opzione predefinita per la maggior parte delle VM; le istanze vengono spostate durante la manutenzione dell’host senza riavvio. Per carichi di lavoro che non tollerano la migrazione (ad es. HFT sensibile alla latenza), impostare la policy di manutenzione su ’terminate’ e affidarsi all’autoriparazione.
Le finestre di manutenzione dell’host sono trasparenti con la migrazione live, ma generano comunque eventi; monitorare e testare.
Prenotazioni: creare prenotazioni di zona per garantire la capacità per lanci critici o SLO rigorosi. Applicare un consumo della prenotazione ‘specifico’ o ‘qualsiasi’ in base alla propria governance.
Le prenotazioni sono garanzie di capacità; abbinarle a sconti per impegno di utilizzo (committed use discount) per la pianificazione dei costi.

Archiviazione, immagini e prestazioni

Dischi permanenti

Tipi: Standard (HDD) per throughput sequenziale a basso costo; Balanced (pd-balanced) per uso generico; SSD (pd-ssd) per IOPS elevati/bassa latenza; Extreme (pd-extreme) per IOPS e throughput provisionati a livelli di prestazioni elevate. I dischi permanenti regionali (Regional PD) forniscono una replica sincrona tra le zone per una maggiore disponibilità.
Le prestazioni scalano con le dimensioni del disco per i tipi standard, balanced e SSD; pre-dimensionare per soddisfare i picchi di IOPS/throughput o utilizzare Extreme per il provisioning esplicito.
L’opzione multi-attach in sola lettura consente di condividere set di dati tra più VM; coordinare di conseguenza i livelli di accesso e di caching.

Local SSD

Effimero, collegato direttamente all’host, con IOPS molto elevati/bassa latenza. I dati vengono persi in caso di arresto/terminazione/migrazione. Utilizzare per spazio temporaneo (scratch), cache e livelli di dati replicati. Assicurare la replica o i checkpoint a livello di applicazione.

Snapshot e immagini

Gli snapshot sono backup incrementali e point-in-time dei dischi permanenti; pianificarli con Resource Manager o gcloud per soddisfare l’RPO. L’archiviazione cross-region supporta il DR (Disaster Recovery).
Le immagini acquisiscono i dischi di avvio più la configurazione. Mantenere una pipeline di immagini con hardening e gestione delle patch. Convalidare gli agenti guest (per logging/monitoring) all’interno delle proprie golden image.
Pattern di ripristino: per un ripristino rapido, mantenere immagini di base di piccole dimensioni e configurare il resto tramite script di avvio o cloud-init; ciò riduce il drift e accelera gli aggiornamenti.

Scelta dei dischi: compromessi e modalità di guasto

I dischi sottodimensionati limitano il throughput dell’applicazione; il sovradimensionamento spreca costi. Misurare le caratteristiche di I/O effettive e scegliere il disco più piccolo che soddisfi le esigenze di picco con un margine.
Per i database, considerare i Regional PD e i dischi pd-ssd/pd-extreme; convalidare il comportamento di fsync e le profondità delle code (queue depth). Evitare i Local SSD per lo stato durevole, a meno che non sia replicato.

Accesso, sicurezza, networking e carichi di lavoro specializzati

Amministrazione Linux e Windows

SSH Linux: preferire OS Login per centralizzare l’autorizzazione SSH e attribuire l’accesso alle identità. Concedere i ruoli compute.osLogin o compute.osAdminLogin a gruppi, non a singoli individui.
RDP Windows: impostare le credenziali di Windows nella console o tramite gcloud; assicurarsi che le regole del firewall consentano la porta TCP 3389 solo da IP attendibili. Utilizzare IAP TCP forwarding per evitare l’esposizione pubblica.
Console seriale: abilitarla come percorso di emergenza (break-glass); utilizzare gcloud compute connect-to-serial-port per il debug dell’avvio. Limitare l’accesso con IAM e controllarlo tramite audit.

SSH, OS Login e gestione delle chiavi

Abilitare OS Login a livello di progetto o di istanza con il metadato enable-oslogin=TRUE. Gli utenti aggiungono la loro chiave pubblica SSH al proprio account Google; IAM controlla l’accesso basato sui ruoli.
Per i privilegi sudo/root, utilizzare il ruolo compute.osAdminLogin. Disabilitare le chiavi SSH a livello di progetto se si utilizza OS Login per prevenire il drift.

Metadati, script di avvio e cloud-init

Il server di metadati fornisce dati dell’istanza/progetto e token di service account. Utilizzare solo token con ambito ben definito (well-scoped); non inserire mai segreti (secret) nel codice (hardcode).
Script di avvio e cloud-init: eseguire il bootstrap degli agenti, recuperare le configurazioni e registrare i servizi. Rendere gli script idempotenti e scrivere i log sulla console seriale per la diagnostica.
I metadati per singola istanza possono sovrascrivere le impostazioni del modello; usarli con cautela per evitare disallineamenti di configurazione (configuration skew).

Service account e ambiti (scope)

Assegnare un service account dedicato per ogni carico di lavoro con ruoli IAM basati sul principio del privilegio minimo (least-privilege) sulle risorse richieste (es. storage.objectCreator su un bucket specifico).
Preferire ambiti (scope) ampi per le API Cloud solo quando l’accesso è strettamente controllato da IAM; altrimenti, limitare gli ambiti alle API minime necessarie.

Networking e indirizzi

Le NIC possono avere solo IP interni o anche esterni. Preferire VM private con Cloud NAT o IAP per l’accesso in uscita (outbound) e amministrativo.
Riservare indirizzi IP interni statici per endpoint stabili come i server di licenza; evitare di dipendere da indirizzi effimeri.
L’External HTTP(S) Load Balancing termina la connessione TLS sull’edge; utilizzare certificati gestiti e health check verso i MIG di backend. Mantenere la prontezza (readiness) del backend allineata con l’health check e il ritardo iniziale (initial delay) del MIG.

Carichi di lavoro specializzati e isolamento

Shielded VM: Secure Boot, vTPM e monitoraggio dell’integrità mitigano i rootkit; abilitare per impostazione predefinita, a meno che driver incompatibili non richiedano diversamente.
Confidential VM: la crittografia della memoria con AMD SEV protegge i dati in uso (data-in-use); l’impatto sulle prestazioni è generalmente minimo, ma va convalidato per le app sensibili alla latenza.
Nodi single-tenant (Sole-tenant node): host fisici dedicati per la conformità, l’isolamento da “vicini rumorosi” (noisy-neighbor) e l’affinità di licenza. Pianificare tenendo conto della frammentazione della capacità e dei costi più elevati.

← Gerarchia delle risorse · Tutti i domini · Container →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →