Delen via

Reporting Services met AlwaysOn-beschikbaarheidsgroepen (SQL Server)

Van toepassing op:SQL Server

Dit artikel bevat informatie over het configureren van Reporting Services voor gebruik met AlwaysOn-beschikbaarheidsgroepen (AG) in SQL Server. De drie scenario's voor het gebruik van Reporting Services en AlwaysOn-beschikbaarheidsgroepen zijn databases voor rapportgegevensbronnen, rapportserverdatabases en rapportontwerp. De ondersteunde functionaliteit en vereiste configuratie verschillen voor de drie scenario's.

Een belangrijk voordeel van het gebruik van AlwaysOn-beschikbaarheidsgroepen met Reporting Services-gegevensbronnen is het gebruik van leesbare secundaire replica's als een rapportagegegevensbron, terwijl de secundaire replica's tegelijkertijd een failover bieden voor een primaire database.

Voor algemene informatie over Always On-beschikbaarheidsgroepen, zie Always On FAQ voor SQL Server 2012 (../../../sql-server/index.yml).

Vereisten voor het gebruik van Reporting Services en AlwaysOn-beschikbaarheidsgroepen

SQL Server Reporting Services en Power BI Report Server maakt gebruik van .NET Framework 4.0 en ondersteunt verbindingsreekseigenschappen van AlwaysOn-beschikbaarheidsgroepen voor gebruik met gegevensbronnen.

Als u AlwaysOn-beschikbaarheidsgroepen wilt gebruiken met Reporting Services 2014 en eerder, moet u een hotfix voor .NET 3.5 SP1 downloaden en installeren. De hotfix voegt ondersteuning toe aan SQL Client voor AG-functies en ondersteuning voor de eigenschappen van de verbindingsreeks applicationIntent en MultiSubnetFailover. Als de hotfix niet is geïnstalleerd op elke computer waarop een rapportserver wordt gehost, zien gebruikers die een voorbeeld van rapporten proberen te bekijken, een foutbericht dat vergelijkbaar is met het volgende. Het foutbericht wordt naar het traceringslogboek van de rapportserver geschreven:

Foutmelding: "Trefwoord wordt niet ondersteund "applicationintent""

Het bericht treedt op wanneer u een van de eigenschappen van AlwaysOn-beschikbaarheidsgroepen in de Reporting Services-verbindingsreeks opneemt, maar de server de eigenschap niet herkent. Het genoteerde foutbericht wordt weergegeven wanneer u op de knop 'Verbinding testen' klikt in de Reporting Services-gebruikersinterfaces. Het verschijnt ook wanneer u een voorbeeld van het rapport bekijkt, als externe foutmeldingen zijn ingeschakeld op de rapportageservers.

Zie KB 2654347A-hotfix voor meer informatie over de vereiste hotfix introduceert ondersteuning voor de AlwaysOn-functies van SQL Server 2012 naar .NET Framework 3.5 SP1.

Zie Vereisten, beperkingen en aanbevelingen voor AlwaysOn-beschikbaarheidsgroepen (SQL Server) voor meer informatie over andere vereisten voor AlwaysOn-beschikbaarheidsgroepen.

Opmerking

Reporting Services-configuratiebestanden zoals RSreportserver.config worden niet ondersteund als onderdeel van de functionaliteit van AlwaysOn-beschikbaarheidsgroepen. Als u handmatig wijzigingen aanbrengt in een configuratiebestand op een van de rapportservers, moet u de replica's handmatig bijwerken.

Rapportgegevensbronnen en beschikbaarheidsgroepen

Het gedrag van Reporting Services-gegevensbronnen op basis van AlwaysOn-beschikbaarheidsgroepen kan variëren, afhankelijk van hoe uw beheerder de AG-omgeving heeft geconfigureerd.

Als u AlwaysOn-beschikbaarheidsgroepen wilt gebruiken voor rapportgegevensbronnen, moet u de verbindingsreeks voor de rapportgegevensbron configureren door de DNS-naam van de beschikbaarheidsgroep listener te gebruiken. Ondersteunde gegevensbronnen zijn het volgende:

  • ODBC-gegevensbron met behulp van SQL Native Client.

  • SQL Client, waarbij de .NET-hotfix is toegepast op de rapportserver.

