Configurare i gruppi di disponibilità AlwaysOn di SQL Server per SharePoint Server
SI APPLICA A:
2013 2016 2019 Subscription Edition 
SharePoint in Microsoft 365
Questo articolo include le informazioni necessarie e le procedure dettagliate per creare e configurare un gruppo di disponibilità AlwaysOn di Microsoft SQL Server per una farm di SharePoint Server o Foundation.
Importante
La procedura descritta in questo articolo mostra come distribuire una nuova farm di SharePoint e non riguarda l'aggiornamento da SQL Server 2008 R2 a una versione più recente di SQL Server.
Importante
Verificare la compatibilità della versione di SQL Server con la versione di SharePoint che si intende distribuire.
Requisiti hardware e software per SharePoint 2013
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 in ogni nodo del cluster.
Creare e configurare un gruppo di disponibilità.
Installare e configurare SharePoint Server o SharePoint 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:
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
SharePoint Server o 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), SQL Server 2016 e SQL Server 2017 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à.
Per ulteriori informazioni, vedere 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 altre informazioni sulla modalità commit sincrona e asincrona, vedere Modalità di disponibilità (gruppi di disponibilità AlwaysOn).
Nota
I problemi relativi a un database, che ad esempio diventa sospetto a seguito della perdita di un file di dati, l'eliminazione di un database o il danneggiamento di un log delle transazioni non causano failover.
Per ulteriori informazioni sui concetti principali relativi alla tecnologia SQL Server AlwaysOn, leggere gli articoli seguenti:
Per informazioni dettagliate sui vantaggi dei gruppi di disponibilità Always On e una panoramica dei termini dei gruppi di disponibilità Always On, vedere Gruppi di disponibilità Always On (SQL Server).
Per altre informazioni sui prerequisiti, vedere Prerequisiti, restrizioni e consigli relativi ai gruppi di disponibilità AlwaysOn.
Importante
È possibile installare SQL Server nel core di Windows Server per migliorare la sicurezza e ridurre la manutenzione, ma non è possibile installare SharePoint Server in Windows Server core. Per ulteriori informazioni, vedere l'articolo relativo a Server Core per Windows Server 2008 R2. Per informazioni su Server Core e Windows Server 2012, vedere Opzioni di installazione di Windows Server.
Windows Server Failover Clustering
Per creare e usare i gruppi di disponibilità Always On di SQL Server, è necessario installare entrambe le versioni di SQL Server in un cluster WSFC (Windows Server Failover Clustering). Per altre informazioni, vedere Windows Server Failover Clustering (WSFC) con SQL Server e per SQL Server 2016 e 2017, Windows Server Failover Clustering (WSFC) con SQL Server.
Per creare e usare i gruppi di disponibilità Always On di SQL Server, è necessario installare SQL Server in un cluster WSFC (Windows Server Failover Clustering).
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 i nodi del cluster devono trovarsi nello stesso dominio di Servizi di dominio Active Directory.
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 altre informazioni, vedere Modalità quorum WSFC e configurazione del voto (SQL Server) e Configurare le impostazioni NodeWeight per il quorum del cluster.
SharePoint Server e SharePoint Foundation 2013
Alcuni database di SharePoint Server non supportano i gruppi di disponibilità AlwaysOn di SQL Server. Prima di configurare un ambiente Always On, è consigliabile esaminare le opzioni Di disponibilità elevata e ripristino di emergenza supportate per i database di SharePoint .
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 o creare un cluster WSFC (Windows Server Failover Clustering) a tre nodi che è possibile usare per installare SQL Server in ogni nodo del cluster. Per informazioni e passaggi dettagliati per configurare un cluster di failover di Windows Server, vedere Clustering di failover.
Preparare l'ambiente SQL Server
Per poter creare un gruppo di disponibilità per SharePoint Server, è necessario predisporre l'ambiente di SQL Server.
Quando si prepara l'ambiente server di database, è necessario tenere conto dei requisiti dei database di SharePoint Server. Prima di installare SQL Server, consultare gli articoli seguenti:
Installare SharePoint 2013 in più server per una farm su tre livelli
Configurare la sicurezza di SQL Server per SharePoint Server
A tale scopo, eseguire le attività seguenti:
Installare i prerequisiti per SQL Server.
Installare SQL Server
Abilitare AlwaysOn.
Installare SQL Server 2012
Per installare SQL Server 2012
Installare i prerequisiti per SQL Server 2012 in ogni nodo del cluster.
Per altre informazioni, vedere Prerequisiti, restrizioni e consigli per i gruppi di disponibilità AlwaysOn (SQL Server).
Installare SQL Server in ogni nodo del cluster.
Per altre informazioni, vedere Installazione per SQL Server 2012.
Installare SQL Server 2014 (SP1)
Utilizzare la procedura seguente per installare SQL Server 2014 (SP1).
Per installare SQL Server 2014 (SP1)
Installare i prerequisiti per SQL Server 2014 (SP1) in ogni nodo del cluster.
Per altre informazioni, vedere Requisiti hardware e software per l'installazione di SQL Server 2014 e Prerequisiti, restrizioni e raccomandazioni per i gruppi di disponibilità AlwaysOn (SQL Server).
Installare SQL Server in ogni nodo del cluster.
Per altre informazioni, vedere Installazione di SQL Server 2014 - Esercitazione dettagliata.
Installare SQL Server 2016 o SQL Server 2017
Usare la procedura seguente per installare SQL Server 2016 o 2017.
Per installare SQL Server 2016 o SQL Server 2017
Installare i prerequisiti di SQL Server in ogni nodo del cluster.
Per altre informazioni, vedere Installare SQL Server.
Installare SQL Server in ogni nodo del cluster.
Per altre informazioni, vedere Installazione del cluster di failover di SQL Server.
Abilitare AlwaysOn
È necessario abilitare AlwaysOn per ogni server di database del cluster.
Nota
È possibile abilitare AlwaysOn tramite SQL Server Management Studio, Transact-SQL o Windows PowerShell.
Per abilitare AlwaysOn
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.
Eseguire l'accesso al server in cui sarà ospitata la replica primaria e avviare Gestione configurazione SQL Server.
In Esplora oggetti selezionare Servizi SQL Server, fare clic con il pulsante destro del mouse su SQL Server (<nome> istanza), dove <nome> istanza è il nome di un'istanza del server locale per cui si desidera abilitare i gruppi di disponibilità AlwaysOn e quindi fare clic su Proprietà.
Selezionare la scheda Disponibilità elevata AlwaysOn .
Selezionare la casella di controllo Abilita gruppi di disponibilità AlwaysOn e quindi fare clic su OK.
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.
Ripetere i passaggi precedenti per abilitare AlwaysOn per SQL Server negli altri nodi del cluster.
Per altre informazioni, vedere Abilitare e disabilitare i gruppi di disponibilità AlwaysOn (SQL Server).
Creare e configurare il gruppo di disponibilità
A seconda dell'ambiente SQL Server 2014 (SP1), SQL Server 2016/2017 o SQL Server 2012 in cui si intende creare il gruppo di disponibilità, potrebbe essere necessario creare un database temporaneo da usare 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.
Nota
[!NOTA] Per poter essere aggiunto a un gruppo di disponibilità, un database deve essere un database utente. I database di sistema non possono appartenere a un gruppo di disponibilità. Per altre informazioni, vedere la sezione "Prerequisiti e restrizioni del database di disponibilità" di Prerequisiti, restrizioni e raccomandazioni per i gruppi di disponibilità AlwaysOn (SQL Server) e vedere Creazione e configurazione di gruppi di disponibilità (SQL Server).
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
- 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
Eseguire l'accesso al server in cui verrà ospitata la replica primaria, ovvero SP-SRV1 in questo esempio.
Avviare Management Studio.
In Esplora oggetti fare clic con il pulsante destro del mouse su Database e quindi scegliere Nuovo database.
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.
In Esplora oggetti espandere Database e fare clic con il pulsante destro del mouse sul database temporaneo appena creato. Selezionare Attività e quindi scegliere Backup.
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.
Nota
Il numero massimo di repliche secondarie è aumentato da 4 a 8 in SQL Server 2014 e versioni successive.
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 altre informazioni, vedere Offload del carico di lavoro di sola lettura nella replica secondaria di un gruppo di disponibilità Always On e Configurare il routing Read-Only per un gruppo 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. |
Nota
SharePoint Server non sfrutta le repliche di sola lettura. Userà solo la replica primaria nel gruppo di disponibilità.
Nota
[!NOTA] Quando si aggiungono repliche a un gruppo, è inoltre necessario specificare l'endpoint per ogni replica e configurare le preferenze di backup. Per altre informazioni, vedere Specificare l'URL dell'endpoint durante l'aggiunta o la modifica di una replica di disponibilità (SQL Server) e secondarie attive: backup in repliche secondarie (gruppi di disponibilità AlwaysOn).
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 altre informazioni, vedere Pagina Selezione sincronizzazione dati iniziale (Creazioni guidate gruppo 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 altre informazioni, vedere Estensione e archiviazione delle condivisionidi rete.
Quando si usa 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 immettendo il nome del percorso UNC (Universal Naming Convention) completo, \Systemname\ShareName\Path, 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à. Ciò si verifica perché le informazioni di accesso vengono archiviate nel database master, 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.
Consultare l'articolo Come trasferire account di accesso e password tra istanze di SQL Server per copiare gli account di accesso tra istanze di SQL Server.
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à
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.
Eseguire l'accesso al server in cui sarà ospitata la replica primaria e avviare SQL Server Management Studio.
Per avviare la Creazione guidata nuovo gruppo di disponibilità, fare clic con il pulsante destro del mouse su Disponibilità elevata AlwaysOn e quindi scegliere Creazione guidata nuovo gruppo di disponibilità.
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 e univoco nel dominio.
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.
Nella pagina Specifica repliche utilizzare le schede seguenti per configurare le repliche per SP-AG1: Repliche, Endpoint e Preferenze di backup.
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 altre informazioni, vedere Connettersi a un listener del gruppo di disponibilità Always On.
Nella scheda Listener configurare un listener del gruppo di disponibilità per questo esempio usando il nome AGListener.
Importante
[!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 Supporto del failover su più subnet del gruppo di disponibilità.
Non è possibile specificare direttamente MultiSubnetFailover=True perché un client di SharePoint non può modificare direttamente una stringa di connessione. È necessario usare PowerShell tramite SharePoint Management Shell per impostare questo valore nella proprietà del database MultiSubnetFailover . Nell'esempio seguente viene mostrato come procedere.
$dbs = Get-SPDatabase | ?{$_.MultiSubnetFailover -ne $true}
foreach ($db in $dbs)
{
$db.MultiSubnetFailover = $true
$db.Update()
}
Selezionare la configurazione desiderata per ogni istanza nella griglia delle istanze selezionate e quindi fare clic su Avanti.
Fare clic su Fine per creare il gruppo di disponibilità.
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.
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.
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.
Nota
Per istruzioni dettagliate sull'installazione e sulla configurazione, vedere Installare SharePoint Server 2019, Installare SharePoint Server 2016 o Installare SharePoint 2013.
Per installare SharePoint Server
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.
Eseguire l'Utilità preparazione prodotti Microsoft SharePoint per installare tutti i prerequisiti per impostare e utilizzare SharePoint Server.
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.
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.
Nella casella Server database della pagina Specifica impostazioni database di configurazione digitare AGListener come nome del computer che esegue SQL Server. 7
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.
Importante
[!IMPORTANTE] Aggiungere solo i database supportati per l'utilizzo con un gruppo di disponibilità SQL Server AlwaysOn. Per ulteriori informazioni, vedere Opzioni di disponibilità elevata e di ripristino di emergenza supportate per database di SharePoint
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à
Eseguire l'accesso al server in cui sarà ospitata la replica primaria e avviare SQL Server Management Studio.
L'account deve 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.
In Esplora oggetti selezionare e, se necessario, espandere i gruppi di disponibilità.
Fare clic con il pulsante destro del mouse sul gruppo di esempio, SP-AG1, e quindi scegliere Aggiungi database.
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.
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.
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.
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.
Importante
[!IMPORTANTE] I database aggiunti a una farm di SharePoint non vengono aggiunti automaticamente al gruppo di disponibilità. È necessario aggiungerli eseguendo i passaggi descritti in questo articolo o utilizzando script per automatizzare la procedura.
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 assicurarsi che il comportamento dell'ambiente Always On sia quello previsto e che si comprendano completamente i requisiti di configurazione e le procedure correlate ai gruppi di disponibilità di SQL Server. 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à usando il failover manuale pianificato o il failover manuale forzato descritti negli articoli seguenti:
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 usando la procedura di failover guidata in SQL Server Management Studio, Transact-SQL o PowerShell in SQL Server.
Nota
Nel caso di uno scenario con cluster di failover attivo-attivo in cui più istanze di SharePoint possono eseguire il failover l'una all'altra, è necessario accertarsi che ogni server disponga di capacità sufficiente per gestire il carico di lavoro locale e il carico di lavoro del server con problemi.
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 2014 (SP1)
SQL Server 2016 e SQL Server 2017
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 altre informazioni, vedere Criteri Always On per problemi operativi con gruppi di disponibilità Always On (SQL Server) per SQL Server 2014 (SP1) e Criteri Always On per problemi operativi - Disponibilità Always On per SQL Server 2016 e SQL Server 2017. Per ulteriori informazioni su SQL Server 2012, vedere gli argomenti seguenti:
Modello Always On Health - Parte 1 - Architettura del modello di integrità
Parte 2 del modello di integrità Always On - Estensione del modello di integrità
È 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 altre informazioni, vedere Monitorare i gruppi di disponibilità (Transact-SQL) per SQL Server 2014 (SP1) e Monitorare i gruppi di disponibilità (Transact-SQL) per SQL Server 2016 e SQL Server 2017.
Vedere anche
Concetti
Installare e configurare SharePoint Server 2016
Ulteriori risorse
Distribuzione di SharePoint Server con i gruppi di disponibilità SQL Server Always On in Azure