Sdílet prostřednictvím

Reporting Services se skupinami dostupnosti AlwaysOn (SQL Server)

platí pro:SQL Server

Tento článek obsahuje informace o konfiguraci služby Reporting Services pro práci se skupinami dostupnosti AlwaysOn (AG) na SQL Serveru. Tři scénáře použití služby Reporting Services a skupin dostupnosti Always On zahrnují databáze pro zdroje dat sestav, databáze serveru sestav a návrh sestav. Podporované funkce a požadovaná konfigurace se pro tři scénáře liší.

Klíčovou výhodou použití skupin dostupnosti Always On se zdroji dat služby Reporting Services je možnost používat čitelné sekundární repliky jako zdroj dat pro generování sestav, zatímco tyto sekundární repliky současně poskytují přepnutí při selhání pro primární databázi.

Obecné informace o skupinách dostupnosti AlwaysOn najdete v tématu Nejčastější dotazy k SQL Serveru 2012 (..). /.. /.. /sql-server/index.yml).

Požadavky na používání služeb Reporting Services a skupin dostupnosti AlwaysOn

SQL Server Reporting Services a Power BI Report Server používá .NET framework 4.0 a podporuje vlastnosti připojovacího řetězce skupin dostupnosti Always On pro použití se zdroji dat.

Pokud chcete používat skupiny dostupnosti AlwaysOn se službou Reporting Services 2014 a staršími verzemi, musíte stáhnout a nainstalovat opravu hotfix pro .NET 3.5 SP1. Oprava hotfix přidává podporu SQL Client pro funkce skupin dostupnosti (AG) a podporu vlastností připojovacího řetězce ApplicationIntent a MultiSubnetFailover. Pokud není oprava hotfix nainstalovaná na každém počítači, který je hostitelem serveru sestav, zobrazí se uživatelům, kteří se pokoušejí zobrazit náhled sestav, chybová zpráva podobná následující a chybová zpráva se zapíše do protokolu trasování serveru sestav:

Zpráva o chybě: Klíčové slovo není podporováno 'applicationintent'.

Tato zpráva se zobrazí, když do připojovacího řetězce služby Reporting Services zahrnete jednu z vlastností skupin dostupnosti AlwaysOn, ale server vlastnost nerozpozná. Zaznamenaná chybová zpráva se zobrazí, když v uživatelských rozhraních služby Reporting Services vyberete tlačítko Test připojení, a také když zobrazíte náhled sestavy, pokud jsou na serverech sestav povoleny vzdálené chyby.

Další informace o požadované opravě hotfix naleznete v článku KB 2654347A oprava hotfix zavádí podporu funkcí AlwaysOn z SQL Serveru 2012 na rozhraní .NET Framework 3.5 SP1.

Informace o dalších požadavcích na skupiny dostupnosti AlwaysOn najdete v tématu Požadavky, omezení a doporučení pro skupiny dostupnosti AlwaysOn (SQL Server).

Poznámka:

Konfigurační soubory služby Reporting Services, jako je napříkladRSreportserver.config , nejsou podporovány jako součást funkcí skupin dostupnosti AlwaysOn. Pokud ručně provedete změny konfiguračního souboru na jednom ze serverů sestav, budete muset repliky aktualizovat ručně.

Zdroje dat v sestavách a skupiny dostupnosti

Chování zdrojů dat služby Reporting Services na základě skupin dostupnosti Always On se může lišit podle toho, jak váš správce nakonfiguroval prostředí těchto skupin.

Pokud chcete pro zdroje dat sestavy využít skupiny dostupnosti AlwaysOn, musíte nakonfigurovat připojovací řetězec zdroje dat sestavy tak, aby používal název DNS naslouchacího procesu skupiny dostupnosti. Podporované zdroje dat jsou následující:

  • Zdroj dat ODBC pomocí nativního klienta SQL

  • Klient SQL s nainstalovanou opravou hotfix .NET na serveru sestav.

