Dela via

Reporting Services med AlwaysOn-tillgänglighetsgrupper (SQL Server)

gäller för:SQL Server

Den här artikeln innehåller information om hur du konfigurerar Reporting Services att fungera med AlwaysOn-tillgänglighetsgrupper (AG) i SQL Server. De tre scenarierna för att använda Reporting Services- och AlwaysOn-tillgänglighetsgrupper är databaser för rapportdatakällor, rapportserverdatabaser och rapportdesign. De funktioner som stöds och den nödvändiga konfigurationen skiljer sig åt för de tre scenarierna.

En viktig fördel med att använda AlwaysOn-tillgänglighetsgrupper med Reporting Services-datakällor är att använda läsbara sekundära repliker som en rapporteringsdatakälla, samtidigt som de sekundära replikerna tillhandahåller en redundansväxling för en primär databas.

Allmän information om AlwaysOn-tillgänglighetsgrupper finns i Vanliga frågor och svar om AlwaysOn för SQL Server 2012 (.. /.. /.. /sql-server/index.yml).

Krav för användning av Reporting Services och AlwaysOn-tillgänglighetsgrupper

SQL Server Reporting Services och Power BI-rapportservern använder .NET Framework 4.0 och stöder Anslutningssträngsegenskaper för AlwaysOn-tillgänglighetsgrupper för användning med datakällor.

Om du vill använda AlwaysOn-tillgänglighetsgrupper med Reporting Services 2014 och tidigare måste du ladda ned och installera en snabbkorrigering för .NET 3.5 SP1. Snabbkorrigeringen lägger till stöd för SQL Client för AG-funktioner och stöd för anslutningssträngsegenskaperna ApplicationIntent och MultiSubnetFailover. Om snabbkorrigeringen inte är installerad på varje dator som är värd för en rapportserver ser användare som försöker förhandsgranska rapporter ett felmeddelande som liknar följande, och felmeddelandet skrivs till rapportserverns spårningslogg:

Felmeddelande: "Nyckelordet stöds inte 'applicationintent'"

Meddelandet inträffar när du inkluderar en av egenskaperna för AlwaysOn-tillgänglighetsgrupper i Reporting Services-anslutningssträngen, men servern känner inte igen egenskapen. Det angivna felmeddelandet visas när du väljer knappen Testa anslutning i Reporting Services-användargränssnitt och när du förhandsgranskar rapporten om fjärrfel är aktiverade på rapportservrarna.

Mer information om den nödvändiga snabbkorrigeringen finns i KB 2654347A snabbkorrigering introducerar stöd för AlwaysOn-funktionerna från SQL Server 2012 till .NET Framework 3.5 SP1.

Mer information om andra Krav för AlwaysOn-tillgänglighetsgrupper finns i Krav, begränsningar och rekommendationer för AlwaysOn-tillgänglighetsgrupper (SQL Server).

Anmärkning

Reporting Services-konfigurationsfiler som RSreportserver.config stöds inte som en del av funktionerna i AlwaysOn-tillgänglighetsgrupper. Om du gör ändringar i en konfigurationsfil manuellt på en av rapportservrarna måste du uppdatera replikerna manuellt.

Rapportera datakällor och tillgänglighetsgrupper

Beteendet för Reporting Services-datakällor baserat på AlwaysOn-tillgänglighetsgrupper kan variera beroende på hur administratören har konfigurerat tillgänglighetsgruppens miljö.

Om du vill använda AlwaysOn-tillgänglighetsgrupper för rapportdatakällor måste du konfigurera anslutningssträngen för rapportdatakällan genom att använda tillgänglighetsgruppens DNS-namn för lyssnaren. Datakällor som stöds är följande:

  • ODBC-datakälla med SQL Native Client.

  • SQL-klienten med .NET-snabbkorrigeringen tillämpad på rapportservern.

