Condividi tramite

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

  • Articolo

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

Un vantaggio fondamentale dell'uso di Always On gruppi di disponibilità con Reporting Services origini dati consiste nell'sfruttare le repliche secondarie leggibili come origine dati di report, mentre le repliche secondarie forniscono un failover per un database primario.

Per informazioni generali sui gruppi di disponibilità di Always On, vedere Domande frequenti su AlwaysOn per SQL Server 2012 (https://msdn.microsoft.com/sqlserver/gg508768).

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

Per usare Always On gruppi di disponibilità con SQL Server 2014 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 si verifica quando si include una delle proprietà dei gruppi di disponibilità Always On nella stringa di connessione Reporting Services, ma il server non riconosce la proprietà . Il messaggio di errore annotato verrà 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 altre informazioni relative all'hotfix richiesto, vedere l'articolo della Knowledge Base KB 2654347 sull'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à di Always On, vedere Prerequisiti, restrizioni e consigli per i gruppi di disponibilità AlwaysOn (SQL Server).For information on other Always On Availability Groups requirements, see Prerequisites, Restrictions, and Recommendations for AlwaysOn Availability Groups (SQL Server).

Nota

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

Origine dati del report e gruppi di disponibilità

Il comportamento di Reporting Services origini dati basate su Always On gruppi di disponibilità può variare a seconda del modo in cui l'amministratore ha configurato l'ambiente del gruppo di disponibilità.

Per utilizzare Always On gruppi di disponibilità per le origini dati del report, è necessario configurare la stringa di connessione dell'origine dati del report consiste nell'usare il nome DNS del listener del gruppo di disponibilità. Vengono di seguito riportate le origini dati supportate:

  • Origine dati SQL che usano 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 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'immagine seguente riporta un esempio di una configurazione dei gruppi di disponibilità 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 richiesta della query di report vengono inviate a una replica secondaria e non alla replica primaria.

Origine dati SSRS tramite gruppi di gruppi di disponibilità

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 Verifica connessione nelle interfacce utente di 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: usare le pagine di configurazione di SharePoint all'interno delle raccolte di documenti per i report già pubblicati in un server SharePoint.

  • Progettazione report: SQL Server Report Builder per SQL Server 2012 o SQL Server Data Tools (SSDT) durante la creazione di nuovi report. Per altre informazioni, vedere la sezione 'Progettazione report' in questo argomento.

Risorse aggiuntive:

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

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

Progettazione report e gruppi di disponibilità

Quando si progettano report in SQL Server Report Builder per SQL Server 2012 o un progetto di report in SQL Server Data Tools (SSDT), un utente può configurare una stringa di connessione all'origine dati del report in modo da contenere nuove proprietà di connessione fornite da gruppi di disponibilità Always On. Il supporto per le nuove proprietà di connessione dipende da dove l'utente visualizza l'anteprima del report.

  • Anteprima locale: SQL Server Report Builder per SQL Server 2012 e SQL Server Data Tools (SSDT) usano .Net Framework 4.0 e supportano le proprietà della stringa di connessione dei gruppi di disponibilità Always On.

  • Anteprima modalità remota o server: Se dopo la pubblicazione di report nel server di report o l'uso dell'anteprima in SQL Server Report Builder per SQL Server 2012, viene visualizzato un errore simile al seguente, è un'indicazione che si sta visualizzando l'anteprima dei report nel server di report e nell'hotfix di .Net Framework 3.5 SP1 per Always On I gruppi di disponibilità non sono stati installati nel server di report.

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

Database del server di report e gruppi di disponibilità

Reporting Services offre un supporto limitato per l'uso di gruppi di disponibilità Always On 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, Reporting Services non userà automaticamente una replica diversa per i database del server di report.

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à Always On.

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.

Differenza tra la modalità nativa e SharePoint

In questa sezione vengono riepilogate le differenze tra l'interazione tra la modalità SharePoint e i server di report in modalità nativa con Always On gruppi di disponibilità.

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 usano 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 si configura il nome del database dell'applicazione di servizio come nome del "punto di accesso client" creato come parte della configurazione di SharePoint. Per altre informazioni sulla configurazione di SharePoint con gruppi di disponibilità Always On, vedere Configurare e gestire SQL Server gruppi di disponibilità per SharePoint Server (https://go.microsoft.com/fwlink/?LinkId=245165).

Nota

I server di report in modalità SharePoint usano un processo di sincronizzazione tra i database dell'applicazione di servizio di 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.

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

Di seguito sono riportati i passaggi di base per preparare e aggiungere i database del server di report a un Always On gruppi di disponibilità:

  • 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 per copiare i database dalla replica primaria nelle repliche secondarie è di ripristinare i database in ogni replica secondaria tramite 'RESTORE WITH NORECOVERY'. Per altre informazioni sulla creazione di repliche secondarie e sulla verifica del funzionamento della sincronizzazione dei dati, vedere Avviare lo spostamento dati in un database secondario AlwaysOn (SQL Server).For more information on creating secondary replicas and verifying data synchronization is working, see Start Data Movement on an AlwaysOn Secondary Database (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 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

La procedura seguente deve essere completata dopo un failover di gruppi di disponibilità Always On in una replica secondaria:

  1. 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.

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

  3. Arrestare il servizio del server di report.

    Se il server di report è in modalità nativa, arrestare il server Windows di report usando 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.

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

  5. Verificare che i report possano essere eseguiti nella 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 Reporting Services al momento del failover e del tempo necessario per Always On Gruppi di disponibilità per eseguire il failover in una replica secondaria e per l'amministratore del server di report per aggiornare l'ambiente di report per l'uso della 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 di Reporting Services.

Vedere anche

SQL Server Native Client supporto per disponibilità elevata, gruppi di disponibilità AlwaysOn di ripristino di emergenza (SQL Server)Introduzione con gruppi di disponibilità AlwaysOn (SQL Server)Uso delle parole chiave stringa di connessione con SQL Server Native ClientSQL Server Native Client supporto per disponibilità elevata, ripristino di emergenzasull'accesso alla connessione client alle repliche di disponibilità (SQL Server)