Progettare per l’affidabilità in AZ-305 significa partire sempre dal requisito di business — l’SLA target, l’RTO/RPO e il budget — e risalire alla topologia minima che lo soddisfa. Il pilastro Reliability dell’Azure Well-Architected Framework ci ricorda che l’alta disponibilità non è un prodotto da acquistare, ma una proprietà emergente dell’intera catena di dipendenze: vale quanto il suo anello più debole.

Le tre leve di ridondanza del compute

Per il tier compute esistono tre livelli progressivi, ciascuno con un SLA e un dominio di guasto diverso.

  • Availability set: distribuisce le VM su update domain e fault domain distinti all’interno di un singolo datacenter. Protegge da guasti hardware localizzati (rack, alimentazione, aggiornamenti pianificati), ma non da un’interruzione dell’intera zona. SLA: 99,95% per due o più VM.
  • Availability zone: colloca le repliche in datacenter fisicamente separati della stessa region, con alimentazione, rete e raffreddamento indipendenti. Protegge dal guasto di un intero datacenter. SLA: 99,99% distribuendo le VM su due o più zone.
  • Deployment multi-region su region pair: replica lo stack in una seconda region per resistere a un disastro regionale. È l’unico livello che indirizza davvero il disaster recovery e i requisiti di residenza/continuità geografica.

Regola di design: se il requisito è “99,99% e tolleranza al guasto di un datacenter”, la risposta è availability zone, non availability set. Le zone sono anche prerequisito per servizi PaaS zone-redundant (zone-redundant SQL Database, zone-redundant Storage ZRS, gateway zone-redundant).

Active-active vs active-passive

Il pattern multi-region si declina in due archetipi con trade-off netti:

  • Active-passive (warm/cold standby): traffico su una region primaria, seconda region in standby con failover manuale o automatizzato. Costo inferiore, RTO più alto, tipico dove basta la resilienza al disastro. Orchestrato spesso con Azure Site Recovery o failover di database geo-replicato.
  • Active-active: entrambe le region servono traffico contemporaneamente dietro un load balancer globale (Azure Front Door o Traffic Manager). RTO prossimo a zero e scalabilità aggiuntiva, ma richiede stato condiviso o replicato in modo consistente e costo raddoppiato. Da raccomandare quando il requisito è “zero downtime percepito” e il workload tollera la coerenza multi-master (o è stateless).

Front Door è la scelta preferibile quando serve routing L7 con TLS offload, caching e WAF integrato; Traffic Manager (DNS-based) quando basta il routing su endpoint non-HTTP o cross-cloud.

Comporre l’SLA end-to-end (composite SLA)

L’errore architetturale più comune è ragionare per singolo componente. L’SLA reale si compone:

  • Dipendenze in serie (l’utente attraversa App → DB → Storage): si moltiplicano gli SLA. App Service 99,95% × SQL 99,99% × Storage 99,9% ≈ 99,84% — più basso di ogni singolo componente.
  • Componenti ridondati in parallelo: la disponibilità sale come 1 − (1 − SLA)^N. Due region al 99,95% dietro Front Door: 1 − (0,0005)² ≈ 99,999975%, cui va poi rimoltiplicato l’SLA del load balancer stesso (Front Door 99,99%).

Aggiungere ridondanza aiuta solo dove esiste un cammino alternativo reale: replicare l’app ma condividere un singolo database non ridondato lascia l’SLA end-to-end schiacciato dal componente non protetto.

Trappole tipiche d’esame

  • Requisito 99,99% con tolleranza al guasto di un datacenter, ma il candidato sceglie availability set → l’availability set garantisce solo 99,95% e resta dentro un unico datacenter. Soluzione: availability zone (o servizio PaaS zone-redundant).
  • Dipendenza single-zone non ridondata nella catena (es. NVA, cache o database pinnato a una sola zona a valle di VM multi-zona) → l’SLA end-to-end collassa sul componente più debole. Soluzione: rendere zone-redundant ogni hop del percorso critico, non solo il front-end.
  • Calcolo ottimistico dell’SLA sommando o prendendo il massimo dei componenti → per dipendenze in serie gli SLA si moltiplicano e il risultato è sempre inferiore al minimo. Soluzione: calcolare il composite SLA (prodotto in serie, 1−(1−SLA)^N in parallelo) e confrontarlo col target.
  • Assumere che la geo-replica del dato (GRS/geo-replication SQL) garantisca HA applicativa → GRS e geo-replica proteggono la durabilità del dato, ma il failover dello storage o del DB non riavvia l’applicazione né sposta il traffico. Soluzione: affiancare compute multi-region + routing globale (Front Door/Traffic Manager) e definire RTO/RPO espliciti.
  • Requisito RPO≈0 e RTO minuti soddisfatto con backup/restore → il restore ha RPO e RTO troppo alti. Soluzione: geo-replica sincrona/attiva (es. active geo-replication, ZRS/GRS a seconda del target) dimensionata sull’RPO richiesto.

In sintesi: mappa il requisito sul livello minimo di ridondanza (set → zone → region), scegli active-active solo quando l’RTO lo impone, e valida sempre il numero finale con il calcolo del composite SLA prima di considerare completo il design.