Panoramica della continuità aziendale del database SQL di Azure
Si applica a:
database SQL di Azure database SQL in Fabric
Il presente articolo offre una panoramica delle funzionalità di continuità aziendale e ripristino di emergenza del database SQL di Azure, descrivendo le opzioni e le raccomandazioni per il ripristino da eventi di interruzione che potrebbero causare la perdita di dati o causare la mancata disponibilità del database e dell'applicazione. Informazioni sulle operazioni da eseguire quando si verifica un errore generato da un utente o da un'applicazione che influisce sull'integrità dei dati, se in una regione o zona di disponibilità di Azure si verifica un'interruzione o quando l'applicazione richiede manutenzione.
Panoramica
La continuità aziendale nel database SQL di Azure si riferisce ai meccanismi, ai criteri e alle procedure che consentono all'azienda di continuare a funzionare in caso di interruzione fornendo disponibilità, disponibilità elevata e ripristino di emergenza.
Nella maggior parte dei casi, il database SQL gestirà gli eventi di arresto improvviso che potrebbero verificarsi nell'ambiente cloud e manterrà le applicazioni e i processi aziendali in esecuzione. Esistono tuttavia alcuni eventi di interruzione in cui la mitigazione potrebbe richiedere del tempo, per esempio:
- Un utente elimina o aggiorna accidentalmente una riga in una tabella.
- Un utente malintenzionato riesce a eliminare dati o database.
- Un evento di emergenza naturale irreversibile arresta un data center o una zona o area di disponibilità.
- Rara interruzione di data center, zona di disponibilità o a livello di area causata da una modifica della configurazione, un bug software o un errore del componente hardware.
Disponibilità
Il database SQL di Azure viene fornito con una promessa di resilienza e affidabilità di base che la protegge da errori software o hardware. I backup del database sono automatizzati per proteggere i dati dal danneggiamento o dall’eliminazione accidentale. Come servizio PaaS (Platform-as-a-Service), il servizio database SQL di Azure offre disponibilità come funzionalità off-the-shelf con un contratto di servizio di disponibilità leader del settore pari al 99,99%.
Disponibilità elevata
Per ottenere disponibilità elevata nell’ambiente cloud Azure, abilitare la ridondanza della zona per il database SQL o il pool elastico per usare le zone di disponibilità e assicurarsi che il database o il pool elastico sia resiliente agli errori di zona. Molte aree di Azure forniscono zone di disponibilità, ossia gruppi separati di data center all'interno di un'area con un'infrastruttura di rete, raffreddamento e alimentazione indipendente. Le zone di disponibilità sono progettate per fornire servizi, capacità e disponibilità elevata nelle zone restanti in caso di interruzione di un'area. L'abilitazione della ridondanza della zona garantisce che il database o il pool elastico sia resiliente agli errori hardware e software di zona e che il recupero sia trasparente per le applicazioni. Quando la disponibilità elevata è abilitata, il servizio del database SQL di Azure è in grado di fornire un contratto di servizio di disponibilità superiore del 99,995%.
Ripristino di emergenza
Per ottenere una maggiore disponibilità e ridondanza tra aree è possibile abilitare le funzionalità di ripristino di emergenza per ripristinare rapidamente il database da un errore irreversibile a livello di area. Le opzioni di ripristino di emergenza per il database SQL di Azure sono:
- La replica geografica attiva consente di creare un database secondario continuamente sincronizzato e leggibile per un database primario in qualsiasi regione.
- I gruppi di failover, oltre a fornire la sincronizzazione continua tra un database primario e secondario, consentono anche di gestire la replica e il failover di alcuni o di tutti i database in un server logico in un server logico secondario in un'altra area. I gruppi di failover forniscono endpoint listener in lettura/scrittura e di sola lettura che rimangono invariati, quindi l'aggiornamento delle stringa di connessione dell'applicazione dopo il failover non è necessario.
- Il ripristino geografico consente di eseguire il ripristino da un'interruzione a livello di area ripristinando i backup con replica geografica quando non è possibile accedere al database nell'area primaria creando un nuovo database su ogni server esistente in qualsiasi area di Azure.
La tabella seguente confronta la replica geografica attiva e i gruppi di failover, due opzioni di ripristino di emergenza per il database SQL di Azure:
| Replica geografica attiva | Gruppi di failover | |
|---|---|---|
| Sincronizzazione continua dei dati tra area primaria e secondaria | Sì | Sì |
| Failover di più database contemporaneamente | No | Sì |
| La stringa di connessione rimane invariata dopo il failover | No | Sì |
| Supporta la scalabilità in lettura | Sì | Sì |
| Più repliche | Sì | No |
| Può trovarsi nella stessa area della replica primaria | Sì | No |
Funzionalità che offrono la continuità aziendale
Dalla prospettiva del database, sono presenti quattro scenari principali di potenziali interruzioni. La tabella seguente elenca funzionalità di continuità aziendale del database SQL che è possibile usare per attenuare un potenziale scenario di interruzione aziendale:
| Scenario di interruzione aziendale | Funzionalità per la continuità aziendale |
|---|---|
| Guasti hardware o errori software locali che interessano il nodo del database. | Per attenuare gli errori hardware e software locali, il database SQL include un'architettura di disponibilità, che garantisce il ripristino automatico da questi errori con uno SLA di disponibilità fino al 99,99%. |
| Il danneggiamento o l'eliminazione di dati causati in genere da un bug dell'applicazione o da un errore umano. Questi errori sono specifici dell'applicazione e in genere non possono essere rilevati dal servizio di database. | Per proteggere l’attività dalla perdita di dati, il database SQL crea automaticamente una combinazione di backup completi del database su base settimanale, backup differenziali del database (ogni 12 ore o 24 ore) e backup dei log delle transazioni ogni 5 - 10 minuti. Per impostazione predefinita, i backup vengono archiviati nell'archiviazione con ridondanza geografica per sette giorni per ogni livello di servizio. Tutti i livelli di servizio, ad eccezione di Basic, supportano un periodo di conservazione dei backup configurabile per il ripristino temporizzato (PITR) fino a 35 giorni. È possibile ripristinare il database eliminato al punto in cui è stato eliminato se il server non è stato eliminato, o se è stata configurata una conservazione a lungo termine (LTR). |
| Rara interruzione di data center o zona di disponibilità causata probabilmente da un evento avverso naturale, una modifica della configurazione, un bug software o un errore del componente hardware. | Per attenuare l'interruzione a livello di data center o di zona di disponibilità, abilitare la ridondanza della zona per il database o pool elastico per usare le zone di disponibilità di Azure e garantire la ridondanza in più zone fisiche all'interno di un'area di Azure. L'abilitazione della ridondanza della zona garantisce che il database o pool elastico sia resiliente agli errori di zona con un contratto di servizio con disponibilità elevata fino al 99,995%. |
| Rara interruzione regionale che influisce su tutte le zone di disponibilità e sui data center che la comprendono, probabilmente causata da un evento di emergenza naturale irreversibile. | Per ridurre un'interruzione a livello di area, abilitare il ripristino di emergenza usando una delle opzioni seguenti: - Opzioni di sincronizzazione continua dei dati, ad esempio gruppi di failover (scelta consigliata) o replica geografica attiva che consentono di creare repliche in un'area secondaria per il failover. - Impostazione della ridondanza dell'archiviazione di backup nell'archiviazione di backup con ridondanza geografica per l'uso del ripristino geografico. |
RTO e RPO
Quando si sviluppa il piano di continuità aziendale, è necessario conoscere il tempo massimo accettabile prima che l'applicazione venga ripristinata completamente dopo l'evento di arresto. Il tempo necessario per un ripristino completo dell'applicazione è noto come obiettivo del tempo di ripristino (RTO). È anche necessario conoscere la perdita massima di aggiornamenti di dati recenti (intervallo di tempo) che l'applicazione è in grado di tollerare durante il ripristino dopo l'evento di arresto improvviso. La potenziale perdita di dati è conosciuta come obiettivo del punto di ripristino (RPO).
La tabella seguente confronta RPO e RTO di ciascuna opzione di continuità aziendale:
| Opzione per la continuità aziendale | RTO (tempo di inattività) | RPO (perdita di dati) |
|---|---|---|
| Disponibilità elevata (usando la ridondanza della zona) |
Generalmente meno di 30 secondi | 0 |
| Ripristino di emergenza (usando gruppi di failover con criteri di failover gestiti dal cliente o replica geografica attiva) |
Generalmente meno di 60 secondi | Uguale o maggiore a 0 (dipende dalle modifiche ai dati prima dell'evento di interruzione che non è stato replicato) |
| Ripristino di emergenza (con il ripristino geografico) |
Da alcuni minuti a diverse ore | Da alcuni minuti a diverse ore |
Elenchi di controllo per continuità aziendale
Per consigli prescrittivi per ottimizzare la disponibilità e ottenere una maggiore continuità aziendale, consultare:
- Elenco di controllo della disponibilità
- Elenco di controllo per la disponibilità elevata
- Elenchi di controllo per il ripristino di emergenza
Prepararsi a un'interruzione regionale
Indipendentemente dalle funzionalità di continuità aziendale usate, è necessario preparare un database secondario in un'altra area. Se non ci si prepara adeguatamente, riportare online le applicazioni dopo un failover o un ripristino del database richiederà ulteriore tempo e, probabilmente, la risoluzione di problemi aggiuntivi in un momento di stress: una combinazione da evitare. Seguire un elenco di controllo per la preparazione dell’area secondaria per un'interruzione regionale.
Ripristinare database all'interno della stessa area di Azure
È possibile usare backup di database automatici per riportare un database a un momento specifico nel passato. In questo modo, è possibile eseguire il ripristino da danneggiamenti dei dati causati da errori umani. Il ripristino temporizzato consente di creare un nuovo database nello stesso server che rappresenta lo stato dei dati prima dell'evento di danneggiamento. Nella maggior parte dei database, le operazioni di ripristino richiedono meno di 12 ore. Potrebbe essere necessario più tempo per ripristinare un database attivo o di dimensioni molto estese. Per altre informazioni, vedere Tempistiche di ripristino del database.
Se il periodo di conservazione massimo del backup supportato del ripristino temporizzato non è sufficiente per l'applicazione, è possibile estenderlo configurando i criteri di conservazione a lungo termine per il database. Per altre informazioni, vedere Conservazione dei backup a lungo termine.
Aggiornare un'applicazione con tempo di inattività minimo
A volte un'applicazione deve essere portata offline per ragioni di manutenzione pianificata, ad esempio un aggiornamento dell'applicazione. Gestione degli aggiornamenti dell'applicazione descrive come usare la replica geografica attiva per consentire gli aggiornamenti in sequenza dell'applicazione cloud al fine di ridurre al minimo i tempi di inattività durante gli aggiornamenti e fornire un percorso di recupero se si verificano problemi.
Risparmiare sui costi con repliche standby
Se la replica secondaria viene usata solo per il ripristino di emergenza e non dispone di carichi di lavoro di lettura o scrittura, è possibile risparmiare sui costi di licenza designando il database per lo standby quando si configura una nuova relazione di replica geografica attiva.
Per altre informazioni, vedere replica standby senza licenza.
Passaggi successivi
Per considerazioni sulla progettazione di applicazioni, vedere Progettare un'applicazione per il ripristino di emergenza cloud e Strategie di ripristino di emergenza del pool elastico.
Vedere Elenco di controllo per la disponibilità elevata e il ripristino di emergenza del database SQL di Azure e Guida al ripristino di emergenza del database SQL di Azure.