Reporting Services mit AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

Dieses Thema enthält Informationen zum Konfigurieren Reporting Services für die Arbeit mit Always On Verfügbarkeitsgruppen in SQL Server 2014. Die drei Szenarien für die Verwendung Reporting Services und Always On Verfügbarkeitsgruppen sind Datenbanken für Berichtsdatenquellen, Berichtsserverdatenbanken und Berichtsentwurf. Die unterstützten Funktionen und die erforderliche Konfiguration sind für die drei Szenarien unterschiedlich.

Ein wichtiger Vorteil der Verwendung Always On Verfügbarkeitsgruppen mit Reporting Services Datenquellen besteht darin, lesbare sekundäre Replikate als Berichtsdatenquelle zu nutzen, während die sekundären Replikate gleichzeitig ein Failover für eine primäre Datenbank bereitstellen.

Allgemeine Informationen zu Always On Verfügbarkeitsgruppen finden Sie unter AlwaysOn FAQ for SQL Server 2012 (https://msdn.microsoft.com/sqlserver/gg508768).

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

Um Always On Verfügbarkeitsgruppen mit SQL Server 2014 Reporting Services verwenden zu können, 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 tritt auf, wenn Sie eine der Always On Verfügbarkeitsgruppeneigenschaften in die Reporting Services Verbindungszeichenfolge einschließen, der Server die Eigenschaft jedoch 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 AlwaysOn-Funktionen aus SQL Server 2012 in .NET Framework 3.5 SP1.

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

Hinweis

Reporting Services Konfigurationsdateien wie RSreportserver.config werden als Teil Always On Verfügbarkeitsgruppen nicht 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, die auf Always On Verfügbarkeitsgruppen basieren, kann je nachdem variieren, wie Ihr Administrator die Gruppenumgebung konfiguriert hat.

Um Always On Verfügbarkeitsgruppen für Berichtsdatenquellen zu verwenden, müssen Sie die Verbindungszeichenfolge der Berichtsdatenquelle konfigurieren, um den DNS-Namen der Verfügbarkeitsgruppe Listener 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 AlwaysOn-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 = AdventureWorks2008R2; 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 Berichts-Manager 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: SQL Server Report Builder für SQL Server 2012 oder SQL Server Data Tools (SSDT), wenn Sie neue Berichte erstellen. Weitere Informationen finden Sie in diesem Thema im Abschnitt „Berichtsentwurf“.

Zusätzliche Ressourcen:

• Verwalten von Berichtsdatenquellen

• Weitere Informationen zu den verfügbaren Verbindungszeichenfolgeneigenschaften finden Sie unter Using Connection String Keywords with SQL Server Native Client.

• Weitere Informationen zu Verfügbarkeitsgruppenlistenern finden Sie unter Erstellen oder Konfigurieren eines Verfügbarkeitsgruppenlisteners (SQL Server).

Ü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" der Übersicht über AlwaysOn-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 in SQL Server Report Builder für SQL Server 2012 oder eines Berichtsprojekts in SQL Server Data Tools (SSDT) kann ein Benutzer eine Berichtsdatenquellverbindungszeichenfolge so konfigurieren, dass sie neue Verbindungseigenschaften enthält, die von Always On Verfügbarkeitsgruppen bereitgestellt werden. Die Unterstützung für die neuen Verbindungseigenschaften hängt davon ab, wo ein Benutzer den Bericht in der Vorschau anzeigt.

• Lokale Vorschau: SQL Server Report Builder für SQL Server 2012 und SQL Server Data Tools (SSDT) verwenden das .NET Framework 4.0 und unterstützen Always On Verbindungszeichenfolgeneigenschaften von Verfügbarkeitsgruppen.

• Remote- oder Servermodusvorschau: Wenn nach dem Veröffentlichen von Berichten auf dem Berichtsserver oder der Verwendung der Vorschau in SQL Server Report Builder für SQL Server 2012 ein Fehler ähnlich dem folgenden angezeigt wird, ist dies ein Hinweis darauf, dass Sie eine Vorschau von Berichten für den Berichtsserver und den .NET Framework 3.5 SP1-Hotfix für Always On Verfügbarkeitsgruppen wurden nicht auf dem Berichtsserver installiert.

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

Berichtsserver-Datenbanken und Verfügbarkeitsgruppen

Reporting Services bietet eingeschränkte Unterstützung für die Verwendung Always On Verfügbarkeitsgruppen mit Berichtsserverdatenbanken. 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.

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

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

In diesem Abschnitt werden die Unterschiede zwischen der Interaktion zwischen SharePoint-Modus und Berichtsservern im einheitlichen Modus mit Always On Verfügbarkeitsgruppen zusammengefasst.

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. Für den SharePoint-Modus konfigurieren Sie den Datenbanknamen der Dienstanwendung so, dass er der Name des "Clientzugriffspunkts" ist, den Sie im Rahmen der SharePoint-Konfiguration erstellt haben. Weitere Informationen zum Konfigurieren von SharePoint mit Always On Verfügbarkeitsgruppen finden Sie unter Konfigurieren und Verwalten SQL Server Verfügbarkeitsgruppen für SharePoint Server (https://go.microsoft.com/fwlink/?LinkId=245165)).

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 Berichtsserverdatenbanken zu einer Always On Verfügbarkeitsgruppen aufgeführt:

• 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 sekundärer Replikate und zum Überprüfen, ob die Datensynchronisierung funktioniert, finden Sie unter Starten der Datenverschiebung in einer sekundären AlwaysOn-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ügbarkeitsgruppenfailover auf ein sekundäres 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 Auslastung zum Zeitpunkt des Failovers sowie der Dauer ab, die Always On Verfügbarkeitsgruppen benötigt, um ein Failover auf ein sekundäres Replikat durchzuführen und der Berichtsserveradministrator die Berichtsumgebung für die Verwendung des neuen primären Replikats zu aktualisieren.

• 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

SQL Server Native Client Unterstützung für Hochverfügbarkeit, NotfallwiederherstellungAlwaysOn-Verfügbarkeitsgruppen (SQL Server)Erste Schritte mit AlwaysOn-Verfügbarkeitsgruppen (SQL Server)Verwenden von Verbindungszeichenfolgenschlüsselwörtern mit SQL Server Native ClientSQL Server Native Client Support for High Availability, Disaster RecoveryAbout Client Connection Access to Availability Replicas (SQL Server)