Бөлісу құралы:

Службы Reporting Services с группами доступности AlwaysOn (SQL Server)

  • Мақала

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

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

Ключевым преимуществом использования групп доступности AlwaysOn с источниками данных служб 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 и поддерживают группы доступности AlwaysOn строка подключения свойства для использования с источниками данных.

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

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

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

Дополнительные сведения о необходимом исправлении см. в разделе Исправление КБ 2654347A добавляет поддержку функций AlwaysOn из SQL Server 2012 в платформу .NET Framework 3.5 с пакетом обновления 1 (SP1).

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

Примечание.

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

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

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

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

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

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

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

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

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

Кнопка "Проверить подключение" в пользовательских интерфейсах служб Reporting Services проверяет, можно ли установить подключение, но не будет проверять конфигурацию группы доступности. Например, если вы включаете 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 и поддерживают группы доступности AlwaysOn строка подключения свойства.

  • Предварительная версия удаленного или серверного режима. Если после публикации отчетов на сервере отчетов или с помощью предварительной версии в построитель отчетов вы увидите ошибку, аналогичную приведенной ниже, это означает, что вы просматриваете отчеты на сервере отчетов, а исправление платформа .NET Framework 3.5 с пакетом обновления 1 (SP1) для групп доступности AlwaysOn не установлено на сервере отчетов.

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

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

Службы Reporting Services и сервер отчетов Power BI имеют ограниченную поддержку использования групп доступности Always On с базами данных сервера отчетов. Базы данных сервера отчетов можно настроить в группе доступности, чтобы быть частью реплики; Однако службы 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 базы данных. Ниже приведены примеры имен баз данных, для сервера отчетов в собственном режиме работы:

  • ReportServer

  • ReportServerTempDB

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  5. Проверьте возможность выполнения отчетов в новой первичной реплике.

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

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

  • Фоновая обработка может выполняться несколько раз из-за логики повтора и неспособности сервера отчетов пометить запланированную работу как выполненную во время отработки отказа.

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

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

См. также