Configurare il ripristino di emergenza per un'applicazione di SharePoint multilivello con Azure Site Recovery

Questo articolo descrive dettagliatamente come proteggere un'applicazione di SharePoint usando Azure Site Recovery.

Panoramica

Microsoft SharePoint è una potente applicazione che può aiutare un gruppo o un reparto a organizzare e condividere informazioni collaborando. SharePoint offre portali Intranet, gestione di documenti e file, collaborazione, social network, reti Extranet, siti Web, ricerca di livello aziendale e business intelligence. Include inoltre funzionalità di integrazione dei sistemi, integrazione dei processi e automazione dei flussi di lavoro. In genere, le organizzazioni considerano SharePoint un'applicazione di livello 1 sensibile al tempo di inattività e alla perdita dei dati.

Oggi Microsoft SharePoint non include funzionalità di ripristino di emergenza predefinite. Indipendentemente dal tipo e dall'entità di un evento di emergenza, il ripristino comporta l'uso di un data center di standby in cui ripristinare la farm. I data center di standby sono necessari per gli scenari in cui sistemi ridondanti locali e backup non sono in grado di eseguire il ripristino da interruzioni nel data center primario.

Una buona soluzione di ripristino di emergenza deve consentire la modellazione di piani di ripristino basati su architetture di applicazioni complesse, come SharePoint. Deve anche permettere di aggiungere passaggi personalizzati per gestire i mapping delle applicazioni tra diversi livelli e quindi fornire il failover con un solo clic e un RTO inferiore nel caso di un evento di emergenza.

Questo articolo descrive dettagliatamente come proteggere un'applicazione di SharePoint usando Azure Site Recovery. Questo articolo descrive le procedure consigliate per la replica di un'applicazione di SharePoint in Azure, l'esecuzione di un'esercitazione sul ripristino di emergenza e il failover dell'applicazione in Azure.

Prerequisiti

Prima di iniziare, è necessario comprendere i concetti illustrati di seguito:

1. Replica di una macchina virtuale in Azure
2. Come progettare una rete di ripristino
3. Esecuzione di un failover di test in Azure
4. Esecuzione di un failover in Azure
5. Come replicare un controller di dominio
6. Come replicare SQL Server

Architettura di SharePoint

SharePoint può essere distribuito in uno o più server usando topologie a livelli e ruoli del server per implementare una progettazione di farm in grado di soddisfare finalità e obiettivi specifici. Una tipica server farm di SharePoint con esigenze e dimensioni elevate che supporta molti utenti simultanei ed elementi di contenuto usa il raggruppamento dei servizi come parte della strategia di scalabilità. Questo approccio comporta l'esecuzione di servizi su server dedicati, il raggruppamento dei servizi e quindi la scalabilità orizzontale dei server come gruppi. La topologia seguente mostra il raggruppamento di servizi e server per una server farm di SharePoint a tre livelli. Per indicazioni dettagliate sulle diverse topologie di SharePoint, vedere la documentazione e le architetture delle linee di prodotti di SharePoint. Altre informazioni sulla distribuzione di SharePoint 2013 sono disponibili in questo documento.

Supporto di Site Recovery

Site Recovery è indipendente dall'applicazione e funziona con qualsiasi versione di SharePoint in esecuzione su un computer supportato. Ai fini di questo articolo sono state usate macchine virtuali VMware con Windows Server 2012 R2 Enterprise. Sono stati usati SharePoint 2013 Enterprise Edition e SQL Server 2014 Enterprise Edition.

Origine e destinazione

Scenario	In un sito secondario	In Azure
Hyper-V	Sì	Sì
VMware	Sì	Sì
Server fisico	Sì	Sì
Azure	N/D	Sì

Aspetti da considerare

Se si usa un cluster basato su dischi condivisi come qualsiasi livello nell'applicazione, non sarà possibile usare Site Recovery per eseguire la replica delle macchine virtuali. È possibile usare la replica nativa fornita dall'applicazione e quindi un piano di ripristino per eseguire il failover di tutti i livelli.

Replica di macchine virtuali

Seguire queste linee guida per avviare la replica delle macchine virtuali in Azure.

• Al termine della replica, in ogni macchina virtuale di ogni livello assicurarsi di selezionare lo stesso set di disponibilità in Elemento replicato>Impostazioni>Proprietà>Calcolo e rete. Ad esempio, se il livello Web include tre macchine virtuali, assicurarsi che le tre macchine virtuali siano tutte configurate per fare parte dello stesso set di disponibilità in Azure.

  

• Per le linee guida sulla protezione di Active Directory e DNS, fare riferimento al documento Proteggere Active Directory e DNS con Azure Site Recovery.

• Per le linee guida sulla protezione del livello database in esecuzione in SQL Server, fare riferimento al documento Proteggere SQL Server.

