Pianificare il ripristino di emergenza (SharePoint Foundation 2010)
Si applica a: SharePoint Foundation 2010
Ultima modifica dell'argomento: 2016-11-30
In questo articolo vengono descritte le decisioni chiave per la scelta delle strategie di ripristino di emergenza per un ambiente Microsoft SharePoint Foundation 2010.
Contenuto dell'articolo:
Panoramica del ripristino di emergenza
Ai fini di questo articolo, si definisce ripristino di emergenza la capacità di recupero da una situazione di non disponibilità di un data center che ospita SharePoint Foundation.
La strategia di ripristino di emergenza utilizzata per SharePoint Foundation deve essere coordinata con quella dell'infrastruttura correlata, inclusi i domini Active Directory, Exchange Server e Microsoft SQL Server. Consultarsi con gli amministratori dell'infrastruttura su cui si basa il proprio ambiente per progettare una strategia e un piano di ripristino di emergenza coordinati.
Il tempo impiegato e le azioni immediate eseguite per rendere operativa un'altra farm in un'altra posizione vengono spesso indicati come hot, warm o cold standby. Di seguito viene riportata una definizione di questi termini:
Hot standby Secondo data center in grado di garantire disponibilità in pochi secondi o minuti.
Warm standby Secondo data center in grado di garantire disponibilità entro pochi minuti oppure ore.
Cold standby Secondo data center in grado di garantire disponibilità entro poche ore o giorni.
Il ripristino di emergenza può rappresentare uno dei requisiti più costosi di un sistema. Più è breve l'intervallo tra il guasto e la disponibilità e più è elevato il numero di sistemi da proteggere, più la soluzione di ripristino di emergenza sarà complessa e costosa. Quando si investe in data center con hot o warm standby, i costi includono:
Componenti hardware e software aggiuntivi, che spesso comportano una maggiore complessità delle operazioni tra applicazioni software, ad esempio script personalizzati per failover e ripristino.
Maggiore complessità operativa.
I costi di gestione di data center con hot o warm standby devono essere valutati in base alle esigenze aziendali. Non tutte le soluzioni di un'organizzazione devono necessariamente richiedere lo stesso livello di disponibilità dopo una situazione di emergenza. È possibile offrire livelli diversi di ripristino di emergenza per contenuto, servizi o farm diverse, ad esempio contenuto con forte impatto sull'azienda, servizi di ricerca oppure una farm di pubblicazione su Internet.
Il ripristino di emergenza è un'area chiave nella quale i gruppi IT offrono contratti di servizio che consentono di definire le aspettative insieme ai gruppi di clienti. Molte organizzazioni IT offrono una vasta gamma di contratti di servizio associati a diversi livelli di addebito.
Quando si implementa il failover tra server farm, è consigliabile distribuire e ottimizzare innanzitutto la soluzione di base in una farm e quindi implementare e testare il ripristino di emergenza.
Scegliere una strategia di ripristino di emergenza
È possibile scegliere tra diversi approcci per definire il ripristino di emergenza per un ambiente SharePoint Foundation, a seconda dei requisiti aziendali. Negli esempi riportati di seguito viene illustrato quando scegliere per un'azienda le strategie di ripristino di emergenza con cold, warm o hot standby.
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 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 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 al momento del 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 implementare per il proprio ambiente, esiste il rischio che si verifichi una perdita di dati.
Pianificazione di data center 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 Microsoft System Center Data Protection Manager 2007 che protegge i dati a livello di computer e consente di ripristinare ogni server singolarmente. In questo articolo non sono contenute istruzioni dettagliate per la creazione e il ripristino in scenari di cold standby. Per ulteriori informazioni, vedere:
Pianificazione di data center con warm standby
In uno scenario di ripristino di emergenza con warm standby è possibile implementare una soluzione di warm standby creando frequentemente immagini virtuali dei server della farm che vengono fornite a una posizione secondaria. In questa posizione secondaria è necessario disporre di un ambiente in cui sia possibile configurare e connettere facilmente le immagini per ricreare l'ambiente della farm.
In questo articolo non sono contenute istruzioni dettagliate per la creazione di soluzioni di warm standby. Per ulteriori informazioni su come pianificare la distribuzione di farm tramite soluzioni virtuali, vedere Effettuare la pianificazione per la virtualizzazione (SharePoint Foundation 2010).
Pianificazione di data center con hot standby
In uno scenario di ripristino di emergenza con hot standby è possibile configurare una farm di failover per garantire il ripristino di emergenza in un data center separato rispetto alla farm primaria. Vengono illustrate di seguito le caratteristiche di un ambiente con una farm di failover separata:
Nella farm di failover devono essere gestiti un database di configurazione e un database del contenuto di Amministrazione centrale separati.
In entrambe le farm devono essere distribuite tutte le personalizzazioni.
Nota
È consigliabile utilizzare una distribuzione tramite script per creare la farm primaria e di failover utilizzando le stesse impostazioni e personalizzazioni di configurazione.
Gli aggiornamenti devono essere applicati singolarmente a entrambe le farm.
I database del contenuto di SharePoint Foundation possono essere sottoposti a mirroring asincrono o log shipping nella farm di failover.
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.
Le applicazioni di servizio variano a seconda che sia possibile eseguirne il log shipping in una farm. Per ulteriori informazioni, vedere Service application redundancy across data centers più avanti in questo articolo.
Questa topologia può essere ripetuta in più data center, se si configura il log shipping di SQL Server in uno o più data center aggiuntivi.
Rivolgersi al fornitore della rete SAN per determinare se è possibile utilizzare la replica SAN o un altro meccanismo supportato per garantire la disponibilità nei data center.
Nella figura riportata di seguito vengono illustrate le farm primaria e di failover prima del failover.
Farm primaria e di failover prima del failover
.gif "Farm primarie e di failover prima del failover")
Ridondanza delle applicazioni di servizio nei data center
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 primario 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 condizioni seguenti:
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 o a mirroring asincrono.
L'applicazione di servizio può essere eseguita per database di sola lettura.
Nelle sezioni riportate di seguito vengono descritte le strategie di ripristino di emergenza consigliate per ogni applicazione di servizio. Le applicazioni di servizio sono raggruppate per strategia.
Database che possono essere sottoposti a log shipping o mirroring asincrono
Dopo che un'applicazione di servizio è stata inizialmente distribuita in una farm secondaria, i database che supportano le applicazioni di servizio seguenti possono essere sottoposti a mirroring asincrono o log shipping nelle farm:
Applicazione del servizio Registro applicazioni
Database: servizio Registro applicazioni
Applicazione del servizio di integrazione applicativa dei dati
Database: integrazione applicativa dei dati
Applicazione di servizio per raccolta dati di utilizzo e integrità
Database: registrazione
Nota
È possibile sottoporre a log shipping o a mirroring il database di registrazione. È consigliabile tuttavia non eseguire il servizio per la raccolta dati di utilizzo e integrità nella farm di ripristino di emergenza e non eseguire il mirroring o il log shipping del database di registrazione.
Applicazioni e database di servizio che non possono essere sottoposti a log shipping o a mirroring asincrono
Le applicazioni di servizio riportate di seguito devono essere distribuite nelle farm primaria e di failover e non possono essere sottoposte a log shipping o a mirroring asincrono. Per la maggior parte di queste applicazioni di servizio, è consigliabile effettuare la distribuzione e quindi verificare che la farm di failover disponga delle stesse impostazioni di configurazione della farm primaria. Se nella farm primaria vengono apportate modifiche di configurazione che hanno effetto sul servizio, sarà necessario aggiornare la farm di failover.
Applicazione servizio impostazioni di sottoscrizione di Microsoft SharePoint Foundation
Database: impostazioni di sottoscrizione
Nota
Il log shipping del database delle impostazioni di sottoscrizione non è supportato.
Requisiti di sistema per il ripristino di emergenza
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 utilizzi il sito di failover. I sistemi devono essere corrispondenti 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 Prodotti SharePoint 2010 e tutti gli aggiornamenti
Benché in questo articolo venga illustrata principalmente la disponibilità di Prodotti SharePoint 2010, anche gli altri componenti del sistema avranno effetto sul tempo di attività del sistema. Verificare in particolare quanto segue:
Controllare che le dipendenze dalle infrastrutture, ad esempio alimentazione, raffreddamento, rete, directory e SMTP, siano completamente ridondanti.
Scegliere un meccanismo di switch, che sia bilanciamento del carico hardware o DNS, che soddisfi le proprie esigenze.