Reporting Services mit Always On-Verfügbarkeitsgruppen (SQL Server)

  • Artikel

Gilt für: SQL Server

Dieser Artikel enthält Informationen, wie Sie Reporting Services in Always On-Verfügbarkeitsgruppen (AG) zur Verwendung mit SQL Serverkonfigurieren. Die drei Szenarien zum Verwenden von Reporting Services und Always On-Verfügbarkeitsgruppen sind Datenbanken für Berichtsdatenquellen, Berichtsserver-Datenbanken und Berichtsentwurf. Die unterstützten Funktionen und die erforderliche Konfiguration sind für die drei Szenarien unterschiedlich.

Ein entscheidender Vorteil bei der Verwendung von Always On-Verfügbarkeitsgruppen mit Reporting Services-Datenquellen liegt darin, dass lesbare sekundäre Replikate als Berichtsdatenquelle genutzt werden, während gleichzeitig die sekundären Replikate ein Failover für eine primäre Datenbank bereitstellen.

Weitere allgemeine Informationen zu Always On-Verfügbarkeitsgruppen finden Sie unter Häufig gestellte Fragen zu Always On für SQL Server 2012 (../../../sql-server/index.yml).

Anforderungen für die Verwendung von Reporting Services und Always On-Verfügbarkeitsgruppen

SQL Server Reporting Services und Power BI-Berichtsserver verwenden .NET Framework 4.0 und unterstützen die Verwendung der Verbindungszeichenfolgen-Eigenschaften von Always On-Verfügbarkeitsgruppen mit Datenquellen.

Um Always On-Verfügbarkeitsgruppen mit Reporting Services 2014 und früher zu verwenden, müssen Sie einen Hotfix für .NET 3.5 SP1 herunterladen und installieren. Der Hotfix fügt Unterstützung für Funktionen des SQL Client für Verfügbarkeitsgruppen und Unterstützung der Verbindungszeichenfolgeneigenschaften ApplicationIntent und MultiSubnetFailoverhinzu. Wenn der Hotfix nicht auf jedem Computer installiert ist, der einen Berichtsserver hostet, dann sehen Benutzer, die versuchen, Berichte in der Vorschau anzuzeigen, eine Fehlermeldung wie die Folgende, und die Fehlermeldung wird in das Ablaufverfolgungsprotokoll des Berichtsservers geschrieben:

Fehlermeldung: "Keyword not supported 'applicationintent'" (Das Schlüsselwort wird nicht unterstützt: 'applicationintent')

Die Meldung wird ausgegeben, wenn Sie eine der Always On-Verfügbarkeitsgruppen-Eigenschaften in die Reporting Services-Verbindungszeichenfolge einschließen, aber der Server die Eigenschaft nicht erkennt. Die angegebene Fehlermeldung wird angezeigt, wenn Sie in den Reporting Services-Benutzeroberflächen auf die Schaltfläche „Verbindung testen“ klicken, und wenn Sie den Bericht in der Vorschau anzeigen, sofern Remotefehler auf den Berichtsservern aktiviert sind.

Weitere Informationen zum erforderlichen Hotfix finden Sie in KB 2654347A, Hotfix bietet Unterstützung für die Always On-Funktionen aus SQL Server 2012 in .NET Framework 3.5 SP1.

Informationen zu anderen Anforderungen von Always On-Verfügbarkeitsgruppen finden Sie unter Voraussetzungen, Einschränkungen und Empfehlungen für Always On-Verfügbarkeitsgruppen (SQL Server).

Hinweis

Reporting Services-Konfigurationsdateien wie RSreportserver.config werden nicht als Teil der Always On-Verfügbarkeitsgruppen-Funktion unterstützt. Wenn Sie manuelle Änderungen an einer Konfigurationsdatei auf einem der Berichtsserver vornehmen, müssen Sie die Replikate manuell aktualisieren.

Berichtsdatenquellen und Verfügbarkeitsgruppen

