Reporting Services com grupos de disponibilidade AlwaysOn (SQL Server)

  • Artigo

Aplica-se a:SQL Server

Este artigo contém informações sobre como configurar o Reporting Services para funcionar com grupos de disponibilidade AlwaysOn (AG) no SQL Server. Os três cenários para usar os grupos de disponibilidade Reporting Services e Always On são bancos de dados para fontes de dados de relatório, bancos de dados do servidor de relatório e design de relatório. A funcionalidade com suporte e a configuração exigida é diferente para os três cenários.

O principal benefício de usar grupos de disponibilidade AlwaysOn com fontes de dados do Reporting Services é utilizar réplicas secundárias legíveis como uma fonte de dados de relatório enquanto, ao mesmo tempo, as réplicas secundárias estão fornecendo um failover para um banco de dados primário.

Para obter informações gerais sobre o grupos de disponibilidade AlwaysOn, confira Perguntas frequentes sobre o Always On do SQL Server 2012 (../../../sql-server/index.yml).

Requisitos para usar o Reporting Services e os grupos de disponibilidade AlwaysOn

O SQL Server Reporting Services e o Servidor de Relatórios do Power BI usa o .NET Framework 4.0 e são compatíveis com as propriedades de cadeia de conexão dos grupos de disponibilidade AlwaysOn para uso com fontes de dados.

Para usar os grupos de disponibilidade AlwaysOn com Reporting Services 2014, e anteriores, você precisará baixar e instalar a correção um hotfix para o .NET 3.5 SP1. O hotfix adiciona suporte a Cliente SQL para os recursos do AG e suporte das propriedades da cadeia de conexão ApplicationIntent e MultiSubnetFailover. Se o hotfix não estiver instalado em cada computador que hospeda um servidor de relatório, os usuários que tentarem visualizar relatórios verão uma mensagem de erro semelhante à seguinte, e a mensagem de erro será gravada no log de rastreamento do servidor de relatório:

Mensagem de erro: “Não há suporte para a palavra-chave 'applicationintent'"

A mensagem ocorre quando você inclui uma das propriedades dos grupos de disponibilidade AlwaysOn na cadeia de conexão do Reporting Services, mas o servidor não reconhece a propriedade. A mensagem de erro destacada será vista quando você clicar no botão “Testar Conexão” nas interfaces de usuário do Reporting Services e quando você visualizar o relatório se os erros remotos estiverem habilitados nos servidores de relatórios.

Para obter mais informações sobre o hotfix necessário, veja o hotfix da KB 2654347A introduz suporte para os recursos AlwaysOn do SQL Server 2012 no .NET Framework 3.5 SP1.

Para obter informações sobre outros requisitos dos grupos de disponibilidade AlwaysOn, consulte Pré-requisitos, restrições e recomendações para grupos de disponibilidade AlwaysOn (SQL Server).

Observação

Não há suporte para arquivos de configuração do Reporting Services como RSreportserver.config, como parte da funcionalidade dos grupos de disponibilidade AlwaysOn. Se você fizer alterações manualmente em um arquivo de configuração em um dos servidores de relatórios, precisará atualizar as réplicas manualmente.

Fontes de dados de relatório e grupos de disponibilidade

O comportamento de fontes de dados do Reporting Services com base nos grupos de disponibilidade AlwaysOn pode variar, dependendo de como o administrador configurou o ambiente do AG.

Para utilizar os grupos de disponibilidade AlwaysOn para fontes de dados de relatório, você precisará configurar a cadeia de conexão da fonte de dados de relatório para usar o Nome DNS do Ouvinte do grupo de disponibilidade. As fontes de dados com suporte são as seguintes:

  • Fontes de dados ODBC usando SQL Native Client.

  • SQL Client, com o hotfix .NET aplicado ao servidor de relatório.

