Reporting Services con Grupos de disponibilidad AlwaysOn (SQL Server)

  • Artículo

Se aplica a:SQL Server

Este artículo contiene información acerca de la configuración de Rerporting Services para que funcione con Grupos de disponibilidad Always On en SQL Server. Los tres escenarios para usar Reporting Services y Grupos de disponibilidad Always On son bases de datos para orígenes de datos de informes, bases de datos del servidor de informes y diseño de informes. La funcionalidad admitida y la configuración requerida son diferentes para los tres escenarios.

Una ventaja fundamental del uso de Grupos de disponibilidad Always On con orígenes de datos de Reporting Services es usar las réplicas secundarias legibles como un origen de datos de informes, al mismo tiempo que las réplicas secundarias proporcionan conmutación por error para una base de datos principal.

Para obtener información general sobre los Grupos de disponibilidad Always On, consulte las preguntas más frecuentes sobre Always On para SQL Server 2012 (../../../sql-server/index.yml).

Requisitos para usar Reporting Services y Grupos de disponibilidad AlwaysOn

SQL Server Reporting Services y Power BI Report Server usan .NET Framework 4.0 y admiten propiedades de cadena de conexión de grupos de disponibilidad Always On para su uso con orígenes de datos.

Para usar Grupos de disponibilidad Always On con Reporting Services 2014 y versiones anteriores, debe descargar e instalar una revisión para .NET 3.5 SP1. La revisión agrega compatibilidad con las características de SQL Client para AG y con las propiedades de cadenas de conexión ApplicationIntent y MultiSubnetFailover. Si la revisión no se instala en cada equipo que hospeda un servidor de informes, los usuarios que intenten obtener la vista previa de los informes verán un mensaje de error similar al siguiente y el mensaje de error se escribirá en el registro de seguimiento del servidor de informes:

Mensaje de error: "La palabra clave no admite "applicationintent""

El mensaje tiene lugar cuando incluye una de las propiedades de grupos de disponibilidad Always On en la cadena de conexión de Reporting Services, pero el servidor no reconoce la propiedad. El mensaje de error indicado se ve cuando seleccione el botón "Probar conexión" en las interfaces de usuario de Reporting Services y cuando vea una vista previa del informe si los errores remotos están habilitados en los servidores de informes.

Para obtener más información sobre la revisión necesaria, vea el artículo de KB 2654347A sobre una revisión que incorpora compatibilidad con las características de AlwaysOn de SQL Server 2012 en .NET Framework 3.5 SP1.

Para obtener información sobre la compatibilidad con Grupos de disponibilidad Always On, consulte Requisitos previos, restricciones y recomendaciones para grupos de disponibilidad Always On.

Nota

Los archivos de configuración de Reporting Services, como RSreportserver.config no se admiten como parte de la funcionalidad de Grupos de disponibilidad Always On. Si tiene que realizar cambios manualmente en un archivo de configuración de uno de los servidores de informes, tendrá que actualizar manualmente las réplicas.

Orígenes de datos de informes y grupos de disponibilidad

El comportamiento de los orígenes de datos de Reporting Services basados en grupos de disponibilidad Always On puede variar en función del modo en el que el administrador haya configurado el entorno de los grupos de disponibilidad.

Para utilizar grupos de disponibilidad Always On para orígenes de datos de informes, tiene que configurar la cadena de conexión del origen de datos de informe para usar el grupo de disponibilidad Nombre DNS del agente de escucha. Los orígenes de datos admitidos son los siguientes:

  • El origen de datos ODBC con SQL Native Client.

  • SQL Client, con la revisión .NET aplicada al servidor de informes.

La cadena de conexión también puede contener nuevas propiedades de conexión AlwaysOn que configuren las solicitudes de consulta de informes para usar la réplica secundaria para los informes de solo lectura. El uso de réplicas secundarias para las solicitudes de notificación reduce la carga en una réplica principal de lectura-escritura. La ilustración siguiente es un ejemplo de una configuración de grupos de disponibilidad Always On de tres réplicas en la que las cadenas de conexión del origen de datos de Reporting Services se han configurado con ApplicationIntent=ReadOnly. En este ejemplo las solicitudes de consulta de informe se envían a una réplica secundaria y no a la réplica principal.

