Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этом разделе содержатся сведения о настройке Reporting Services для работы с группами доступности Always On в SQL Server 2014 г. Три сценария использования групп доступности Reporting Services и Always On — это базы данных для источников данных отчетов, базы данных сервера отчетов и структуры отчетов. Поддерживаемые функции и необходимая конфигурация для разных вариантов использования будут различными.
Ключевым преимуществом использования Always On групп доступности с Reporting Services источниками данных является использование доступных для чтения вторичных реплик в качестве источника данных отчетов, в то время как в то же время вторичные реплики обеспечивают отработку отказа для базы данных-источника.
Общие сведения о группах доступности Always On см. в разделе Вопросы и ответы по AlwaysOn для SQL Server 2012 (https://msdn.microsoft.com/sqlserver/gg508768).
Требования, которые необходимо выполнить для использования служб Reporting Services и групп доступности AlwaysOn
Чтобы использовать группы доступности Always On с Reporting Services SQL Server 2014, необходимо скачать и установить исправление для .NET 3.5 с пакетом обновления 1 (SP1). Это исправление добавляет в клиент SQL Server поддержку компонентов групп доступности, а также поддержку свойств строки подключения ApplicationIntent и MultiSubnetFailover. Если не установить это исправление на все компьютеры, на которых размещен сервер отчетов, то пользователи, пытающиеся просмотреть отчеты, будут видеть сообщение об ошибке примерно следующего содержания, которое также будет записываться в журнал трассировки сервера отчетов.
Сообщение об ошибке: "Ключевое слово "applicationintent" не поддерживается"
Сообщение появляется при включении одного из свойств групп доступности Always On в строку подключения Reporting Services, но сервер не распознает это свойство. Указанное сообщение об ошибке отображается при нажатии кнопки "Проверить подключение" в пользовательском интерфейсе служб Reporting Services, а также при просмотре отчета, если на сервере отчета включено отслеживание удаленных ошибок.
Дополнительные сведения о необходимом исправлении см. в разделе Исправление КБ 2654347A добавляет поддержку функций AlwaysOn из SQL Server 2012 в платформу .NET Framework 3.5 с пакетом обновления 1 (SP1).
Сведения о других требованиях Always On групп доступности см. в разделе Предварительные требования, ограничения и рекомендации для групп доступности AlwaysOn (SQL Server).
Примечание
Reporting Services файлы конфигурации, такие как RSreportserver.config, не поддерживаются в составе функций групп доступности Always On. Если изменения в файл конфигурации на одном из серверов отчетов вносятся вручную, то необходимо будет вручную обновить реплики.
Источники данных отчетов и группы доступности
Поведение Reporting Services источников данных на основе Always On групп доступности может отличаться в зависимости от того, как администратор настроил среду группы доступности.
Чтобы использовать Always On группы доступности для источников данных отчета, необходимо настроить строку подключения к источнику данных отчета, чтобы использовать DNS-имя прослушивателя группы доступности. Поддерживаются следующие источники данных.
Источник данных ODBC, использующий SQL Native Client.
Клиент SQL Server, если на сервере отчетов применено исправление .Net.
Строка соединения также может содержать новые свойства соединения AlwaysOn, которые настраивают запросы отчетов на использование вторичной реплики для доступных только для чтения отчетов. Использование вторичной реплики для запросов отчетов позволяет снизить нагрузку на доступную для чтения и записи первичную реплику. На следующем рисунке приведен пример настройки группы доступности из трех реплик, где строки подключения источников данных служб Reporting Services имеют параметр ApplicationIntent=ReadOnly. В этом примере запросы отчетов отправляются вторичной, а не первичной реплике.
Ниже приведен пример строки подключения, где [AvailabilityGroupListenerName] ― это DNS-имя прослушивателя , заданное при создании реплик.
Data Source=[AvailabilityGroupListenerName];Initial Catalog = AdventureWorks2008R2; ApplicationIntent=ReadOnly
При нажатии кнопки Проверить подключение в пользовательском интерфейсе служб Reporting Services будет проверена возможность подключения, при этом конфигурация группы доступности проверяться не будет. Если параметр ApplicationIntent включить в строку подключения к серверу, который не входит в группу доступности, то этот дополнительный параметр не будет использован, а при нажатии кнопки Проверка соединения будет просто проверена возможность установления соединения с указанным сервером.
Место изменения строки подключения будет зависеть от способа создания и публикации отчетов.
Собственный режим. Для общих источников данных и отчетов, которые уже опубликованы на сервере отчетов, работающем в собственном режиме, пользуйтесь диспетчером отчетов.
Режим интеграции с SharePoint. Для отчетов, которые уже опубликованы на сервере SharePoint, пользуйтесь страницами конфигурации SharePoint в библиотеках документов.
Проектирование отчетов: SQL Server Report Builder для SQL Server 2012 или SQL Server Data Tools (SSDT) при создании новых отчетов. Дополнительные сведения приведены в разделе "Конструирование отчетов" этой главы.
Дополнительные ресурсы
Дополнительные сведения об имеющихся свойствах строки подключения см. в разделе Using Connection String Keywords with SQL Server Native Client.
Дополнительные сведения о прослушивателях групп доступности см. в статье Создание или настройка прослушивателя группы доступности (SQL Server).
Рекомендации Обычно при получении вторичными репликами изменений данных от первичной реплики происходит задержка. На задержку обновления между первичной и вторичными репликами влияют следующие факторы.
Число вторичных реплик. При добавлении в конфигурацию новых вторичных реплик задержка увеличивается.
Географическое местоположение и расстояние между первичной и вторичными репликами. Например, задержка будет больше, если вторичные реплики находятся в другом центре обработки данных, чем в ситуации, когда они расположены в том же здании, что и первичная реплика.
Настройка режима доступности для каждой реплики. Режим доступности определяет, ожидает ли первичная реплика перед фиксацией транзакций для базы данных, чтобы вторичная реплика сохранила записи журнала транзакций на диск. Дополнительные сведения см. в разделе "Режимы доступности" статьи Общие сведения о группах доступности AlwaysOn (SQL Server)..
При использовании доступной только для чтения вторичной реплики в качестве источника данных служб Reporting Services важно обеспечить соответствие задержки обновления данных потребностям пользователей отчетов.
Конструирование отчетов и группы доступности
При проектировании отчетов в SQL Server Report Builder для SQL Server 2012 или проекта отчета в SQL Server Data Tools (SSDT) пользователь может настроить строку подключения к источнику данных отчета, содержащую новые свойства подключения, предоставляемые группами доступности Always On. Поддержка новых свойств соединения зависит от того, где пользователь просматривает отчеты.
Локальная предварительная версия: SQL Server Report Builder для SQL Server 2012 и SQL Server Data Tools (SSDT) используют .NET Framework 4.0 и поддерживают свойства строки подключения групп доступности Always On.
Предварительная версия удаленного или серверного режима. Если после публикации отчетов на сервере отчетов или использования предварительной версии в SQL Server Report Builder для SQL Server 2012 вы увидите сообщение об ошибке, аналогичное приведенному ниже. Это означает, что вы просматриваете отчеты на сервере отчетов и исправление .NET Framework 3.5 с пакетом обновления 1 (SP1) для Always On Группы доступности не установлены на сервере отчетов.
Сообщение об ошибке: "Ключевое слово "applicationintent" не поддерживается"
Базы данных сервера отчетов и группы доступности
Reporting Services предоставляет ограниченную поддержку использования групп доступности Always On с базами данных сервера отчетов. В группе доступности базы данных сервера отчетов можно настроить так, чтобы они были частью реплики. Но при отработке отказа службы Reporting Services не будут автоматически использовать другую реплику баз данных сервера отчетов.
Чтобы выполнить отработку отказа или восстановление, необходимо произвести определенные действия вручную или воспользоваться пользовательскими скриптами автоматизации. До завершения этих действий некоторые функции сервера отчетов могут работать неправильно после отработки отказа Always On групп доступности.
Примечание
При планировании отработки отказа и аварийного восстановления для баз данных сервера отчетов рекомендуется всегда создавать резервную копию ключа шифрования сервера отчетов.
Различия с собственным режимом SharePoint
В этом разделе перечислены различия между взаимодействием серверов отчетов в режиме SharePoint и собственном режиме с Always On группами доступности.
Сервер отчетов, работающий в режиме интеграции с SharePoint, создает 3 базы данных для каждого создаваемого вами приложения служб Reporting Services. Соединение с базой данных сервера отчетов, работающей в режиме интеграции с SharePoint, настраивается в центре администрирования SharePoint при создании нового приложения службы SharePoint. Имена баз данных по умолчанию включают идентификатор GUID, связанный с приложением службы. Ниже приведены примеры имен баз данных, для сервера отчетов в режиме интеграции с SharePoint:
ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6
ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6TempDB
ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6_Alerting
Сервера отчетов, работающие в собственном режиме, используют 2 базы данных. Ниже приведены примеры имен баз данных, для сервера отчетов в собственном режиме работы:
ReportServer
ReportServerTempDB
В этом режиме базы данных Alerting и связанные компоненты не поддерживаются и не используются. Серверы отчетов, работающие в собственном режиме, настраиваются в диспетчере конфигурации служб Reporting Services. В режиме SharePoint имя базы данных приложения службы должно быть именем "точки доступа клиента", созданной в рамках конфигурации SharePoint. Дополнительные сведения о настройке SharePoint с помощью Always On групп доступности см. в статье Настройка групп доступности SQL Server для SharePoint Server и управление ими (https://go.microsoft.com/fwlink/?LinkId=245165).
Примечание
Серверы отчетов, работающие в режиме интеграции с SharePoint, используют процесс синхронизации между базами данных приложения служб Reporting Services и базами данных содержимого SharePoint. Важно поддерживать работу баз данных сервера отчетов и баз данных содержимого вместе. Следует рассмотреть возможность включения этих баз данных в одну группу доступности, чтобы отработка отказа и восстановление для них выполнялось одновременно. Рассмотрим следующий сценарий.
- Выполняется восстановление или отработка отказа копии базы данных содержимого, которая не получила такие же обновления данных, какие получила база данных сервера отчетов.
- Процесс синхронизации служб Reporting Services обнаружит различия между списками элементов из базы данных содержимого и из баз данных сервера отчетов.
- Процесс синхронизации удалит или обновит элементы в базе данных содержимого.
Подготовка баз данных сервера отчетов для групп доступности
Ниже приведены основные шаги по подготовке и добавлению баз данных сервера отчетов в группу доступности Always On.
Создайте группу доступности и задайте DNS-имя прослушивателя.
Первичная реплика. Включите базы данных сервера отчетов в одну группу доступности и создайте первичную реплику, в которой будут представлены все базы данных сервера отчетов.
Вторичные реплики. Создайте одну или несколько вторичных реплик. Стандартным вариантом копирования баз данных из первичной реплики во вторичные реплики является восстановление баз данных на вторичной реплике с помощью инструкции RESTORE WITH NORECOVERY. Дополнительные сведения о создании вторичных реплик и проверке работоспособности синхронизации данных см. в статье Начало перемещения данных в базе данных-получателе AlwaysOn (SQL Server).
Учетные данные сервера отчетов. Во вторичных репликах, созданных из первичной, необходимо создать соответствующие учетные данные сервера отчетов. Действия, которые для этого нужно предпринять, зависят от типа проверки подлинности, используемой в среде служб Reporting Services: учетная запись службы Window Reporting Services, учетная запись пользователя Windows или проверка подлинности SQL Server. Дополнительные сведения см. в статье Настройка подключения к базе данных сервера отчетов (диспетчер конфигурации сервера отчетов).
Обновите подключение к базе данных, указав в нем DNS-имя прослушивателя. В отношении серверов отчетов, работающих в собственном режиме, измените параметр Имя базы данных сервера отчетов в диспетчере конфигурации служб Reporting Services. В режиме интеграции с SharePoint измените Имя сервера базы данных для приложений служб Reporting Services.
Действия по выполнению аварийного восстановления баз данных сервера отчетов
После отработки отказа групп доступности Always On на дополнительный реплика необходимо выполнить следующие действия.
Остановите экземпляр службы агента SQL Server, который использовался СУБД базы данных-источника, где размещены базы данных служб Reporting Services.
Запустите службу агента SQL Server на компьютере, который стал новой первичной репликой.
Остановите службу сервера отчетов.
Если сервер отчетов работает в собственном режиме, остановите сервер Windows сервера отчетов с помощью диспетчера конфигурации служб Reporting Services.
Если же сервер отчетов настроен в режиме интеграции с SharePoint, остановите общую службу Reporting Services в центре администрирования SharePoint.
Запустите службу сервера отчетов или службу SharePoint для Reporting Services.
Проверьте возможность выполнения отчетов в новой первичной реплике.
Работа сервера отчетов при выполнении отработки отказа
Когда выполняется отработка отказа для баз данных сервера отчетов и была обновлена среда сервера отчетов, в которой теперь будет новая первичная реплика, возникают некоторые проблемы, которые являются следствием отработки отказа или восстановления. Влияние этих проблем будет зависеть от загрузки Reporting Services во время отработки отказа, а также от времени, необходимого для перехода Always On групп доступности на дополнительный реплика а администратор сервера отчетов — на обновление среды отчетов для использования новой основной реплика.
Фоновая обработка может выполняться несколько раз из-за логики повтора и неспособности сервера отчетов пометить запланированную работу как выполненную во время отработки отказа.
Фоновая обработка, которая обычно запускается во время отработки отказа, не запускается, поскольку агент SQL Server не способен записывать данные в базе данных сервера отчетов, и эти данные не будут синхронизированы с новой первичной репликой.
После завершения отработки отказа базы данных и перезапуска службы сервера отчетов задания агента SQL Server будут автоматически созданы повторно. Пока задания агента SQL не будут воссозданы, любая фоновая обработка, связанная с заданиями агента SQL Server, выполняться не будет. К ним относятся подписки, расписания и моментальные снимки служб Reporting Services.
См. также:
SQL Server Native Client поддержка высокого уровня доступности, аварийного восстановлениягрупп доступности AlwaysOn (SQL Server)начало работы с группами доступности AlwaysOn (SQL Server)Использование ключевых слов строки подключения с SQL Server Native ClientSQL Server Native Client Поддержка высокого уровня доступности, аварийное восстановлениеО доступе к репликам доступности с подключением клиента (SQL Server)