Configurare gruppi di disponibilità AlwaysOn di SQL Server per SharePoint Server

 

**Si applica a:**SharePoint Foundation 2013, SharePoint Server 2013, SharePoint Server 2016

**Ultima modifica dell'argomento:**2018-03-09

Sintesi: informazioni su come creare e configurare un gruppo di disponibilità Always On di SQL Server per una farm di SharePoint Server 2016 e SharePoint 2013.

In questo articolo vengono fornite le informazioni necessarie e le procedure dettagliate per creare e configurare un gruppo di disponibilità AlwaysOn di Microsoft SQL Server 2014 (SP1) o un gruppo di disponibilità Always On di Microsoft SQL Server 2016 per una farm di SharePoint Server 2016 e un gruppo di disponibilità Always On di SQL Server 2012 per una farm di SharePoint 2013.

Contenuto dell'articolo:

• Panoramica del processo

• Prima di iniziare

• Passaggi dettagliati per configurare un gruppo di disponibilità AlwaysOn per SharePoint

• Utilizzare test del failover per convalidare l'installazione AlwaysOn

• Monitorare l'ambiente AlwaysOn

Panoramica del processo

Per distribuire una farm di SharePoint in cui viene utilizzato un gruppo di disponibilità AlwaysOn, è consigliabile attenersi alla procedura di installazione e configurazione seguente:

• Selezionare o creare un cluster di failover di Windows Server.

• Installare SQL Server 2014 (SP1), SQL Server 2016 o SQL Server 2012 in ogni nodo del cluster.

• Creare e configurare un gruppo di disponibilità.

• Installare e configurare SharePoint Server 2016, SharePoint Server 2013 oSharePoint Foundation 2013.

• Aggiungere i database di SharePoint al gruppo di disponibilità.

• Testare il failover per il gruppo di disponibilità.

Prima di iniziare

Prima di avviare la distribuzione, leggere le informazioni seguenti relative a SQL Server AlwaysOn, le tecnologie che supportano AlwaysOn e SharePoint Server 2016:

• Conoscenze e competenze necessarie

• Concetti relativi ai gruppi di disponibilità AlwaysOn

• Requisiti hardware e software

• Autorizzazioni

Conoscenze e competenze necessarie

Per implementare gruppi di disponibilità SQL Server AlwaysOn come soluzione di disponibilità elevata e ripristino di emergenza, interagiscono diverse tecnologie che devono essere installate e configurate correttamente. È consigliabile che il team responsabile dell'impostazione di un ambiente AlwaysOn perProdotti SharePoint già conosca e abbia una certa esperienza pratica nell'utilizzo delle tecnologie seguenti:

• Servizi Windows Server Failover Clustering (WSFC)

• SQL Server 2014 (SP1), SQL Server 2016 o SQL Server 2012

• SharePoint Server 2016

• SharePoint Server 2013

• SharePoint Foundation 2013

Concetti relativi ai gruppi di disponibilità SQL Server AlwaysOn

Un gruppo di disponibilità è costituito dai componenti seguenti:

• Repliche, ovvero un set discreto di database utente (denominati database di disponibilità) per cui viene eseguito il failover come singola unità. Ogni gruppo di disponibilità in SQL Server 2014 (SP1) e SQL Server 2016 supporta una replica primaria e fino a otto repliche secondarie. Ogni gruppo di disponibilità in SQL Server 2012 supporta una replica primaria e fino a quattro repliche secondarie.

• Un'istanza specifica di SQL Server per ospitare ogni replica e mantenere una copia locale di ogni database appartenente al gruppo di disponibilità.

Gruppi di disponibilità AlwaysOn (SQL Server) e Panoramica dei gruppi di disponibilità AlwaysOn (SQL Server)

Repliche e failover

La replica primaria rende i database di disponibilità disponibili per le connessioni di lettura/scrittura dai client e invia i record di log delle transazioni per ogni database primario a tutte le repliche secondarie. Ogni replica secondaria a sua volta applica i record di log delle transazioni ai relativi database secondari.

