Reporting Services con i gruppi di disponibilità Always On (SQL Server)

Si applica a:SQL Server

Questo articolo contiene informazioni su come configurare Reporting Services per funzionare con i gruppi di disponibilità Always On (AG) in SQL Server. I tre scenari per l'uso di Reporting Services e dei gruppi di disponibilità Always On sono i database per le origini dati dei report, i database del server di report e la progettazione di report. La funzionalità supportata e la configurazione richiesta sono diverse per i tre scenari.

Un vantaggio fondamentale derivante dall'uso dei gruppi di disponibilità Always On con le origini dati di Reporting Services è la possibilità di usare le repliche secondarie leggibili come origine dati per la creazione di report, mentre al tempo stesso le repliche secondarie fungono da failover del database primario.

Per informazioni generali sui Gruppi di disponibilità AlwaysOn, vedere Domande frequenti su AlwaysOn per SQL Server 2012 (../../../sql-server/index.yml).

Requisiti per l'uso di Reporting Services e dei gruppi di disponibilità AlwaysOn

SQL Server Reporting Services e il server di report di Power BI usano .NET Framework 4.0 e supportano le proprietà della stringa di connessione dei Gruppi di disponibilità AlwaysOn per l'uso con le origini dati.

Per usare i Gruppi di disponibilità AlwaysOn con Reporting Services 2014 e versioni precedenti, è necessario scaricare e installare un hotfix per .NET 3.5 SP1. L'hotfix aggiunge a SQL Client il supporto per le funzionalità AG e per le proprietà della stringa di connessione ApplicationIntent e MultiSubnetFailover. Se l'hotfix non viene installato in ogni computer in cui si trova il server di report, allora gli utenti che provano a visualizzare un'anteprima dei report visualizzeranno un messaggio di errore simile a quello di seguito riportato e questo verrà scritto nel log di traccia del server di report:

Messaggio di errore: "Parola chiave non supportata 'applicationintent'"

Il messaggio viene visualizzato quando si include una delle proprietà dei Gruppi di disponibilità AlwaysOn nella stringa di connessione di Reporting Services, ma il server non riconosce la proprietà. Il messaggio di errore annotato viene visualizzato quando si fa clic sul pulsante "Verifica connessione" nelle interfacce utente di Reporting Services e quando viene visualizzata l'anteprima del report nel caso in cui vengano abilitati errori remoti nei server di report.

Per ulteriori informazioni sull'hotfix richiesto, vedere l'articolo della Knowledge Base KB 2654347 Un hotfix introduce il supporto per le funzionalità Always On da SQL Server 2012 a .NET Framework 3.5 SP1.

Per informazioni su altri requisiti dei Gruppi di disponibilità AlwaysOn, vedere Prerequisiti, restrizioni e consigli per i gruppi di disponibilità AlwaysOn (SQL Server).

Origine dati del report e gruppi di disponibilità

Il comportamento delle origini dati di Reporting Services basate sui gruppi di disponibilità Always On può variare a seconda di come l'amministratore ha configurato l'ambiente AG.

Per usare i gruppi di disponibilità Always On per le origini dati dei report, è necessario configurare la stringa di connessione delle origini dati dei report in modo che usi il nome DNS del listener del gruppo di disponibilità. Vengono di seguito riportate le origini dati supportate:

• Origine dati ODBC che usa SQL Native Client.

• SQL Client con l'hotfix .NET applicato al server di report.

La stringa di connessione può anche contenere nuove proprietà di connessione AlwaysOn che configurano le richieste della query del report in modo da usare la replica secondaria per il report di sola lettura. L'utilizzo della replica secondaria per le richieste di report riduce il carico nella replica primaria di lettura e scrittura. L'illustrazione seguente mostra un esempio di una configurazione AG a tre repliche in cui le stringhe di connessione dell'origine dati di Reporting Services sono state configurate con ApplicationIntent=ReadOnly. In questo esempio, le richieste della query di report vengono inviate a una replica secondaria e non alla replica primaria.

Di seguito viene riportata una stringa di connessione di esempio in cui [AvailabilityGroupListenerName] è il Nome DNS del listener configurato al momento della creazione delle repliche:

Data Source=[AvailabilityGroupListenerName];Initial Catalog = AdventureWorks2022; ApplicationIntent=ReadOnly

Il pulsante Verifica connessione nelle interfacce utente di Reporting Services verifica se è possibile stabilire una connessione, ma non convalida la configurazione del gruppo di disponibilità (AG). Ad esempio, se si include ApplicationIntent in una stringa di connessione a un server che non fa parte di un AG, il parametro aggiuntivo viene ignorato e il pulsante Test connessione verifica solo che sia possibile stabilire una connessione al server specificato.

In base alla modalità di creazione e pubblicazione dei report verrà determinato dove si modifica la stringa di connessione:

• Modalità nativa: usare il portale Web per le origini dati condivise e i report già pubblicati in un server di report in modalità nativa.

• Modalità SharePoint: utilizzare le pagine di configurazione SharePoint all'interno delle librerie del documento per i report già pubblicati in un server SharePoint.

• Progettazione dei report: Report Builder o SQL Server Data Tools (SSDT) per creare nuovi report. Per altre informazioni, vedere la sezione “Progettazione report” in questo articolo.

Risorse aggiuntive:

• Gestire origini dati dei report

• Per altre informazioni sulle proprietà della stringa di connessione disponibili, vedere Using Connection String Keywords with SQL Server Native Client.

• Per altre informazioni sui listener del gruppo di disponibilità, vedere Creare o configurare un listener del gruppo di disponibilità (SQL Server).

Considerazioni: le repliche secondarie subiranno dei ritardi nella ricezione di modifiche di dati rispetto alla replica primaria. I seguenti fattori possono influenzare la latenza di aggiornamento tra la replica primaria e quella secondaria:

• Numero di repliche secondarie. Il ritardo aumenta con ogni replica secondaria aggiunta alla configurazione.

• Posizione geografica e distanza tra la replica primaria e quella secondaria. Ad esempio, il ritardo è in genere maggiore se le repliche secondarie si trovano in centri dati diversi piuttosto che nello stesso edificio della replica primaria.

• Configurazione della modalità di disponibilità per ogni replica. La modalità di disponibilità determina se la replica primaria dovrà attendere la scrittura su disco delle transazioni prima di eseguire il commit delle transazioni su un database. Per altre informazioni, vedere la sezione 'Modalità di disponibilità' di Panoramica dei Gruppi di disponibilità AlwaysOn (SQL Server).

Quando si utilizza una replica secondaria di sola lettura come origine dati di Reporting Services, è importante garantire che la latenza di aggiornamento dei dati soddisfi le esigenze degli utenti dei report.

Progettazione di report e gruppi di disponibilità

Durante la progettazione di report in Generatore report o di un progetto report in SQL Server Data Tools (SSDT), un utente può configurare una stringa di connessione dell'origine dati del report in modo che contenga nuove proprietà di connessione fornite dai Gruppi di disponibilità AlwaysOn. Il supporto per le nuove proprietà di connessione dipende da dove l'utente visualizza l'anteprima del report.

• Anteprima locale: Generatore report e SQL Server Data Tools (SSDT) usano .NET Framework 4.0 e supportano le proprietà della stringa di connessione dei Gruppi di disponibilità AlwaysOn.

• Anteprima modalità server o remota: se viene visualizzato un messaggio di errore simile a quello riportato di seguito dopo la pubblicazione dei report nel server di report o dopo l'uso dell'anteprima in Generatore report, questo significa che si sta visualizzando l'anteprima dei report nel server di report e che l'hotfix di .NET Framework 3.5 SP1 per i Gruppi di disponibilità AlwaysOn non è stato installato nel server di report.

Messaggio di errore: "Parola chiave non supportata 'applicationintent'"

Database di Report Server e gruppi di disponibilità

Reporting Services e il server di report di Power BI offrono supporto limitato nell'uso dei Gruppi di disponibilità AlwaysOn con i database del server di report. I database del server di report possono essere configurati in un AG per far parte di una replica; tuttavia, quando si verifica un failover, Reporting Services non utilizzerà automaticamente una replica diversa per i database del server di report. L'utilizzo di MultiSubnetFailover con i database del server di report non è supportato.

Le azioni manuali o gli script di automazione personalizzati devono essere usati per completare il failover e il recupero. Fino al completamento di queste azioni, alcune funzionalità del server di report potrebbero non funzionare correttamente dopo il failover dei Gruppi di disponibilità AlwaysOn.

Differenze tra la modalità nativa di SharePoint

Questa sezione contiene un riepilogo delle differenze tra la modalità di interazione dei server di report della modalità SharePoint e della modalità nativa con i Gruppi di disponibilità AlwaysOn.

Tramite un server di report SharePoint vengono creati 3 database per ciascuna applicazione di servizio di Reporting Services creata. La connessione ai database del server di report in modalità SharePoint viene configurata in Amministrazione centrale SharePoint quando si crea l'applicazione di servizio. Nei nomi predefiniti dei database è incluso un GUID associato all'applicazione di servizio. Di seguito sono riportati i nomi di database di esempio per un server di report in modalità SharePoint:

• ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6

• ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6TempDB

• ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6_Alerting

Nei server di report in modalità nativa vengono usati 2 database. Di seguito sono riportati i nomi di database di esempio per un server di report in modalità nativa:

• ReportServer

• ReportServerTempDB

