Службы отчетов и группы доступности Always On (SQL Server)

Область применения:SQL Server

В этой статье содержатся сведения о настройке служб Reporting Services для работы с группами доступности AlwaysOn в SQL Server. Существует три варианта использования служб Reporting Services и групп доступности Always On: базы данных для источников данных отчетов, базы данных сервера отчетов и конструирование отчетов. Поддерживаемые функции и необходимая конфигурация для разных вариантов использования будут различными.

Ключевое преимущество использования групп доступности Always On с источниками данных служб Reporting Services заключается в том, что доступные для чтения вторичные реплики можно использовать в качестве источника данных для отчетов, при этом эти же вторичные реплики обеспечивают аварийное переключение для основной базы данных.

Общие сведения о группах доступности Always On см. в вопросах и ответах о группах доступности Always On для SQL Server 2012 (../../../sql-server/index.yml).

Требования, которые необходимо выполнить для использования служб Reporting Services и групп доступности AlwaysOn

Службы SQL Server Reporting Services и Сервер отчетов Power BI используют платформу .NET Framework 4.0 и поддерживают свойства строки подключения для групп доступности Always On при работе с источниками данных.

Чтобы использовать группы доступности Always On с Reporting Services 2014 и более ранними версиями, необходимо загрузить и установить исправление для .NET 3.5 SP1. Это исправление добавляет в клиент SQL поддержку функций групп доступности (AG), а также свойств строки подключения ApplicationIntent и MultiSubnetFailover. Если исправление не установлено на каждом компьютере, на котором размещен сервер отчетов, пользователи, пытающиеся просмотреть отчеты, увидят сообщение об ошибке, аналогичное следующему, и сообщение об ошибке будет записано в журнал трассировки сервера отчетов:

Сообщение об ошибке. "Ключевое слово applicationintent не поддерживается"

Сообщение возникает при включении одного из свойств групп доступности AlwaysOn в строка подключения служб Reporting Services, но сервер не распознает это свойство. Отмеченное сообщение об ошибке отображается при нажатии кнопки "Проверить подключение" в пользовательских интерфейсах служб Reporting Services и при предварительном просмотре отчета, если удаленные ошибки включены на серверах отчетов.

Дополнительные сведения о необходимом исправлении см. в KB 2654347: исправление добавляет поддержку функций Always On из SQL Server 2012 в .NET Framework 3.5 SP1.

Дополнительные сведения о других требованиях групп доступности Always On см. в статье Предварительные требования, ограничения и рекомендации для групп доступности Always On.

Примечание.

Файлы конфигурации Reporting Services, например RSreportserver.config, не поддерживаются как часть функциональности групп доступности Always On. Если изменения в файл конфигурации на одном из серверов отчетов вносятся вручную, то необходимо будет вручную обновить реплики.

Источники данных отчетов и группы доступности

Поведение источников данных служб Reporting Services, основанных на группах доступности Always On, может различаться в зависимости от того, как администратор настроил среду AG.

Для использования групп доступности Always On для источников данных отчетов необходимо настроить строку подключения источника данных отчета так, чтобы в ней использовалось DNS-имя прослушивателя группы доступности. Поддерживаются следующие источники данных.

  • Источник данных ODBC, использующий SQL Native Client.

  • SQL Client с исправлением для .NET, применённым к серверу отчётов.

Строка подключения также может содержать новые свойства подключения Always On, которые настраивают запросы к отчетам таким образом, чтобы для отчетности только для чтения использовалась вторичная реплика. Использование вторичной реплики для запросов отчетов снижает нагрузку на первичную реплику чтения и записи. На следующей иллюстрации показан пример конфигурации AG с тремя репликами, в которой строки подключения к источникам данных служб Reporting Services настроены с параметром ApplicationIntent=ReadOnly. В этом примере запросы отчетов отправляются во вторичную реплику, а не в первичную реплику.

Ниже приведен пример строки подключения, где [AvailabilityGroupListenerName] ― это DNS-имя прослушивателя , заданное при создании реплик.

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

Кнопка Проверить подключение в пользовательском интерфейсе служб Reporting Services проверяет возможность установки соединения, однако не проверяет конфигурацию группы доступности (AG). Например, если вы включите ApplicationIntent в строку подключения к серверу, который не входит в группу доступности, этот дополнительный параметр будет проигнорирован, и кнопка Проверить подключение только проверит, что подключение к указанному серверу может быть установлено.

Место изменения строки подключения будет зависеть от способа создания и публикации отчетов.

  • Собственный режим. Для общих источников данных и отчетов, которые уже опубликованы на сервере отчетов, работающем в собственном режиме, используйте веб-портал.

  • Режим SharePoint. Для отчетов, которые уже опубликованы на сервере SharePoint, пользуйтесь страницами конфигурации SharePoint в библиотеках документов.

  • Проектирование отчетов: Построитель отчетов или SQL Server Data Tools (SSDT) для создания новых отчетов. Дополнительные сведения см. в разделе «Структура отчета» этой статьи.

