Compartir a través de

Reporting Services con grupos de disponibilidad AlwaysOn (SQL Server)

  • Artículo

Este tema contiene información sobre cómo configurar Reporting Services para trabajar con grupos de disponibilidad (AG) de Always On en SQL Server 2014. 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 clave del uso de Always On grupos de disponibilidad con Reporting Services orígenes de datos es aprovechar las réplicas secundarias legibles como origen de datos de informes, mientras que, al mismo tiempo, las réplicas secundarias proporcionan una conmutación por error para una base de datos principal.

Para obtener información general sobre los grupos de disponibilidad de Always On, consulte Preguntas más frecuentes sobre AlwaysOn para SQL Server 2012 (https://msdn.microsoft.com/sqlserver/gg508768).

Requisitos para usar Reporting Services y grupos de disponibilidad de AlwaysOn

Para usar Always On grupos de disponibilidad con SQL Server 2014 Reporting Services, 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 se produce cuando se incluye una de las propiedades Always On Grupos de disponibilidad en la cadena de conexión Reporting Services, pero el servidor no reconoce la propiedad . El mensaje de error indicado se verá cuando haga clic en 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 acerca de la revisión necesaria, vea La revisión de KB 2654347A introduce compatibilidad con las características de AlwaysOn de SQL Server 2012 de .NET Framework 3.5 SP1.

Para obtener información sobre otros requisitos de los grupos de disponibilidad de Always On, consulte Requisitos previos, restricciones y recomendaciones para grupos de disponibilidad AlwaysOn (SQL Server).

Nota

Reporting Services archivos de configuración como RSreportserver.config no se admiten como parte de Always On funcionalidad de grupos de disponibilidad. 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 Reporting Services orígenes de datos basados en Always On grupos de disponibilidad puede variar en función de cómo el administrador haya configurado el entorno del grupo de disponibilidad.

Para usar Always On grupos de disponibilidad para orígenes de datos de informe, debe configurar la cadena de conexión del origen de datos de informe para usar el nombre DNS del agente de escucha del grupo de disponibilidad. 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 reducirá 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.

Origen de datos de SSRS mediante grupos de ag

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 = AdventureWorks2008R2; ApplicationIntent=ReadOnly

El botón Probar conexión de las interfaces de usuario de Reporting Services validarán si una conexión se puede establecer, pero no validará 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 Administrador de informes para los informes y los orígenes de datos compartidos que ya se hayan publicado 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: SQL Server Report Builder para SQL Server 2012 o SQL Server Data Tools (SSDT) al crear nuevos informes. Vea la sección "Diseño de informes" en este tema 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, consulte la sección "Modos de disponibilidad" de Información general de los grupos de disponibilidad AlwaysOn (SQL Server).

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

Al diseñar informes en SQL Server Report Builder para SQL Server 2012 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 que contenga nuevas propiedades de conexión proporcionadas por Always On grupos de disponibilidad. La compatibilidad con las nuevas propiedades de conexión depende de si un usuario obtiene la vista previa del informe.

  • Versión preliminar local: SQL Server Report Builder para SQL Server 2012 y SQL Server Data Tools (SSDT) usan .Net Framework 4.0 y admiten propiedades de cadena de conexión de grupos de disponibilidad Always On.

  • Vista previa del modo de servidor o remoto: Si después de publicar informes en el servidor de informes o usar la versión preliminar en SQL Server Report Builder para SQL Server 2012, verá un error similar al siguiente, es una indicación de que está previsualizar los informes en el servidor de informes y la revisión de .Net Framework 3.5 SP1 para Always On Los grupos de disponibilidad no se han 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 ofrece compatibilidad limitada para usar Always On grupos de disponibilidad 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.

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 se completen estas acciones, es posible que algunas características del servidor de informes no funcionen correctamente después de la conmutación por error de los grupos de disponibilidad de 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 de SharePoint y los servidores de informes en modo nativo con Always On grupos de disponibilidad.

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. Para el modo de SharePoint, configure el nombre de la 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 Always On grupos de disponibilidad, vea Configurar y administrar grupos de disponibilidad SQL Server para SharePoint Server (https://go.microsoft.com/fwlink/?LinkId=245165).

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

Estos son los pasos básicos para preparar y agregar las bases de datos del servidor de informes a un grupo de disponibilidad de 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, consulte 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 agente 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

Los pasos siguientes deben completarse después de una conmutación por error de grupos de disponibilidad Always On en 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. El impacto de estos problemas variará en función de la carga Reporting Services en el momento de la conmutación por error, así como del tiempo que tarda Always On grupos de disponibilidad en conmutar por error a una réplica secundaria y para que el administrador del servidor de informes actualice el entorno 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

SQL Server Native Client compatibilidad con alta disponibilidad, grupos de disponibilidad AlwaysOn de recuperación ante desastres(SQL Server)Introducción con grupos de disponibilidad AlwaysOn (SQL Server)Uso de palabras clave de cadena de conexión con SQL Server Native ClientSQL Server Native Client compatibilidad con alta disponibilidad, recuperación antedesastres acerca del acceso de conexión de cliente a réplicas de disponibilidad (SQL Server)