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

Dieses Thema enthält Informationen über die Konfiguration von Reporting Services zur Verwendung mit AlwaysOn-Verfügbarkeitsgruppen (AG) in SQL Server 2012. Die drei Szenarien zum Verwenden von Reporting Services und AlwaysOn-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 AlwaysOn-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.

Allgemeine Informationen zu AlwaysOn-Verfügbarkeitsgruppen finden Sie unter den FAQ zu AlwaysOn für SQL Server 2012 (https://msdn.microsoft.com/en-us/sqlserver/gg508768).

In diesem Thema:

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

• Berichtsdatenquellen und Verfügbarkeitsgruppen

• Berichtsentwurf und Verfügbarkeitsgruppen

• Berichtsserver-Datenbanken und Verfügbarkeitsgruppen

• • Unterschiede zwischen dem einheitlichen Modus und dem SharePoint-Modus

  • Vorbereiten von Berichtsserver-Datenbanken für Verfügbarkeitsgruppen

  • Schritte zum Abschluss der Notfallwiederherstellung von Berichtsserver-Datenbanken

  • Berichtsserververhalten, wenn ein Failover auftritt

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

Um AlwaysOn-Verfügbarkeitsgruppen mit SQL Server 2012 Reporting Services 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 MultiSubnetFailover hinzu. 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: "Das Schlüsselwort wird nicht unterstützt: 'applicationintent'"

Die Meldung wird ausgegeben, wenn Sie eine der AlwaysOn-Verfügbarkeitsgruppen-Eigenschaften in die Reporting Services-Verbindungszeichenfolge einschließen, aber der Server die Eigenschaft nicht erkennt. Die angegebene Fehlermeldung wird angezeigt, wenn Sie auf die Schaltfläche 'Verbindung testen' in den Reporting Services-Benutzeroberflächen 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 AlwaysOn-Verfügbarkeitsgruppen-Anforderungen finden Sie unter Voraussetzungen, Einschränkungen und Empfehlungen für AlwaysOn-Verfügbarkeitsgruppen (SQL Server).

  

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

Nach oben

Berichtsdatenquellen und Verfügbarkeitsgruppen

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

Um AlwaysOn-Verfügbarkeitsgruppen für Berichtsdatenquellen zu verwenden, müssen Sie die Berichtsdatenquellenverbindungszeichenfolge 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 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-Datenquellenverbindungszeichenfolgen 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-Berichts-Generator für SQL Server 2012 oder SQL Server-Datentools (SSDT), wenn Sie neue Berichte erstellen. Weitere Informationen finden Sie im Abschnitt 'Berichtsentwurf' in diesem Thema.

Zusätzliche Ressourcen:

• Verwalten von Berichtsdatenquellen

• Weitere Informationen zu den verfügbaren Verbindungszeichenfolgeneigenschaften finden Sie unter Verwenden von Schlüsselwörtern für Verbindungszeichenfolgen mit 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 über Verfügbarkeitsmodi unter Ü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.

Nach oben

Berichtsentwurf und Verfügbarkeitsgruppen

Beim Entwerfen von Berichten in SQL Server-Berichts-Generator für SQL Server 2012 oder eines Berichtsprojekts in SQL Server-Datentools (SSDT) kann ein Benutzer eine Berichtsdatenquellenverbindungszeichenfolge so konfigurieren, dass sie von AlwaysOn-Verfügbarkeitsgruppen bereitgestellte 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: SQL Server-Berichts-Generator für SQL Server 2012 und SQL Server-Datentools (SSDT) verwenden .NET Framework 4.0 und unterstützen AlwaysOn-Verfügbarkeitsgruppen-Verbindungszeichenfolgeneigenschaften.

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

Fehlermeldung: "Das Schlüsselwort wird nicht unterstützt: 'applicationintent'"

Nach oben

Berichtsserver-Datenbanken und Verfügbarkeitsgruppen

Reporting Services bietet eingeschränkte Unterstützung für das Verwenden von AlwaysOn-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.

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

 

Nach oben

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 AlwaysOn-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 Reporting Services-Konfigurations-Manager. 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 AlwaysOn-Verfügbarkeitsgruppen finden Sie unter Konfigurieren und Verwalten von 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.

Nach oben

Vorbereiten von Berichtsserver-Datenbanken für Verfügbarkeitsgruppen

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

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

• Primäres Replikat: Konfigurieren Sie die Berichtsserver-Datenbanken als Teil einer einzelnen Verfügbarkeitsgruppe, und erstellen Sie ein primäres Replikat, das alle Berichtsserver-Datenbanken einschließt. Dazu gehört Folgendes:

• Sekundäre Replikate: Erstellen Sie ein oder mehrere sekundäre Replikate. 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 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 Verbindung mit der Berichtsserver-Datenbank (einheitlicher Modus).

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

Nach oben

Schritte zum Abschluss der Notfallwiederherstellung von Berichtsserver-Datenbanken

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

1. Beenden Sie die Instanz des SQL Agent-Diensts, der vom primären Datenbankmodul verwendet wurde, das 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 Reporting Services Konfigurations-Managers.

   Wenn der Berichtsserver für den SharePoint-Modus konfiguriert ist, beenden Sie den freigegebenen Reporting Services-Dienst in 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.

 

Nach oben

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 AlwaysOn-Verfügbarkeitsgruppen zum Failover auf ein sekundäres Replikat benötigt 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.

Nach oben

Siehe auch

Konzepte

SQL Server Native Client-Unterstützung für hohe Verfügbarkeit, Notfallwiederherstellung

AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

Erste Schritte mit AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

Verwenden von Schlüsselwörtern für Verbindungszeichenfolgen mit SQL Server Native Client

SQL Server Native Client-Unterstützung für hohe Verfügbarkeit, Notfallwiederherstellung

Informationen zum Clientverbindungszugriff auf Verfügbarkeitsreplikate (SQL Server)