Tutte le repliche possono essere eseguite nella modalità con commit asincrono oppure al massimo tre di esse possono essere eseguite nella modalità con commit sincrono. Per ulteriori informazioni su queste due modalità, vedere Modalità di disponibilità (gruppi di disponibilità AlwaysOn).

Per ulteriori informazioni sui concetti principali relativi alla tecnologia SQL Server AlwaysOn, leggere gli articoli seguenti:

• Per informazioni dettagliate sui vantaggi offerti dai gruppi di disponibilità AlwaysOn e una panoramica della terminologia correlata, vedere Gruppi di disponibilità AlwaysOn (SQL Server).

• Per ulteriori informazioni sui prerequisiti, vedere Prerequisiti, restrizioni e consigli relativi ai gruppi di disponibilità AlwaysOn.

Windows Server Failover Clustering

Per creare e utilizzare i gruppi di disponibilità AlwaysOn di SQL Server 2014 (SP1) o SQL Server 2016, è necessario installare entrambe le versioni di SQL Server in un cluster di Windows Server Failover Clustering (WSFC). Per ulteriori informazioni, vedere Windows Server Failover Clustering (WSFC) con SQL Server e per SQL Server 2016, Windows Server Failover Clustering (WSFC) con SQL Server.

Per creare e utilizzare i gruppi di disponibilità AlwaysOn di SQL Server 2012, è necessario installare SQL Server 2012 in un cluster di Windows Server Failover Clustering (WSFC).

Benché la configurazione di un cluster WSFC esuli dagli scopi di questo articolo, tenere presenti i requisiti seguenti prima di installare e configurare un cluster:

• Tutti nodi del cluster devono trovarsi nello stesso dominio di Servizi di dominio Active Directory (AD DS).

• Ogni replica di disponibilità appartenente a un gruppo di disponibilità deve risiedere in un nodo diverso dello stesso cluster WSFC (Windows Server Failover Clustering).

• L'autore del cluster deve disporre degli account e delle autorizzazioni seguenti:

  • Deve disporre di un account di dominio nel dominio in cui sarà presente il cluster.

  • Deve disporre di autorizzazioni di amministratore locale in ogni nodo del cluster.

  • Disporre delle autorizzazioni di Create Computer objects e Read All Properties in AD DS. Per ulteriori informazioni, vedere Guida dettagliata del cluster di failover: configurazione degli account in Active Directory e Come creare un cluster in un ambiente restrittivo di Active Directory.

Un aspetto molto importante della configurazione del clustering di failover e di AlwaysOn è rappresentato dalla determinazione dei voti di quorum necessari per i nodi del cluster.

Il clustering di failover è basato su un algoritmo di voto secondo il quale più della metà dei votanti, ovvero il quorum, deve essere online e in grado di comunicare reciprocamente. Dal momento che un determinato cluster ha un numero specifico di nodi e una configurazione quorum specifica, il servizio cluster può determinare cosa costituisce un quorum. Il servizio cluster si arresterà su tutti i nodi se il numero dei votanti scende al di sotto della maggioranza richiesta.

Per ulteriori informazioni, vedere Modalità quorum WSFC e configurazione del voto (SQL Server) e Configurare le impostazioni NodeWeight per il quorum del cluster.

SharePoint Server 2016, SharePoint Foundation 2013 e SharePoint Server 2013

Alcuni database di SharePoint Server non supportano i gruppi di disponibilità AlwaysOn di SQL Server. È consigliabile consultare Opzioni di disponibilità elevata e di ripristino di emergenza supportate per database di SharePoint, Requisiti hardware e software per SharePoint Server 2016 e Requisiti hardware e software per SharePoint 2013 prima di configurare un ambiente AlwaysOn.

Passaggi dettagliati per configurare un gruppo di disponibilità AlwaysOn per SharePoint

Nella figura sotto riportata viene illustrata una farm di SharePoint Server 2016 (SPHA_farm) in cui viene utilizzato un gruppo di disponibilità denominato SP-AG1. La farm SPHA_farm verrà utilizzata nei passaggi seguenti come esempio di riferimento per configurare AlwaysOn.

