Condividi tramite

Servizi di Reporting con AlwaysOn Availability Groups (SQL Server)

Questo argomento contiene informazioni sulla configurazione di Reporting Services per l'uso con i gruppi di disponibilità AlwaysOn in SQL Server 2014. 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 dei report. La funzionalità supportata e la configurazione necessaria sono diverse per i tre scenari.

Un fondamentale vantaggio dell'utilizzo dei gruppi di disponibilità Always On con le origini dati di Reporting Services consiste nell'utilizzare repliche secondarie leggibili come fonte di dati per i report, mentre le repliche secondarie forniscono un failover per il database primario.

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

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

Per usare i gruppi di disponibilità AlwaysOn con SQL Server 2014 Reporting Services, è necessario scaricare e installare un hotfix per .Net 3.5 SP1. L'hotfix aggiunge il supporto a SQL Client per le funzionalità del gruppo di disponibilità e il supporto per le proprietà della stringa di connessione ApplicationIntent e MultiSubnetFailover. Se l'hotfix non è installato in ogni computer che ospita un server di report, gli utenti che tentano di visualizzare in anteprima i report visualizzeranno un messaggio di errore simile al seguente e il messaggio di errore 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à AlwaysOn nella stringa di connessione di Reporting Services, ma il server non riconosce la proprietà . Il messaggio di errore segnalato verrà visualizzato quando si fa clic sul pulsante "Test Connessione" nelle interfacce utente dei servizi di report e quando si visualizza l'anteprima del report, se gli errori remoti sono abilitati nei server di report.

Per altre informazioni sull'hotfix necessario, vedere KB 2654347A hotfix introduce il supporto per le funzionalità AlwaysOn 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).

Annotazioni

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

Origini dei 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 utilizzare i gruppi di disponibilità Always On per le origini dati del report, è necessario configurare la stringa di connessione dell'origine dati del report utilizzando il nome DNS del listener del gruppo di disponibilità. Le origini dati supportate sono le seguenti:

  • Origine dati ODBC utilizzando SQL Native Client.

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

La stringa di connessione può contenere anche nuove proprietà di connessione AlwaysOn che configurano le richieste di query del report per l'uso della replica secondaria per la creazione di report di sola lettura. L'uso della replica secondaria per le richieste di report ridurrà il carico su una replica di lettura/scrittura primaria. La figura seguente è un esempio di una configurazione di tre repliche AG in cui le stringhe di connessione dell'origine dati di Reporting Services sono state configurate con ApplicationIntent=Read-Only. In questo esempio le richieste di query del report vengono inviate a una replica secondaria e non alla replica primaria.

Origine dati SSRS usando gruppi di disponibilità

Di seguito è 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

Il pulsante Test Connessione nelle interfacce utente di Reporting Services verificherà se è possibile stabilire una connessione, ma non convaliderà la configurazione del gruppo di disponibilità (AG). Se, ad esempio, si include ApplicationIntent in una stringa di connessione a un server che non fa parte di un AG (gruppo di disponibilità), il parametro aggiuntivo viene ignorato e il pulsante Test connessione convaliderà soltanto il fatto che si possa stabilire una connessione con il server specificato.

A seconda della modalità di creazione e pubblicazione dei report, determina la posizione in cui si modifica la stringa di connessione:

  • Modalità nativa: Usare Gestione report per origini dati condivise e report già pubblicati in un server di report in modalità nativa.

  • Modalità SharePoint: Utilizzare le pagine di configurazione di SharePoint all'interno delle raccolte documenti 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) per creare nuovi report. Vedere la sezione "Progettazione report" in questo argomento per ulteriori informazioni.

Risorse aggiuntive:

Considerazioni: Le repliche secondarie in genere riscontrano un ritardo nella ricezione di modifiche ai dati dalla replica primaria. I fattori seguenti possono influire sulla latenza di aggiornamento tra le repliche primarie e secondarie:

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

  • Posizione geografica e distanza tra le repliche primarie e secondarie. Ad esempio, il ritardo è in genere maggiore se le repliche secondarie si trovano in un data center diverso rispetto a quando si trovano nello stesso edificio della replica primaria.

  • Configurazione della modalità di disponibilità per ogni replica. La modalità di disponibilità determina se la replica primaria attende il commit delle transazioni in un database fino a quando una replica secondaria non ha scritto la transazione su disco. Per altre informazioni, vedere la sezione "Modalità di disponibilità" di Panoramica dei gruppi di disponibilità AlwaysOn (SQL Server).

Quando si usa un database secondario di sola lettura come origine dati di Reporting Services, è importante assicurarsi che la latenza di aggiornamento dei dati soddisfi le esigenze degli utenti del report.

Progettazione dei report e gruppi di disponibilità

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

  • Anteprima locale: Generatore report di SQL Server 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à AlwaysOn.

  • Anteprima della modalità remota o del server: Se dopo la pubblicazione di report nel server di report o l'uso dell'anteprima in Generatore report di SQL Server per SQL Server 2012, viene visualizzato un errore simile al seguente, indica che i report vengono visualizzati in anteprima sul server di report e 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 e gruppi di disponibilità del server di report