De verbindingsreeks kan ook nieuwe Always On-verbindingseigenschappen bevatten, waarmee rapportaanvragen worden geconfigureerd om een secundaire replica te gebruiken voor alleen-lezen rapportage. Het gebruik van secundaire replica voor het rapporteren van aanvragen vermindert de belasting van een primaire replica voor lezen/schrijven. De volgende afbeelding is een voorbeeld van een configuratie van drie replica-AG's waarbij de Verbindingsreeksen van de Reporting Services-gegevensbron zijn geconfigureerd met ApplicationIntent=ReadOnly. In dit voorbeeld worden rapportquery's verzonden naar een secundaire replica in plaats van naar de primaire replica.

Hier volgt een voorbeeld van een verbindingsreeks, waarbij de [AvailabilityGroupListenerName] de DNS-naam van de listener is die is geconfigureerd toen replica's werden gemaakt:

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

De knop Verbinding testen in Reporting Services-gebruikersinterfaces controleert of er een verbinding tot stand kan worden gebracht, maar de AG-configuratie wordt niet gevalideerd. Als u ApplicationIntent bijvoorbeeld opneemt in een verbindingsreeks naar een server die geen deel uitmaakt van ag, wordt de extra parameter genegeerd en wordt de knop Verbinding testen alleen gevalideerd of er een verbinding tot stand kan worden gebracht met de opgegeven server.

Afhankelijk van hoe uw rapporten worden gemaakt en gepubliceerd, bepaalt u waar u de verbindingsreeks bewerkt:

  • Systeemeigen modus: Gebruik de webportal voor gedeelde gegevensbronnen en rapporten die al zijn gepubliceerd naar een rapportserver in de systeemeigen modus.

  • SharePoint-modus: Gebruik SharePoint-configuratiepagina's in de documentbibliotheken voor rapporten die al zijn gepubliceerd op een SharePoint-server.

  • Rapportontwerp: Report Builder of SQL Server Data Tools (SSDT) wanneer u nieuwe rapporten maakt. Zie de sectie Rapportontwerp in dit artikel of meer informatie.

Aanvullende informatiebronnen:

Overwegingen: Secundaire replica's ervaren doorgaans een vertraging bij het ontvangen van gegevenswijzigingen van de primaire replica. De volgende factoren kunnen van invloed zijn op de updatelatentie tussen de primaire en secundaire replica's:

  • Het aantal secundaire replica's. De vertraging neemt toe met elke secundaire replica die is toegevoegd aan de configuratie.

  • Geografische locatie en afstand tussen de primaire en secundaire replica's. De vertraging is bijvoorbeeld meestal groter als de secundaire replica's zich in een ander datacenter bevinden dan in hetzelfde gebouw als de primaire replica.

  • Configuratie van de beschikbaarheidsmodus voor elke replica. De beschikbaarheidsmodus bepaalt of de primaire replica wacht op het doorvoeren van transacties op een database totdat een secundaire replica de transactie naar de schijf heeft geschreven. Zie de sectie Beschikbaarheidsmodi van Overzicht van AlwaysOn-beschikbaarheidsgroepen (SQL Server) voor meer informatie.

Wanneer u een alleen-lezen secundaire als Reporting Services-gegevensbron gebruikt, is het belangrijk om ervoor te zorgen dat de latentie van gegevensupdates voldoet aan de behoeften van de rapportgebruikers.

Rapportontwerp en beschikbaarheidsgroepen

Bij het ontwerpen van rapporten in Report Builder of een rapportproject in SQL Server Data Tools (SSDT), kan een gebruiker een verbindingsreeks voor rapportgegevensbronnen configureren om nieuwe verbindingseigenschappen te bevatten die worden geleverd door AlwaysOn-beschikbaarheidsgroepen. Ondersteuning voor de nieuwe verbindingseigenschappen is afhankelijk van waar een gebruiker een voorbeeld van het rapport bekijkt.

  • Lokale preview: Report Builder en SQL Server Data Tools (SSDT) maken gebruik van .NET Framework 4.0 en bieden ondersteuning voor eigenschappen van verbindingsreeksen voor AlwaysOn-beschikbaarheidsgroepen.

  • Voorbeeld van externe modus of servermodus: Als na het publiceren van rapporten naar de rapportserver of bij het gebruiken van een voorbeeld in Report Builder een foutmelding wordt weergegeven die lijkt op het volgende, is dat een indicatie dat u een voorbeeld van rapporten bekijkt op de rapportserver en de hotfix voor .NET Framework 3.5 SP1 voor Always On-beschikbaarheidsgroepen is niet geïnstalleerd op de rapportserver.

