Scegliere una strategia di ripristino di emergenza per SharePoint Server
**Si applica a:**SharePoint Foundation 2013, SharePoint Server 2013, SharePoint Server 2016
**Ultima modifica dell'argomento:**2018-03-09
Sintesi: informazioni sulle opzioni di ripristino di emergenza e sulle tecnologie supportate per il ripristino di una farm di SharePoint Server 2016 e SharePoint 2013 in caso di emergenza.
Il ripristino di emergenza è la capacità di ripristino da una situazione in cui il data center principale che ospita una farm di SharePoint Server non è in grado di continuare a funzionare. Indipendentemente dalla natura e dalla causa dell'evento, l'interruzione del funzionamento del data center è sufficientemente significativa da attivare le azioni definite nel piano di ripristino di emergenza dell'organizzazione, che comportano l'attivazione di una farm completamente funzionante che utilizza le risorse dei computer contenute in un data center non coinvolto dall'evento.
Contenuto dell'articolo:
Introduzione
Opzioni di ripristino per data center di standby
Requisiti di sistema per il ripristino
In SharePoint Server 2016 e SQL Server 2014 con Service Pack 1 (SP1) o SQL Server 2016, SharePoint 2013 e SQL Server 2008 R2 con Service Pack 1 (SP1) o SQL Server 2012 sono disponibili opzioni di ripristino della configurazione e del contenuto in grado di soddisfare gli obiettivi in termini di tempo di ripristino (RTO, Recovery Time Objective) e di punto di ripristino (RPO; Recovery Point Objective) richiesti per la propria organizzazione in caso di emergenza. Per ulteriori informazioni su questi e altri concetti di ripristino di emergenza, vedere Concetti relativi a ripristino di emergenza e disponibilità elevata in SharePoint Server.
Introduzione
Una strategia di ripristino di emergenza efficace per una farm di SharePoint Server deve essere in grado di soddisfare i requisiti aziendali dell'organizzazione, generalmente espressi utilizzando due misure, ovvero l'obiettivo in termini di tempo di ripristino (RTO, Recovery Time Objective) e l'obiettivo in termini di punto di ripristino (RPO; Recovery Point Objective). I requisiti RTO e RPO vengono ricavati determinando il costo del tempo di inattività dell'organizzazione in caso di emergenza.
Importante
Come procedura consigliata, è opportuno identificare e quantificare in modo chiaro gli obiettivi RTO e RPO dell'organizzazione prima di sviluppare una strategia di ripristino e implementare una soluzione tecnica, concentrandosi sui requisiti e non sulle operazioni da eseguire.
I costi relativi al tempo di inattività variano in modo significativo a seconda dei settori e delle organizzazioni, soprattutto a causa dei diversi effetti prodotti dal tempo di inattività. Le dimensioni delle organizzazioni rappresentano uno dei fattori più importanti. La definizione di una misura comporta l'indicazione della natura e delle implicazioni dell'errore. Semplificando al massimo, un errore di un'applicazione critica può comportare i seguenti tipi di perdite:
Perdita del servizio dell'applicazione. L'effetto del tempo di inattività varia a seconda dell'applicazione e dell'organizzazione.
Perdita di dati. La perdita potenziale di dati a causa di un'interruzione del funzionamento del sistema può avere un impatto legale e finanziario significativo.
La maggior parte delle organizzazioni sarò soggetta a un costo relativo al tempo di inattività per entrambi i tipi precedenti di perdite, ma la natura dell'organizzazione determinerà il tipo di perdita che avrà un impatto maggiore. Il seguente articolo relativo al report sul tempo di inattività IT non pianificato che può costare 5000 dollari al minuto, scritto da Chris Preimesberger su eWEEK, evidenzia l'effetto economico del tempo di inattività di un data center.
Nella maggior parte degli scenari i Prodotti SharePoint rappresentano una delle diverse applicazioni che devono essere ripristinate in caso di arresto di un data center per una situazione di emergenza. Per questo motivo non sono state incluse informazioni sulla pianificazione del ripristino di emergenza preferendo illustrare le opzioni per garantire il ripristino di una farm di SharePoint Server 2016 in un'altra posizione.
Indipendentemente dal tipo e dall'entità di una situazione di emergenza, il ripristino prevede l'utilizzo di un data center di standby in cui ripristinare la farm.
Opzioni di ripristino per data center di standby
I data center di standby sono necessari per gli scenari in cui sistemi ridondanti locali e backup non possono eseguire il ripristino dall'interruzione nel data center principale. Il tempo impiegato e le azioni immediate eseguite per rendere operativa una farm sostitutiva in un'altra posizione vengono spesso indicati come hot, warm o cold standby. Di seguito viene riportata una definizione di questi termini:
Cold standby. Data center secondario in grado di garantire disponibilità entro poche ore o giorni.
Warm standby. Data center secondario in grado di garantire disponibilità entro pochi minuti oppure ore.
Hot standby. Data center secondario in grado di garantire disponibilità in pochi secondi o minuti.
Ognuno di questi data center di standby ha caratteristiche e requisiti specifici e un costo operativo e di gestione associato.
Strategia di ripristino di emergenza con cold standby: un'azienda fornisce backup per supportare il ripristino bare metal in archivi fuori sede locali e internazionali a intervalli regolari e ha stipulato contratti sul posto per il noleggio di server di emergenza in un'altra area.
Vantaggi:
È spesso l'opzione meno costosa da gestire da un punto di vista operativo.
È spesso un'opzione costosa da ripristinare, perché richiede di configurare correttamente i server fisici dopo una situazione di emergenza.
Svantaggi: è l'opzione di ripristino più lenta.
Strategia di ripristino di emergenza con warm standby: un'azienda fornisce backup o immagini server virtuali per farm di ripristino di emergenza locali e internazionali.
Vantaggi: è spesso ripristinabile con costi relativamente bassi, poiché una server farm virtuale può richiedere poche attività di configurazione dopo il ripristino.
Svantaggi: può essere molto costosa e richiedere molte risorse per la gestione.
Strategia di ripristino di emergenza con hot standby: un'azienda esegue più data center, ma fornisce contenuto e servizi attraverso un solo data center.
Vantaggi: è spesso ripristinabile in tempi relativamente rapidi.
Svantaggi: può essere piuttosto costosa da configurare e gestire.
Importante
Indipendentemente dalla soluzione di ripristino di emergenza che si sceglie di applicare tra quelle descritte precedentemente, esiste il rischio che si verifichi una perdita di dati.
Ripristino con cold standby
In uno scenario di ripristino di emergenza con cold standby è possibile effettuare il ripristino configurando una nuova farm in una nuova posizione (possibilmente con una distribuzione tramite script) e ripristinando i backup. In alternativa, è possibile procedere ripristinando una farm da una soluzione di backup, ad esempio System Center 2016 - Data Protection Manager (DPM) o System Center 2012 - Data Protection Manager (DPM). System Center Data Protection Manager protegge i dati a livello di sistema operativo dei computer e consente di ripristinare ogni server singolarmente. Questo articolo non include istruzioni dettagliate per la creazione e il ripristino in scenari di cold standby. Per ulteriori informazioni, vedere:
Ripristino con warm standby
In uno scenario di ripristino di emergenza con warm standby è possibile implementare un ambiente con warm standby creando una farm duplicata nel data center alternativo e fare in modo che venga aggiornata regolarmente utilizzando backup completi e incrementali della farm primaria.
Ambienti con warm standby virtuali
La virtualizzazione rappresenta un'opzione utile e poco costosa per una soluzione di ripristino con warm standby. Per fornire l'infrastruttura necessaria per il ripristino, è possibile utilizzare Hyper-V come soluzione interna oppure Azure come soluzione ospitata.
È possibile creare immagini virtuali dei server di produzione e fornirle al data center di standby. Utilizzando la soluzione con standby virtuale, è necessario che le immagini virtuali vengano create abbastanza frequentemente, in modo che per il ripristino della farm vengano forniti contenuto e configurazioni aggiornati. Nella posizione secondaria è necessario disporre di un ambiente in cui sia possibile configurare e connettere facilmente le immagini per ricreare l'ambiente della farm. Per ulteriori informazioni, vedere Distribuzione di SharePoint Server 2016 con gruppi di disponibilità AlwaysOn di SQL Server in Azure
Ripristino con hot standby
In uno scenario di ripristino di emergenza con hot standby è possibile configurare una farm di failover nel data center di standby in modo che possa subentrare quasi immediatamente in caso di disconnessione della farm primaria. Un ambiente con una farm di failover separata deve avere le seguenti caratteristiche:
Nella farm di failover devono essere gestiti un database di configurazione e un database del contenuto separati per il sito Web Amministrazione centrale SharePoint.
In entrambe le farm devono essere distribuite tutte le personalizzazioni.
Suggerimento
Per garantire uniformità tra le due farm e ridurre la possibilità di errore, è consigliabile utilizzare una distribuzione tramite script per creare la farm primaria e la farm di failover utilizzando le stesse impostazioni di configurazione e personalizzazioni.
Gli aggiornamenti del sistema operativo e gli aggiornamenti software di SQL Server e dei SharePoint Server devono essere applicati a entrambe le farm per garantire una configurazione uniforme.
È possibile copiare i database del contenuto dei SharePoint Server nella farm di failover utilizzando il mirroring asincrono, il commit asincrono in una replica del gruppo di disponibilità o il log shipping.
Nota
Il mirroring di SQL Server può essere utilizzato solo per copiare i database in un singolo server mirror, mentre il log shipping può essere effettuato in più server secondari.
La funzionalità di mirroring di database di SQL Server verrà eliminata nelle versioni future. Se ne sconsiglia l'utilizzo nell'implementazione di nuove distribuzioni. Per le applicazioni che attualmente utilizzano questa funzionalità, è opportuno pianificare il passaggio ai gruppi di disponibilità AlwaysOn.Le applicazioni di servizio variano a seconda che sia possibile eseguirne il log shipping in una farm. Per ulteriori informazioni, vedere Ridondanza delle applicazioni di servizio più avanti in questo articolo.
La topologia di farm con hot standby può essere ripetuta in più data center, se si configura il log shipping di SQL Server in uno o più data center aggiuntivi.
Importante
La larghezza di banda di rete disponibile e la latenza sono aspetti importanti di cui tenere conto quando si utilizza un metodo di failover per il ripristino di emergenza.
Rivolgersi al fornitore della rete SAN per determinare se è possibile utilizzare la replica SAN o un altro meccanismo supportato per garantire il livello di disponibilità con hot standby nei data center.
Ridondanza delle applicazioni di servizio
Per garantire la disponibilità nei data center per le applicazioni di servizio, è consigliabile utilizzare per i servizi che possono essere eseguiti tra le farm una farm di servizi separata accessibile sia dal data center principale che da quello secondario.
Per i servizi che non possono essere eseguiti tra farm e per garantire la disponibilità per la farm di servizi stessa, la strategia per la ridondanza di un'applicazione di servizio tra data center varia a seconda che sussistano le seguenti condizioni:
L'esecuzione dell'applicazione di servizio nella farm di ripristino di emergenza quando non è in uso rappresenta un valore aggiunto per l'azienda.
I database associati all'applicazione di servizio possono essere sottoposti a log shipping, a mirroring asincrono o a replica tramite commit asincrono.
L'applicazione di servizio può essere eseguita per database di sola lettura.
Leggere l'articolo Opzioni di disponibilità elevata e di ripristino di emergenza supportate per database di SharePoint prima di progettare una soluzione di ripristino di emergenza basata su un data center con warm o hot standby.
Requisiti di sistema per il ripristino
In uno scenario ideale i componenti e i sistemi di failover corrispondono ai componenti e ai sistemi primari in tutti gli aspetti: piattaforma, hardware e numero di server. Come minimo, l'ambiente di failover deve essere in grado di gestire il traffico previsto durante un failover. Tenere presente che è probabile che solo un sottoinsieme di utenti debba utilizzare il sito di failover. I sistemi devono corrispondere almeno per gli aspetti riportati di seguito:
Versione del sistema operativo e tutti gli aggiornamenti
Versioni di SQL Server e tutti gli aggiornamenti
Versioni di SharePoint Server e tutti gli aggiornamenti
Oltre ai requisiti precedenti, il tempo di ripristino di una farm sarà determinato anche dalla disponibilità delle strutture e dei componenti dell'infrastruttura. Verificare che vengano soddisfatti i seguenti requisiti:
Controllare che l'alimentazione, il raffreddamento, la rete, le directory e SMTP siano completamente ridondanti.
Scegliere un meccanismo di switch, che sia bilanciamento del carico hardware o DNS, in grado di soddisfare le proprie esigenze.
See also
Concetti relativi a ripristino di emergenza e disponibilità elevata in SharePoint Server