Preparare l'ambiente cluster di Windows Server

Ottenere l'accesso oppure creare un cluster di Windows Server Failover Clustering (WSFC) con tre nodi da poter utilizzare per installare SQL Server 2014 (SP1), SQL Server 2016 o SQL Server 2012 in ogni nodo del cluster. Per informazioni e procedure dettagliate sulla configurazione di un cluster di failover di Windows Server 2012 R2, vedere Panoramica del clustering di failover.

Preparare l'ambiente SQL Server

Per poter creare un gruppo di disponibilità per SharePoint Server 2016, è necessario predisporre l'ambiente di SQL Server 2014 (SP1) o SQL Server 2016.

A tale scopo, eseguire le attività seguenti:

• Installare i prerequisiti per SQL Server.

• Installare SQL Server 2014 (SP1), SQL Server 2016 o SQL Server 2012.

• Abilitare AlwaysOn.

Installare SQL Server 2014 (SP1)

Utilizzare la procedura seguente per installare SQL Server 2014 (SP1).

Per installare SQL Server 2014 (SP1)

1. Installare i prerequisiti per SQL Server 2014 (SP1) in ogni nodo del cluster.

   Per ulteriori informazioni, vedere Requisiti hardware e software per l'installazione di SQL Server 2014 e Prerequisiti, restrizioni e suggerimenti per i gruppi di disponibilità AlwaysOn (SQL Server).

2. Installare SQL Server in ogni nodo del cluster.

   Per ulteriori informazioni, vedere Installazione rapida di SQL Server 2014 e Esercitazione guidata sull'installazione di SQL Server 2014.

Installare SQL Server 2016

Usare la procedura seguente per installare SQL Server 2016.

Per installare SQL Server 2016

1. Installare i prerequisiti di SQL Server 2016 in ogni nodo del cluster.

   Per ulteriori informazioni, vedere Installare SQL Server 2016.

2. Installare SQL Server 2016 in ogni nodo del cluster.

   Per ulteriori informazioni, vedere Installazione del cluster di failover di SQL Server.

Installare SQL Server 2012

Per installare SQL Server 2012

1. Installare i prerequisiti per SQL Server 2012 in ogni nodo del cluster.

   Per ulteriori informazioni, vedere Prerequisiti, restrizioni e consigli per i gruppi di disponibilità AlwaysOn (SQL Server).

2. Installare SQL Server in ogni nodo del cluster.

   Per ulteriori informazioni, vedere Installazione per SQL Server 2012.

Abilitare AlwaysOn

È necessario abilitare AlwaysOn per ogni server di database del cluster.

Per abilitare AlwaysOn

1. Il proprio account di accesso deve disporre dei livelli di autorizzazione necessari per creare un gruppo di disponibilità. L'account deve essere membro del ruolo predefinito del database db_owner e disporre dell'autorizzazione CREATE AVAILABILITY GROUP per il server oppure dell'autorizzazione CONTROL AVAILABILITY GROUP, ALTER ANY AVAILABILITY GROUP o CONTROL SERVER.

2. Eseguire l'accesso al server in cui sarà ospitata la replica primaria e avviare Configuration ManagerSQL Server.

3. In Esplora oggetti selezionare Servizi di SQL Server, fare clic con il pulsante destro del mouse su SQL Server (<instance name>), dove <instance name> è il nome di un'istanza del server locale per la quale si desidera abilitare i gruppi di disponibilità AlwaysOn, e quindi scegliere Proprietà.

4. Fare clic sulla scheda Disponibilità elevata AlwaysOn.

5. Selezionare la casella di controllo Abilita gruppi di disponibilità AlwaysOn e quindi fare clic su OK.

6. Anche se la modifica viene salvata, è necessario riavviare manualmente il servizio SQL Server (MSSQLSERVER) per confermarla. Il riavvio manuale consente di scegliere un'ora di riavvio adatta per le proprie esigenze aziendali.

7. Ripetere i passaggi precedenti per abilitare AlwaysOn per SQL Server negli altri nodi del cluster.