Anslutningssträngen kan också innehålla nya AlwaysOn-anslutningsegenskaper som konfigurerar rapportfrågebegäranden att använda sekundär replik för skrivskyddad rapportering. Användning av en sekundär replik för rapporteringsbegäranden minskar belastningen på en läs- och skrivbar primär replik. Följande illustration är ett exempel på en konfiguration med tre replika-AG där anslutningssträngarna för datakällan i Reporting Services har konfigurerats med ApplicationIntent=ReadOnly. I det här exemplet skickas rapportfrågebegäranden till en sekundär replik och inte till den primära repliken.

Följande är ett exempel på en anslutningssträng, där [AvailabilityGroupListenerName] är lyssnarens DNS-namn som konfigurerades när repliker skapades:

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

Knappen Testa anslutning i Reporting Services-användargränssnitten kontrollerar om en anslutning kan etableras, men den validerar inte tillgänglighetsgruppens konfiguration. Om du till exempel inkluderar ApplicationIntent i en anslutningssträng till en server som inte ingår i en AG (tillgänglighetsgrupp) ignoreras den extra parametern, och Testa anslutning-knappen bekräftar endast att en anslutning kan upprättas till den angivna servern.

Beroende på hur dina rapporter skapas och publiceras avgör du var du redigerar anslutningssträngen:

  • Internt läge: Använd webbportalen för delade datakällor och rapporter som redan har publicerats till en rapportserver i inbyggt läge.

  • SharePoint-läge: Använd SharePoint-konfigurationssidor i dokumentbiblioteken för rapporter som redan har publicerats till en SharePoint-server.

  • Rapportdesign: Report Builder eller SQL Server Data Tools (SSDT) när du skapar nya rapporter. Se avsnittet Rapportdesign i den här artikeln eller mer information.

Ytterligare resurser:

Överväganden: Sekundära repliker får vanligtvis en fördröjning i mottagandet av dataändringar från den primära repliken. Följande faktorer kan påverka uppdateringsfördröjningen mellan de primära och sekundära replikerna:

  • Antalet sekundära repliker. Fördröjningen ökar med varje sekundär replik som läggs till i konfigurationen.

  • Geografisk plats och avstånd mellan de primära och sekundära replikerna. Fördröjningen är till exempel vanligtvis större om de sekundära replikerna finns i ett annat datacenter än om de fanns i samma byggnad som den primära repliken.

  • Konfiguration av tillgänglighetsläget för varje replik. Tillgänglighetsläget avgör om den primära repliken väntar med att checka in transaktioner på en databas tills en sekundär replik har skrivit transaktionen till disken. Mer information finns i avsnittet "Tillgänglighetslägen" i Översikt över AlwaysOn-tillgänglighetsgrupper (SQL Server).

När du använder en skrivskyddad sekundär som en datakälla för Reporting Services är det viktigt att säkerställa att latensen i datauppdateringen uppfyller rapportanvändarnas behov.

Rapportdesign och tillgänglighetsgrupper

När du utformar rapporter i Report Builder eller ett rapportprojekt i SQL Server Data Tools (SSDT) kan en användare konfigurera en anslutningssträng för rapportdatakällan så att den innehåller nya anslutningsegenskaper som tillhandahålls av AlwaysOn-tillgänglighetsgrupper. Stöd för de nya anslutningsegenskaperna beror på var en användare förhandsgranskar rapporten.

  • Lokal förhandsversion: Report Builder och SQL Server Data Tools (SSDT) använder .NET Framework 4.0 och stöder anslutningssträngsegenskaper för AlwaysOn-tillgänglighetsgrupper.

  • Förhandsversion av fjärr- eller serverläge: Om du efter att ha publicerat rapporter på rapportservern eller använt förhandsversionen i Report Builder ser ett fel som liknar följande, är det en indikation på att du förhandsgranskar rapporter mot rapportservern och att .NET Framework 3.5 SP1-snabbkorrigeringen för AlwaysOn-tillgänglighetsgrupper inte har installerats på rapportservern.

Felmeddelande: "Nyckelordet stöds inte 'applicationintent'"

Rapportserverdatabaser och tillgänglighetsgrupper