Připojovací řetězec může obsahovat také nové vlastnosti připojení Always On, které konfigurují dotazy sestav tak, aby používaly sekundární repliku pro sestavy pouze pro čtení. Použití sekundární repliky pro požadavky na generování sestav snižuje zatížení primární repliky, která zpracovává operace čtení i zápisu. Následující ilustrace je příkladem AG konfigurace se třemi kopiemi, kde byly připojovací řetězce zdroje dat služby Reporting Services nakonfigurovány s parametrem ApplicationIntent=ReadOnly. V tomto příkladu se požadavky na dotazy sestavy odesílají do sekundární repliky, nikoli primární repliky.

Následuje příklad připojovacího řetězce, kde [AvailabilityGroupListenerName] je název DNS naslouchacího procesu nakonfigurovaný při vytváření replik:

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

Tlačítko Test připojení v uživatelských rozhraních služby Reporting Services ověří, zda je možné navázat připojení, ale neověří konfiguraci AG. Pokud například zahrnete ApplicationIntent do připojovacího řetězce k serveru, který není součástí AG, nadbytečný parametr bude ignorován a tlačítko Test připojení ověří pouze připojení, které je možné navázat na zadaný server.

V závislosti na tom, jak se sestavy vytvářejí a publikují, se určuje, kde upravíte připojovací řetězec:

  • Nativní režim: Webový portál použijte pro sdílené zdroje dat a sestavy, které jsou již publikovány na serveru sestav v nativním režimu.

  • Režim SharePointu: Konfigurační stránky SharePointu v knihovnách dokumentů můžete použít pro sestavy, které jsou již publikovány na serveru SharePoint.

  • Návrh sestavy: Při vytváření nových sestav použijte Tvůrce sestav nebo SQL Server Data Tools (SSDT). Podívejte se do části 'Návrh sestavy' v tomto článku pro více informací.

Další zdroje informací:

Úvahy: Sekundární repliky obvykle dochází ke zpoždění při přijímání změn dat z primární repliky. Latenci aktualizace mezi primárními a sekundárními replikami můžou ovlivnit následující faktory:

  • Počet sekundárních replik. Zpoždění se zvyšuje s každou sekundární replikou přidanou do konfigurace.

  • Zeměpisné umístění a vzdálenost mezi primárními a sekundárními replikami. Zpoždění je například obvykle větší, pokud jsou sekundární repliky v jiném datovém centru, než kdyby byly ve stejné budově jako primární replika.

  • Konfigurace režimu dostupnosti pro každou repliku Režim dostupnosti určuje, zda primární replika čeká na potvrzení transakcí v databázi, dokud sekundární replika zapíše transakci na disk. Další informace najdete v části Režimy dostupnosti v přehledu skupin dostupnosti AlwaysOn (SQL Server).

Při použití sekundární databáze pouze pro čtení jako zdroje dat pro Reporting Services je důležité zajistit, aby časová prodleva při aktualizaci dat splňovala potřeby uživatelů reportů.

Návrh zprávy a skupiny dostupnosti

Při navrhování sestav v Tvůrci sestav nebo projektu sestavy v SQL Server Data Tools (SSDT) může uživatel nakonfigurovat připojovací řetězec zdroje dat sestavy tak, aby obsahoval nové vlastnosti připojení poskytované skupinami dostupnosti AlwaysOn. Podpora nových vlastností připojení závisí na tom, kde uživatel zobrazí náhled sestavy.

  • Místní náhled: Tvůrce sestav a SQL Server Data Tools (SSDT) používají rozhraní .NET Framework 4.0 a podporují vlastnosti připojovacího řetězce skupin dostupnosti AlwaysOn.

  • Náhled vzdáleného režimu nebo režimu serveru: Pokud po publikování sestav na server sestav nebo použití náhledu v Tvůrci sestav se zobrazí chyba podobná následující, znamená to, že se zobrazují náhledy sestav na serveru sestav a opravy hotfix rozhraní .NET Framework 3.5 SP1 pro skupiny dostupnosti AlwaysOn nebyly nainstalovány na serveru sestav.