Das Verhalten von Reporting Services-Datenquellen auf Grundlage von Always On-Verfügbarkeitsgruppen kann abhängig davon variieren, wie der Administrator die Verfügbarkeitsgruppenumgebung konfiguriert hat.

Um Always On-Verfügbarkeitsgruppen für Berichtsdatenquellen zu verwenden, müssen Sie die Berichtsdatenquellen-Verbindungszeichenfolge konfigurieren, um die Verfügbarkeitsgruppe DNS-Name des Listeners zu verwenden. Die folgenden Datenquellen werden unterstützt:

  • ODBC-Datenquelle mit SQL Native Client.

  • SQL Client, mit dem auf den Berichtsserver angewendeten .NET-Hotfix.

Die Verbindungszeichenfolge kann auch neue Always On-Verbindungseigenschaften enthalten, mit denen die Berichtsabfrageanforderungen zum Verwenden sekundärer Replikate für die schreibgeschützte Berichterstellung konfiguriert werden. Durch die Verwendung von sekundären Replikaten für Berichtsanforderungen wird die Last für ein primäres Lese-/Schreib-Replikat verringert. Die folgende Abbildung ist ein Beispiel für eine Verfügbarkeitsgruppenkonfiguration mit drei Replikaten, in der die Reporting Services-Datenquellen-Verbindungszeichenfolgen mit ApplicationIntent=ReadOnly konfiguriert wurden. In diesem Beispiel werden die Berichtsabfrageanforderungen an ein sekundäres Replikat und nicht das primäre Replikat gesendet.

Im Folgenden sehen Sie eine Beispielverbindungszeichenfolge, bei der [AvailabilityGroupListenerName] der DNS-Name des Listeners ist, der bei Erstellung der Replikate konfiguriert wurde:

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

Über die Schaltfläche Verbindung testen auf den Reporting Services-Benutzeroberflächen wird überprüft, ob eine Verbindung hergestellt werden kann. Damit wird jedoch nicht die Verfügbarkeitsgruppenkonfiguration überprüft. Wenn Sie z. B. ApplicationIntent in eine Verbindungszeichenfolge zu einem Server einschließen, der kein Teil der Verfügbarkeitsgruppe ist, wird der zusätzliche Parameter ignoriert, und die Schaltfläche Verbindung testen überprüft nur, ob eine Verbindung zum angegebenen Server hergestellt werden kann.

Abhängig davon, wie die Berichte erstellt und veröffentlicht werden, wird bestimmt, wo Sie die Verbindungszeichenfolge bearbeiten:

  • Einheitlicher Modus: Verwenden Sie das Webportal für freigegebene Datenquellen und Berichte, die bereits auf einem Berichtsserver im einheitlichen Modus veröffentlicht wurden.

  • SharePoint-Modus: Verwenden Sie die SharePoint-Konfigurationsseiten innerhalb der Dokumentbibliotheken für Berichte, die bereits auf einem SharePoint-Server veröffentlicht wurden.

  • Berichtsentwurf: Berichts-Generator oder SQL Server Data Tools (SSDT) beim Erstellen neuer Berichte. Weitere Informationen finden Sie in diesem Thema im Abschnitt „Berichtsentwurf“.

Zusätzliche Ressourcen:

Überlegungen: Sekundäre Replikate empfangen Datenänderungen vom primären Replikat in der Regel mit Verzögerung. Die folgenden Faktoren können sich auf die Updatewartezeit zwischen den primären und sekundären Replikaten auswirken:

  • Die Anzahl der sekundären Replikate. Die Verzögerung nimmt mit jedem sekundären Replikat zu, das der Konfiguration hinzugefügt wird.

  • Geografischer Standort und Entfernung zwischen den primären und sekundären Replikaten. Die Verzögerung ist z. B. in der Regel größer, wenn die sekundären Replikate sich einem anderen Rechenzentrum befinden, als wenn sie sich im gleichen Gebäude wie das primäre Replikat befinden.

  • Konfiguration des Verfügbarkeitsmodus für jedes Replikat. Der Verfügbarkeitsmodus legt fest, ob das primäre Replikat mit dem Commit der Transaktionen für eine Datenbank wartet, bis das sekundäre Replikat die Transaktion auf den Datenträger geschrieben hat. Weitere Informationen finden Sie im Abschnitt „Verfügbarkeitsmodi“ des Themas Übersicht über Always On-Verfügbarkeitsgruppen (SQL Server).

