Configurare il ripristino di emergenza nelle farm di SharePoint utilizzando il log shipping di SQL Server

In questo articolo viene descritto come utilizzare il processo di log shipping di Microsoft SQL Server 2005 o Microsoft SQL Server 2008 per creare una farm di ripristino di emergenza in un data center distribuito su un'ampia area geografica per Microsoft Office SharePoint Server 2007 con Service Pack 2 (SP2). Utilizzando questa configurazione è possibile implementare un sito di ripristino di emergenza in grado di offrire i risultati della ricerca corrente in caso di failover. In questo articolo si presuppone la familiarità con i concetti e i termini presentati in Pianificare l'ambiente per la disponibilità (Office SharePoint Server).

Sono spesso necessari molti team e ruoli di un'organizzazione per creare e configurare un data center e una farm secondari. Per poter configurare e verificare un ambiente secondario, è necessario consultarsi con gli amministratori dei provider di autenticazione, con gli amministratori dei database SQL Server e con gli amministratori di tutte le farm SharePoint coinvolte. Questo articolo ha lo scopo principale di assistere gli amministratori della farm di SharePoint nell'esecuzione delle operazioni seguenti:

• Comprendere i requisiti per la creazione di farm di ripristino di emergenza per cui eseguire il log shipping

• Impostare ambienti di prova per cui eseguire il log shipping

• Concordare con gli amministratori dei database SQL Server chi configurerà il log shipping per gli ambienti di produzione.

Sezioni dell'articolo:

• Introduzione al log shipping

• Panoramica di Office SharePoint Server e del log shipping

• Requisiti per il data center e la farm secondari

• Configurazione dell'ambiente di log shipping

• Failover

• Considerazioni per il test del failover

• Riconfigurare il log shipping o il failback

• Riepilogo

Introduzione al log shipping

Mediante il log shipping è possibile configurare SQL Server affinché invii costantemente backup dei registri delle transazioni da un database primario in un'istanza del server primario a uno o più database secondari in istanze diverse del server secondario. I backup dei registri delle transazioni vengono applicati singolarmente a ogni database secondario. Il backup continuo dei registri delle transazioni da un database primario e successivamente la copia e il ripristino dei registri in un database secondario consentono di mantenere il database secondario sincronizzato con il database primario. Il log shipping può anche includere una terza istanza facoltativa del server, ovvero il server di monitoraggio, che registra la cronologia e lo stato delle operazioni di backup e ripristino, e genera avvisi se tali operazioni non vengono eseguite come previsto.

Il log shipping si basa su tre processi e ognuno di essi esegue le operazioni seguenti:

1. Backup del registro transazioni nell'istanza del server primario

2. Copia del file del registro transazioni nell'istanza del server secondario

3. Ripristino del backup del registro nell'istanza del server secondario

Nel diagramma seguente è illustrato il log shipping.

Per ulteriori informazioni, vedere l'articolo della documentazione in linea di SQL Server Log shipping (https://go.microsoft.com/fwlink/?linkid=151252&clcid=0x410).

Panoramica di SharePoint Server e del log shipping

Il log shipping di SQL Server può essere utilizzato per inviare i database del contenuto, inclusi i database dei siti personali, e i database SSO da una farm che esegue Office SharePoint Server 2007 con SP2 a una o più farm secondarie distribuite su una vasta area geografica.

Importante

Sebbene sia possibile configurare il log shipping su una versione diversa da Office SharePoint Server 2007 con SP2, è consigliabile utilizzare Office SharePoint Server 2007 con SP2 poiché offre i vantaggi seguenti:

• Quando si attiva la modalità non in linea per un database del contenuto, anche per le raccolte siti associate a tale database viene attivata la stessa modalità e l'interfaccia utente viene modificata per rimuovere le attività che richiedono modifiche al database.

• Durante le ricerche, i database del contenuto che sono stati scollegati e ricollegati alla stessa applicazione Web in Office SharePoint Server 2007 con SP2 vengono considerati come origini dati note e vengono eseguite indicizzazioni incrementali, anziché indicizzazioni complete. Questo aspetto è importante poiché negli ambienti per cui viene eseguito il log shipping è consigliabile scollegare e ricollegare i database del contenuto alla farm secondaria per aggiornare il database di configurazione nella farm secondaria in modo che possa riconoscere le raccolte siti nuove o rimosse. La nuova capacità di eseguire indicizzazioni incrementali dopo aver ricollegato un database riduce nettamente i tempi di indicizzazione e migliora l'attualità della ricerca.

Utilizzi delle farm secondarie

In genere si presuppone che lo scopo principale di una farm secondaria sia essenzialmente il ripristino di emergenza. Se tuttavia si crea una farm secondaria che esegue Office SharePoint Server 2007 con SP2, è possibile esporre i siti nella farm secondaria per cui è stato eseguito il log shipping agli utenti. È possibile scegliere se distribuire un file degli host che rimandi ai siti nella farm secondaria oppure se definire un mapping di accesso alternativo dedicato per ogni applicazione Web nella farm secondaria che si desidera esporre con uno spazio dei nomi secondario, ad esempio http://secondario.contoso.com o http://solalettura.contoso.com. I siti esposti non offriranno funzionalità di scrittura agli utenti. Questo articolo si basa sul presupposto che sia in esecuzione Office SharePoint Server 2007 con SP2. Per ulteriori informazioni, vedere Eseguire una farm che utilizza database di sola lettura (Office SharePoint Server).

Nota