Per ulteriori informazioni, vedere Abilitare e disabilitare la funzionalità Gruppi di disponibilità AlwaysOn (SQL Server).

Creare e configurare il gruppo di disponibilità

A seconda dell'ambiente SQL Server 2014 (SP1), SQL Server 2016 o SQL Server 2012 in cui si intende creare il gruppo di disponibilità, potrebbe essere necessario creare un database temporaneo da utilizzare prima di creare il gruppo di disponibilità.

Il processo per la creazione di un gruppo di disponibilità richiede che venga specificato un nome per tale gruppo e che venga selezionato come database di disponibilità un database utente idoneo nell'istanza del server connesso.

Se non vi sono database utente nell'istanza del server connesso, che è il caso di questo esempio, sarà necessario crearne uno. Per creare un database utente temporaneo che funga da replica primaria temporanea per il gruppo, attenersi alla procedura seguente.

Per creare un database utente temporaneo

1. Verificare che il proprio account di accesso disponga delle autorizzazioni corrette per questa attività. Per creare il nuovo database, è necessario disporre di una delle autorizzazioni seguenti nel database master:

   • CREATE DATABASE

   • CREATE ANY DATABASE

   • ALTER ANY DATABASE

2. Eseguire l'accesso al server in cui verrà ospitata la replica primaria, ovvero SP-SRV1 in questo esempio.

3. Avviare Management Studio.

4. In Esplora oggetti fare clic con il pulsante destro del mouse su Database e quindi scegliere Nuovo database.

5. Nella finestra di dialogo Nuovo database digitare il nome del database in Nome database, ovvero "TemporaryUserDB" per questo esempio.

   Poiché si tratta di un database temporaneo da eliminare dopo avere creato il gruppo di disponibilità, è possibile utilizzare le impostazioni predefinite. Fare clic su OK.

   Poiché la Creazione guidata Gruppo di disponibilità non crea un gruppo di disponibilità se non è stato effettuato il backup del database utente, è necessario eseguire il backup del database temporaneo.

6. In Esplora oggetti espandere Database, fare clic con il pulsante destro del mouse sul database temporaneo appena creato, scegliere Attività e quindi Backup.

7. Nella finestra di dialogo Backup database fare clic su OK per accettare tutte le impostazioni predefinite e creare il backup.

Informazioni sulle repliche e sulla sincronizzazione dei dati

È necessario avere familiarità con le informazioni seguenti sulle repliche e sulla sincronizzazione dei dati prima di creare e configurare i gruppi di disponibilità per la farm di SharePoint.

Informazioni sulle repliche

A ogni replica di disponibilità è assegnato un ruolo iniziale, ovvero il ruolo primario o il ruolo secondario, che viene ereditato dai database di disponibilità di tale replica. Il ruolo di una certa replica determina se ospita database di lettura/scrittura oppure database di sola lettura, il tipo di failover e se utilizza il commit sincrono o asincrono.

Nella tabella seguente sono riportate le informazioni da specificare per ogni replica quando si crea inizialmente il gruppo di disponibilità o quando si aggiungono repliche secondarie.

Requisiti per la configurazione delle repliche

Informazioni relative alla replica	Descrizione
Istanza del server	Visualizza il nome dell'istanza del server in cui sarà ospitata la replica di disponibilità.
Ruolo iniziale	Indica il ruolo che svolgerà inizialmente la nuova replica, ovvero primario o secondario.
Failover automatico (fino a 2)	Indica il tipo di failover utilizzato dalla replica, ovvero automatico o manuale.
Commit sincrono (fino a 3)	Indica il tipo di commit utilizzato per la replica.
Secondario leggibile	Indica se una replica secondaria può essere letta. Le opzioni di configurazione non sono disponibili per l'accesso in lettura, la sola lettura e la finalità di sola lettura. Per ulteriori informazioni, vedere Repliche secondarie attive: repliche secondarie leggibili (gruppi di disponibilità AlwaysOn) e Configurare l'accesso in sola lettura in una replica di disponibilità (SQL Server). Nota In SQL Server 2014 e versioni successive, le repliche secondarie leggibili continuano a essere disponibili per i carichi di lavoro di lettura quando sono scollegate dalle repliche principali o durante una perdita di quorum del cluster.

