Definire RTO e RPO come driver di design

Ogni decisione di disaster recovery (DR) parte da due metriche di business, non tecniche:

  • RTO (Recovery Time Objective): quanto tempo puoi restare offline. Guida la scelta della strategia di failover (attivo/attivo, attivo/passivo caldo, freddo).
  • RPO (Recovery Point Objective): quanta perdita di dati puoi tollerare. Guida la strategia di replica (sincrona vs asincrona).

Il principio architetturale è che il costo cresce esponenzialmente man mano che RTO e RPO tendono a zero. In sede di design non sovradimensionare: un workload di reporting interno con RTO di 24h non giustifica un’architettura attivo/attivo multi-region. Allinea la spesa al valore di business, coerentemente con i pilastri Reliability e Cost Optimization dell’Azure Well-Architected Framework.

DR per IaaS: Azure Site Recovery

Per macchine virtuali (workload lift-and-shift), la raccomandazione standard è Azure Site Recovery (ASR):

  • Replica asincrona continua dei dischi verso la region secondaria; RPO tipicamente in secondi/minuti.
  • RTO dipende dal tempo di boot e dall’ordinamento dei tier (vedi sotto), tipicamente decine di minuti.
  • Supporta recovery plan con gruppi, script e azioni manuali per orchestrare il failover.

Trade-off: ASM mantiene la region secondaria in stato “replica” senza VM in esecuzione, quindi il costo è basso (storage + licenza ASR), ma il ripristino non è istantaneo. Se il requisito è RTO vicino a zero, ASM non basta: serve un’architettura attivo/attivo con VMSS in entrambe le region dietro Azure Front Door o Traffic Manager.

DR per PaaS: replica nativa

Per i servizi gestiti, non usare ASM: sfrutta le capacità di replica native, più semplici e affidabili.

  • Azure SQL Database: usa i failover group (auto-failover) con geo-replica. Il failover group fornisce un listener endpoint stabile (.database.windows.net) che reindirizza automaticamente le connessioni alla replica promossa, eliminando la necessità di cambiare la connection string.
  • Cosmos DB: abilita multi-region writes o failover automatico; la replica geografica è integrata.
  • Storage Account: scegli GZRS/RA-GRS in base al bisogno di lettura dalla secondaria; ricorda che il failover geografico dello storage è un’operazione con RPO non nullo.
  • App Service / AKS: replica lo stack in due region e bilancia con Front Door.

Topologia di rete, DNS e dependency mapping

Il failover applicativo funziona solo se rete e DNS sono progettati prima dell’incidente:

  • Pre-provisiona VNet, subnet e NSG nella region secondaria (non “just in time”). Evita address space sovrapposti se prevedi peering o coesistenza durante il failover.
  • Global load balancing: Azure Front Door (L7, per HTTP/S, con WAF e health probe) o Traffic Manager (DNS-based, per endpoint non-HTTP). Il redirect del traffico verso la secondaria è il meccanismo che rende il failover trasparente al client.
  • DNS TTL basso sui record critici per accelerare la propagazione durante il failover.
  • Dependency mapping: documenta le dipendenze tra tier (web → app → database → identity/Entra ID → storage) e definisci l’ordine di failover. Il database e i servizi di identità devono essere disponibili prima del tier applicativo.

Trappole tipiche d’esame

  • Requisito: DR mai fallito in produzione ma con RTO garantito contrattualmente → soluzione: test di DR pianificati e ripetuti. Un piano non testato è un piano che non esiste. ASM offre il test failover in una rete isolata senza impattare la produzione: usalo per validare RTO/RPO senza rischi.
  • Requisito: applicazione multi-tier che dopo il failover non si avvia → soluzione: recovery plan con ordinamento dei gruppi. Se il tier app parte prima del database, le connessioni falliscono. Definisci gruppi ASM ordinati (DB prima, app dopo) con eventuali script post-boot.
  • Requisito: failover che fallisce per mancanza di risorse nella secondaria → soluzione: capacità garantita. La region secondaria potrebbe non avere abbastanza VM disponibili durante un disastro regionale. Usa On-demand Capacity Reservation per garantire la capacità compute; non dare per scontata la disponibilità di uno specifico SKU.
  • Requisito: connection string da non modificare al failover del DB → soluzione: failover group listener. Non usare la geo-replica “read-secondary” semplice se serve un endpoint stabile: il failover group fornisce l’FQDN del listener che segue automaticamente il primario.
  • Requisito: minimizzare costo mantenendo RPO in minuti per VM → soluzione: Azure Site Recovery (attivo/passivo). Non proporre un’architettura attivo/attivo (costosa) quando l’RTO tollera decine di minuti; ASM con replica asincrona è la scelta cost-effective.
  • Requisito: fallback dopo il ripristino della region primaria → soluzione: pianifica il failback. Il DR non è completo senza reprotect e failback ordinato verso la primaria, evitando divergenza dei dati.