Дополнительные ресурсы:

Замечания. Обычно при получении вторичными репликами изменений данных от первичной реплики происходит задержка. На задержку обновления между первичной и вторичными репликами влияют следующие факторы.

  • Число вторичных реплик. При добавлении в конфигурацию новых вторичных реплик задержка увеличивается.

  • Географическое местоположение и расстояние между первичной и вторичными репликами. Например, задержка будет больше, если вторичные реплики находятся в другом центре обработки данных, чем в ситуации, когда они расположены в том же здании, что и первичная реплика.

  • Настройка режима доступности для каждой реплики. Режим доступности определяет, должна ли первичная реплика ждать перед фиксацией транзакций в базе данных, пока вторичная реплика не запишет транзакцию на диск. Дополнительные сведения см. в разделе "Режимы доступности" статьи Обзор групп доступности AlwaysOn (SQL Server).

При использовании вторичного источника данных только для чтения в качестве источника данных служб Reporting Services важно обеспечить задержку обновления данных в соответствии с потребностями пользователей отчета.

Разработка отчетов и группы доступности

При конструировании отчетов в построителе отчетов или проекта отчета в SQL Server Data Tools (SSDT) пользователь может настроить строку подключения к источнику данных отчета с помощью новых свойств подключения, предоставляемых группами доступности Always On. Поддержка новых свойств соединения зависит от того, где пользователь просматривает отчеты.

  • Локальный предварительный просмотр: Построитель отчетов и SQL Server Data Tools (SSDT) используют платформу .NET Framework 4.0 и поддерживают свойства строки подключения для групп доступности Always On.

  • Предварительный просмотр в удаленном или серверном режиме: Если после публикации отчетов на сервер отчетов или при использовании функции предварительного просмотра в Конструкторе отчетов появляется ошибка, аналогичная приведенной ниже, это означает, что предварительный просмотр отчетов выполняется через сервер отчетов и что на сервере отчетов не установлено исправление для .NET Framework 3.5 SP1 для групп доступности Always On.

Сообщение об ошибке. "Ключевое слово applicationintent не поддерживается"

Базы данных сервера отчетов и группы доступности

Службы Reporting Services и сервер отчетов Power BI имеют ограниченную поддержку использования групп доступности Always On с базами данных сервера отчетов. Базы данных сервера отчетов можно настроить в группе доступности Always On (AG) так, чтобы они входили в состав реплики; однако службы Reporting Services не будут автоматически использовать другую реплику для баз данных сервера отчетов при отработке отказа. Использование MultiSubnetFailover с базами данных сервера отчетов не поддерживается.

Чтобы завершить переключение при отказе и восстановление, необходимо использовать ручные действия или пользовательские сценарии автоматизации. До выполнения этих действий некоторые функции сервера отчетов могут работать неправильно после отработки отказоустойчивого переключения группы доступности Always On.

Примечание.

При планировании переключения при отказе и аварийного восстановления для баз данных сервера отчетов рекомендуется всегда сохранять резервную копию ключа шифрования сервера отчетов.

Различия между собственным режимом SharePoint

В этом разделе приведены различия между способами взаимодействия сервера отчетов с группами доступности Always On в режиме интеграции с SharePoint и в собственном режиме.

Сервер отчетов, работающий в режиме интеграции с SharePoint, создает 3 базы данных для каждого создаваемого вами приложения служб Reporting Services. Соединение с базой данных сервера отчетов, работающей в режиме интеграции с SharePoint, настраивается в центре администрирования SharePoint при создании нового приложения службы SharePoint. Имена баз данных по умолчанию включают идентификатор GUID, связанный с приложением службы. Ниже приведены примеры имен баз данных, для сервера отчетов в режиме интеграции с SharePoint:

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6TempDB

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6_Alerting

Сервера отчетов, работающие в собственном режиме, используют 2 базы данных. Ниже приведены примеры имен баз данных, для сервера отчетов в собственном режиме работы:

  • Сервер отчетов

  • ReportServerTempDB

Примечание.

При настройке служб Reporting Services для работы с группой доступности (AG) модель восстановления для ReportServerTemp базы данных изменяется на Полная. В результате существуют сценарии, в которых ReportServerTemp база данных постоянно увеличивается. Рекомендуется удалить базу данных ReportServerTemp из конфигурации AG (группы доступности) и задать для модели восстановления значение «Simple». База ReportServerTemp данных хранит только временные данные. Удаление из группы доступности не влияет на службы Reporting Services (службы отчетов).

Собственный режим не поддерживает или не использует базы данных оповещений и связанные функции. Серверы отчетов, работающие в собственном режиме, настраиваются в диспетчере конфигурации служб Reporting Services. В режиме интеграции с SharePoint в качестве имени базы данных приложения службы следует указать имя точки доступа клиента, которую вы создали при конфигурации SharePoint. Дополнительные сведения о настройке SharePoint для работы с группами доступности Always On см. в статье Настройка групп доступности SQL Server для SharePoint Server и управление ими (/previous-versions/office/sharepoint-server-2010/hh913923(v=office.14)).