El siguiente es un ejemplo de cadena de conexión en el que [AvailabilityGroupListenerName] es el nombre DNS del agente de escucha que se configuró cuando las réplicas se crearon:

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

El botón Probar conexión de las interfaces de usuario de Reporting Services validan si una conexión se puede establecer, pero no valida la configuración de los grupos de disponibilidad. Por ejemplo, si incluye ApplicationIntent en una cadena de conexión a un servidor que no es parte de AG, el parámetro adicional se pasa por alto y el botón Probar conexión solo validará si una conexión se puede establecer en el servidor especificado.

El modo en que se creen los informes y se publiquen determinará dónde modificará la cadena de conexión:

  • Modo nativo: use el portal web para los informes y los orígenes de datos compartidos ya publicados en un servidor de informes en modo nativo.

  • Modo de SharePoint: use las páginas de configuración de SharePoint dentro de las bibliotecas de documentos para los informes que ya se han publicado en un servidor SharePoint.

  • Diseño de informes: --- title: include file description: include file author: maggiesMSFT ms.author: maggies ms.date: 12/06/2018 ms.service: ms.topic: include ms.custom: include fileGenerador de informes o SQL Server Data Tools (SSDT) cuando se crean informes nuevos. Vea la sección "Diseño de informes" en este artículo o en la información adicional.

Recursos adicionales:

Consideraciones: las réplicas secundarias normalmente experimentarán una demora al recibir los cambios de datos de la réplica principal. Los factores siguientes pueden afectar a la latencia entre las réplicas principales y secundarias:

  • El número de réplicas secundarias. La demora aumenta con cada réplica secundaria que se agrega a la configuración.

  • La ubicación geográfica y la distancia entre las réplicas principales y secundarias. Por ejemplo, la demora suele ser mayor si las réplicas secundarias están en un centro de datos diferente o si están en el mismo edificio que la réplica principal.

  • Configuración del modo de disponibilidad para cada réplica. El modo de disponibilidad determina si la réplica principal espera la confirmación de transacciones en una base de datos hasta que una réplica secundaria haya escrito las entradas del registro de transacciones en el disco. Para obtener más información, vea la sección "Modos de disponibilidad" en ¿Qué es un grupo de disponibilidad AlwaysOn?.

Cuando se usa una réplica secundaria de solo lectura como origen de datos de Reporting Services, es importante asegurarse de que la latencia de actualización de los datos satisface las necesidades de los usuarios de los informes.

Diseñador de informes y grupos de disponibilidad

Cuando se diseñan informes en --- title: include file description: include file author: maggiesMSFT ms.author: maggies ms.date: 12/06/2018 ms.service: ms.topic: include ms.custom: include fileGenerador de informes o un proyecto de informe en SQL Server Data Tools (SSDT), un usuario puede configurar una cadena de conexión de origen de datos de informe para contener nuevas propiedades de conexión proporcionadas por grupos de disponibilidad Always On. La compatibilidad con las nuevas propiedades de conexión depende de si un usuario obtiene la vista previa del informe.

  • Versión preliminar local: --- title: include file description: include file author: maggiesMSFT ms.author: maggies ms.date: 12/06/2018 ms.service: ms.topic: include ms.custom: include fileGenerador de informes y SQL Server Data Tools (SSDT) utilizan .NET Framework 4.0 y son compatibles con las propiedades de cadena de conexión de grupos de disponibilidad Always On.

  • Vista previa en modo servidor o remoto: Si después de publicar informes en el servidor de informes o mediante la vista previa en --- title: include file description: include file author: maggiesMSFT ms.author: maggies ms.date: 12/06/2018 ms.service: ms.topic: include ms.custom: include fileGenerador de informes aparece un error similar al siguiente, es una indicación de que se están previsualizando los informes en el servidor de informes y la revisión de .NET Framework 3.5 SP1 para los grupos de disponibilidad Always On no se ha instalado en el servidor de informes.