La modalità nativa non supporta o usa i database di avviso e le funzionalità correlate. I server di report in modalità nativa vengono configurati nel Gestione configurazione di Reporting Services. Per la modalità SharePoint, configurare il nome database dell'applicazione di servizio in modo che sia il nome del "punto di accesso client" creato come parte della configurazione di SharePoint. Per altre informazioni sulla configurazione di SharePoint con i Gruppi di disponibilità AlwaysOn, vedere Configurare e gestire i gruppi di disponibilità di SQL Server per Server SharePoint (/previous-versions/office/sharepoint-server-2010/hh913923(v=office.14)).

Preparare i database del server di report per i gruppi di disponibilità

Di seguito vengono riportati i passaggi di base per la preparazione e l'aggiunta dei database del server di report ai Gruppi di disponibilità AlwaysOn:

• Creare il proprio gruppo di disponibilità e configurare un Nome DNS del listener.

• Replica primaria: configurare i database del server di report affinché diventino parte di un gruppo di disponibilità singolo e creare una replica primaria che includa tutti i database del server di report.

• Repliche secondarie: creare una o più repliche secondarie. L'approccio comune alla copia dei database dalla replica primaria alle repliche secondarie consiste nel ripristinare i database in ogni replica secondaria usando 'RESTORE WITH NORECOVERY'. Per altre informazioni sulla creazione di repliche secondarie e la verifica del funzionamento della sincronizzazione dei dati, vedere Avviare lo spostamento dati su un database secondario AlwaysOn (SQL Server).

• Credenziali del server di reportistica: È necessario creare le credenziali appropriate del server di reportistica nelle repliche secondarie create nell'istanza primaria. I passaggi esatti dipendono da quale tipo di autenticazione si sta usando nell'ambiente di Reporting Services; l'account di servizio Windows Reporting Services, l'account utente Windows o l'autenticazione SQL Server. Per altre informazioni, vedere Configurare una connessione del database del server di report (Gestione configurazione SSRS).

• Aggiornare la connessione al database per usare il nome DNS del listener. Per i server di report in modalità nativa, cambiare il Nome database del server di report in Gestione configurazione di Reporting Services. Per la modalità SharePoint, cambiare il Nome del server di database per le applicazioni di servizio Reporting Services.

Passaggi per completare il ripristino di emergenza dei database del server di report

È necessario completare i passaggi seguenti dopo un failover dei Gruppi di disponibilità AlwaysOn in una replica secondaria:

1. Arrestare l'istanza del servizio SQL Agent utilizzata dal motore di database principale che ospita i database di Reporting Services.

2. Avviare il servizio SQL Agent nel computer che rappresenta la nuova replica primaria.

3. Arresta il servizio Report Server.

   Se il server di report è in modalità nativa, arrestare il servizio del server di report di Windows utilizzando Reporting Services Configuration Manager.

   Se il server di report è configurato per la modalità SharePoint, arrestare il servizio condiviso di Reporting Services nell'Amministrazione centrale SharePoint.

4. Avviare il servizio del server di report o il servizio SharePoint di Reporting Services.

5. Verificare che i report possano essere eseguiti sulla nuova replica primaria.

Comportamento del server di report quando si verifica un failover

Quando si verifica il failover dei database del server di report e l'ambiente del server di report è stato aggiornato per usare la nuova replica primaria, ci sono alcuni problemi operativi che risultano dal processo di failover e recupero. L'impatto di questi problemi varia a seconda del carico di Reporting Services al momento del failover, nonché del tempo necessario affinché i gruppi di disponibilità Always On eseguano il failover su una replica secondaria e affinché l'amministratore del server di report aggiorni l'ambiente di reportistica per usare la nuova replica primaria.

• L'esecuzione dell'elaborazione in background potrebbe verificarsi più di una volta a causa della logica di riesecuzione e l'incapacità del server di report di indicare il lavoro programmato come completato durante il periodo di failover.

• L'elaborazione di background che normalmente sarebbe dovuta essere attivata per l'esecuzione durante il periodo del failover non verrà eseguita poiché SQL Server Agent non sarà in grado di scrivere i dati nel database del server di report e questi dati non saranno sincronizzati per la nuova replica primaria.

• Al termine del failover del database e dopo aver riavviato il servizio del server di report, i processi di SQL Server Agent verranno ricreati in modo automatico. Fino a che i processi di SQL Agent non vengono ricreati, le esecuzioni di background associate ai processi SQL Server Agent non verranno elaborate. Ciò include le sottoscrizioni, le pianificazioni e le istantanee di Reporting Services.

Vedi anche

• Supporto di SQL Server Native Client per il ripristino di emergenza a disponibilità elevata
• Gruppi di disponibilità Always On (SQL Server)
• Introduzione ai gruppi di disponibilità Always On (SQL Server)
• Utilizzo delle parole chiave delle stringhe di connessione con SQL Server Native Client
• Supporto di SQL Server Native Client per il ripristino di emergenza a disponibilità elevata
• Informazioni sull'accesso delle connessioni client per le repliche di disponibilità (SQL Server)