Wenn ein schreibgeschütztes sekundäres Replikat als Reporting Services-Datenquelle verwendet wird, muss sichergestellt werden, dass die Datenupdatewartezeit die Anforderungen der Berichtsbenutzer erfüllt.

Berichtsentwurf und Verfügbarkeitsgruppen

Beim Entwerfen von Berichten im Berichts-Generator oder eines Berichtsprojekts in SQL Server Data Tools (SSDT) kann ein Benutzer eine Berichtsdatenquellen-Verbindungszeichenfolge so konfigurieren, dass sie von Always On-Verfügbarkeitsgruppen bereitgestellte neue Verbindungseigenschaften enthält. Die Unterstützung für die neuen Verbindungseigenschaften hängt davon ab, wo ein Benutzer den Bericht in der Vorschau anzeigt.

  • Lokale Vorschau: Berichts-Generator und SQL Server Data Tools (SSDT) verwenden das .NET Framework 4.0 und unterstützen Verbindungszeichenfolgen-Eigenschaften von Always On-Verfügbarkeitsgruppen.

  • Remote- oder Servermodusvorschau: Wenn nach dem Veröffentlichen von Berichten auf dem Berichtsserver oder Anzeigen der Vorschau im Berichts-Generator ein Fehler wie der Folgende angezeigt wird, ist dies ein Hinweis darauf, dass Sie Berichte vom Berichtsserver in der Vorschau anzeigen und der .NET Framework 3.5 SP1-Hotfix für Always On-Verfügbarkeitsgruppen nicht auf dem Berichtsserver installiert wurde.

Fehlermeldung: "Keyword not supported 'applicationintent'" (Das Schlüsselwort wird nicht unterstützt: 'applicationintent')

Berichtsserver-Datenbanken und Verfügbarkeitsgruppen

Reporting Services und Power BI-Berichtsserver bieten eingeschränkte Unterstützung für die Verwendung von Always On-Verfügbarkeitsgruppen mit Berichtsserver-Datenbanken. Die Berichtsserver-Datenbanken können in Verfügbarkeitsgruppen als Teil eines Replikats konfiguriert werden, Reporting Services verwendet bei einem Failover jedoch nicht automatisch ein anderes Replikat für die Berichtsserver-Datenbanken. Die Verwendung von MultiSubnetFailover mit den Berichtsserver-Datenbanken wird nicht unterstützt.

Manuelle Aktionen oder benutzerdefinierte Automatisierungsskripts müssen verwendet werden, um das Failover und die Wiederherstellung abzuschließen. Bis diese Aktionen abgeschlossen sind, funktionieren einige Funktionen des Berichtsservers möglicherweise nicht ordnungsgemäß nach dem Always On-Verfügbarkeitsgruppen-Failover.

Hinweis

Wenn Sie Failover und Notfallwiederherstellung für die Berichtsserver-Datenbanken planen, sollten Sie immer eine Kopie des Berichtsserververschlüsselungsschlüssels sichern.

Unterschiede zwischen dem einheitlichen Modus und dem SharePoint-Modus

Dieser Abschnitt fasst die Unterschiede bei der Interaktion von Berichtsservern im SharePoint-Modus und im einheitlichen Modus mit Always On-Verfügbarkeitsgruppen zusammen.