Mensaje de error: "La palabra clave no admite "applicationintent""

Bases de datos del servidor de informes y grupos de disponibilidad

Reporting Services y Power BI Report Server ofrecen compatibilidad limitada para usar grupos de disponibilidad Always On con bases de datos del servidor de informes. Las bases de datos del servidor de informes se pueden configurar en grupos de disponibilidad Always On para que formen parte de una réplica. Sin embargo, Reporting Services no usará automáticamente una réplica diferente para las bases de datos del servidor de informes cuando se produzca una conmutación por error. No se admite el uso de MultiSubnetFailover con las bases de datos del servidor de informes.

Los scripts de automatización personalizada o acciones manuales tienen que usarse para realizar la conmutación por error y la recuperación. Hasta que estas acciones se completen, algunas características del servidor de informes pueden no funcionar correctamente después de la conmutación por error de los grupos de disponibilidad Always On.

Nota

Al planear la recuperación de desastres y la conmutación por error para las bases de datos del servidor de informes, se aconseja que siempre haga una copia de seguridad de la clave de cifrado del servidor de informes.

Diferencias entre el modo nativo de SharePoint

En esta sección, se resumen las diferencias entre el modo en el que los servidores de informes del modo nativo y el modo de SharePoint interactúan con grupos de disponibilidad Always On.

Un servidor de informes de SharePoint crea 3 bases de datos para cada aplicación de servicio de Reporting Services que cree. La conexión a las bases de datos del servidor de informes en modo de SharePoint se configura en Administración central de SharePoint al crear una nueva aplicación de servicio. Los nombres predeterminados de las bases de datos incluyen un GUID que está asociado a la aplicación de servicio. Estos son los nombres de base de datos de ejemplo, para un servidor de informes en modo de SharePoint:

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6TempDB

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6_Alerting

Loas servidores de informes de modo nativo usan 2 bases de datos. Estos son los nombres de base de datos de ejemplo, para un servidor de informes en modo nativo:

  • ReportServer

  • ReportServerTempDB

El modo nativo no admite ni usa las bases de datos de alerta ni las características relacionadas. Los servidores de informes en modo nativo se configuran en el Administrador de configuración de Reporting Services. En el modo SharePoint, configure el nombre de base de datos de la aplicación de servicio para que sea el nombre del "punto de acceso de cliente" que creó como parte de la configuración de SharePoint. Para obtener más información sobre cómo configurar SharePoint con grupos de disponibilidad Always On, vea Configuración y administración de grupos de disponibilidad de SQL Server para SharePoint Server (/previous-versions/office/sharepoint-server-2010/hh913923(v=office.14)).

Nota

Los servidores de informes en el modo de SharePoint usan un proceso de sincronización entre las bases de datos de aplicación de servicio de Reporting Services y las bases de datos de contenido de SharePoint. Es importante mantener juntas las bases de datos del servidor de informes y las bases de datos de contenido. Debe considerar configurarlas en los mismos grupos de disponibilidad para que conmuten por error y se recuperen como un conjunto. Considere el caso siguiente:

  • Restaura o conmuta por error a una copia de la base de datos de contenido que no ha recibido las mismas actualizaciones que la base de datos del servidor de informes.
  • El proceso de sincronización de Reporting Services detectará las diferencias entre la lista de elementos de la base de datos de contenido y las bases de datos del servidor de informes.
  • El proceso de sincronización eliminará o actualizará los elementos de la base de datos de contenido.

Preparar las bases de datos del servidor de informes para grupos de disponibilidad