Reporting Services offre un supporto limitato per l'uso dei gruppi di disponibilità Always On con i database del server di report. I database del server di reportistica possono essere configurati nel gruppo di disponibilità per far parte di una replica; tuttavia, Reporting Services non userà automaticamente una replica diversa per i database del server di reportistica in caso di failover.

Per completare il failover e il ripristino, è necessario usare azioni manuali o script di automazione personalizzati. Fino al completamento di queste azioni, alcune funzionalità del server di report potrebbero non funzionare correttamente dopo il failover dei gruppi di disponibilità AlwaysOn.

Annotazioni

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

Differenze tra la modalità nativa di SharePoint

Questa sezione riepiloga le differenze tra l'interazione dei server di report in modalità SharePoint e in modalità nativa con i gruppi di disponibilità Always On.

Un server di report di SharePoint crea 3 database per ogni applicazione di servizio 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 usano 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 né usa i database di avviso e le funzionalità correlate. I server di report in modalità nativa vengono configurati in Gestione configurazione Reporting Services. Per la modalità SharePoint, configurare 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à AlwaysOn, vedere Configurare e gestire i gruppi di disponibilità di SQL Server per SharePoint Server (https://go.microsoft.com/fwlink/?LinkId=245165).

Annotazioni

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 di SharePoint. È importante mantenere insieme i database del server di report e i database del contenuto. Dovresti considerare di configurarli negli stessi gruppi di disponibilità in modo da eseguire il failover e il ripristino come un unico insieme. Si consideri lo scenario seguente:

  • Si ripristina o si esegue il failover in una copia del database del contenuto che non ha ricevuto gli stessi aggiornamenti recenti ricevuti dal 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 gruppi di disponibilità AlwaysOn:

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

  • Replica primaria: Configurare i database del server di report come parte di un singolo gruppo di disponibilità e creare una replica primaria che include 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 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 sulla verifica del funzionamento della sincronizzazione dei dati, vedere Avviare lo spostamento dati in un database secondario AlwaysOn (SQL Server).

  • Credenziali del server di report: È necessario creare le credenziali appropriate del server di report nelle repliche secondarie create nel database primario. I passaggi esatti dipendono dal tipo di autenticazione in uso nell'ambiente Reporting Services; Account del servizio Windows Reporting Services, account utente di Windows o autenticazione di SQL Server. Per altre informazioni, vedere Configurare una connessione al database del server di report (Gestione configurazione SSRS)

  • Aggiornare la connessione al database per utilizzare il Nome DNS Lister. per i server di report in modalità nativa, modificare il nome del database del server di report in Gestione configurazione Reporting Services. Per la modalità SharePoint, modificare 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

Dopo il failover di un Always On Availability Groups in una replica secondaria, è necessario seguire i passaggi seguenti:

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

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

  3. Arrestare il servizio Server di report.

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

    Se il server di report è configurato per la modalità SharePoint, arrestare il servizio condiviso di Reporting Services in 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 esegue il failover dei database del server di report e si è aggiornato l'ambiente del server di report per usare la nuova replica primaria, si verificano alcuni problemi operativi che derivano dal processo di failover e ripristino. L'impatto di questi problemi varia a seconda del carico di Reporting Services al momento del failover, nonché del tempo necessario per consentire ai gruppi di disponibilità AlwaysOn di eseguire il failover in una replica secondaria e per consentire all'amministratore del server di report di aggiornare l'ambiente di report in modo da usare la nuova replica primaria.

  • L'esecuzione dell'elaborazione in background può verificarsi più volte a causa della logica di ripetizione dei tentativi e dell'impossibilità del server di report di contrassegnare il lavoro pianificato come completato durante il periodo di failover.

  • L'esecuzione dell'elaborazione in background che normalmente sarebbe stata attivata per l'esecuzione durante il periodo del failover non si verificherà perché SQL Server Agent non sarà in grado di scrivere dati nel database del server di report e questi dati non verranno sincronizzati con la nuova replica primaria.

  • Dopo il completamento del failover del database e dopo l'avvio del servizio del server di report, i processi di SQL Server Agent verranno ricreati automaticamente. Finché i processi di SQL Agent non vengono ricreati, le esecuzioni in background associate ai processi di SQL Server Agent non verranno elaborate. Sono incluse sottoscrizioni, pianificazioni e snapshot nei Reporting Services.

Vedere anche

Supporto di SQL Server Native Client per disponibilità elevata, ripristino di emergenzagruppi di disponibilità AlwaysOn (SQL Server)Introduzione ai gruppi di disponibilità AlwaysOn (SQL Server)Uso delle parole chiave della stringa di connessione con SQL Server Native ClientSupporto di SQL Server Native Client per la disponibilità elevata e ripristino di emergenzaInformazioni sull'accesso client alla connessione alle repliche di disponibilità (SQL Server)

  • Last updated on