Ein SharePoint-Berichtsserver erstellt für jede Reporting Services-Dienstanwendung, die Sie erstellen, 3 Datenbanken. Die Verbindung mit den Berichtsserver-Datenbanken im SharePoint-Modus wird in der SharePoint-Zentraladministration konfiguriert, wenn Sie die Dienstanwendung erstellen. Die Standardnamen der Datenbanken enthalten eine GUID für die Dienstanwendung. Datenbanknamen für einen SharePoint-Modusberichtsserver können beispielsweise wie folgt aussehen:

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6TempDB

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6_Alerting

Für Berichtsserver im einheitlichen Modus werden 2 Datenbanken verwendet. Datenbanknamen für einen Berichtsserver im einheitlichen Modus können beispielsweise wie folgt aussehen:

  • ReportServer

  • ReportServerTempDB

Der einheitliche Modus unterstützt bzw. verwendet Warnungsdatenbanken und zugehörige Funktionen nicht. Berichtsserver im einheitlichen Modus konfigurieren Sie im Konfigurations-Manager für Reporting Services. Im SharePoint-Modus konfigurieren Sie den Dienstanwendungsdatenbanknamen als Namen des „Clientzugriffspunkts“, den Sie als Teil der SharePoint-Konfiguration erstellten. Weitere Informationen zum Konfigurieren von SharePoint mit Always On-Verfügbarkeitsgruppen finden Sie unter Konfigurieren und Verwalten von SQL Server-Verfügbarkeitsgruppen für SharePoint Server (/previous-versions/office/sharepoint-server-2010/hh913923(v=office.14)).

Hinweis

Berichtsserver im SharePoint-Modus verwenden einen Synchronisierungsvorgang zwischen den Reporting Services-Dienstanwendungsdatenbanken und den SharePoint-Inhaltsdatenbanken. Es ist wichtig, die Berichtsserver-Datenbanken und Inhaltsdatenbanken zusammen zu verwalten. Sie sollten erwägen, sie in den gleichen Verfügbarkeitsgruppen zu konfigurieren, damit sie bei Failover und Wiederherstellung als Satz behandelt werden. Nehmen Sie das folgende Szenario als Beispiel:

  • Sie führen eine Wiederherstellung oder ein Failover zu einer Kopie der Inhaltsdatenbank aus, die nicht die gleichen letzten Updates wie die Berichtsserver-Datenbank empfangen hat.
  • Der Reporting Services-Synchronisierungsvorgang erkennt Unterschiede zwischen der Liste der Elemente in der Inhaltsdatenbank und den Berichtsserver-Datenbanken.
  • Der Synchronisierungsvorgang löscht oder aktualisiert Elemente in der Inhaltsdatenbank.

Vorbereiten von Berichtsserver-Datenbanken für Verfügbarkeitsgruppen

Im Folgenden sind die grundlegenden Schritte zum Vorbereiten und Hinzufügen der Berichtsserver-Datenbanken zu einer Always On-Verfügbarkeitsgruppe beschrieben:

  • Erstellen Sie die Verfügbarkeitsgruppe, und konfigurieren Sie einen DNS-Namen des Listeners.

  • Primäres Replikat: Konfigurieren Sie die Berichtsserverdatenbanken als Teil einer einzelnen Verfügbarkeitsgruppe, und erstellen Sie ein primäres Replikat, das alle Berichtsserverdatenbanken einschließt.

  • Sekundäre Replikate: Erstellen Sie mindestens ein sekundäres Replikat. Die übliche Methode zum Kopieren der Datenbanken vom primären Replikat zum sekundären Replikat besteht darin, die Datenbanken mit „RESTORE WITH NORECOVERY“ auf jedem sekundären Replikat wiederherzustellen. Weitere Informationen zum Erstellen von sekundären Replikaten und zum Überprüfen, ob die Datensynchronisierung funktioniert, finden Sie unter Starten der Datenverschiebung auf einer sekundären Always On-Datenbank (SQL Server).

  • Berichtsserveranmeldeinformationen: Sie müssen die entsprechenden Berichtsserveranmeldeinformationen auf den sekundären Replikaten erstellen, die Sie auf dem primären Replikat erstellt haben. Die genauen Schritte hängen davon ab, welchen Authentifizierungstyp Sie in der Reporting Services-Umgebung verwenden; Windows-Reporting Services-Dienstkonto, Windows-Benutzerkonto oder SQL Server-Authentifizierung. Weitere Informationen finden Sie unter Konfigurieren einer Berichtsserver-Datenbankverbindung (SSRS-Konfigurations-Manager).

  • Aktualisieren Sie die Datenbankverbindung, um den DNS-Namen des Listeners zu verwenden. Ändern Sie den Berichtsserver-Datenbanknamen für Berichtsserver im einheitlichen Modus im Konfigurations-Manager für Reporting Services. Ändern Sie für den SharePoint-Modus den Datenbankservernamen für die Reporting Services-Dienstanwendung(en).