Configurazione della rete

Proprietà della rete

• Per le macchine virtuali di livello app e Web, configurare le impostazioni di rete nel portale di Azure in modo che le macchine virtuali siano collegate alla rete di ripristino di emergenza corretta dopo il failover.

  

• Se si usa un indirizzo IP statico, specificare l'indirizzo IP che dovrà essere usato dalla macchina virtuale nel campo Indirizzo IP di destinazione

  

DNS e routing del traffico

Per i siti con connessione Internet, creare un profilo di Gestione traffico di tipo "Priorità" nella sottoscrizione di Azure. Configurare quindi il DNS e il profilo di Gestione traffico nel modo seguente.

Where	Origine	Destinazione
DNS pubblico	DNS pubblico per siti di SharePoint Esempio: sharepoint.contoso.com	Gestione traffico contososharepoint.trafficmanager.net
DNS locale	sharepointonprem.contoso.com	IP pubblico nella farm locale

Nel profilo di Gestione traffico creare gli endpoint primario e di ripristino. Usare l'endpoint esterno per l'endpoint locale e l'indirizzo IP pubblico per l'endpoint di Azure. Assicurarsi che la priorità sia impostata come più alta per l'endpoint locale.

Ospitare una pagina di test su una porta specifica, ad esempio la porta 800, nel livello Web di SharePoint in modo che Gestione traffico possa rilevare automaticamente la disponibilità dopo il failover. Questa è una soluzione alternativa per i casi in cui non è possibile abilitare l'autenticazione anonima in uno dei siti di SharePoint.

Configurare il profilo di Gestione traffico con le impostazioni seguenti:

• Metodo di routing: "Priorità"
• Durata DNS: "30 secondi"
• Impostazioni di monitoraggio degli endpoint: se l'autenticazione anonima può essere abilitata, è possibile fornire l'endpoint di un sito Web specifico. In alternativa, è possibile usare una pagina di test su una porta specifica, ad esempio la porta 800.

Creazione di un piano di ripristino

Un piano di ripristino consente di definire la sequenza di failover di vari livelli in un'applicazione multilivello, conservando la coerenza dell'applicazione. Seguire la procedura descritta durante la creazione di un piano di ripristino per un'applicazione Web multilivello. Altre informazioni sulla creazione di un piano di ripristino.

Aggiunta di macchine virtuali a gruppi di failover

1. Creare un piano di ripristino aggiungendo le macchine virtuali di livello app e Web.

2. Fare clic su ‘Personalizza’ per raggruppare le macchine virtuali. Per impostazione predefinita tutte le macchine virtuali fanno parte del ‘Gruppo 1’.

   

3. Creare un altro gruppo (Gruppo 2) e spostare le macchine virtuali di livello Web nel nuovo gruppo. Le macchine virtuali di livello app devono fare parte del ‘Gruppo 1’, mentre le macchine virtuali di livello Web devono fare parte del ‘Gruppo 2’. In questo modo, le macchine virtuali di livello app vengono avviate per prime, seguite da quelle di livello Web.

Aggiunta di script al piano di ripristino

È possibile distribuire gli script di Azure Site Recovery usati più comunemente nell'account di Automazione facendo clic sul pulsante ‘Distribuisci in Azure’. Quando si usa qualsiasi script pubblicato, assicurarsi di seguire le istruzioni nello script.

1. Aggiungere uno script precedente all'azione al ‘Gruppo 1’ per il gruppo di disponibilità SQL. Usare lo script ASR-SQL-FailoverAG pubblicato negli script di esempio. Assicurarsi di seguire le istruzioni nello script e apportare le modifiche necessarie nello script nel modo appropriato.

   

   

2. Aggiungere uno script successivo all'azione per collegare un servizio di bilanciamento del carico nelle macchine virtuali sottoposte a failover di livello Web (Gruppo 2). Usare lo script ASR-AddSingleLoadBalancer pubblicato negli script di esempio. Assicurarsi di seguire le istruzioni nello script e apportare le modifiche necessarie nello script nel modo appropriato.

   

   