Reporting Services och Power BI-rapportservern har begränsat stöd för användning av AlwaysOn-tillgänglighetsgrupper med rapportserverdatabaser. Rapportserverdatabaserna kan konfigureras i en tillgänglighetsgrupp så att de är en del av en replik; dock kommer Reporting Services inte automatiskt att använda en annan replik för rapportserverdatabaserna när ett failover inträffar. Användning av MultiSubnetFailover, med rapportserverdatabaserna, stöds inte.

Manuella åtgärder eller anpassade automatiseringsskript måste användas för att slutföra redundansväxlingen och återställningen. Tills dessa åtgärder har slutförts kanske vissa funktioner på rapportservern inte fungerar korrekt efter redundansväxlingen för AlwaysOn-tillgänglighetsgrupper.

Anmärkning

När du planerar redundans och haveriberedskap för rapportserverdatabaserna bör du alltid säkerhetskopiera en kopia av krypteringsnyckeln för rapportservern.

Skillnader mellan inbyggt SharePoint-läge

I det här avsnittet sammanfattas skillnaderna mellan hur SharePoint-läge och rapportservrar i inbyggt läge interagerar med AlwaysOn-tillgänglighetsgrupper.

En SharePoint-rapportserver skapar tre databaser för varje Reporting Services-tjänstprogram som du skapar. Anslutningen till rapportserverdatabaserna i SharePoint-läge konfigureras i Central Administration av SharePoint när du skapar tjänstprogrammet. Standardnamnen för databaserna innehåller ett GUID som är associerat med tjänstprogrammet. Följande är exempel på databasnamn för en Rapportserver i SharePoint-läge:

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6TempDB

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6_Alerting

Rapportservrar i inbyggt läge använder två databaser. Följande är exempel på databasnamn för en rapportserver i inbyggt läge:

  • Rapportserver

  • ReportServerTempDB

Anmärkning

När du konfigurerar Reporting Services att fungera med en tillgänglighetsgrupp (AG) ändras återställningsmodellen ReportServerTemp för databasen till Full. Därför finns det scenarier där ReportServerTemp databasen fortsätter att växa i storlek. Det är bästa praxis att ta bort ReportServerTemp databasen från din tillgänglighetsgruppskonfiguration och att ha återställningsmodellen satt till Enkel. Databasen ReportServerTemp lagrar endast temporära data. Att ta bort det från tillgänglighetsgruppen (AG) påverkar inte Reporting Services.

Inbyggt läge stöder inte eller använder aviseringsdatabaser och relaterade funktioner. Du konfigurerar rapportservrar i inbyggt läge i Reporting Services Configuration Manager. För SharePoint-läge konfigurerar du namnet på tjänstprogramdatabasen till namnet på den "klientåtkomstpunkt" som du skapade som en del av SharePoint-konfigurationen. Mer information om hur du konfigurerar SharePoint med AlwaysOn-tillgänglighetsgrupper finns i Konfigurera och hantera SQL Server-tillgänglighetsgrupper för SharePoint Server (/tidigare versioner/office/sharepoint-server-2010/hh913923(v=office.14)).

Anmärkning

Rapportservrar i SharePoint-läge använder en synkroniseringsprocess mellan Reporting Services-tjänstprogramdatabaserna och SharePoint-innehållsdatabaserna. Det är viktigt att underhålla rapportserverdatabaserna och innehållsdatabaserna tillsammans. Du bör överväga att konfigurera dem i samma tillgänglighetsgrupper så att de redundansväxlar och återställer som en uppsättning. Tänk på följande scenario:

  • Du återställer eller växla över till en kopia av innehållsdatabasen som inte har fått de senaste uppdateringarna som rapportserverdatabasen har fått.
  • Synkroniseringsprocessen för Reporting Services identifierar skillnader mellan listan över objekt i innehållsdatabasen och rapportserverdatabaserna.
  • Synkroniseringsprocessen tar bort eller uppdaterar objekt i innehållsdatabasen.

Förbereda rapportserverdatabaser för tillgänglighetsgrupper