Zpráva o chybě: Klíčové slovo není podporováno 'applicationintent'.

Databáze serveru sestav a skupiny dostupnosti

Služba Reporting Services a Server sestav Power BI nabízí omezenou podporu pro používání skupin dostupnosti AlwaysOn s databázemi serveru sestav. Databáze serveru sestav lze nakonfigurovat ve skupině dostupnosti (Availability Group) tak, aby byly součástí repliky; Služba Reporting Services ale při selhání nebude automaticky používat jinou repliku pro databáze serveru sestav. Použití funkce MultiSubnetFailover s databázemi serveru sestav se nepodporuje.

Ruční akce nebo vlastní automatizační skripty je potřeba použít k dokončení převzetí služeb při selhání a obnovení. Dokud se tyto akce nedokončí, nemusí některé funkce serveru sestav fungovat správně po převzetí služeb při selhání skupin dostupnosti AlwaysOn.

Poznámka:

Při plánování přepnutí a zotavení po havárii pro databáze serveru sestav se doporučuje vždy zálohovat šifrovací klíč serveru sestav.

Rozdíly mezi nativním režimem SharePointu

Tato část shrnuje rozdíly mezi tím, jak sharepointový režim a nativní servery sestav pracují se skupinami dostupnosti AlwaysOn.

Server sestav SharePointu vytvoří 3 databáze pro každou aplikaci služby Reporting Services, kterou vytvoříte. Připojení k databázím serveru sestav v režimu SharePoint je nakonfigurováno v Centrální správě SharePointu při vytváření aplikace služby. Výchozí názvy databází zahrnují identifikátor GUID přidružený k aplikaci služby. Následují příklady názvů databází pro server sestav v režimu SharePoint:

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6TempDB

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6_Alerting

Servery sestav v nativním režimu používají 2 databáze. Následuje příklad názvů databází pro server sestav v nativním režimu:

  • ReportServer

  • ReportServerTempDB

Poznámka:

Při konfiguraci služby Reporting Services pro práci se skupinou dostupnosti (AG) se model obnovení databáze ReportServerTemp změní na Úplné. V důsledku toho existují scénáře, ve kterých ReportServerTemp databáze stále roste. Osvědčeným postupem je odebrat ReportServerTemp databázi z konfigurace skupiny dostupnosti a nastavit model obnovení na jednoduchý. Databáze ReportServerTemp ukládá pouze dočasná data. Odebrání ze skupiny dostupnosti nemá vliv na službu Reporting Services.

Nativní režim nepodporuje ani nepoužívá databáze výstrah a související funkce. Servery sestav v nativním režimu nakonfigurujete v nástroji Configuration Manager služby Reporting Services. V režimu SharePointu nakonfigurujete název databáze aplikace služby jako název "přístupového bodu klienta", který jste vytvořili v rámci konfigurace Služby SharePoint. Další informace o konfiguraci SharePointu se skupinami dostupnosti AlwaysOn najdete v tématu Konfigurace a správa skupin dostupnosti SQL Serveru pro SharePoint Server (/previous-versions/office/sharepoint-server-2010/hh913923(v=office.14)).

Poznámka:

Servery sestav režimu SharePoint používají proces synchronizace mezi databázemi aplikací služby Reporting Services a databázemi obsahu služby SharePoint. Je důležité udržovat databáze serveru sestav a databáze obsahu společně. Měli byste zvážit jejich konfiguraci ve stejných skupinách dostupnosti, aby mohly při selhání přejít na záložní a obnovit jako celek. Představte si následující scénář:

  • Obnovíte nebo provedete převzetí služeb při selhání na kopii databáze obsahu, která neobdržela stejné nedávné aktualizace jako databáze serveru sestav.
  • Proces synchronizace služby Reporting Services rozpozná rozdíly mezi seznamem položek v databázi obsahu a databázemi serveru sestav.
  • Proces synchronizace odstraní nebo aktualizuje položky v databázi obsahu.

Příprava databází reportovacího serveru pro dostupnostní skupiny

