Scegliere una strategia di ripristino di emergenza per SharePoint Server
SI APPLICA A:
2013 2016 2019 Subscription Edition 
SharePoint in Microsoft 365
Il ripristino di emergenza viene definito come la possibilità di eseguire il ripristino da una situazione in cui il data center primario che ospita una farm di SharePoint Server non è in grado di continuare a funzionare. Indipendentemente dalla natura dell'evento e dalla relativa causa, l'interruzione del data center è sufficientemente significativa da mettere in moto le azioni definite nel piano di ripristino di emergenza dell'organizzazione. Ciò significa inserire una farm completamente operativa nell'ambiente di produzione usando risorse computer che si trovano in un data center che non è interessato dall'evento.
SharePoint Server 2019, 2016, 2013 e i server SQL che li supportano forniscono opzioni di configurazione e ripristino del contenuto che possono soddisfare gli obiettivi RTO (Recovery Time Objective) e RPO (Recovery Point Objective) necessari per l'azienda 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, è consigliabile identificare e quantificare chiaramente l'RTO e l'RPO dell'organizzazione prima di sviluppare una strategia di ripristino e implementare una soluzione tecnica. Concentrarsi su ciò che è necessario, non su come farlo.
I costi dei tempi di inattività variano in modo significativo tra e all'interno dei settori, soprattutto a causa dei diversi effetti dei tempi di inattività. Le dimensioni dell'azienda sono il fattore più ovvio. Tuttavia, non è l'unico. L'impostazione di una misura significa stabilire la natura e le implicazioni del fallimento. Ridotto al livello più semplice, un errore di un'applicazione critica potrebbe causare 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 incorrerà in un costo di tempo di inattività da entrambi i tipi di perdita precedenti, ma la natura dell'azienda determinerà quale tipo di perdita ha l'effetto più grande. L'articolo seguente, scritto da Chris Preimesberger in eWEEK, evidenzia l'effetto finanziario del tempo di inattività del data center. I tempi di inattività IT non pianificati possono costare $ 5K al minuto: report.
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, ma ci si concentra sulle opzioni per assicurarsi che sia possibile ripristinare la farm di SharePoint Server 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.
Pros: Spesso l'opzione meno costosa da mantenere a livello operativo. È spesso un'opzione costosa da ripristinare, perché richiede di configurare correttamente i server fisici dopo una situazione di emergenza.
Cons: è l'opzione di ripristino più lenta.
Strategia di ripristino di emergenza di tipo warm standby con Azure Site Recovery.
Pros: È spesso ripristinabile con costi relativamente bassi, poiché una server farm virtuale può richiedere poche attività di configurazione dopo il ripristino.
Cons: 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.
Pros: È spesso ripristinabile in tempi relativamente rapidi.
Cons: 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 di cold standby, è possibile ripristinare una nuova farm in una nuova posizione (preferibilmente usando una distribuzione con script) e ripristinare i backup. In alternativa, è possibile ripristinare la farm usando una soluzione di backup, ad esempio System Center - Data Protection Manager (DPM). DPM protegge i dati a livello di sistema operativo del 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. Per altre informazioni, vedere Distribuzione di SharePoint Server con i gruppi di disponibilità Always On 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.
Consiglio
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 del database di SQL Server verrà rimossa nelle versioni future. È consigliabile evitare di usare questa funzionalità nelle nuove distribuzioni. Pianificare la modifica delle applicazioni che attualmente usano questa funzionalità. Usare invece i 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
[!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. È consigliabile rivolgersi al fornitore san per determinare se è possibile usare la replica SAN per i database SQL o un altro meccanismo supportato per fornire il livello di disponibilità hot standby tra i data center. Si noti che l'uso della replica SAN per i server SharePoint non è supportato.
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 fornire la disponibilità per la farm di servizi stessa, la strategia per fornire ridondanza tra i data center per un'applicazione di servizio varia. La strategia utilizzata dipende dal fatto che:
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.
Vedere anche
Concetti
Concetti relativi a ripristino di emergenza e disponibilità elevata in SharePoint Server
Altre risorse
Quali carichi di lavoro è possibile proteggere con Azure Site Recovery.?