3. Aggiungere un passaggio manuale per aggiornare i record DNS perché puntino alla nuova farm in Azure.

   • Per i siti con connessione Internet, non è necessario alcun aggiornamento dei record DNS dopo il failover. Seguire i passaggi descritti nella sezione delle linee guida per le impostazioni di rete per configurare Gestione traffico. Se il profilo di Gestione traffico è stato configurato come descritto nella sezione precedente, aggiungere uno script per aprire una porta fittizia (porta 800 nell'esempio) nella macchina virtuale di Azure.

   • Per i siti interni, aggiungere un passaggio manuale per aggiornare il record DNS perché punti al nuovo indirizzo IP del servizio di bilanciamento del carico della macchina virtuale di livello Web.

4. Aggiungere un passaggio manuale per ripristinare l'applicazione di ricerca da un backup o avviare un nuovo servizio di ricerca.

5. Per il ripristino dell'applicazione del servizio di ricerca da un backup, seguire la procedura seguente:

   • Questo metodo presuppone che sia stato eseguito un backup dell'applicazione del servizio di ricerca prima dell'evento di emergenza e che il backup sia disponibile nel sito di ripristino di emergenza.
   • A questo scopo, è possibile pianificare in tutta semplicità il backup (ad esempio, una volta al giorno) e usare una procedura di copia per spostare il backup nel sito di ripristino di emergenza. Le procedure di copia possono includere programmi basati su script come AzCopy (Azure Copy) o la configurazione di DFSR (Distributed File Services Replication).
   • Quando la farm di SharePoint è in esecuzione, passare ad Amministrazione centrale, quindi a "Backup e ripristino" e selezionare Ripristina. Il ripristino interroga il percorso di backup specificato. Potrebbe essere necessario aggiornare il valore. Selezionare il backup dell'applicazione del servizio di ricerca che si vuole ripristinare.
   • La ricerca viene ripristinata. Tenere presente che l'operazione di ripristino si aspetta di trovare la stessa topologia, ovvero lo stesso numero di server, e le stesse lettere di unità assegnate ai server. Per altre informazioni, vedere il documento Ripristinare le applicazioni del servizio di ricerca in SharePoint 2013.

6. Per avviare il sistema con una nuova applicazione del servizio di ricerca, seguire i passaggi seguenti:

   • Questo metodo presuppone che nel sito di ripristino di emergenza sia disponibile un backup del database di amministrazione della ricerca.
   • Poiché gli altri database dell'applicazione del servizio di ricerca non vengono replicati, devono essere ricreati. A questo scopo, passare ad Amministrazione centrale ed eliminare l'applicazione del servizio di ricerca. Eliminare i file di indice in tutti i server che ospitano l'indice di ricerca.
   • Ricreare l'applicazione del servizio di ricerca perché vengano ricreati i database. È consigliabile aver preparato uno script che ricrea questa applicazione del servizio, perché non è possibile eseguire tutte le operazioni tramite l'interfaccia utente grafica. Ad esempio, l'impostazione del percorso dell'unità degli indici e la configurazione della topologia di ricerca sono possibili solo usando i cmdlet di PowerShell per SharePoint. Usare il cmdlet di Windows PowerShell Restore-SPEnterpriseSearchServiceApplication e specificare il database di amministrazione della ricerca Search_Service__DB fornito dal log e replicato. Questo cmdlet fornisce la configurazione, lo schema, le proprietà gestite, le regole e le origini della ricerca e crea un set predefinito degli altri componenti.
   • Una volta ricreata l'applicazione del servizio di ricerca, è necessario avviare una ricerca per indicizzazione completa per ogni origine di contenuto per ripristinare il servizio di ricerca. Verranno perse alcune informazioni di analisi dalla farm locale, ad esempio i suggerimenti per la ricerca.

7. Al termine di tutti i passaggi, salvare il piano di ripristino. Il piano di ripristino finale avrà un aspetto simile al seguente:

   

Esecuzione di un failover di test

Seguire queste linee guida per eseguire un failover di test.

1. Accedere al portale di Azure e selezionare l'insieme di credenziali di Servizi di ripristino.
2. Fare clic sul piano di ripristino creato per l'applicazione di SharePoint.
3. Selezionare Failover di test.
4. Selezionare il punto di recupero e la rete virtuale di Azure per avviare il processo di failover di test.
5. Quando l'ambiente secondario è disponibile, è possibile eseguire le convalide.
6. Al termine delle convalide, è possibile fare clic su "Pulizia failover di test" nel piano di ripristino perché l'ambiente di failover di test venga pulito.

Per le linee guida su come eseguire il failover di test per Active Directory e DNS, fare riferimento al documento Considerazioni sul failover di test per Active Directory e DNS.

Per le linee guida su come eseguire il failover di test per gruppi di disponibilità SQL AlwaysOn, fare riferimento al documento Esecuzione di un ripristino di emergenza delle applicazioni con Azure Site Recovery e processi di failover di test.

Esecuzione di un failover

Seguire queste linee guida per eseguire un failover.

1. Accedere al portale di Azure e selezionare l'insieme di credenziali di Servizi di ripristino.
2. Fare clic sul piano di ripristino creato per l'applicazione di SharePoint.
3. Fare clic su 'Failover'.
4. Selezionare il punto di recupero per avviare il processo di failover.

Passaggi successivi

Altre informazioni sulla replica di altre applicazioni con Site Recovery.