Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Scenari di disaster recovery
Questa sezione fornisce esempi di errori in una singola zona o AWS regione di disponibilità e illustra le opzioni per il disaster recovery (DR). Gli esempi presuppongono un Recovery Point Objective (RPO) di 15 minuti e un Recovery Time Objective (RTO) di 4 ore.
Errore nella zona di disponibilità
È possibile utilizzare una delle seguenti opzioni per il ripristino da un singolo errore della zona di disponibilità entro i parametri specificati (RPO di 15 minuti, RTO di 4 ore).
-
Effettua il ripristino dell'applicazione utilizzando il backup di immagini Amazon Elastic Compute Cloud (Amazon EC2) più recente e connettiti all'istanza di database Warm Standby esistente tramite una distribuzione di gruppo di disponibilità Always On o la spedizione di log.
-
Una configurazione del gruppo di disponibilità Always On di SQL Server per DR con due o più nodi fornisce il failover automatico sul nodo secondario tramite la modalità di commit sincrono o di commit asincrono, in modo che il database sia immediatamente disponibile. Per una configurazione HA, entrambi i nodi sono disponibili per le operazioni di lettura. Questa opzione soddisfa perfettamente i requisiti RTO e RPO. Nell'edizione SQL Server Standard, è possibile utilizzare anche i gruppi di disponibilità di base, ma è limitato a due nodi, poiché un gruppo di disponibilità può includere solo un database. Tuttavia, è possibile configurare più gruppi di disponibilità all'interno di una regione o tra più regioni. Questa configurazione consente di risparmiare sui costi, poiché non vi è alcun costo aggiuntivo per il nodo secondario, che non è accessibile per le operazioni di lettura. L'edizione SQL Server Enterprise offre funzionalità complete e failover per tutti i database all'interno di un singolo gruppo di disponibilità. Per esempi di questa opzione, vedere i seguenti diagrammi di architettura:
-
La spedizione dei log di SQL Server come soluzione DR richiede un failover manuale su un server di standby e dipende dalla frequenza dei backup dei log. Questa è una delle opzioni di DR meno costose. Non è necessario che le edizioni di SQL Server per il sito DR principale e il sito DR fornito con log corrispondano. Questa opzione soddisfa l'RPO (utilizzando backup del registro delle transazioni ogni 5 minuti) e l'RTO, ma richiede la manutenzione tramite script manuali e personalizzati. Per un esempio di questa opzione, consultate il seguente diagramma di architettura:
-
-
Se si dispone di un'applicazione come un'applicazione SQL Server Reporting Services (SSRS) con una distribuzione scalabile, il load balancer può reindirizzare tutto il traffico verso il nodo secondario.
-
Puoi utilizzare Amazon EC2 base AMIs per l'applicazione e il server di database per il provisioning dell'infrastruttura. I database possono essere ripristinati in una nuova zona di disponibilità, a seconda delle dimensioni e della frequenza di backup, dai backup nativi più recenti (backup completo, backup differenziale o backup del registro delle transazioni ogni 5 minuti) o utilizzando le istantanee EBS. Questa opzione soddisfa i requisiti RPO e RTO ma richiede uno script personalizzato. È inoltre necessario considerare il tempo necessario per il provisioning dell'infrastruttura e soddisfare i requisiti RPO e RTO può essere difficile.
-
EC2 Le immagini Amazon (inclusi i volumi EBS) per entrambe le applicazioni e il server di database possono essere ripristinate in una nuova zona di disponibilità. L'RPO può essere impegnativo, a seconda del backup più recente, ma questa opzione può essere combinata con i log delle transazioni più recenti per soddisfare i requisiti. Questa opzione supporta le istantanee di Windows Volume Shadow Copy Service (VSS).
Errore nella regione
È possibile utilizzare una delle seguenti opzioni per il ripristino da un errore in una singola AWS regione entro i parametri specificati (RPO di 15 minuti, RTO di 4 ore).
-
Puoi utilizzare Amazon Machine Images (AMIs) di EC2 base su Amazon per l'applicazione e il server di database per il provisioning dell'infrastruttura. I database possono essere ripristinati in una nuova regione, a seconda delle dimensioni e della frequenza di backup, dai backup nativi più recenti (backup completo, backup differenziale o backup del registro delle transazioni ogni 5 minuti). Questa opzione soddisfa i requisiti RPO e RTO ma richiede uno script personalizzato.
-
La spedizione dei log di SQL Server come soluzione DR richiede un failover manuale su un server di standby e dipende dalla frequenza dei backup dei log. Questa è una delle opzioni di DR meno costose. Non è necessario che le edizioni di SQL Server per il sito DR principale e il sito DR fornito con log corrispondano. Questa opzione soddisfa l'RPO (utilizzando i backup del registro delle transazioni ogni 5 minuti) e l'RTO, ma richiede la manutenzione tramite script manuali e personalizzati. I database di grandi dimensioni richiedono tempi di ripristino lunghi.
-
-
Puoi utilizzare un' EC2 AMI Amazon sia per l'applicazione che per il server di database e ripristinarla su una destinazione in una nuova regione. L'RPO dipende dalla dimensione e dalla frequenza dei backup.
-
Le immagini più recenti delle applicazioni possono essere ripristinate utilizzando un'AMI. È possibile utilizzare i backup nativi recenti del registro differenziale o delle transazioni ogni 5 minuti per aggiornare il database in modo da soddisfare l'RPO.
-
L'RTO dipende dalla dimensione e dal tempo di trasferimento e ripristino delle istantanee nella nuova regione, se l'origine non è già sincronizzata con la destinazione.
-
-
La soluzione con il minor tempo di inattività consiste nel ripristinare l'immagine di backup dell'applicazione e disporre di un nodo SQL Server in standby caldo in una regione remota utilizzando una configurazione del gruppo di disponibilità a due, tre o quattro nodi (di base, classica o distribuita) e connettersi al server del database in standby dopo un failover. La replica in modalità commit sincrona soddisfa i requisiti RPO, mentre la replica in modalità commit asincrona potrebbe subire ritardi a seconda del volume delle transazioni. È possibile utilizzare una configurazione di gruppi di disponibilità distribuiti per scalare i nodi del database in una nuova regione, se necessario. Questa configurazione riduce anche la complessità perché utilizza due gruppi di disponibilità indipendenti anziché un singolo gruppo di disponibilità distribuito tra le regioni in modalità di commit sincrono o di commit asincrono e soddisfa perfettamente i requisiti RTO e RPO. In alternativa, è possibile utilizzare anche i gruppi di disponibilità di base di SQL Server nell'edizione Standard. Tuttavia, presenta delle limitazioni perché supporta solo fino a due nodi e solo un database può appartenere a un singolo gruppo di disponibilità, sebbene siano supportati più gruppi di disponibilità. È possibile configurare l'edizione SQL Server Standard all'interno di una o più regioni. Questa edizione offre risparmi sui costi perché non prevede costi per il nodo secondario, che non è accessibile per le operazioni di lettura. L'edizione SQL Server Enterprise offre funzionalità complete e supporta il failover di tutti i database come failover di un singolo gruppo di disponibilità.
Casi di utilizzo comune
Come esercizio di dimensionamento, l'80% delle applicazioni SQL Server in esecuzione su Amazon EC2 con un normale carico di lavoro OLTP (Online Transaction Processing) può essere raggruppato in una delle tre categorie in base alla loro importanza:
-
Backup di SQL Server HA/DR con SQL Server, utilizzando due repliche con commit sincrono e una replica in modalità commit asincrona
-
AWS Backup HA/DR con backup di SQL Server, utilizzando un' EC2 AMI Amazon sia per l'applicazione che per il database e storage Amazon EBS
-
AWS Backup HA/DR con backup di SQL Server, utilizzando un' EC2 AMI di base Amazon per il server di database, un' EC2 immagine Amazon per l'applicazione e istantanee Amazon EBS
La tabella seguente fornisce dettagli su ciascuna categoria.
| SQL Server HA/ DR con backup di SQL Server | AWS Backup HA/DR con AMIs storage EBS e backup di SQL Server | AWS Backup HA/DR con AMIs, istantanee EBS e backup di SQL Server | |
|---|---|---|---|
Processo di ripristino in caso di emergenza |
|
|
|
Risorse primarie |
|
|
|
HA/DR |
Offre HA e DR |
Offre solo DR |
Offre solo DR |
RPO |
Il failover è gestito dal gruppo di disponibilità di SQL Server (il DR è manuale) |
Con script manuale o personalizzato |
Con script manuale o personalizzato |
RTO |
Da secondi a minuti |
Da minuti a ore |
Più ore |
Rischio di scomparsa SLAs |
Bassa |
Media |
Elevata |
Gestibilità |
Semplice |
Media |
Media |
Dimensionamento |
Semplice |
Media |
Media |
Limiti alle dimensioni dei file per i caricamenti su Amazon S3 o il trasferimento tra regioni |
N/A: gestito in modalità di commit sincrono o in modalità di commit asincrono in modalità standby a caldo |
Sì |
Sì |
Perdita di dati |
Quasi zero (dipende dal carico di lavoro e dall'infrastruttura predisposta) |
Dipende dalla frequenza delle immagini di EC2 backup di Amazon e dei backup di SQL Server |
Dipende dalla frequenza delle immagini di EC2 backup di Amazon o degli snapshot EBS e dei backup di SQL Server |
Costo |
Media |
Basso — medio |
Basso — medio |