Se si crea una farm secondaria che non esegue Office SharePoint Server 2007 con SP2, è consigliabile non esporre alcun sito agli utenti. Le farm per cui è stato eseguito il log shipping in cui non è installato Office SharePoint Server 2007 con SP2 sono di sola lettura, tuttavia non inviano avvisi chiari agli utenti che tentano di scrivere dati nel sito. Per ulteriori informazioni sui problemi legati all'utilizzo di Office SharePoint Server con un database del contenuto di sola lettura, vedere l'articolo della Knowledge Base: Utilizzo di Microsoft Windows SharePoint Services con un database del contenuto configurato in sola lettura in Microsoft SQL Server (https://go.microsoft.com/fwlink/?linkid=117362&clcid=0x410).

Topologia del log shipping

Nel diagramma seguente è illustrato uno scenario con due data center e due farm configurate per l'utilizzo del log shipping. In questo scenario, il data center di ripristino di emergenza ospita una farm secondaria di sola lettura.

Sono presenti due farm logiche, una in ogni data center. Ogni farm rappresenta un'installazione diversa, con configurazioni e database del contenuto amministrativo diversi e diversi provider di servizi condivisi. Viene eseguito il log shipping solo dei database del contenuto e del database SSO dal data center primario al data center secondario. SSP A gestisce la ricerca nella farm primaria e SSP B gestisce la ricerca nella farm secondaria. Viene eseguito uno script di aggiornamento del database di configurazione (C) nella farm secondaria. Come è illustrato nel diagramma, è importante coordinare i tempi dei tre processi nell'ambiente secondario in modo che non si sovrappongano:

1. Elaborazione dei database per cui è stato eseguito il log shipping

2. Ricerca per indicizzazione

3. Configurazione dello script di aggiornamento del database

Questa topologia può essere ripetuta fra molti data center, se si configura il log shipping di SQL Server in uno o più data center aggiuntivi.

Considerazioni generali sul log shipping in Office SharePoint Server

In questa sezione sono descritte le limitazioni all'utilizzo del shipping in Office SharePoint Server 2007 con SP2.

• Per impostazione predefinita, il processo di failover per il log shipping è manuale. È tuttavia possibile creare script per automatizzare il failover.

• In caso di failover non pianificato, è possibile che si verifichi la perdita di dati, in base alla frequenza di log shipping e al momento in cui si è verificato il problema. È possibile perdere i dati dall'ultimo intervallo di log shipping prima del problema.

• Non è possibile eseguire il log shipping del database di configurazione in un'altra farm in quanto contiene informazioni specifiche dei clienti. È pertanto necessario mantenere manualmente le stesse personalizzazioni e impostazioni di configurazione in entrambe le farm.

• Non è possibile eseguire in modo efficace il log shipping del database di ricerca nella farm secondaria poiché è necessario che il database di ricerca, il file di indice e il database del provider di servizi condivisi siano sincronizzati. Per garantire la disponibilità della ricerca in una farm di failover con database per cui è stato eseguito il log shipping, è possibile utilizzare le soluzioni seguenti:

  • Configurare ed eseguire un provider di servizi condivisi per offrire le funzionalità di ricerca nella farm di failover. Questa soluzione può implementare la disponibilità della ricerca non appena la farm secondaria sia attiva e correttamente in esecuzione, ed è adatta a volumi elevati. In questo articolo è illustrato come configurare ed eseguire un provider di servizi condivisi di ricerca nella farm di failover.

  • Ripristinare il provider di servizi condivisi dalla farm primaria nella farm di failover utilizzando le caratteristiche di backup e ripristino incorporate in SharePoint. Questa soluzione offre la disponibilità della ricerca dopo il ripristino del provider di servizi condivisi e dopo che la ricerca ha indicizzato di nuovo il contenuto. Se l'intervallo richiesto per ripristinare il provider di servizi condivisi rientra nei tempi di ripristino prestabiliti per la farm, è consigliabile utilizzare questa soluzione. Questa soluzione non verrà descritta in dettaglio nel presente articolo. Per ulteriori informazioni sul backup e il ripristino del provider di servizi condivisi di ricerca, vedere Eseguire il backup e il ripristino dei provider di servizi condivisi (Office SharePoint Server 2007).

• Se si esegue il servizio profili nella farm primaria, è consigliabile configurare il provider di servizi condivisi nella farm secondaria affinché esegua tale servizio. Per mantenere sincronizzati i profili in tutti i provider di servizi condivisi, è necessario utilizzare il motore di replica dei profili utente incluso nella versione a 32 bit del Toolkit di amministrazione Microsoft SharePoint x86(informazioni in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=151962&clcid=0x410) o nella versione a 64 bit del Toolkit di amministrazione di Microsoft SharePoint x64(informazioni in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=142035&clcid=0x410). Per ulteriori informazioni, vedere Motore di replica dei profili utente (Office SharePoint Server).

• Non è consigliabile eseguire il log shipping di database diversi dai database del contenuto e dai database SSO, ad esempio i database Microsoft Office Project Server 2007. Per i database non menzionati in precedenza, è consigliabile eseguire il backup e il ripristino nella farm di failover.

• Le raccolte siti aggiunte alla farm primaria non vengono aggiunte automaticamente al database di configurazione della farm secondaria, devono pertanto essere aggiunti mediante le operazioni Stsadm o uno script. Per uno script di esempio, vedere Creare uno script per aggiornare l'elenco di siti nel database di configurazione della farm secondaria (script di aggiornamento).

Gli aggiornamenti per Office SharePoint Server devono essere applicati ai file binari sia nella farm primaria che in quella secondaria, ma possono essere applicati ai database nella farm primaria e quindi inviati tramite log shipping alla farm secondaria. In questo articolo le patch non vengono descritte in dettaglio, ma il processo è riepilogato di seguito:

1. Sospendere il log shipping.

2. Scollegare i database del contenuto dell'applicazione Web nella farm secondaria mediante Amministrazione centrale o uno script.

3. Aggiornare entrambe le farm, iniziando dalla farm primaria.

   Importante

   Verificare che il processo sia stato completato correttamente nella farm primaria e in quella secondaria. I database nella farm secondaria non vengono aggiornati durante il processo di aggiornamento, bensì tramite il log shipping.

4. Avviare il log shipping.

5. Poiché i tentativi di collegare database non aggiornati alla farm secondaria hanno esito negativo e possono lasciare la farm in uno stato non supportato, è necessario garantire che uno o due cicli di log shipping siano stati completati prima di collegare i database del contenuto per cui è stato eseguito il log shipping alla farm secondaria.

   Facoltativa. È anche possibile utilizzare la query seguente per determinare se lo schema del database della farm primaria è stato completamente replicato nella farm secondaria prima di collegare i database.

   USE <contentdb>

   GO

   SELECT * FROM Versions

   La query restituisce i numeri di versione nel formato seguente.

   00000000-0000-0000-0000-000000000000

   L'ultima versione nell'elenco corrisponde alla versione di Microsoft Office SharePoint Server 2007 installata più recentemente.

   Importante

   Microsoft in genere non supporta l'esecuzione di query nei database utilizzati da Prodotti e tecnologie SharePoint. La query precedente è un'eccezione ammessa in quanto riguarda i metadati del database. Le query dirette possono incidere negativamente sulle prestazioni e l'affidabilità del sistema. Per ulteriori informazioni sugli effetti delle modifiche dirette ai database, vedere l'articolo della Knowledge Base Supporto per le modifiche apportate ai database utilizzati dai prodotti server di Office e da Windows SharePoint Services (https://go.microsoft.com/fwlink/?linkid=105589&clcid=0x410)

6. Collegare i database per cui è stato eseguito il log shipping alla farm secondaria.

Considerazioni sulle prestazioni per il log shipping in Office SharePoint Server

Analizzare la quantità di dati per cui è stato eseguito il log shipping, in modo da impostare correttamente gli intervalli dei processi di backup, copia e ripristino per il log shipping. Tale quantità dipende dalla quantità di modifiche giornaliere apportate ai database del contenuto. In genere una farm tipica subisce modifiche comprese tra il 2% e il 4%, ma con le modifiche di manutenzione il livello di modifica può raggiungere il 5% o il 7% nelle ore di punta. Per determinare la quantità di modifiche apportate ai database del contenuto nel sistema, per ogni database del contenuto sottoposto a log shipping calcolare la somma delle modifiche nei backup dei registri delle transazioni in un determinato intervallo di tempo, e calcolare la percentuale di modifiche in rapporto alle dimensioni del database primario.

È consigliabile eseguire il backup e la copia di numerosi registri delle transazioni di piccole dimensioni anziché di pochi registri delle transazioni più grandi. Pianificare i backup e le copie dei registri a intervalli frequenti. È invece possibile scegliere intervalli meno frequenti per il ripristino dei registri delle transazioni. È consigliabile iniziare utilizzando intervalli di backup e copia di 5 minuti, e intervalli di ripristino di 15 minuti. SQL Server 2008 include la possibilità di utilizzare intervalli di log shipping inferiori a un minuto. Per ulteriori informazioni, vedere Pianificazione di log shipping inferiori al minuto in SQL Server 2008(informazioni in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=151253&clcid=0x410)

È possibile che si verifichino problemi di prestazioni se il tempo impiegato dal sistema per il log shipping supera il tempo richiesto per creare nuovi registri, ovvero se non si riesce mai a rispettare la pianificazione del log shipping. Questo tipo di situazione può essere causato da problemi di velocità effettiva o di latenza. In tal caso, è consigliabile valutare l'utilizzo di Windows Replica DFS (Distributed File System) con il servizio directory Active Directory in esecuzione su Windows Server 2003 R2 o Servizi di dominio Active Directory in esecuzione su Windows Server 2008 per sostituire il processo di copia con log-shipping. Per ulteriori informazioni sull'utilizzo di Replica DFS, vedere Cenni preliminari sulla soluzione File system distribuito (DFS) in Microsoft Windows Server 2003 R2 (https://go.microsoft.com/fwlink/?linkid=150764&clcid=0x410) e Guida dettagliata ai file system distribuiti in Windows Server 2008(informazioni in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=150765&clcid=0x410).

Nel grafico seguente viene confrontata la velocità effettiva offerta da varie tecnologie di replica che possono essere utilizzate per copiare i registri delle transazioni per cui è stato eseguito il log shipping.

SQL Server 2008 offre anche la possibilità di comprimere i backup per ridurre le dimensioni dei file di cui eseguire il log shipping. Per ulteriori informazioni, vedere Regolazione delle prestazioni della compressione dei backup in SQL Server 2008, parte 1(informazioni in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=151254&clcid=0x410) e Regolazione della compressione dei backup parte 2(informazioni in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=151255&clcid=0x410).

Considerazioni di sicurezza sul log shipping in Office SharePoint Server

Per eseguire il log shipping in SQL Server con Office SharePoint Server 2007 con SP2, i membri del team devono disporre delle autorizzazioni seguenti:

• Per configurare Office SharePoint Server 2007 con SP2 con il log shipping ed eseguire le procedure descritte in questo articolo, un membro del team deve appartenere al gruppo Amministratori farm di SharePoint.

• Per configurare il log shipping di SQL Server ed eseguire le procedure descritte in questo articolo, un membro del team deve avere il ruolo predefinito del server sysadmin in ogni istanza del server.

Quando un amministratore di database imposta un database per cui è stato eseguito il log shipping, gli account di accesso e le autorizzazioni di SQL Server per il database da utilizzare con una farm SharePoint non vengono configurati automaticamente nei database master e msdb nel server per cui è stato eseguito il log shipping. Sarà necessario pertanto configurare le autorizzazioni per gli account di accesso necessari, tra cui:

• L'account del pool di applicazioni di Amministrazione centrale deve essere membro dei ruoli predefiniti del server dbcreator e securityadmin.

• Tutti gli account dei pool di applicazioni e gli account dei servizi di ricerca e di accesso al contenuto predefiniti devono disporre di account di accesso di SQL Server, anche se non sono assegnati a ruoli predefiniti del server o del database di SQL Server.

• I membri del gruppo Amministratori farm di SharePoint devono inoltre disporre di account di accesso di SQL Server e devono essere membri degli stessi ruoli dell'account del pool di applicazioni di Amministrazione centrale.

È consigliabile trasferire gli account di accesso e le autorizzazioni dal server principale al server mirror eseguendo uno script. Uno script di esempio è disponibile nell'articolo 918992 della Knowledge Base Come trasferire gli account di accesso e le password tra istanze di SQL Server 2005 (https://go.microsoft.com/fwlink/?linkid=122053&clcid=0x410). Per ulteriori informazioni generali su come trasferire i metadati di SQL Server tra le istanze, vedere l'articolo della documentazione in linea di SQL Server Gestione dei metadati quando si rende disponibile un database in un'altra istanza del server (https://go.microsoft.com/fwlink/?linkid=122055&clcid=0x410) e l'articolo 321247 della Knowledge Base Come configurare la sicurezza per il log shipping SQL Server (https://go.microsoft.com/fwlink/?linkid=150830&clcid=0x410).

Le directory di backup e ripristino nella configurazione del log shipping devono conformarsi ai requisiti seguenti:

• Affinché il processo di backup venga eseguito correttamente, è necessario che l'account di servizio SQL Server nell'istanza del server primario e l'account proxy del processo di backup (per impostazione predefinita, l'account SQL Server Agent nell'istanza del server primario) dispongano di autorizzazioni di lettura/scrittura per la directory di backup.

• Affinché il processo di copia venga eseguito correttamente, è necessario che l'account proxy del processo di copia (per impostazione predefinita, l'account SQL Server Agent nell'istanza del server secondario) disponga delle autorizzazioni di lettura per la directory backup e delle autorizzazioni di scrittura per la directory di copia.

• Affinché il processo di ripristino venga eseguito correttamente, è necessario che l'account di servizio SQL Server nell'istanza del server secondario e l'account proxy del processo di ripristino (per impostazione predefinita, l'account SQL Server Agent nell'istanza del server secondario) dispongano di autorizzazioni di lettura/scrittura per la directory di copia.

Requisiti per il data center e la farm secondari

Per quanto concerne l'ambiente del data center secondario si parte dai presupposti seguenti:

• Il data center secondario include un controller di dominio in esecuzione e il provider di autenticazione appropriato. Per ulteriori informazioni, vedere Installare un controller di dominio aggiuntivo (https://go.microsoft.com/fwlink/?linkid=150832&clcid=0x410).

• Se una distribuzione include le caratteristiche di integrazione di Microsoft Exchange Server 2007, il data center secondario contiene un server Exchange 2007 per cui è stato eseguito il log shipping o un altro tipo di replica. Per ulteriori informazioni, vedere Disponibilità elevata (https://go.microsoft.com/fwlink/?linkid=150839&clcid=0x410).

La farm di failover deve presentare le caratteristiche seguenti:

• Un database di configurazione separato e un database del contenuto di Amministrazione centrale separato devono essere installati e gestiti nella farm di failover, pertanto tutte le modifiche alla configurazione eseguite nella farm primaria devono essere replicate manualmente alla farm di failover.

  Tra le informazioni archiviate nel database di configurazione sono incluse quelle elencate di seguito.

  Caratteristiche attivate	Impostazioni per la registrazione diagnostica
  Modelli di modulo distribuiti dall'amministratore	Impostazioni per la posta elettronica
  Impostazioni del mapping di accesso alternativo	Impostazioni di connessione a servizi esterni
  Impostazioni antivirus	Impostazioni di ricerca a livello di farm
  Impostazioni del pool di applicazioni, inclusi gli account di servizio, ovvero tutti gli account eseguiti come applicazioni Web, tra cui l'account del crawler e l'account di ricerca.	Impostazioni per il visualizzatore HTML
  Tipi di file bloccati	Impostazioni del Cestino e altre impostazioni generali per le applicazioni Web
  Impostazioni per la distribuzione del contenuto	Impostazioni per i processi timer
  Regole di impatto del crawler	Impostazioni per l'elaborazione dell'analisi dei dati di utilizzo
  Nomi e posizioni dei database	Nomi delle applicazioni Web e dei database. Assicurarsi di documentare i nomi dei database del contenuto associati a ogni applicazione Web.
  Modelli quote predefiniti	Impostazioni di gestione dei flussi di lavoro

  Nota

  Se è stato configurato il mapping di accesso alternativo per la farm primaria, è molto importante configurarlo in modo identico nella farm secondaria. Per documentare le impostazioni del mapping di accesso alternativo, esportarle in un file di testo utilizzando il comando stsadm -o enumalternatedomains.

• Tutte le personalizzazioni, ad esempio le caratteristiche, le soluzioni, i modelli di sito e le soluzioni di terze parti quali i filtri IFilter, devono essere distribuite in entrambe le farm. È consigliabile includere tutte le personalizzazioni in un pacchetto sotto forma di soluzioni per consentire la distribuzione rapida. Per ulteriori informazioni, vedere Distribuire le personalizzazioni.

• I database del contenuto devono essere impostati per l'utilizzo del modello di recupero con registrazione completa. Per informazioni su come impostare il modello di recupero di un database, vedere Procedura: Visualizzazione o modifica del modello di recupero di un database (SQL Server Management Studio) (https://go.microsoft.com/fwlink/?linkid=151701&clcid=0x410).

• Il server primario e i server secondari devono eseguire la stessa edizione di SQL Server 2005 o SQL Server 2008. Il log shipping è disponibile nelle edizioni Standard, Developer ed Enterprise.

• Se si intende esporre la farm secondaria per cui è stato eseguito il log shipping agli utenti, configurare il mapping di accesso alternativo con uno spazio dei nomi secondario per la farm secondaria, ad esempio http://secondario.contoso.com o http://solalettura.contoso.com. Per ulteriori informazioni, vedere Configurare il mapping di accesso alternativo. Questo mapping di accesso alternativo deve essere sostituito con un mapping identico a quello della farm primaria durante il failover.

Configurazione dell'ambiente di log shipping

In questa sezione vengono illustrate procedure dettagliate per la configurazione del log shipping.

Le procedure descritte in questa sezione si basano sul presupposto che nell'organizzazione i dipendenti conoscano i prerequisiti seguenti:

• Come distribuire Office SharePoint Server

• Come impostare le identità del pool di applicazioni

• Come arrestare e avviare il servizio di ricerca

• Come configurare un DNS (Domain Name System) per accettare e bloccare il traffico

• Come utilizzare il file degli host per attivare e disattivare i siti locali

La fase di failover è composta dalle seguenti procedure:

• Preparare la farm primaria

• Preparare la farm secondaria

• Configurare il log shipping

• Collegare i database per cui è stato eseguito il log shipping alla farm secondaria di SharePoint

• Configurare la ricerca e i profili per la farm secondaria

• Creare uno script per aggiornare l'elenco di siti nel database di configurazione della farm secondaria (script di aggiornamento)

• Coordinare i tempi dei processi di log shipping, delle ricerche per indicizzazione e dello script di aggiornamento

• Facoltativo. Mantenere SSO nella farm secondaria

• Facoltativo. Concedere agli utenti l'accesso alla farm di sola lettura

Preparare la farm primaria

I passaggi per la preparazione del server primario includono i seguenti:

1. Impostare l'identità del pool di applicazioni nelle applicazioni Web su un account di dominio disponibile in entrambe le farm. Per ulteriori informazioni, vedere Cambiare l'identità del pool di applicazioni per un'applicazione Web (Office SharePoint Server).

2. Documentare tutte le impostazioni di configurazione in modo che possano essere applicate alla farm secondaria. Per ulteriori informazioni, vedere Preparare il backup e il ripristino di una farm (Office SharePoint Server 2007). Accertarsi di documentare in particolare le impostazioni di mapping di accesso alternativo esportandole in un file di testo mediante il comando stsadm -o enumalternatedomains.

3. Documentare tutte le personalizzazioni. Sarà più facile applicare di nuovo le personalizzazioni alla farm secondaria se vengono incluse in pacchetti come soluzioni. Per ulteriori informazioni, vedere Distribuire le personalizzazioni.

Preparare la farm secondaria

1. Installare e configurare Office SharePoint Server nella farm secondaria. Per ulteriori informazioni, vedere Distribuire Office SharePoint Server 2007 in un ambiente server farm.

   Se si dispone di apparecchiature sufficienti, è consigliabile configurare lo stesso numero di server Web front-end e database presenti nella farm primaria. In caso contrario, è possibile utilizzare un numero inferiore di server nella farm secondaria, ma potrebbero non essere in grado di gestire lo stesso carico della farm primaria.

   Verificare che il numero di versione e il livello di patch siano gli stessi nella farm primaria e nella farm secondaria. Per ulteriori informazioni, vedere Centro risorse aggiornamenti per Prodotti e tecnologie SharePoint(informazioni in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=106182&clcid=0x410).

2. Applicare tutte le configurazioni e le personalizzazioni eseguite nella farm primaria. Per ulteriori informazioni, vedere Distribuire le personalizzazioni.

3. Creare duplicati di tutte le applicazioni Web esistenti nella farm primaria, accertandosi di utilizzare la stessa identità del pool di applicazioni delle applicazioni Web nella farm primaria. Per ulteriori informazioni, vedere Creazione e gestione di applicazioni Web (Office SharePoint Server).

4. Disattivare i processi timer seguenti. Per ulteriori informazioni, vedere Gestire i processi timer di SharePoint (Office SharePoint Server).

   Elaborazione in blocco attività flusso di lavoro	Sincronizzazione profilo	Raccolta siti: Eliminazione
   Registro modifiche	Sincronizzazione rapida profilo	Analisi utilizzo
   Statistiche database	Elaborazione del Centro record	Definizione processo pagina di propagazione varianti
   Eliminazione siti inattivi	Cestino	Definizione processo sito di propagazione varianti
   Avviso di quota disco	Approvazione pianificata	Aggiornamento criteri Watson per Windows SharePoint Services
   Criterio scadenza	Revisione di pagina pianificata	Flusso di lavoro
   Esenzione elaborazione e creazione report	Annullamento della pubblicazione pianificato	Pulitura automatica flussi di lavoro
   Avvisi immediati	Ricerca ed elaborazione	Failover flussi di lavoro
   Criteri di gestione delle informazioni	Processo di sincronizzazione provider di servizi condivisi

Configurare il log shipping

È possibile configurare il log shipping utilizzando SQL Server Management Studio o Transact-SQL. In questo articolo viene descritto come utilizzare Management Studio.

Configurare il log shipping sul server primario

1. Aprire Management Studio in un server di database nella farm primaria.

2. Nel riquadro di spostamento Esplora oggetti fare clic con il pulsante destro del mouse sul database del contenuto per l'applicazione Web, selezionare Attività e quindi fare clic su Distribuisci log transazioni.

   Verrà visualizzata la finestra di dialogo Proprietà database.

3. Selezionare Attiva come database primario in una configurazione per la distribuzione dei log.

4. Fare clic su Impostazioni backup.

   Verrà visualizzata la finestra di dialogo Impostazioni backup distribuzione log delle transazioni.

   1. In Percorso di rete della cartella di backup immettere il percorso della cartella di backup nella farm primaria.

   2. Immettere i valori necessari in Elimina i file più vecchi di e Invia avviso se il backup non viene eseguito entro.

   3. Esaminare la pianificazione inclusa nella sezione Processo di backup. Se è necessario personalizzare la pianificazione, fare clic su Pianificazione.

      Annotare quando è prevista l'esecuzione dei processi di log shipping in base alla pianificazione in modo da poter pianificare di conseguenza le ricerche per indicizzazione e altri processi batch.

   4. Facoltativo. Esaminare l'impostazione nella sezione Compressione se si desidera utilizzare la compressione del backup.

   5. Fare clic su OK.

5. Nella finestra di dialogo Proprietà database fare clic su Aggiungi nella sezione Database secondari.

   Verrà visualizzata la finestra di dialogo Impostazioni database secondario.

   • Fare clic su Connetti e stabilire una connessione all'istanza di SQL Server che si desidera utilizzare come server secondario. Per impostazione predefinita, il nome del database secondario è lo stesso nome del database utilizzato per il server primario.

   • Nella scheda Inizializza database secondario selezionare Sì, genera un backup completo del database primario e ripristinalo nel database secondario (crea il database secondario se non esiste).

   • Nella scheda Copia file, nella casella Cartella di destinazione per i file copiati, immettere il percorso della cartella nel server secondario in cui si desidera che vengano copiati i backup dei registri delle transazioni.

   • Nella scheda Ripristina log delle transazioni, nella sezione Stato del database durante il ripristino dei backup, selezionare Modalità standby e deselezionare Disconnetti utenti dal database per il ripristino dei backup.

   • Fare clic su OK.

   • È consigliabile salvare le impostazioni in uno script. Nella finestra di dialogo Proprietà database fare clic su Script configurazione e quindi su Genera script di configurazione in un file.

     Verrà visualizzata la finestra di dialogo Salva con nome. Immettere la cartella in cui si desidera salvare il file e fare clic su OK.

   • Fare clic su OK.

     Tutti i processi verranno eseguiti una volta per inizializzare il log shipping e verrà segnalato se il processo ha avuto esito positivo o negativo.

6. Ripetere la procedura precedente per tutti i database che si intende sottoporre a log shipping. Per ulteriori informazioni, vedere Procedura: Attivazione della funzione di log shipping (SQL Server Management Studio) (https://go.microsoft.com/fwlink/?linkid=151644&clcid=0x410).

Facoltativo. Sostituire l'attività di copia del log shipping con la Replica DFS

1. Attivare e configurare la Replica DFS per l'ambiente utilizzato. Per ulteriori informazioni, vedere Replica (https://go.microsoft.com/fwlink/?linkid=151670&clcid=0x410). Per un esempio di configurazione della Replica DFS, vedere Guida dettagliata ai file system distribuiti in Windows Server 2008(informazioni in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=150765&clcid=0x410).

2. Poiché verrà utilizzata la Replica DFS per il trasporto, è necessario disattivare il processo di copia del log shipping per ogni database che partecipa alla configurazione del log shipping. Per ulteriori informazioni, vedere Procedura: Disabilitazione o abilitazione di un processo (SQL Server Management Studio) (https://go.microsoft.com/fwlink/?linkid=151673&clcid=0x410)

Verificare che il log shipping sia stato eseguito correttamente

1. Avviare Management Studio nel server di database della farm secondaria.

2. Nel riquadro di spostamento Esplora oggetti verificare che lo stato dei database del contenuto per cui è stato eseguito il log shipping sia Standby o Sola lettura.

3. Determinare il tempo impiegato per eseguire i processi di log shipping nella farm secondaria eseguendo i processi e calcolandone la durata. Per ulteriori informazioni, vedere Monitoraggio del log shipping (https://go.microsoft.com/fwlink/?linkid=151682&clcid=0x410).

Collegare i database per cui è stato eseguito il log shipping alla farm secondaria di SharePoint

1. Nel sito Web Amministrazione centrale SharePoint, sulla barra di avvio veloce fare clic su Gestione applicazioni nella sezione Amministrazione centrale. Verrà visualizzata la pagina Gestione applicazioni.

   Nella sezione Gestione applicazione Web SharePoint fare clic su Database del contenuto.

   Verrà visualizzata la pagina Gestisci database del contenuto.

2. Nella colonna Nome database fare clic sul database del contenuto che si desidera rimuovere. Verrà visualizzata la pagina Gestisci impostazioni database del contenuto.

3. Nella sezione Rimozione database del contenuto selezionare la casella di controllo Rimuovi database del contenuto e quindi fare clic su OK.

4. Nella pagina Gestisci database del contenuto fare clic su Aggiungi database del contenuto. Verrà visualizzata la pagina Aggiungi database del contenuto.

5. Immettere il server di database appropriato e il nome del database del contenuto per cui è stato eseguito il log shipping, quindi fare clic su OK.

6. Ripetere la procedura per tutti i database di cui si desidera eseguire il log shipping.

   È ora possibile esplorare il contenuto nella farm secondaria.

Configurare la ricerca e i profili per la farm secondaria

Configurare la ricerca nella farm secondaria in conformità con gli obiettivi aziendali per lo scenario di ripristino di emergenza. È consigliabile eseguire inizialmente la ricerca negli stessi database e con le stesse impostazioni e regole di indicizzazione della farm primaria. Se si stabilisce che non è possibile pianificare le ricerche per indicizzazione e il log shipping in modo che non si sovrappongano, è consigliabile modificare il contenuto incluso nelle ricerche per indicizzazione. Ad esempio, prima del failover è possibile eseguire la ricerca per indicizzazione solo nei database con contenuto di elevato impatto aziendale e quindi eseguire la ricerca per indicizzazione nell'altro contenuto solo dopo il failover. Per ulteriori informazioni, vedere Limitare o aumentare la quantità di contenuto sottoposto a ricerca per indicizzazione (Office SharePoint Server).

1. Interrompere il processo di SQL Server Agent nella farm secondaria per disattivare il shipping mentre si configura la ricerca.

2. Configurare la ricerca nella farm secondaria.

   Determinare quanto possono durare le ricerche per indicizzazione nella farm secondaria. È possibile utilizzare i dati raccolti dalla farm primaria per stimare il tempo necessario nella farm secondaria.

   Importante

   Accertarsi di pianificare le ricerche per indicizzazione in momenti in cui non sono in esecuzione processi di log shipping. Per ulteriori informazioni, vedere Coordinare i tempi dei processi di log shipping, delle ricerche per indicizzazione e dello script di aggiornamento.

3. Avviare il processo di SQL Server Agent nella farm secondaria per attivare il log shipping.

4. Se si utilizzano i profili, quelli nei provider di servizi condivisi di failover non vengono sincronizzati con i profili del provider di servizi condivisi primario, ma rimarranno nello stato in cui si trovavano dopo l'importazione iniziale. Per mantenere sincronizzati i profili in tutti i provider di servizi condivisi, è necessario utilizzare il motore di replica dei profili utente incluso nella versione a 32 bit del Toolkit di amministrazione di Microsoft SharePoint x86(informazioni in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=151962&clcid=0x410) o nella versione a 64 bit del Toolkit di amministrazione di Microsoft SharePoint x64(informazioni in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=142035&clcid=0x410). Per ulteriori informazioni, vedere Motore di replica dei profili utente (Office SharePoint Server).

Creare uno script per aggiornare gli elenchi di siti nel database di configurazione della farm secondaria (script di aggiornamento)

Utilizzare l'esempio seguente quale modello per creare uno script di aggiornamento da eseguire nella farm secondaria quando sono state aggiunte o eliminate raccolte siti nella farm primaria.

Nello script di esempio sostituire <db_name1>, <URL> e <db_name2>, <URL> con i nomi dei database per cui è stato eseguito il log shipping.

Aggiungere sezioni di collegamento (attach) o scollegamento (detach) per ogni database per cui è stato eseguito log shipping.

echo off

SET PATH=C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN;%PATH%

echo %time Shutting down the Osearch service…
SC config Osearch start= disabled
SC stop Osearch

echo %time Shutting down the SQL Server Agent service…
SC \\<SQL Server> config SQLSERVERAGENT start= disabled
SC \\<SQL Server>  stop SQLSERVERAGENT
f
echo %time About to refresh Site Map…

echo %time About to detach db <db_name1>
stsadm.exe -o deletecontentdb -url <URL> -databasename <db_name1>  -databaseserver <SQL_Server>
echo %time About to attach db <db_name1>
stsadm.exe -o addcontentdb -url <URL> -databasename <db_name1> -databaseserver <SQL_Server>

echo %time  About to detach db <db_name2>
stsadm.exe -o deletecontentdb -url <URL> -databasename <db_name2>  -databaseserver <SQL_Server>
echo %time  About to attach db <db_name2>
stsadm.exe -o addcontentdb -url <URL> -databasename <db_name2> -databaseserver <SQL_Server>

rem --:: repeat for all databases ::--

echo %time Restarting the Osearch service…
SC config Osearch start= demand
SC start Osearch

echo %time Restarting the SQL Server Agent service…
SC \\<SQL Server> config SQLSERVERAGENT start= demand
SC \\<SQL Server>  start SQLSERVERAGENT

echo on

Coordinare i tempi dei processi di log shipping, delle ricerche per indicizzazione e dello script di aggiornamento

1. Determinare il tempo impiegato per eseguire i processi di log shipping nella farm secondaria e quando si desidera pianificare l'esecuzione dei processi.

2. Determinare la durata delle ricerche per indicizzazione incrementali più lunghe nella farm secondaria e quando si desidera pianificare tali processi. È possibile utilizzare i dati della ricerca per indicizzazione della farm primaria per determinare il tempo impiegato per completare le ricerche per indicizzazione. Per ulteriori informazioni sulla pianificazione di una ricerca per indicizzazione incrementale, vedere Pianificare una ricerca per indicizzazione incrementale (Office SharePoint Server 2007).

3. Se possibile, pianificare i processi di log shipping e di ricerca per indicizzazione in modo che non si sovrappongano.

4. Se non è possibile pianificare il log shipping e le ricerche per indicizzazione incrementali in modo da evitare sovrapposizioni, scegliere una delle opzioni seguenti:

   • Eseguire manualmente i processi di log shipping e le ricerche per indicizzazione, sospendendo una serie di processi mentre si esegue l'altra.

   • Attribuire la precedenza alle ricerche per indicizzazione rispetto all'elaborazione dei registri e creare uno script che avvii automaticamente il log shipping quando il processo del crawler non è in esecuzione.

   • Se l'unico processo attivo nel database è il processo del crawler, configurare il log shipping in modo che attenda fino a quando il database non sarà in uso e quindi elaborerà il log shipping.

   Se nessuna di queste opzioni funziona e se non si riesce a pianificare la quantità di dati per il log shipping e i tempi della ricerca per indicizzazione in modo che non si sovrappongano, sarà opportuno operare dei tagli, ad esempio se non è possibile completare il log shipping e la ricerca nei tempi disponibili, eseguire la ricerca per indicizzazione solo nei database del contenuto a elevato impatto aziendale prima del failover e avviare la ricerca per indicizzazione dell'altro contenuto dopo il failover.

5. Pianificare l'esecuzione dello script di aggiornamento. Se non sono state aggiunte nuove raccolte siti alla farm primaria, non è necessario eseguire lo script di aggiornamento. Se invece sono state aggiunte nuove raccolte siti, è necessario eseguire periodicamente lo script di aggiornamento utilizzando l'Utilità di pianificazione di Windows. Quando lo script di aggiornamento viene eseguito, vengono sospesi i processi del crawler e di log shipping. Per ulteriori informazioni sulla pianificazione delle attività, vedere Pianificazione delle operazioni (https://go.microsoft.com/fwlink/?linkid=151894&clcid=0x410).

   Se lo script di aggiornamento viene annullato mentre è in esecuzione, è consigliabile eseguirlo manualmente per verificare che tutti i database vengano ricollegati e che tutti i servizi siano riattivati.

Facoltativo. Mantenere SSO nella farm secondaria

• Eseguire il backup della chiave di crittografia dopo la configurazione iniziale di SSO e quindi eseguire di nuovo il backup della chiave ogni volta che viene rigenerata. Per ulteriori informazioni, vedere Eseguire il backup di SSO (Office SharePoint Server 2007).

  Tenere presente le restrizioni seguenti quando si esegue il backup della chiave di crittografia:

  • Per eseguire questa attività, è necessario essere membri dell'account di amministratore SSO.

  • Non è possibile eseguire il backup della chiave di crittografia in remoto. Per eseguire il backup della chiave di crittografia, è necessario accedere al server delle chiavi di crittografia in locale.

  • È necessario trasferire fisicamente il dispositivo di archiviazione rimovibile contenente la chiave di crittografia SSO nella farm secondaria e ripristinarlo.

Facoltativo. Concedere agli utenti l'accesso alla farm di sola lettura

1. Se possibile, offrire agli utenti un file degli host aggiornato che rimandi alle applicazioni Web nella farm secondaria che si desidera esporre.

2. Se non è possibile distribuire un file degli host, definire un mapping di accesso alternativo dedicato per ogni applicazione Web che si desidera esporre, ad esempio http//solalettura.contoso.com o http://secondario.contoso.com, e configurare la mappa nel DNS.

   Nota

   Se non è disponibile spazio sufficiente per definire mapping di accesso alternativo per una determinata applicazione Web, questa opzione di mapping dedicato non può essere applicata.

Failover

È possibile eseguire il failover manualmente o tramite script. In questo articolo verrà descritto solo il failover manuale.

Nel diagramma seguente è illustrato un ambiente con più farm di cui è stato eseguito il failover. Il log shipping è stato interrotto e gli amministratori della farm hanno eseguito le azioni seguenti:

• Il DNS è stato impostato per interrompere il traffico verso la farm primaria.

• I registri delle transazioni non applicati sono stati applicati ai database sul server secondario.

• Lo stato dei database del contenuto nella farm secondaria è stato modificato in lettura/scrittura.

• Il DNS è stato impostato per accettare il traffico nella farm secondaria.

Nota

In questa sezione viene illustrato come eseguire un failover completo (non di prova). Per ulteriori informazioni sul test del failover, vedere Considerazioni per il test del failover.

La fase di failover è composta dalle procedure seguenti.

• Disattivare tutti i processi di log shipping nella farm primaria

• Interrompere il traffico verso la farm primaria

• Eseguire il backup dei registri delle transazioni sul server primario

• Ripristinare i registri delle transazioni più recenti nel server secondario

• Impostare i database del contenuto in lettura/scrittura

• Facoltativo. Ripristinare la chiave di crittografia SSO

• Indirizzare il traffico verso la farm secondaria

• Completare la configurazione dell'ambiente secondario

Disattivare tutti i processi di log shipping nella farm primaria

1. Se la farm è ancora disponibile e il log shipping non è ancora stato interrotto, disattivare tutti i processi di log shipping nei server di database della farm primaria.

2. Se non è possibile accedere ai database nei server, eseguire l'istruzione Transact-SQL seguente per ogni database e ignorare il passaggio: Impostare i database del contenuto in lettura/scrittura.

   RESTORE DATABASE content_db WITH RECOVERY
   

Interrompere il traffico verso la farm primaria

• Per interrompere il traffico verso la farm primaria, seguire le procedure consigliate per il DNS. Non inoltrare ancora il traffico verso la farm secondaria.

  In questo articolo non viene descritto come utilizzare o configurare il DNS. Per ulteriori informazioni sul DNS, vedere Riferimento tecnico per il DNS(informazioni in lingua inglese)(https://go.microsoft.com/fwlink/?linkid=151820&clcid=0x410).

  Nota

  Quando la farm primaria non è disponibile, gli utenti riceveranno dei messaggi di errore.

Eseguire il backup dei registri delle transazioni nel server primario

1. Determinare se la farm primaria è ancora disponibile e se entrambe le server farm possono accedere alla cartella di rete condivisa in cui sono archiviati i backup. Se nessuna delle due condizioni è valida, passare alla procedura Impostare i database del contenuto in lettura/scrittura.

2. In Management Studio, nel riquadro di spostamento Esplora oggetti, fare clic con il pulsante destro del mouse su un database del contenuto, scegliere Attività e quindi fare clic su Backup. Verrà visualizzata la finestra di dialogo Backup database.

3. Fare clic sull'elenco a discesa Tipo di backup e selezionare Log delle transazioni.

4. Nella pagina Selezione pagina fare clic su Opzioni.

5. Nella sezione Log delle transazioni selezionare Esegui backup della parte finale del log e lascia il database in stato di ripristino e quindi fare clic su OK.

6. Ripetere questa procedura per tutti i database per cui è stato eseguito il log shipping.

Ripristinare i registri delle transazioni più recenti nel server secondario

1. Questa procedura è utile solo se la farm primaria è ancora disponibile e se entrambe le server farm possono accedere alla condivisione di rete in cui sono archiviati i backup. Se nessuna delle due condizioni è valida, passare alla procedura Impostare i database del contenuto in lettura/scrittura.

   In Management Studio nel server secondario, fare clic con il pulsante destro del mouse sul database del contenuto, scegliere Attività, fare clic su Ripristina e quindi su Log delle transazioni. Verrà visualizzata la finestra di dialogo Ripristina log delle transazioni.

2. Nella scheda Generale selezionare Da file o nastro e immettere il percorso del file di backup creato nel server primario.

3. Nella sezione Stato di recupero selezionare Lascia il database pronto per l'utilizzo eseguendo il rollback delle transazioni di cui non è stato eseguito il commit. I log delle transazioni aggiuntivi non possono essere ripristinati. (RESTORE WITH RECOVERY) e quindi fare clic su OK.

4. Ripetere questa procedura per tutti i database per cui è stato eseguito il log shipping.

Impostare i database del contenuto in lettura/scrittura

Dopo aver impostato i database nella farm secondaria in lettura/scrittura, è necessario ristabilire il log shipping da un nuovo file di backup nel server secondario che verrà quindi copiato nel server primario.

1. In Management Studio fare clic con il pulsante destro del mouse sul database del contenuto da impostare in sola lettura e quindi scegliere Proprietà. Verrà visualizzata la finestra di dialogo Proprietà database.

2. Nel riquadro Selezione pagina fare clic su Opzioni e scorrere l'elenco Altre opzioni fino alla sezione Stato.

3. Alla voce Database di sola lettura fare clic sulla freccia accanto a True, selezionare False e quindi fare clic su OK.

4. Ripetere l'operazione per tutti gli altri database del contenuto.

Facoltativo. Ripristinare la chiave di crittografia SSO

1. Nella farm secondaria riavviare il servizio SSO.

2. Configurare SSO nel server secondario.

3. Nella farm secondaria riavviare il servizio SSO.

4. Ripristinare la chiave dall'unità rimovibile.

5. Creare una definizione di applicazione per verificare che sia possibile creare nuove definizioni di applicazione.

6. Verificare di poter ottenere le credenziali da varie applicazioni utilizzando il metodo GetCredentials. Per ulteriori informazioni, vedere Metodo ISsoProvider.GetCredentials (Microsoft.SharePoint.Portal.SingleSignon)(informazioni in lingua inglese)(https://go.microsoft.com/fwlink/?linkid=151824&clcid=0x410).

Indirizzare il traffico verso la farm secondaria

1. Verificare che le impostazioni del mapping di accesso alternativo alla farm secondaria corrispondano a quelle della farm primaria.

2. Per indirizzare il traffico verso la farm secondaria, seguire le procedure consigliate per il DNS.

   Nota

   Dopo aver indirizzato il traffico nel DNS verso la farm secondaria, gli utenti potrebbero dover chiudere e riaprire il browser in uso affinché l'operazione di reindirizzamento venga eseguita.

Completare la configurazione dell'ambiente secondario

1. Definire processi di manutenzione comuni.

   • Impostare il monitoraggio.

   • Implementare processi di backup a livello di produzione.

2. Iniziare a ripristinare il precedente ambiente primario.

Considerazioni sul test di failover

Quando si esegue il test di failover, stabilire con chiarezza il livello richiesto in base ai contratti di servizio. Di seguito sono riportati alcuni esempi comuni di test di failover.

Verification that the secondary site is live, and is being crawled   Per questo tipo di test di failover, è possibile offrire agli utenti un file degli host o un percorso di mapping di accesso alternativo alla farm secondaria, in modo che possano verificare che la farm sia attiva e aggiornata. Non sono necessari altri passaggi.

Farm failover   In questo tipo di test, la farm primaria viene disattivata per un breve intervallo annunciato, mentre la farm secondaria non viene impostata in stato di lettura/scrittura. Per questo tipo di test, seguire le procedure descritte nella sezione Failover, con le differenze seguenti:

Passaggi per il test di failover	Descrizione
Eseguire	1. Per iniziare il test di failover, nella farm secondaria arrestare il processo di SQL Server Agent, in modo che non vengano elaborati registri.
Non eseguire	2. Disattivare tutti i processi di log shipping nella farm primaria.
Eseguire	3. Interrompere il traffico verso la farm primaria.
Eseguire	4. Eseguire il backup dei registri delle transazioni nel server primario.
Eseguire	5. Ripristinare i registri delle transazioni più recenti nel server secondario.
Non eseguire	6. Impostare i database del contenuto in lettura/scrittura.
Non eseguire	7. Facoltativo. Ripristinare la chiave di crittografia SSO.
Eseguire	8. Indirizzare il traffico verso la farm secondaria.
Non eseguire	9. Completare la configurazione dell'ambiente secondario.

Planned data center failover with additional precautions   In questo tipo di test, il data center primario viene disattivato per un intervallo annunciato, mentre la farm secondaria viene impostata in stato di lettura/scrittura. Per questo tipo di test, seguire le procedure descritte nella sezione Failover, con le differenze seguenti:

Passaggi per il test di failover	Descrizione
Eseguire	1. Per iniziare il test di failover, nella farm secondaria arrestare il processo di SQL Server Agent, in modo che non vengano elaborati registri.
Eseguire	2. Disattivare tutti i processi di log shipping nella farm primaria.
Eseguire	3. Interrompere il traffico verso la farm primaria.
Eseguire	4. Eseguire il backup dei registri delle transazioni nel server primario.
Eseguire	5. Ripristinare i registri delle transazioni più recenti nel server secondario.
Eseguire	6. Impostare i database del contenuto in lettura/scrittura.
Eseguire	7. Facoltativo. Ripristinare la chiave di crittografia SSO.
Eseguire	8. Indirizzare il traffico verso la farm secondaria.
Non eseguire	9. Completare la configurazione dell'ambiente secondario.
Nuovo passaggio	10. Mantenere tutti i backup per cui è stato eseguito il log shipping nella farm secondaria in modo da poter utilizzare il backup del database dalla farm secondaria per riavviare il log shipping.

Planned data center failover without additional precautions   In questo tipo di test, il data center primario viene disattivato per un intervallo annunciato per determinare la durata di un ripristino effettivo. È possibile che si verifichi la perdita di alcuni dati. La farm secondaria viene impostata in stato di lettura/scrittura. Per questo tipo di test, seguire le procedure descritte nella sezione Failover.

Passaggi per il test di failover	Descrizione
Eseguire	1. Prima di iniziare, eseguire il backup dei database per cui è stato eseguito il log shipping nella farm primaria, in modo da disporre di un backup attuale da utilizzare per riavviare il log shipping.
Eseguire	2. Disattivare tutti i processi di log shipping nella farm primaria.
Eseguire	3. Interrompere il traffico verso la farm primaria.
Eseguire	4. Eseguire il backup dei registri delle transazioni nel server primario.
Eseguire	5. Ripristinare i registri delle transazioni più recenti nel server secondario.
Eseguire	6. Impostare i database del contenuto in lettura/scrittura.
Eseguire	7. Facoltativo. Ripristinare la chiave di crittografia SSO.
Eseguire	8. Indirizzare il traffico verso la farm secondaria.
Non eseguire	9. Completare la configurazione dell'ambiente secondario.

Riconfigurare il log shipping

Quando la farm secondaria è operativa, il database primario è accessibile e il problema relativo a tale farm è stato esaminato e risolto, è possibile trasformare il database primario precedente nel nuovo database secondario oppure eseguire deliberatamente il failover dalla farm secondaria alla precedente farm primaria e quindi riconfigurare il log shipping come era stato strutturato inizialmente.

1. Configurare il log shipping tra la farm secondaria e quella primaria. Stabilire una relazione di log shipping tra l'istanza di SQL Server nella farm secondaria e l'istanza corrispondente nella farm primaria. Per i dettagli, vedere la sezione Configurazione dell'ambiente di log shipping.

2. Nella farm primaria applicare eventuali backup dei registri delle transazioni non applicati a ogni database.

3. Utilizzare il DNS per interrompere il traffico nella farm secondaria.

4. Eseguire il failover dalla farm secondaria alla farm primaria originale. Per i dettagli, vedere la sezione Failover e quindi riconfigurare il log shipping.

5. Facoltativo. Ripristinare il servizio SSO utilizzando la copia locale della chiave di crittografia sul supporto.

6. Riattivare la farm primaria, verificare che tutto funzioni come previsto e quindi modificare il DNS in modo che indirizzi il traffico in entrata verso la farm primaria.

7. Riconfigurare il log shipping dalla farm primaria alla farm secondaria.

Riepilogo

La procedura di utilizzo del log shipping per implementare una farm di ripristino di emergenza in un data center secondario è alquanto complessa. Accertarsi di definire contratti di servizio chiari con gli utenti e sottoporre regolarmente l'ambiente a test.

Riconoscimenti

Il team responsabile per la pubblicazione di contenuto su Microsoft Office SharePoint Server ringrazia i seguenti collaboratori e revisori tecnici per avere collaborato a questo documento:

• Doron Bar-Caspi, Senior Program Manager, SharePoint Customer Advisory Team

• Lindsay Allen, Principal Program Manager Lead, SQL Server Customer Programs

• Sanjay Mishra, Senior Program Manager, SQL Server Customer Programs

• Burzin Patel, Senior Program Manager, SQL Server Customer Programs

• Bill Baer, Technology Architect, Microsoft SharePoint Online

• Cory Burns, Operations Engineer, Microsoft SharePoint Online

• Steve Peschka, Senior Architect

• JP Poissant, Senior Consultant II, Microsoft Consulting Services, Canada