Sincronizzazione dei dati

Durante il processo di creazione di un gruppo di disponibilità, è necessario effettuare una copia esatta dei dati presenti nella replica primaria e installare la copia nella replica secondaria. Questa è la sincronizzazione dati iniziale per il gruppo di disponibilità. Per ulteriori informazioni, vedere Pagina Seleziona sincronizzazione dati iniziale (procedure guidate Gruppi di disponibilità AlwaysOn).

Deve esistere una condivisione di rete a cui devono accedere tutti i nodi nella configurazione AlwaysOn per eseguire la sincronizzazione dati iniziale fra tutti i nodi del cluster che ospitano una replica. Per ulteriori informazioni, vedere Estensione Condivisioni di rete e Panoramica dei servizi di archiviazione e file.

Quando si utilizza la Creazione guidata Gruppo di disponibilità per avviare la sincronizzazione dei dati, si applicano le restrizioni seguenti:

• Se i percorsi file nel percorso della replica secondaria sono diversi dai percorsi file nel percorso primario, sarà necessario avviare manualmente la sincronizzazione dei dati.

• Se in una replica secondaria esiste un qualsiasi database secondario, sarà necessario eliminare manualmente i database secondari prima di avviare la sincronizzazione dei dati nella Creazione guidata Gruppo di disponibilità. Se però si desidera utilizzare i database secondari esistenti, uscire dalla Creazione guidata Gruppo di disponibilità e avviare manualmente la sincronizzazione dei dati.

• Per poter utilizzare la Creazione guidata Gruppo di disponibilità per sincronizzare i dati, è necessario disporre di una condivisione di backup in cui possano scrivere tutte le repliche. È possibile specificare la condivisione selezionandola o immettendone il percorso UNC (Universal Naming Convention) completo, \\NomeSistema\NomeCondivisione\Percorso\, nella casella Specificare un percorso di rete condiviso accessibile da tutte le repliche.

Per ogni database incluso nel gruppo di disponibilità, nella pagina di avvio della sincronizzazione dei dati viene visualizzato lo stato di avanzamento delle operazioni seguenti:

• Creazione di un backup completo del database primario nella condivisione di rete

• Ripristino di questi backup nel percorso della replica secondaria

  Queste operazioni di ripristino utilizzano entrambe l'opzione RESTORE WITH NORECOVERY e lasciano il nuovo database secondario nello stato RESTORING.

• Aggiunta del database secondario al gruppo di disponibilità

  Con questo passaggio il database secondario viene impostato sullo stato ONLINE e la sincronizzazione dei dati viene avviata per tale database.

Replica degli account di accesso

Gli account di accesso di SharePoint creati utilizzando lo stesso approccio delle versioni precedenti di SQL Server non vengono replicati in un gruppo di disponibilità. Questa situazione si verifica perché le informazioni di accesso sono archiviate nel database MasterDB, che non viene replicato. Anche se gli account di farm vengono creati durante la sincronizzazione delle repliche, le informazioni di accesso non sono disponibili dopo un failover.

Se si è già provveduto a creare un gruppo di disponibilità e a sincronizzare le repliche primaria e secondarie, è possibile ovviare al problema copiando manualmente gli account di accesso dalla replica primaria alle repliche secondarie.

In SQL Server 2012 è stato introdotto il concetto di utenti con password per database indipendenti. In questo caso, nel database sono archiviati tutti i relativi metadati e le informazioni degli utenti, pertanto un utente definito in tale database non deve disporre di un account di accesso corrispondente. Le informazioni presenti in questo database vengono replicate dal gruppo di disponibilità e sono disponibili dopo un failover. Per ulteriori informazioni, vedere Database indipendenti.

Creare e configurare il gruppo di disponibilità

Attenersi alla procedura seguente per creare un gruppo di disponibilità nella replica primaria, ovvero SP-SRV1 in questo esempio.

Creare il gruppo di disponibilità

