Definire RTO, RPO e livelli di ripristino

La pianificazione della continuità aziendale (BCP) è il processo volto a garantire che le funzioni aziendali critiche possano continuare durante e dopo un evento disastroso. Nel cloud computing, ciò significa progettare sistemi in grado di riprendersi dai guasti entro soglie accettabili di tempo e perdita di dati. Due metriche fondamentali, RTO e RPO, definiscono che cosa sia «accettabile» per ogni carico di lavoro.

Il Recovery Time Objective (RTO) è la durata massima accettabile per cui un sistema può rimanere offline dopo un evento disastroso. Risponde alla domanda: «Per quanto tempo l'azienda può tollerare che questa applicazione non sia disponibile?». L'RTO viene espresso in unità di tempo: ore, minuti o secondi. Un sistema di elaborazione dei pagamenti potrebbe avere un RTO di 15 minuti, mentre un portale HR interno potrebbe avere un RTO di 24 ore.

Il Recovery Point Objective (RPO) è la quantità massima accettabile di dati persi, misurata in termini di tempo. Risponde alla domanda: «Quanti dati può permettersi di perdere l'azienda?». Se l'RPO è di 1 ora, l'azienda accetta di perdere fino a 1 ora di transazioni. L'RPO determina la frequenza con cui è necessario eseguire il backup o replicare i dati. Un RPO pari a 0 richiede la replica sincrona, che è costosa e può influire sulle prestazioni di scrittura.

È importante non confondere RTO e RPO:

• RTO riguarda il tempo: per quanto tempo il sistema rimane inattivo
• RPO riguarda i dati: quanti dati vengono persi

Un sistema potrebbe avere un RTO breve (ripristino rapido) ma un RPO lungo (accettando una perdita significativa di dati), o viceversa. L'ideale è che entrambi siano brevi, ma per ottenere questo risultato sono necessari investimenti significativi nella replica e nella capacità di standby a caldo.

Non tutti i carichi di lavoro hanno lo stesso livello di criticità. Un approccio comune consiste nel classificare i carichi di lavoro in livelli di ripristino in base all'impatto aziendale:

• Livello 1 (Mission-Critical) — RTO/RPO rigidi, costo più elevato (ad esempio pagamenti e piattaforme di trading)
• Livello 2 (Business-Critical) — RTO/RPO moderati (ad esempio CRM ed ERP)
• Livello 3 (Non-Critical) — RTO/RPO meno stringenti, costo più contenuto (ad esempio ambienti di sviluppo e archivi)

I diversi livelli di ripristino corrispondono a funzionalità Azure differenti:

• Livello 1 — scritture in più aree geografiche di Cosmos DB, gruppi di failover automatico di SQL, architettura active-active, Traffic Manager
• Livello 2 — Azure Site Recovery verso un'area geografica secondaria, geo-replica SQL (replica di lettura), backup giornalieri con conservazione di 30 giorni
• Livello 3 — Azure Backup con pianificazioni settimanali, nessuna replica, ripristino da snapshot

Per giustificare l'investimento in un'architettura con RTO ridotto, calcoli il costo del downtime del carico di lavoro. Questo include la perdita di ricavi, le penali SLA per i clienti, la perdita di produttività del personale e i danni alla reputazione. Se un'ora di downtime costa 500.000 $, spendere 50.000 $ al mese per una configurazione active-active è facilmente giustificabile. Utilizzi questi valori per elaborare un business case relativo al livello di ripristino appropriato.

Azure Site Recovery (ASR) è il servizio principale per raggiungere gli obiettivi RTO/RPO del livello 2 in Azure. ASR replica continuamente le VM in un'area geografica secondaria e può avviare un failover entro pochi minuti. La frequenza di replica per le VM Azure è di 30 secondi (coerente con gli arresti anomali) oppure di 1-4 ore (coerente con l'applicazione), fornendo in genere un RPO compreso in tale intervallo, a seconda della configurazione.

Per i carichi di lavoro in cui l'RPO è misurato in ore, è sufficiente Azure Backup con una pianificazione appropriata. Ad esempio, un RPO di 4 ore richiede un intervallo di backup di almeno 4 ore. Azure Backup supporta criteri avanzati che consentono pianificazioni di backup orarie per le VM Azure. Per i database, il ripristino temporizzato (PITR) con backup dei log delle transazioni può raggiungere un RPO inferiore a 1 ora a un costo inferiore rispetto ad ASR.

Gli obiettivi RTO e RPO devono essere documentati formalmente in una Business Impact Analysis (BIA) e riesaminati dagli stakeholder sia tecnici sia aziendali. La BIA associa ogni applicazione al relativo livello di ripristino, documenta gli obiettivi RTO/RPO, identifica i servizi Azure che consentiranno di raggiungere tali obiettivi e specifica la pianificazione dei test (la frequenza con cui il piano DR viene convalidato tramite esercitazioni).

Gli obiettivi RTO e RPO rimangono aspirazionali finché non vengono convalidati tramite test DR. Durante un test DR, misuri il tempo effettivo necessario per il ripristino (rispetta l'RTO dichiarato?) e la perdita effettiva di dati al punto di ripristino (rispetta l'RPO dichiarato?). Se il test evidenzia delle lacune, aggiorni l'architettura o le procedure finché gli obiettivi non vengono raggiunti costantemente. Documenti i risultati dei test per gli audit di conformità.

Verifichi la Sua comprensione dei concetti di Microsoft Azure Fundamentals (AZ-900) trattati in questa lezione.

In questa lezione ha appreso che RTO è il downtime massimo accettabile, mentre RPO è la perdita massima accettabile di dati misurata in termini di tempo; i carichi di lavoro vengono classificati in livelli di ripristino associati a servizi Azure specifici; e i test sono essenziali per convalidare la possibilità di raggiungere gli obiettivi RTO/RPO. Prossimamente esamineremo i piani di ripristino e il failover automatizzato con Azure Site Recovery.