Reporting Services com grupos de disponibilidade AlwaysOn (SQL Server)

Este tópico contém informações sobre como configurar Reporting Services para trabalhar com grupos de disponibilidade Always On (AG) no SQL Server 2014. Os três cenários para usar Reporting Services e grupos de disponibilidade 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.

Um dos principais benefícios de usar Always On Grupos de Disponibilidade com fontes de dados Reporting Services é aproveitar réplicas secundárias legíveis como uma fonte de dados de relatório e, 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 Always On Grupos de Disponibilidade, consulte Perguntas frequentes do AlwaysOn para SQL Server 2012 (https://msdn.microsoft.com/sqlserver/gg508768).

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

Para usar Always On Grupos de Disponibilidade com SQL Server 2014 Reporting Services, você precisa baixar e instalar 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 Always On Grupos de Disponibilidade na cadeia de conexão 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, consulte o hotfix na base de dados de conhecimento 2654347A que introduz suporte para os recursos AlwaysOn do SQL Server 2012 para o .NET Framework 3.5 SP1.

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

Fontes de dados de relatório e grupos de disponibilidade

O comportamento de Reporting Services fontes de dados com base em Always On Grupos de Disponibilidade pode variar dependendo de como o administrador configurou o ambiente do AG.

Para utilizar Always On Grupos de Disponibilidade para fontes de dados de relatório, você precisa 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 reduzirá 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 = AdventureWorks2008R2; ApplicationIntent=ReadOnly

O botão Testar Conexão em interfaces de usuário do Reporting Services validará se uma conexão puder ser estabelecida, mas não validará 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 Gerenciador de Relatórios 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: SQL Server Report Builder para SQL Server 2012 ou SQL Server Data Tools (SSDT) ao criar novos relatórios. Confira a seção 'Design de relatórios' neste tópico ou em mais informações.

Recursos adicionais:

• Gerenciar fontes de dados de relatório

• Para obter mais informações sobre as propriedades da cadeia de conexão disponíveis, consulte Using Connection String Keywords with SQL Server Native Client.

• Para obter mais informações sobre ouvintes do grupo de disponibilidade, veja Criar ou configurar um ouvinte do grupo de disponibilidade (SQL Server).

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, consulte a seção "Modos de Disponibilidade" de Visão geral dos grupos de disponibilidade AlwaysOn (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 no SQL Server Report Builder para SQL Server 2012 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.

• Versão prévia local: SQL Server Report Builder para SQL Server 2012 e SQL Server Data Tools (SSDT) usam o .Net Framework 4.0 e dão suporte a propriedades de cadeia de conexão dos Grupos de Disponibilidade do Always On.

• Versão prévia do modo remoto ou de servidor: Se depois de publicar relatórios no servidor de relatório ou usar a visualização no SQL Server Report Builder para SQL Server 2012, você verá um erro semelhante ao seguinte, é uma indicação de que você está visualizando relatórios no servidor de relatório e no Hotfix do .Net Framework 3.5 SP1 para Always On Os Grupos de Disponibilidade não foram instalados 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

Reporting Services oferece suporte limitado para usar Always On Grupos de Disponibilidade 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 failover ocorrer.

Ações manuais ou scripts de automação personalizados precisam ser usados para concluir o failover e a recuperação. Até que essas ações sejam concluídas, alguns recursos do servidor de relatório podem não funcionar corretamente após o failover dos Grupos de Disponibilidade do Always On.

Diferenças entre o modo nativo do SharePoint

Esta seção resume as diferenças entre como o modo do SharePoint e os servidores de relatório do modo nativo interagem com Always On Grupos de Disponibilidade.

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 do aplicativo de serviço como o nome do "ponto de acesso do cliente" que você criou como parte da configuração do SharePoint. Para obter mais informações sobre como configurar o SharePoint com grupos de disponibilidade Always On, consulte Configurar e gerenciar SQL Server grupos de disponibilidade para o SharePoint Server (https://go.microsoft.com/fwlink/?LinkId=245165).

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

Estas são as etapas básicas de preparação e adição dos bancos de dados do servidor de relatório a um Always On Grupos de Disponibilidade:

• 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, consulte Iniciar movimentação de dados em um banco de dados secundário AlwaysOn (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 após um failover dos Grupos de Disponibilidade do Always On para um réplica secundário:

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 desses problemas variará dependendo da carga de Reporting Services no momento do failover, bem como do tempo necessário para que Always On Grupos de Disponibilidade façam failover para um réplica secundário e para que o administrador do servidor de relatório atualize o ambiente de relatório para usar o novo réplica primário.

• 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 tiver sido concluído e depois que o serviço de servidor de relatório tiver sido reiniciado, os trabalhos do SQL Server Agent serão recriados automaticamente. Até que os trabalhos do SQL Agent tiverem sido recriados, não será processada nenhuma execução em segundo plano associada aos trabalhos do SQL Server Agent. Isto inclui assinaturas do Reporting Services, agendas e instantâneos.

Consulte Também

SQL Server Native Client suporte para grupos de disponibilidade AlwaysOn de alta disponibilidade e recuperação de desastre (SQL Server)Introdução com grupos de disponibilidade AlwaysOn (SQL Server)usando palavras-chave de cadeia de conexão com SQL Server Native ClientSQL Server Native Client suporte para alta disponibilidade, recuperação de desastresobre o acesso de conexão do cliente a réplicas de disponibilidade (SQL Server)