1. Verificare che il proprio account di accesso disponga delle autorizzazioni necessarie per creare un gruppo di disponibilità. Sono necessarie l'appartenenza al ruolo predefinito del database db_owner e l'autorizzazione CREATE AVAILABILITY GROUP per il server, l'autorizzazione CONTROL AVAILABILITY GROUP, l'autorizzazione ALTER ANY AVAILABILITY GROUP o l'autorizzazione CONTROL SERVER.

2. Eseguire l'accesso al server in cui sarà ospitata la replica primaria e avviare SQL Server Management Studio.

3. Per avviare la Creazione guidata Gruppo di disponibilità, fare clic con il pulsante destro del mouse su Disponibilità elevata AlwaysOn e quindi scegliere Creazione guidata Gruppo di disponibilità.

4. Fare clic su Avanti per passare alla pagina Specifica nome. Immettere SP-AG1 come nome del nuovo gruppo di disponibilità nella casella Nome gruppo di disponibilità.

   Questo nome deve essere un identificatore di SQL Server valido, univoco nel cluster WSFC (Windows Server Failover Clustering) e univoco nel dominio.

5. Nella pagina Selezione database tutti i database utente idonei per diventare il database primario per il nuovo gruppo di disponibilità sono elencati nella griglia Database utente in questa istanza di SQL Server. Selezionare TemporaryUserDB e quindi fare clic su Avanti.

6. Nella pagina Specifica repliche utilizzare le schede seguenti per configurare le repliche per SP-AG1: Repliche, Endpoint e Preferenze di backup.

