Condividi tramite

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

  • Articolo

Si applica a: SQL Server

Questo articolo contiene informazioni su come configurare Reporting Services con i Gruppi di disponibilità Always On in SQL Server. 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 i Gruppi di disponibilità AlwaysOn. La funzionalità supportata e la configurazione richiesta sono diverse per i tre scenari.

La possibilità di usare le repliche secondarie leggibili come origine dati di 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 dati di Reporting Services.

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

Origine dati del report e gruppi di disponibilità

Il comportamento delle origini dati di 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 usare i Gruppi di disponibilità AlwaysOn per le origini dati dei report, è necessario configurare la stringa di connessione delle origini dati dei report per 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ò 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'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 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

Mediante il pulsante Verifica connessione nelle interfacce utente di Reporting Services viene 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: 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 report: Generatore report o SQL Server Data Tools (SSDT) quando si creano nuovi report. Per altre informazioni, vedere la sezione “Progettazione report” in questo articolo.

Risorse aggiuntive:

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 altre informazioni, vedere la sezione 'Modalità di disponibilità' di Panoramica dei Gruppi di disponibilità AlwaysOn (SQL Server).

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à

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 del server di report 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 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. 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.

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

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. 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 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 SharePoint Server (/previous-versions/office/sharepoint-server-2010/hh913923(v=office.14)).

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. Prendi in considerazione 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 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 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 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 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 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 in base al carico di Reporting Services al momento del failover e al tempo necessario per l'esecuzione del failover dei 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 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. Ad esempio, le sottoscrizioni, le pianificazioni e le istantanee di Reporting Services.

Vedi anche