A cadeia de conexão também pode conter novas propriedades de conexão AlwaysOn que configuram as solicitações de consulta de relatório para usar a réplica secundária para relatório somente leitura. O uso de réplica secundária para solicitações de relatório reduz a carga em uma réplica primária de leitura/gravação. A ilustração a seguir é um exemplo de uma configuração de três réplicas de AG onde as cadeias de conexão da fonte de dados do Reporting Services foram configuradas com ApplicationIntent=ReadOnly. Neste exemplo, as solicitações de consulta de relatório são enviadas para uma réplica secundária e não para a réplica primária.

Veja a seguir uma cadeia de conexão de exemplo, em que o [AvailabilityGroupListenerName] é o Nome DNS do Ouvinte que foi configurado quando as réplicas foram criadas:

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

O botão Testar Conexão em interfaces de usuário do Reporting Services valida se uma conexão pode ser estabelecida, mas não valida a configuração do AG. Por exemplo, se você incluir ApplicationIntent em uma cadeia de conexão para um servidor que não faça parte do AG, o parâmetro adicional será ignorado e o botão Testar Conexão somente validará uma conexão que puder ser estabelecida com o servidor especificado.

Dependendo de como seus relatórios são criados e publicados, isso determinará onde você editará a cadeia de conexão:

  • Modo nativo: use o portal da Web para fontes de dados compartilhadas e relatórios que já estão publicados em um servidor de relatório de modo nativo.

  • Modo do SharePoint: use as páginas de configuração do SharePoint dentro das bibliotecas de documentos para relatórios que já estão publicados em um servidor do SharePoint.

  • Design de relatório: --- título: incluir descrição do arquivo: incluir autor do arquivo: maggiesMSFT ms.author: maggies ms.date: 12/06/2018 ms.service: ms.topic: incluir ms.custom: incluir construtor fileReport ou SSDT (SQL Server Data Tools) ao criar novos relatórios. Confira a seção “Design de relatórios” neste artigo ou em mais informações.

Recursos adicionais:

Considerações: as réplicas secundárias normalmente experimentarão um atraso ao receber alterações de dados da réplica primária. Os fatores a seguir podem afetar a latência da atualização entre as réplicas primárias e secundárias:

  • O número de réplicas secundárias. O atraso aumenta com cada réplica secundária adicionada à configuração.

  • A localização geográfica e a distância entre as réplicas primárias e secundárias. Por exemplo, o atraso será geralmente maior se as réplicas secundárias estiverem em um data center diferente do que se estivessem no mesmo prédio que a réplica primária.

  • Configuração do modo de disponibilidade para cada réplica. O modo de disponibilidade determina se a réplica primária espera para confirmar transações em um banco de dados até que uma réplica secundária tenha gravado a transação em disco. Para obter mais informações, confira a seção "Modos de disponibilidade" de Visão geral dos grupos de disponibilidade Always On (SQL Server).

Ao usar uma réplica secundária somente leitura como uma fonte de dados do Reporting Services, é importante verificar se a latência de atualização de dados atende as necessidades dos usuários de relatório.

Design de relatório e grupos de disponibilidade

Ao criar relatórios em --- título: incluir descrição do arquivo: incluir autor do arquivo: maggiesMSFT ms.author: maggies ms.date: 12/06/2018 ms.service: ms.topic: incluir ms.custom: incluir construtor fileReport ou um projeto de relatório no SSDT (SQL Server Data Tools), um usuário pode configurar uma cadeia de conexão de fonte de dados de relatório para conter novas propriedades de conexão fornecidas por grupos de disponibilidade Always On. O suporte para as novas propriedades de conexão depende de onde o usuário visualiza o relatório.

  • Visualização local: --- título: incluir descrição do arquivo: incluir autor do arquivo: maggiesMSFT ms.author: maggies ms.date: 12/06/2018 ms.service: ms.topic: incluir ms.custom: incluir construtor fileReport e SQL Server Data Tools (SSDT) usam o .NET framework 4.0 e oferecem suporte a propriedades de cadeia de conexão de grupos de disponibilidade Always On.

  • Visualização remota ou do modo de servidor: se depois de publicar relatórios no servidor de relatório ou usar a visualização no título: --- incluir descrição do arquivo: incluir autor do arquivo: maggiesMSFT ms.author: maggies ms.date: 12/06/2018 ms.service: ms.topic: incluir ms.custom: incluir fileReport Builder, um erro semelhante ao seguinte for exibido, significa que você está visualizando relatórios no servidor de relatório e que o .NET Framework 3.5 SP1 Hotfix para grupos de disponibilidade Always On não foi instalado no servidor de relatório.