Följande är de grundläggande stegen för att förbereda och lägga till rapportserverdatabaserna i en AlwaysOn-tillgänglighetsgrupper:

  • Skapa tillgänglighetsgruppen och konfigurera ett DNS-namn för lyssnaren.

  • Primär replik: Konfigurera rapportserverdatabaserna så att de ingår i en enda tillgänglighetsgrupp och skapa en primär replik som innehåller alla rapportserverdatabaser.

  • Sekundära repliker: Skapa en eller flera sekundära repliker. Den vanliga metoden för att kopiera databaserna från den primära repliken till de sekundära replikerna är att återställa databaserna till varje sekundär replik med hjälp av "RESTORE WITH NORECOVERY". Mer information om hur du skapar sekundära repliker och verifierar att datasynkronisering fungerar finns i Starta dataflytt på en alwayson-sekundär databas (SQL Server).

  • Autentiseringsuppgifter för rapportserver: Du måste skapa lämpliga autentiseringsuppgifter för rapportservern på de sekundära repliker som du skapade i den primära. De exakta stegen beror på vilken typ av autentisering du använder i Reporting Services-miljön. Window Reporting Services-tjänstkonto, Windows-användarkonto eller SQL Server-autentisering. Mer information finns i Konfigurera en rapportserverdatabasanslutning (SSRS Configuration Manager)

  • Uppdatera databasanslutningen så att den använder lyssnarens DNS-namn. för rapportservrar i inbyggt läge ändrar du rapportserverns databasnamn i Reporting Services-konfigurationshanteraren. För SharePoint-läge ändrar du databasservernamnet för Reporting Services-tjänstprogram.

Steg för att slutföra katastrofåterställning av rapportserverns databaser

Följande steg måste slutföras efter en redundansväxling av Always On-tillgänglighetsgrupper till en sekundär kopia:

  1. Stoppa instansen av SQL Agent-tjänsten som användes av den primära databasmotorn som är värd för Reporting Services-databaserna.

  2. Starta SQL Agent-tjänsten på datorn som är den nya primära repliken.

  3. Stoppa rapportservertjänsten.

    Om rapportservern är i inbyggt läge, stoppar du Windows-rapportservern med hjälp av Reporting Services konfigurationshanteraren.

    Om rapportservern har konfigurerats för SharePoint-läge stoppar du den delade Reporting Services-tjänsten i Central administration av SharePoint.

  4. Starta rapportservertjänsten eller Reporting Services SharePoint-tjänsten.

  5. Kontrollera att rapporter kan köras mot den nya primära repliken.

Rapportserverbeteende när en failover inträffar

När rapportserverdatabaser redundansväxlar och du har uppdaterat rapportservermiljön för att använda den nya primära repliken, finns det några driftproblem som beror på redundansväxlingen och återställningsprocessen. Effekten av dessa problem varierar beroende på Reporting Services-belastningen vid tidpunkten för redundansväxlingen samt hur lång tid det tar för AlwaysOn-tillgänglighetsgrupper att redundansväxla till en sekundär replik och för rapportserveradministratören att uppdatera rapporteringsmiljön för att använda den nya primära repliken.

  • Körningen av bakgrundsprocesser kan ske mer än en gång på grund av återförsökslogik och rapportserverns oförmåga att markera schemalagt arbete som slutfört under failover-perioden.

  • Körningen av bakgrundsprocesser som normalt skulle ha utlösts för körning under omkoppling sker inte eftersom SQL Server Agent inte kommer att kunna skriva data till rapportserverdatabasen och dessa data inte kommer att synkroniseras till den nya primära repliken.

  • När databasredundansväxlingen är klar och när rapportservertjänsten har startats om skapas SQL Server Agent-jobb automatiskt igen. Tills SQL-agentjobben har återskapats bearbetas inte bakgrundskörningar som är associerade med SQL Server Agent-jobb. Detta inkluderar Reporting Services-prenumerationer, scheman och ögonblicksbilder.

Se även