Následuje základní postup přípravy a přidání databází serveru sestav do skupin dostupnosti AlwaysOn:

  • Vytvořte skupinu dostupnosti a nakonfigurujte název DNS listeneru.

  • Primární replika: Nakonfigurujte databáze serveru sestav tak, aby byly součástí jedné skupiny dostupnosti, a vytvořte primární repliku, která zahrnuje všechny databáze serveru sestav.

  • Sekundární repliky: Vytvořte jednu nebo více sekundárních replik. Běžným přístupem ke kopírování databází z primární repliky do sekundárních replik je obnovení databází do každé sekundární repliky pomocí funkce RESTORE WITH NORECOVERY. Další informace o vytváření sekundárních replik a ověřování synchronizace dat najdete v tématu Zahájení přesunu dat na sekundární databázi AlwaysOn (SQL Server).

  • Přihlašovací údaje serveru sestav: Na sekundárních replikách, které jste vytvořili na primárním serveru, musíte vytvořit odpovídající přihlašovací údaje serveru sestav. Přesný postup závisí na tom, jaký typ ověřování používáte v prostředí služby Reporting Services. Účet služby Windows Reporting Services, uživatelský účet systému Windows nebo ověřování SYSTÉMU SQL Server. Další informace najdete v tématu Konfigurace připojení k databázi serveru sestav (SSRS Configuration Manager)

  • Aktualizujte připojení k databázi pro použití názvu DNS posluchače. pro servery sestav v nativním režimu změňte název databáze serveru sestav ve Správci konfigurace služby Reporting Services. V režimu Služby SharePoint změňte název databázového serveru pro aplikace služby Reporting Services.

Kroky dokončení obnovy po havárii databází serveru Report

Po převzetí služeb při selhání skupin dostupnosti AlwaysOn do sekundární repliky je potřeba provést následující kroky:

  1. Zastavte instanci služby agenta SQL, kterou používal primární databázový stroj hostující databáze služby Reporting Services.

  2. Spusťte službu agenta SQL na počítači, který je novou primární replikou.

  3. Zastavte službu Serveru sestav.

    Pokud je server sestav v nativním režimu, zastavte službu serveru sestav systému Windows pomocí nástroje Správce konfigurace Reporting Services.

    Pokud je server sestav nakonfigurovaný pro režim SharePointu, zastavte sdílenou službu Reporting Services v Centrální správě SharePointu.

  4. Spusťte službu serveru sestav nebo službu SharePoint pro Reporting Services.

  5. Ověřte, že se sestavy můžou spouštět proti nové primární replice.

Chování serveru sestav při přepnutí při selhání

Když dojde k failoveru databází serveru sestav a aktualizujete prostředí serveru sestav, aby používalo novou primární repliku, mohou nastat provozní problémy vyplývající z procesu failoveru a obnovení. Dopad těchto problémů se liší v závislosti na zatížení služby Reporting Services v době převzetí služeb při selhání a také v době, po kterou trvá, aby skupiny dostupnosti AlwaysOn převzaly služby při selhání sekundární replikou a aby správce serveru sestav aktualizoval prostředí pro vytváření sestav tak, aby používalo novou primární repliku.

  • Provádění zpracování na pozadí může nastat více než jednou z důvodu logiky opakování a nemožnosti serveru sestav označit naplánovanou práci jako dokončenou během období převzetí služeb při selhání.

  • Provedení zpracování na pozadí, které by bylo normálně spuštěno během období převzetí služeb při selhání, nenastane, protože agent SQL Serveru nebude moci zapisovat data do databáze serveru sestav a tato data nebudou synchronizována s novou primární replikou.

  • Po dokončení přepnutí při selhání databáze a restartování služby serveru sestav se úlohy SQL Server Agent automaticky vytvoří. Dokud se úlohy agenta SQL znovu nevytvoří, nezpracují se žádné spouštění na pozadí přidružené k úlohám agenta SQL Serveru. To zahrnuje předplatné, časové plány a snímky v rámci Reporting Services.

Viz také

  • Last updated on