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

Articolo
06/02/2015

In questo argomento sono contenute informazioni sulla configurazione di Reporting Services per l'utilizzo con i Gruppi di disponibilità AlwaysOn in SQL Server 2012. I database per le origini dati del report, i database del server di report e la progettazione report rappresentano i tre scenari per l'utilizzo di Reporting Services e Gruppi di disponibilità AlwaysOn. La funzionalità supportata e la configurazione richiesta sono diverse per i tre scenari.

La possibilità di utilizzare le repliche secondarie leggibili come origine dati Reporting Services mentre le repliche secondarie forniscono allo stesso tempo un failover per un database primario è un vantaggio chiave nell'utilizzo dei Gruppi di disponibilità AlwaysOn con le origini dei dati di Reporting Services.

Per informazioni generali sui Gruppi di disponibilità AlwaysOn vedere le domande frequenti relative a AlwaysOn per SQL Server 2012 (https://msdn.microsoft.com/en-us/sqlserver/gg508768).

Contenuto dell'argomento:

Requisiti per l'utilizzo di Reporting Services e Gruppi di disponibilità AlwaysOn
Origine dati del report e gruppi di disponibilità
Progettazione report e gruppi di disponibilità
Database del server di report e gruppi di disponibilità
- Differenza tra la modalità nativa e SharePoint
- Preparare i database del server di report per i gruppi di disponibilità
- Passaggi per completare il ripristino di emergenza dei database del server di report
- Comportamento del server di report quando si verifica un failover

Requisiti per l'utilizzo di Reporting Services e Gruppi di disponibilità AlwaysOn

Per utilizzare i Gruppi di disponibilità AlwaysOn con SQL Server 2012 Reporting Services, è necessario scaricare e installare un hotfix per .Net 3.5 SP1. L'hotfix aggiunge supporto a SQL Client per le funzionalità dei gruppi di disponibilità 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 verrà visualizzato quando si fa clic sul pulsante "Test connessione" nelle interfacce utente Reporting Services e quando viene visualizzata l'anteprima del report nel caso in cui vengano abilitati errori remoti sui server di report.

Per ulteriori informazioni relative all'hotfix richiesto, vedere KB 2654347: hotfix che introduce il supporto per le funzionalità AlwaysOn di SQL Server 2012 in .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).

[!NOTA]

I file di configurazione di Reporting Services come RSreportserver.config non sono supportati come parte della funzionalità dei Gruppi di disponibilità AlwaysOn. Se si apportano modifiche manuali a un file di configurazione in uno dei server di report, sarà necessario aggiornare manualmente le repliche.

Icona freccia usata con il collegamento Torna all'inizio Torna all'inizio

Origine dati del report e gruppi di disponibilità

Il comportamento delle origini dati Reporting Services basate sui Gruppi di disponibilità AlwaysOn può variare a seconda di come l'amministratore esegue la configurazione dell'ambiente dei gruppi di disponibilità.

Per utilizzare i Gruppi di disponibilità AlwaysOn per le origini dati dei report, è necessario configurare la stringa di connessione delle origini dati dei report per utilizzare il Nome DNS listener del gruppo di disponibilità. Vengono di seguito riportate le origini dati supportate:

Origine dati SQL che utilizza SQL Native Client.
SQL Client con l'hotfix .Net applicato al server di report.

La stringa di connessione può inoltre contenere nuove proprietà di connessione AlwaysOn che configurano le richieste della query del report in modo da utilizzare 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. Nell'immagine seguente viene riportato un esempio di una configurazione dei gruppi di disponibilità a tre repliche in cui le stringhe di connessione dell'origine dati Reporting Services sono state configurate con ApplicationIntent=ReadOnly. In questo esempio le richiesta della query di report vengono inviate a una replica secondaria e non alla replica primaria.

Utilizzo dei gruppi di disponibilità in un'origine dati SSRS

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 = AdventureWorks2008R2; ApplicationIntent=ReadOnly

Mediante il pulsante Test connessione nelle interfacce utente Reporting Services verrà eseguita la convalida, qualora sia possibile, stabilire una connessione, ma la configurazione del gruppo di disponibilità non verrà convalidata. Ad esempio, se viene incluso ApplicationIntent in una stringa di connessione a un server che non fa parte del gruppo di disponibilità, il parametro aggiuntivo viene ignorato e mediante il pulsante Test connessione verrà convalidata solo una connessione a un server specifico.

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

Modalità nativa: utilizzare Gestione report per le origini dati condivise e i report che sono 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 report: Generatore report di SQL Server per SQL Server 2012 o SQL Server Data Tools (SSDT) al momento della creazione di nuovi report. Per ulteriori informazioni, vedere la sezione 'Progettazione report' in questo argomento.

Risorse aggiuntive:

Gestire origini dati dei report
Per ulteriori informazioni sulle proprietà della stringa di connessione disponibili, vedere Utilizzo delle parole chiave delle stringhe di connessione con SQL Server Native Client.
Per ulteriori 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. Aumenti di ritardo per 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 ulteriori informazioni, vedere la sezione relativa alle modalità di disponibilità in Panoramica di Gruppi di disponibilità AlwaysOn (SQL Server).

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

Icona freccia usata con il collegamento Torna all'inizio Torna all'inizio

Progettazione report e gruppi di disponibilità

Durante la progettazione di report in Generatore report di SQL Server per SQL Server 2012 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: in Generatore report di SQL Server per SQL Server 2012 e SQL Server Data Tools (SSDT) viene utilizzato .Net Framework 4.0 e vengono supportate le proprietà della stringa di connessione di 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'utilizzo dell'anteprima in Generatore report di SQL Server per SQL Server 2012, 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’"

Icona freccia usata con il collegamento Torna all'inizio Torna all'inizio

Database del server di report e gruppi di disponibilità

Reporting Services offre supporto limitato nell'utilizzo dei Gruppi di disponibilità AlwaysOn con i database del server di report. I database del server di report possono essere configurati nel gruppo di disponibilità in modo da far parte di una replica; tuttavia, quando si verifica un failover, in Reporting Services non verrà utilizzata automaticamente una replica diversa per i database del server di report.

Le azioni manuali o gli script di automazione personalizzati devono essere utilizzati 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.

[!NOTA]

Quando si pianifica un failover e un ripristino di emergenza per i database del server di report, si consiglia di eseguire sempre una copia di backup della chiave di crittografia del server di report.

Icona freccia usata con il collegamento Torna all'inizio Torna all'inizio

Differenza tra la modalità nativa e SharePoint

In questa sezione vengono riepilogate le differenze tra la modalità di interazione dei server di report della modalità SharePoint e della modalità Nativa con i Gruppi di disponibilità AlwaysOn.

Un server di report SharePoint crea 3 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. I nomi predefiniti dei database includono 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

I server di report in modalità nativa utilizzano 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 utilizza i database di avviso e le funzionalità correlate. Configurare i server di report in modalità nativa in Gestione configurazione Reporting Services. Per la modalità SharePoint, configurare il nome database dell'applicazione di servizio affinché sia il nome del "punto di accesso client" creato come parte della configurazione di SharePoint. Per ulteriori informazioni sulla configurazione di SharePoint con Gruppi di disponibilità AlwaysOn, vedere Configurare e gestire i gruppi di disponibilità di SQL Server per SharePoint Server (https://go.microsoft.com/fwlink/?LinkId=245165).

[!NOTA]

I server di report in modalità SharePoint utilizzano un processo di sincronizzazione tra i database dell'applicazione di servizio Reporting Services e i database del contenuto SharePoint. È importante mantenere insieme i database del server di report e i database del contenuto. Prendere in considerazione l'ipotesi di configurarli negli stessi gruppi di disponibilità in modo che eseguano il failover e il recupero come un set. Si consideri lo scenario seguente:

Ripristinare un failover in una copia del database del contenuto che non ha ricevuto gli stessi aggiornamenti recenti del database del server di report.

Il processo di sincronizzazione di Reporting Services rileverà le differenze tra l'elenco di elementi nel database del contenuto e i database del server di report.

Il processo di sincronizzazione eliminerà o aggiornerà gli elementi nel database del contenuto.

Icona freccia usata con il collegamento Torna all'inizio Torna all'inizio

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

Vengono di seguito 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. Ad esempio:
Repliche secondarie: creare una o più repliche secondarie. L'approccio comune per copiare i database dalla replica primaria nelle repliche secondarie è di ripristinare i database in ogni replica secondaria tramite 'RESTORE WITH NORECOVERY'. Per ulteriori 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 report: è necessario creare le credenziali del server di report appropriate nelle repliche secondarie create in quella primaria. I passaggi esatti dipendono da quale tipo di autenticazione si sta utilizzando nell'ambiente Reporting Services; l'account di servizio Windows Reporting Services, l'account utente Windows, o l'autenticazione SQL Server. Per ulteriori informazioni, vedere Configurare una connessione del database del server di report (modalità nativa)
Aggiornare la connessione al database per utilizzare il nome DNS del listener. Per i server di report in modalità nativa, cambiare il Nome database del server di report in Gestione configurazione Reporting Services. Per la modalità SharePoint, cambiare il Nome del server di database per le applicazioni di servizio Reporting Services.

Icona freccia usata con il collegamento Torna all'inizio Torna all'inizio

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

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

Arrestare l'istanza del servizio SQL Agent in uso da parte del motore di database primario in cui si trovano i database di Reporting Services.
Avviare il servizio SQL Agent nel computer che rappresenta la nuova replica primaria.
Arrestare il servizio del server di report.

Se il server di report è in modalità nativa, arrestare il server Windows di report utilizzando la Gestione configurazione di Reporting Services.

Se il server di report è configurato per la modalità SharePoint, arrestare il servizio condiviso di Reporting Services nell'Amministrazione centrale SharePoint.
Avviare il servizio del server di report o il servizio SharePoint di Reporting Services.
Verificare che i report possano essere eseguiti nella nuova replica primaria.

Icona freccia usata con il collegamento Torna all'inizio Torna all'inizio

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 utilizzare la nuova replica primaria, ci sono alcuni problemi operativi che risultano dal processo di failover e recupero. L'impatto di questi problemi varia in base al carico di Reporting Services al momento del failover e al tempo necessario per l'esecuzione del failover di Gruppi di disponibilità AlwaysOn in una replica secondaria e per l'aggiornamento da parte dell'amministratore del server di report dell'ambiente di gestione dei report per utilizzare 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. Ad esempio, le sottoscrizioni, le pianificazioni e le istantanee Reporting Services.

Icona freccia usata con il collegamento Torna all'inizio Torna all'inizio