Примечание.

Серверы отчетов, работающие в режиме интеграции с SharePoint, используют процесс синхронизации между базами данных приложения служб Reporting Services и базами данных содержимого SharePoint. Важно поддерживать работу баз данных сервера отчетов и баз данных содержимого вместе. Следует рассмотреть возможность настройки их в одних и тех же группах доступности, чтобы переключение при отказе и восстановление выполнялись как единое целое. Рассмотрим следующий сценарий:

  • Вы восстанавливаете копию базы данных содержимого или переключаетесь при отказе на нее, хотя она не получила тех же последних обновлений, которые получила база данных сервера отчетов.
  • Процесс синхронизации служб Reporting Services обнаружит различия между списками элементов из базы данных содержимого и из баз данных сервера отчетов.
  • Процесс синхронизации удалит или обновит элементы в базе данных содержимого.

Подготовьте базы данных сервера отчетов для групп доступности

Ниже приведены основные шаги по подготовке и добавлению баз данных сервера отчетов в группы доступности Always On:

  • Создайте группу доступности и задайте DNS-имя прослушивателя.

  • Первичная реплика. Включите базы данных сервера отчетов в одну группу доступности и создайте первичную реплику, в которой будут представлены все базы данных сервера отчетов.

  • Вторичные реплики. Создайте одну или несколько вторичных реплик. Распространенный подход к копированию баз данных из первичной реплики в вторичные реплики заключается в восстановлении баз данных в каждой вторичной реплике с помощьюRESTORE WITH NORECOVERY. Дополнительные сведения о создании вторичных реплик и проверке работы синхронизации данных см. в статье Запуск перемещения данных для вторичной базы данных Always On (SQL Server).

  • Учетные данные сервера отчетов. Во вторичных репликах, созданных из первичной, необходимо создать соответствующие учетные данные сервера отчетов. Точные шаги зависят от типа проверки подлинности, используемой в среде служб Reporting Services; Учетная запись службы Windows Reporting Services, учетная запись пользователя Windows или проверка подлинности SQL Server. Дополнительные сведения см. в статье Настройка подключения к базе данных сервера отчетов (диспетчер конфигурации сервера отчетов).

  • Обновите подключение к базе данных, указав в нем DNS-имя прослушивателя. В отношении серверов отчетов, работающих в собственном режиме, измените параметр Имя базы данных сервера отчетов в диспетчере конфигурации служб Reporting Services. В режиме интеграции с SharePoint измените Имя сервера базы данных для приложений служб Reporting Services.

Действия по выполнению аварийного восстановления баз данных сервера отчетов

После переключения группы доступности Always On при отказе на вторичную реплику необходимо выполнить следующие действия:

  1. Остановите экземпляр службы SQL Server Agent, который использовался основным ядром СУБД, на котором размещались базы данных Reporting Services.

  2. Запустите службу SQL Server Agent на компьютере, который является новой первичной репликой.

  3. Остановите службу сервера отчетов.

    Если сервер отчетов работает в собственном режиме, остановите сервер Windows сервера отчетов с помощью диспетчера конфигурации служб Reporting Services.

    Если же сервер отчетов настроен в режиме интеграции с SharePoint, остановите общую службу Reporting Services в центре администрирования SharePoint.

  4. Запустите службу сервера отчетов или службу Reporting Services для SharePoint.

  5. Проверьте, что отчеты могут выполняться на новой первичной реплике.

Поведение сервера отчетов при переключении на резервный сервер

Когда для баз данных сервера отчетов выполняется переключение при отказе и среда сервера отчетов настроена на использование новой основной реплики, возникают некоторые эксплуатационные проблемы, вызванные процессами переключения при отказе и восстановления. Влияние этих проблем зависит от нагрузки на службы Reporting Services в момент переключения при отказе, а также от времени, необходимого для переключения группы доступности Always On на вторичную реплику и для обновления администратором сервера отчетов среды отчетности с целью использования новой первичной реплики.

  • Выполнение фоновой обработки может происходить несколько раз из-за механизма повторных попыток и невозможности сервера отчетов пометить запланированную задачу как завершенную в период переключения при отказе.

  • Выполнение фоновой обработки, которая обычно должна была бы запускаться в период переключения при отказе, не будет выполняться, так как агент SQL Server не сможет записать данные в базу данных сервера отчетов, и эти данные не будут синхронизированы с новой первичной репликой.

  • После завершения переключения при отказе базы данных и перезапуска службы сервера отчетов задания агента SQL Server будут автоматически воссозданы. Пока задания агент SQL Server не будут заново созданы, связанные с ними фоновые задачи не будут обрабатываться. К ним относятся подписки, расписания и снимки Reporting Services.

См. также

  • Last updated on