Foutmelding: "Trefwoord wordt niet ondersteund "applicationintent""

Rapportserverdatabases en beschikbaarheidsgroepen

Reporting Services en Power BI Report Server bieden beperkte ondersteuning voor het gebruik van AlwaysOn-beschikbaarheidsgroepen met rapportserverdatabases. De rapportserverdatabases kunnen worden geconfigureerd in AG als onderdeel van een replica; Reporting Services gebruikt echter niet automatisch een andere replica voor de rapportserverdatabases wanneer er een failover plaatsvindt. Het gebruik van MultiSubnetFailover, met de rapportserverdatabases, wordt niet ondersteund.

Handmatige acties of aangepaste automatiseringsscripts moeten worden gebruikt om de failover en het herstel te voltooien. Totdat deze acties zijn voltooid, werken sommige functies van de rapportserver mogelijk niet correct na de failover van alwayson-beschikbaarheidsgroepen.

Opmerking

Bij het plannen van failover en herstel na noodgevallen voor de rapportserverdatabases, wordt u aangeraden altijd een back-up te maken van een kopie van de versleutelingssleutel van de rapportserver.

Verschillen tussen de systeemeigen Modus van SharePoint

In deze sectie vindt u een overzicht van de verschillen tussen de manier waarop rapportservers in de SharePoint-modus en systeemeigen modus communiceren met AlwaysOn-beschikbaarheidsgroepen.

Een SharePoint-rapportserver maakt drie databases voor elke Reporting Services-servicetoepassing die u maakt. De verbinding met de rapportserverdatabases in de SharePoint-modus wordt geconfigureerd in centraal beheer van SharePoint wanneer u de servicetoepassing maakt. De standaardnamen van de databases bevatten een GUID die is gekoppeld aan de servicetoepassing. Hier volgen voorbeelddatabasenamen voor een Rapportserver in de SharePoint-modus:

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6TempDB

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6_Alerting

Rapportservers in systeemeigen modus maken gebruik van 2 databases. Hier volgen voorbeelddatabasenamen voor een rapportserver in de systeemeigen modus:

  • ReportServer

  • ReportServerTempDB

Opmerking

Wanneer u Reporting Services configureert voor gebruik met een beschikbaarheidsgroep (AG), verandert het herstelmodel voor de ReportServerTemp database in Volledig. Als gevolg hiervan zijn er scenario's waarin de ReportServerTemp database steeds groter wordt. Het is een best practice om de database uit uw ReportServerTemp AG-configuratie te verwijderen en het herstelmodel op Simple te laten instellen. In de ReportServerTemp database worden alleen tijdelijke gegevens opgeslagen. Het verwijderen uit de beschikbaarheidsgroep heeft geen invloed op Reporting Services.

In de systeemeigen modus worden de waarschuwingsdatabases en gerelateerde functies niet ondersteund of gebruikt. U configureert rapportservers in de systeemeigen modus in Reporting Services Configuration Manager. Voor de SharePoint-modus configureert u de naam van de servicetoepassingsdatabase als de naam van het clienttoegangspunt dat u hebt gemaakt als onderdeel van de SharePoint-configuratie. Zie Sql Server-beschikbaarheidsgroepen configureren en beheren voor SharePoint Server (/vorige versies/office/sharepoint-server-2010/hh913923(v=office.14)) voor meer informatie over het configureren van SharePoint-beschikbaarheidsgroepen met AlwaysOn-beschikbaarheidsgroepen.

Opmerking

Rapportservers in de SharePoint-modus gebruiken een synchronisatieproces tussen de Reporting Services-servicetoepassingsdatabases en de SharePoint-inhoudsdatabases. Het is belangrijk om de rapportserverdatabases en inhoudsdatabases bij elkaar te houden. Overweeg deze te configureren in dezelfde beschikbaarheidsgroepen, zodat ze overgaan en herstellen als één geheel. Houd rekening met het volgende scenario:

  • U herstelt of voert een failover uit naar een kopie van de inhoudsdatabase die niet dezelfde recente updates heeft ontvangen als de rapportserverdatabase.
  • Het synchronisatieproces van Reporting Services detecteert verschillen tussen de lijst met items in de inhoudsdatabase en de rapportserverdatabases.
  • Tijdens het synchronisatieproces worden items in de inhoudsdatabase verwijderd of bijgewerkt.