Schritte zum Abschluss der Notfallwiederherstellung von Berichtsserver-Datenbanken

Die folgenden Schritte müssen nach einem Always On-Verfügbarkeitsgruppen-Failover zu einem sekundären Replikat ausgeführt werden:

  1. Beenden Sie die Instanz des SQL Agent-Diensts, der von der primären Datenbank-Engine verwendet wurde, die die Reporting Services-Datenbanken hostet.

  2. Starten Sie den SQL Agent-Dienst auf dem Computer, der das neue primäre Replikat ist.

  3. Beenden Sie den Berichtsserverdienst.

    Wenn der Berichtsserver im einheitlichen Modus ausgeführt wird, beenden Sie den Windows-Berichtsserver mithilfe des Konfigurations-Manager für Reporting Services.

    Wenn der Berichtsserver für den SharePoint-Modus konfiguriert ist, beenden Sie den freigegebenen Reporting Services-Dienst in der SharePoint-Zentraladministration.

  4. Starten Sie den Berichtsserverdienst oder Reporting Services-SharePoint-Dienst.

  5. Stellen Sie sicher, dass Berichte für das neue primäre Replikat ausgeführt werden können.

Berichtsserververhalten, wenn ein Failover auftritt

Bei einem Failover der Berichtsserver-Datenbanken in einer Berichtsserverumgebung, die für die Verwendung des neuen primären Replikats aktualisiert wurde, entstehen funktionale Probleme, die sich aus dem Failover und dem Wiederherstellungsvorgang ergeben. Die Auswirkungen dieser Probleme hängen von der Reporting Services-Last zum Zeitpunkt des Failovers und von der Länge der Zeit ab, die die Always On-Verfügbarkeitsgruppen zum Failover auf ein sekundäres Replikat benötigen, und die der Berichtsserver-Administrator zum Aktualisieren der Berichtsumgebung für die Verwendung des neuen primären Replikats braucht.

  • Die Ausführung der Hintergrundverarbeitung tritt möglicherweise mehr als einmal auf. Dies liegt an der Wiederholungslogik und der Unfähigkeit des Berichtsservers, die geplante Arbeit während des Failoverzeitraums als abgeschlossen zu markieren.

  • Die Ausführung der Hintergrundverarbeitung, die normalerweise für den Zeitraum des Failovers ausgelöst worden wäre, tritt nicht auf, da der SQL Server-Agent nicht in der Lage ist, Daten in die Berichtsserver-Datenbank zu schreiben und diese Daten nicht mit dem neuen primären Replikat synchronisiert werden.

  • Nachdem das Datenbankfailover abgeschlossen wurde, und nachdem der Berichtsserverdienst neu gestartet wurde, werden Aufträge des SQL Server-Agents automatisch neu erstellt. Hintegrundausführungen, die dem SQL Server-Agent zugeordnet sind, werden so lange nicht verarbeitet, bis die SQL Agent-Aufträge neu erstellt werden. Hierzu zählen Reporting Services-Abonnements, Zeitpläne und Momentaufnahmen.

Weitere Informationen