Mensagem de erro: “Não há suporte para a palavra-chave 'applicationintent'"

Bancos de dados do servidor de relatório e grupos de disponibilidade

O Reporting Services e o Servidor de Relatórios do Power BI oferece suporte limitado para usar os grupos de disponibilidade AlwaysOn com bancos de dados do servidor de relatório. Os bancos de dados do servidor de relatórios podem ser configurados no AG para fazer parte de uma réplica; porém, o Reporting Services não usará automaticamente uma réplica diferente para os bancos de dados do servidor de relatório quando um ocorrer um failover. Não há suporte para o uso de MultiSubnetFailover com os bancos de dados do servidor de relatório.

Ações manuais ou scripts de automação personalizados precisam ser usados para concluir o failover e a recuperação. Até que estas ações sejam concluídas, alguns recursos do servidor de relatório poderão não funcionar corretamente depois do failover dos grupos de disponibilidade AlwaysOn.

Observação

Ao planejar failover e recuperação de desastres para os bancos de dados do servidor de relatório, é sempre recomendável fazer backup de uma cópia da chave de criptografia do servidor de relatório.

Diferenças entre o modo nativo do SharePoint

Esta seção resume as diferenças entre o modo com o SharePoint e os servidores de relatórios de modo nativo interagem com os grupos de disponibilidade AlwaysOn.

Um servidor de relatório do SharePoint cria 3 bancos de dados para cada aplicativo de serviço do Reporting Services criado. A conexão para bancos de dados do servidor de relatório no modo do SharePoint é configurada na Administração Central do SharePoint quando você cria o aplicativo de serviço. Os nomes padrão dos bancos de dados incluem um GUID que está associado com o aplicativo de serviço. A seguir são apresentados nomes de bancos de dados de exemplo para o servidor de relatório do modo do SharePoint:

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6TempDB

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6_Alerting

Os servidores de relatórios de modo nativo usam 2 bancos de dados. A seguir são apresentados nomes de bancos de dados de exemplo para o servidor de relatório do modo nativo:

  • ReportServer

  • ReportServerTempDB

O modo nativo não dá suporte nem usa os bancos de dados de alertas e recursos relacionados. Configure os servidores de relatório de modo nativo no Gerenciador de Configurações do Reporting Services. Para o modo do SharePoint, configure o nome do banco de dados de aplicativo de serviço para ser o nome do "ponto de acesso para cliente" que você criou como parte da configuração do SharePoint. Para obter mais informações sobre como configurar o SharePoint com os grupos de disponibilidade Always On, consulte Configurar e gerenciar grupos de disponibilidade do SQL Server para SharePoint Server (/previous-versions/office/sharepoint-server-2010/hh913923(v=office.14)).

Observação

Os servidores de relatórios do modo do SharePoint usam um processo de sincronização entre os bancos de dados de aplicativo de serviço do Reporting Services e os bancos de dados de conteúdo do SharePoint. É importante manter os bancos de dados do servidor de relatório e os bancos de dados de conteúdo juntos. Configure-os nos mesmos grupos de disponibilidade para que eles realizem failover e recuperação como um conjunto. Considere o cenário a seguir.

  • Você restaura ou realiza failover para uma cópia do banco de dados de conteúdo que não tenha recebido as mesmas atualizações recentes que o banco de dados do servidor de relatório recebeu.
  • O processo de sincronização do Reporting Services detectará diferenças entre a lista de itens no banco de dados de conteúdo e os bancos de dados do servidor de relatório.
  • O processo de sincronização excluirá ou atualizará itens no banco de dados de conteúdo.

Preparar os bancos de dados do servidor de relatório para grupos de disponibilidade