A continuación, se indican los pasos básicos para preparar y agregar las bases de datos del servidor de informes a grupos de disponibilidad Always On:

  • Cree su grupo de disponibilidad y configure un nombre DNS del agente de escucha.

  • Réplica principal: configure las bases de datos del servidor de informes para que formen parte de un solo grupo de disponibilidad y cree una réplica principal que incluya todas las bases de datos del servidor de informes.

  • Réplicas secundarias: cree una o varias réplicas secundarias. El enfoque habitual para copiar las bases de datos de la réplica principal a la secundaria consiste en restaurar las bases de datos en cada réplica secundaria mediante "RESTORE WITH NORECOVERY". Para obtener más información sobre cómo crear réplicas secundarias y comprobar que la sincronización de datos funciona, vea Iniciar el movimiento de datos en una base de datos secundaria AlwaysOn (SQL Server).

  • Credenciales del servidor de informes: tiene que crear las credenciales del servidor de informes apropiadas en las réplicas secundarias que creó en la principal. Los pasos exactos dependen del tipo de autenticación que usa en su entorno de Reporting Services: la cuenta de servicio de Windows para Reporting Services, la cuenta de usuario de Windows o la autenticación de SQL Server. Para obtener más información, consulte Configurar una conexión de base de datos del servidor de informes (Administrador de configuración del servidor de informes).

  • Actualice la conexión a la base de datos para utilizar el nombre DNS del cliente de escucha. Para los servidores de informes en modo nativo, cambie el Nombre de base de datos del servidor de informes en el Administrador de configuración de Reporting Services. Para el modo de SharePoint, cambie el Nombre del servidor de base de datos para las aplicaciones de servicio de Reporting Services.

Pasos para completar la recuperación de desastres de bases de datos del servidor de informes

Es necesario realizar los siguientes pasos después de una conmutación por error de grupos de disponibilidad Always On a una réplica secundaria:

  1. Detenga la instancia del servicio Agente SQL que usaba el motor de base de datos principal que hospeda las bases de datos de Reporting Services.

  2. Inicie el servicio Agente SQL en el equipo que sea la nueva réplica principal.

  3. Detenga el servicio del servidor de informes.

    Si el servidor de informes está en modo nativo, detenga el servidor Windows del servidor de informes con el Administrador de configuración de Reporting Services.

    Si el servidor de informes está configurado para el modo de SharePoint, detenga el servicio compartido de Reporting Services en Administración central de SharePoint.

  4. Inicie el servicio del servidor de informes o el servicio SharePoint de Reporting Services.

  5. Compruebe que los informes se puedan ejecutar con la nueva réplica principal.

Comportamiento del servidor de informes cuando se produce una conmutación por error

Cuando las bases de datos del servidor conmutan por error y ha actualizado el entorno del servidor de informes para que use la nueva réplica principal, hay algunos problemas operativos que se derivan del proceso de conmutación por error y recuperación. La repercusión de estos problemas varía según la carga de Reporting Services en el momento de la conmutación por error, así como lo que tardan los grupos de disponibilidad Always On en conmutar por error a una réplica secundaria y el administrador del servidor de informes en actualizar el entorno de elaboración de informes para usar la nueva réplica principal.

  • La ejecución del procesamiento en segundo plano puede ocurrir más de una vez debido a la lógica de reintento y a la incapacidad del servidor de informes de marcar el trabajo programado a medida que se completa durante el período de conmutación por error.

  • La ejecución del proceso en segundo plano que normalmente se habría desencadenado durante el período de la conmutación por error no se producirá porque el Agente SQL Server no podrá escribir los datos en la base de datos del servidor de informes y estos datos no se sincronizarán con la nueva réplica principal.

  • Una vez completada la conmutación por error de la base de datos y tras reiniciarse el servicio del servidor de informes, los trabajos del Agente SQL Server se volverán a crear de forma automática. Hasta que los trabajos del agente SQL se vuelvan a crear, cualquier ejecución en segundo plano asociada a los trabajos del Agente SQL Server no se procesarán. Esto incluye las suscripciones, programaciones e instantáneas de Reporting Services.

Consulte también