7. Un listener del gruppo di disponibilità è un nome di rete virtuale che fornisce connettività client al database a un determinato gruppo di disponibilità. I listener dei gruppi di disponibilità indirizzano le connessioni in ingresso alla replica primaria oppure a una replica secondaria di sola lettura. Il listener garantisce un rapido failover delle applicazioni dopo il failover di un gruppo di disponibilità. Per ulteriori informazioni, vedere Listener del gruppo di disponibilità, connettività client e failover dell'applicazione (SQL Server).

   Nella scheda Listener configurare un listener del gruppo di disponibilità per questo esempio utilizzando il nome AGListener.

   Importante

   Può verificarsi una latenza intermittente insolitamente elevata quando si utilizzano gruppi di disponibilità con repliche distribuite in più subnet.
   Come procedura consigliata, le connessioni ai gruppi di disponibilità di SharePoint in un ambiente con più subnet dovrebbero configurare specifyMultiSubnetFailover=True per evitare i problemi causati da un'elevata latenza di rete. Per ulteriori informazioni, vedere Listener del gruppo di disponibilità, connettività client e failover dell'applicazione (SQL Server.

   Non è possibile specificare direttamente MultiSubnetFailover=True perché un client di SharePoint non può modificare direttamente una stringa di connessione. È necessario utilizzare PowerShell per impostare tale valore nella proprietà di database MultiSubnetFailover. Nell'esempio seguente viene mostrato come procedere.

   $dbs = Get-SPDatabase | ?{$_.MultiSubnetFailover -ne $true}
        foreach ($db in $dbs)
        {
             $db.MultiSubnetFailover = $true
              $db.Update()
        }
   

8. Selezionare la configurazione desiderata per ogni istanza nella griglia delle istanze selezionate e quindi fare clic su Avanti.

9. Fare clic su Fine per creare il gruppo di disponibilità.

10. La pagina Seleziona sincronizzazione dati iniziale consente di selezionare una preferenza di sincronizzazione e di specificare il percorso di rete condiviso a cui possono accedere tutte le repliche. Per questo ambiente accettare l'impostazione predefinita, Completo, che consente di effettuare backup di database e log completi. Fare clic su Avanti.

11. Nella pagina Convalida della procedura guidata verranno visualizzati i risultati di sei verifiche prima che sia possibile continuare con la creazione del gruppo di disponibilità. Se vengono superate tutte le verifiche, fare clic su Avanti per proseguire. Se uno qualsiasi dei test ha esito negativo, non è possibile proseguire finché l'errore non verrà corretto e non si farà clic su Ripeti convalida per eseguire di nuovo i test di convalida. Quando tutti i test hanno esito positivo, fare clic su Avanti per continuare.

12. Nella pagina Riepilogo verificare la configurazione della replica da aggiungere e quindi fare clic su Fine per salvarla. Per modificare la configurazione, fare clic su Indietro per tornare alle pagine precedenti della procedura guidata.

Installare e configurare SharePoint Server

A questo punto del processo è possibile installare SharePoint Server e creare la farm. Utilizzare la procedura seguente come riferimento per installare e configurare SharePoint Server.

Per installare SharePoint Server

1. Copiare i file di programma di SharePoint Server su un disco locale nel computer in cui si intende installare SharePoint oppure in una condivisione file di rete.

2. Eseguire l'Utilità preparazione prodotti Microsoft SharePoint per installare tutti i prerequisiti per impostare e utilizzare SharePoint Server.

3. Eseguire il programma di installazione per installare i file binari, configurare le autorizzazioni di sicurezza e modificare le impostazioni del Registro di sistema per SharePoint Server.

4. Eseguire Configurazione guidata Prodotti SharePoint per installare e configurare il database di configurazione, per installare e configurare il database del contenuto, nonché per installare Amministrazione centrale.

5. Nella casella Server database della pagina Specifica impostazioni database di configurazione digitare AGListener come nome del computer che esegue SQL Server.

   Importante

   Per fornire il failover automatico, è necessario specificare il nome del listener del gruppo di disponibilità come nome del database per SharePoint Server.

Aggiungere i database di SharePoint al gruppo di disponibilità

Per finalizzare l'impostazione di AlwaysOn per una farm di SharePoint Server, aggiungere i database di SharePoint al gruppo di disponibilità e sincronizzare le repliche secondarie con la replica primaria.

Nel server che ospita la replica primaria è necessario eseguire l'apposita procedura guidata per aggiungere tutti i database di SharePoint al gruppo di disponibilità. La procedura che segue è uguale a quella descritta per creare il gruppo di disponibilità.

Per aggiungere i database di SharePoint al gruppo di disponibilità

1. Eseguire l'accesso al server in cui sarà ospitata la replica primaria e avviare SQL Server Management Studio.

   L'account utilizzato deve essere membro del gruppo degli amministratori locali per ogni server in cui si installa SharePoint Server

   L'account deve inoltre disporre di almeno una delle autorizzazioni seguenti:

   • Autorizzazione ALTER AVAILABILITY GROUP per il gruppo di disponibilità

   • Autorizzazione CONTROL AVAILABILITY GROUP

   • Autorizzazione ALTER ANY AVAILABILITY GROUP

   • Autorizzazione CONTROL SERVER

   Per aggiungere un database a un gruppo di disponibilità, è necessario essere membri del ruolo predefinito del database db_owner.

2. In Esplora oggetti selezionare e, se necessario, espandere i gruppi di disponibilità.

3. Fare clic con il pulsante destro del mouse sul gruppo di esempio, SP-AG1, e quindi scegliere Aggiungi database.

4. Nella pagina Selezione database tutti i database utente idonei per diventare il database primario per il nuovo gruppo di disponibilità sono elencati nella griglia Database utente in questa istanza di SQL Server. Utilizzare le caselle di controllo per selezionare tutti i database che si desidera aggiungere al gruppo e quindi fare clic su Avanti.

5. La pagina Seleziona sincronizzazione dati iniziale consente di selezionare una preferenza di sincronizzazione e di specificare il percorso di rete condiviso a cui possono accedere tutte le repliche. Per questo ambiente verrà accettata l'impostazione predefinita, Completo, che consente di effettuare backup di database e log completi. Fare clic su Avanti.

6. Nella pagina Convalida della procedura guidata verranno visualizzati i risultati di sei verifiche prima che sia possibile continuare con la creazione del gruppo di disponibilità. Se uno qualsiasi dei test ha esito negativo, non è possibile proseguire finché l'errore non verrà corretto e non si farà clic su Ripeti convalida per eseguire di nuovo i test di convalida. Quando tutti i test hanno esito positivo, fare clic su Avanti per continuare.

7. Nella pagina Riepilogo verificare la configurazione della replica da aggiungere e quindi fare clic su Fine per mantenerla. Per modificare la configurazione, fare clic su Indietro per tornare alle pagine precedenti della procedura guidata.

Utilizzare test del failover per convalidare l'installazione AlwaysOn

Dopo avere sincronizzato i dati di SharePoint con le repliche secondarie, il passaggio finale consiste nel testare il failover.

È necessario eseguire test di failover completi per verificare che il comportamento dell'ambiente AlwaysOn sia quello previsto e che siano perfettamente chiari i requisiti e le procedure di configurazione relativi ai gruppi di disponibilità di SQL Server 2014 (SP1), SQL Server 2016 o SQL Server 2012. Tali test includono, tra le altre cose, le attività seguenti:

• Verificare che tutti i servizi e le funzionalità della farm siano completamente funzionanti.

• Verificare che i dati di SharePoint Server siano stati mantenuti e non siano danneggiati.

Testare il failover dei gruppi di disponibilità utilizzando il failover manuale pianificato o il failover manuale forzato descritti negli articoli seguenti:

SQL Server 2012

• Eseguire un failover manuale pianificato di un gruppo di disponibilità (SQL Server)

• Eseguire un failover manuale forzato di un gruppo di disponibilità (SQL Server)

SQL Server 2014 (SP1)

• Eseguire un failover manuale pianificato di un gruppo di disponibilità (SQL Server)

• Eseguire un failover manuale forzato di un gruppo di disponibilità (SQL Server)

SQL Server 2016

• Eseguire un failover manuale pianificato di un gruppo di disponibilità (SQL Server)

• Eseguire un failover manuale forzato di un gruppo di disponibilità (SQL Server)

È possibile eseguire uno di questi tipi di failover utilizzando la procedura di failover guidata in SQL Server Management Studio, Transact-SQL o PowerShell in SQL Server 2014 (SP1), SQL Server 2016 e SQL Server 2012.

Monitorare l'ambiente AlwaysOn

È necessario monitorare un ambiente AlwaysOn per verificarne le prestazioni, lo stato e la capacità.

Prestazioni

I seguenti nuovi oggetti prestazioni sono disponibili per monitorare un ambiente AlwaysOn.

SQL Server 2012

• SQL Server: replica di database

• SQL Server: replica di disponibilità

SQL Server 2014 (SP1)

• SQL Server, Replica di database

• SQL Server, Replica di disponibilità

SQL Server 2016

• SQL Server, Replica di database

• SQL Server, Replica di database

Stato e capacità

Per un monitoraggio dello stato generale, è possibile utilizzare il dashboard dei gruppi di disponibilità per ottenere lo stato dei gruppi di disponibilità presenti nel sistema. Per ulteriori informazioni, vedere Criteri Always On per problemi operativi con gruppi di disponibilità Always On (SQL Server) per SQL Server 2014 (SP1) e Criteri AlwaysOn per problemi operativi con gruppi di disponibilità AlwaysOn (SQL Server) per SQL Server 2016. Per ulteriori informazioni su SQL Server 2012, vedere gli argomenti seguenti:

• Modello dello stato di AlwaysOn Parte 1 - Architettura del modello dello stato

• Modello dello stato di AlwaysOn Parte 2 - Estensione del modello dello stato

È inoltre possibile utilizzare Transact-SQL per monitorare i gruppi di disponibilità con il set di viste del catalogo e DMV (Dynamic Management View) fornite per i gruppi di disponibilità AlwaysOn. Per ulteriori informazioni, vedere Monitorare Gruppi di disponibilità (Transact-SQL) per SQL Server 2014 (SP1) e Monitorare Gruppi di disponibilità (Transact-SQL) per SQL Server 2016.

See also

Installare e configurare SharePoint Server 2016

Distribuzione di SharePoint Server 2016 con gruppi di disponibilità AlwaysOn di SQL Server in Azure