Veja a seguir as etapas básicas de preparar e adicionar os bancos de dados do servidor de relatório para um grupo de disponibilidade Always On:

  • Crie seu Grupo de disponibilidade e configure um Nome DNS do Ouvinte.

  • Réplica primária: configure os bancos de dados do servidor de relatório para fazerem parte de um único grupo de disponibilidade e para criarem uma réplica primária que inclui todos os bancos de dados do servidor de relatório.

  • Réplicas secundárias: crie uma ou mais réplicas secundárias. A abordagem comum para copiar os bancos de dados da réplica primária para a réplica secundária é restaurar os bancos de dados para cada réplica secundária usando 'RESTORE WITH NORECOVERY'. Para obter mais informações sobre como criar réplicas secundárias e verificar se a sincronização de dados está funcionando, veja Iniciar movimentação de dados em um banco de dados secundário (SQL Server).

  • Credenciais do servidor de relatório: você precisa criar as credenciais de servidor de relatório apropriadas nas réplicas secundárias, tal qual você criou na réplica primária. As etapas exatas dependem de que tipo de autenticação você está usando em seu ambiente do Reporting Services; conta de serviço do Windows Reporting Services, conta de usuário do Windows ou autenticação do SQL Server. Para saber mais, confira Configurar uma conexão de banco de dados do servidor de relatório (Configuration Manager do SSRS)

  • Atualize a conexão de banco de dados para usar o Nome DNS do Ouvinte. para os servidores de relatórios do modo de nativo, altere o Nome do Banco de Dados do Servidor de Relatório no gerenciador de configuração do Reporting Services. Para o modo do SharePoint, altere o Nome do servidor de banco de dados para o aplicativo de serviço do Reporting Services.

Etapas para concluir a recuperação de bancos de dados do servidor de relatório

As etapas a seguir precisam ser concluídas depois de um failover dos grupos de disponibilidade AlwaysOn para uma réplica secundária:

  1. Pare a instância do serviço SQL Agent que estava sendo usado pelo mecanismo de banco de dados primário que hospeda os bancos de dados do Reporting Services.

  2. Inicie o serviço SQL Agent no computador que é a nova réplica primária.

  3. Pare o serviço do servidor de relatório.

    Se o servidor de relatório estiver em modo nativo, pare o servidor de relatório do servidor do Windows usando o gerenciador de configuração do Reporting Services.

    Se o servidor de relatório estiver configurado para o modo do SharePoint, pare o serviço compartilhado do Reporting Services na Administração Central do SharePoint.

  4. Inicie o serviço do servidor de relatório ou serviço do SharePoint do Reporting Services.

  5. Verifique se os relatórios podem ser executar na nova réplica primária.

Comportamento do servidor de relatório quando ocorre um failover

Quando ocorre o failover de bancos de dados do servidor de relatório e você atualizou o ambiente do servidor de relatório para usar a nova réplica primária, há alguns problemas operacionais que resultam do failover e do processo de recuperação. O impacto desss problemas varia, dependendo da carga do Reporting Services na hora de failover e também do período de tempo que leva para os grupos de disponibilidade AlwaysOn fazerem failover para uma réplica secundária e para o administrador do servidor de relatório atualizar o ambiente de relatório para usar a nova réplica primária.

  • A execução do processamento em segundo plano pode ocorrer mais de uma vez devido à lógica de repetição e a incapacidade de o servidor de relatório marcar trabalho agendado como concluído durante o período de failover.

  • A execução do processamento em segundo plano que normalmente deveria ter sido disparado para ser executado durante o período do failover não ocorrerá porque o SQL Server Agent não poderá gravar dados no banco de dados do servidor de relatório e estes dados não serão sincronizados na nova réplica primária.

  • Depois que o failover de banco de dados for concluído e depois que o serviço de servidor de relatório for reiniciado, os trabalhos do SQL Server Agent serão recriados automaticamente. Até que os trabalhos do SQL Agent sejam recriados, não será processada nenhuma execução em segundo plano associada aos trabalhos do SQL Server Agent. Isso inclui assinaturas do Reporting Services, agendas e instantâneos.

Confira também