Rapportserverdatabases voorbereiden voor beschikbaarheidsgroepen

Hier volgen de basisstappen voor het voorbereiden en toevoegen van de rapportserverdatabases aan een AlwaysOn-beschikbaarheidsgroep:

  • Maak uw beschikbaarheidsgroep en configureer een DNS-naam van de listener.

  • Primaire replica: Configureer de rapportserverdatabases als onderdeel van één beschikbaarheidsgroep en maak een primaire replica die alle rapportserverdatabases bevat.

  • Secundaire replica's: Maak een of meer secundaire replica's. De algemene benadering voor het kopiëren van de databases van de primaire replica naar de secundaire replica('s) is het herstellen van de databases naar elke secundaire replica met behulp van 'RESTORE WITH NORECOVERY'. Zie Gegevensverplaatsing starten op een AlwaysOn Secondary Database (SQL Server) voor meer informatie over het maken van secundaire replica's en controleren of gegevenssynchronisatie werkt.

  • Rapportserverreferenties: U moet de juiste rapportserverreferenties maken op de secundaire replica's die u op de primaire replica hebt gemaakt. De exacte stappen zijn afhankelijk van het type verificatie dat u gebruikt in uw Reporting Services-omgeving; Windows Reporting Services-serviceaccount, Windows-gebruikersaccount of SQL Server-verificatie. Zie Een rapportserverdatabaseverbinding (SSRS Configuration Manager) configureren voor meer informatie

  • Werk de databaseverbinding bij om de DNS-naam van de listener te gebruiken. voor rapportservers in de systeemeigen modus wijzigt u de naam van de rapportserverdatabase in Reporting Services Configuration Manager. Voor de SharePoint-modus wijzigt u de naam van de databaseserver voor de Reporting Services-servicetoepassing(en).

Stappen voor het voltooien van herstel na noodgevallen van Rapportserverdatabases

De volgende stappen moeten worden uitgevoerd na een failover van AlwaysOn-beschikbaarheidsgroepen naar een secundaire replica:

  1. Stop het exemplaar van de SQL Agent-service die werd gebruikt door de primaire database-engine die als host fungeert voor de Reporting Services-databases.

  2. Start de SQL Agent-service op de computer die de nieuwe primaire replica is.

  3. Stop de Report Server-service.

    Als de rapportserver zich in de systeemeigen modus bevindt, stopt u de Windows-server van de rapportserver met Behulp van Reporting Services Configuration Manager.

    Als de rapportserver is geconfigureerd voor de SharePoint-modus, stopt u de gedeelde Reporting Services-service in Centraal beheer van SharePoint.

  4. Start de rapportserverservice of Reporting Services SharePoint-service.

  5. Controleer of rapporten kunnen worden uitgevoerd op de nieuwe primaire replica.

Gedrag van rapportserver wanneer een failover plaatsvindt

Wanneer de rapportserverdatabases een failover ondergaan en u vervolgens de rapportserveromgeving hebt bijgewerkt om de nieuwe primaire replica te gebruiken, ontstaan er enkele operationele problemen als gevolg van het failover- en herstelproces. De impact van deze problemen is afhankelijk van de Reporting Services-belasting op het moment van failover en de tijd die nodig is voor AlwaysOn-beschikbaarheidsgroepen om een failover uit te voeren naar een secundaire replica en de rapportserverbeheerder de rapportageomgeving bij te werken voor het gebruik van de nieuwe primaire replica.

  • De uitvoering van achtergrondverwerking kan meer dan één keer plaatsvinden vanwege logica voor opnieuw proberen en het onvermogen van de rapportserver om gepland werk te markeren als voltooid tijdens de failoverperiode.

  • De uitvoering van achtergrondverwerking die normaal gesproken zou zijn geactiveerd om te worden uitgevoerd tijdens de periode van de failover, gebeurt niet omdat SQL Server Agent geen gegevens kan schrijven naar de rapportserverdatabase en deze gegevens worden niet gesynchroniseerd met de nieuwe primaire replica.

  • Nadat de databasefailover is voltooid en nadat de rapportserverservice opnieuw is opgestart, worden SQL Server Agent-taken automatisch opnieuw gemaakt. Totdat de SQL-agenttaken opnieuw worden gemaakt, worden alle achtergronduitvoeringen die zijn gekoppeld aan SQL Server Agent-taken niet verwerkt. Dit omvat Reporting Services-abonnementen, planningen en momentopnamen.

Zie ook