Reporting Services con grupos de disponibilidad AlwaysOn (SQL Server)

Este tema contiene información acerca de la configuración de Reporting Services para que funcione con Grupos de disponibilidad AlwaysOn (AG) en SQL Server 2012. Los tres escenarios para usar Reporting Services y Grupos de disponibilidad AlwaysOn son las bases de datos para orígenes de datos de informes, las bases de datos del servidor de informes y el diseñador de informes. La funcionalidad admitida y la configuración requerida son diferentes para los tres escenarios.

Una ventaja clave del uso de Grupos de disponibilidad AlwaysOn con los orígenes de datos Reporting Services es aprovechar las réplicas secundarias legibles como un origen de datos de informes, al mismo tiempo que las réplicas secundarias proporcionan una base de datos principal.

Para obtener información general sobre Grupos de disponibilidad AlwaysOn, vea Preguntas más frecuentes sobre AlwaysOn en SQL Server 2012 (https://msdn.microsoft.com/en-us/sqlserver/gg508768).

En este tema:

• Requisitos para usar Reporting Services y grupos de disponibilidad de AlwaysOn

• Orígenes de datos de informes y grupos de disponibilidad

• Diseñador de informes y grupos de disponibilidad

• Bases de datos del servidor de informes y grupos de disponibilidad

• • Diferencias entre el modo nativo de SharePoint

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

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

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

Requisitos para usar Reporting Services y grupos de disponibilidad de AlwaysOn

Para usar Grupos de disponibilidad AlwaysOn con SQL Server 2012 Reporting Services, tiene que 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 se admite ‘applicationintent’”

El mensaje tiene lugar cuando incluye una de las propiedades Grupos de disponibilidad AlwaysOn en la cadena de conexión Reporting Services, pero el servidor no reconoce la propiedad. El mensaje de error anotado se verá cuando haga clic en el botón ‘Probar conexión’ en las interfaces de usuario Reporting Services y cuando obtenga la vista previa del informe si los errores remotos se habilitan 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 más información acerca de otros requisitos de Grupos de disponibilidad AlwaysOn, vea Requisitos previos, restricciones y recomendaciones para Grupos de disponibilidad AlwaysOn (SQL Server).

  

[!NOTA]

Los archivos de configuración de Reporting Services como RSreportserver.config no se admiten como parte de la funcionalidad Grupos de disponibilidad AlwaysOn. 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.

Parte superior

Orígenes de datos de informes y grupos de disponibilidad

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

Para utilizar Grupos de disponibilidad AlwaysOn para notificar los orígenes de datos, 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 reducirá la carga en una réplica principal de lectura-escritura. La ilustración siguiente es un ejemplo de una configuración AG de tres réplicas en la que las cadenas de conexión del origen de datos 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.

 

Lo siguiente es una cadena de conexión de ejemplo, en la 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 en las interfaces de usuario de Reporting Services validarán si una conexión se puede establecer pero no validará la configuración de AG. 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ñador de informes: Generador de informes de SQL Server para SQL Server 2012 o Herramientas de datos de SQL Server (SSDT) al crear nuevos informes. Vea la sección ‘Diseño de informes’ en este tema o en la información adicional.

Recursos adicionales:

• Administrar orígenes de datos de informe

• Para obtener más información acerca de las propiedades de cadenas de conexión disponibles, vea Usar palabras clave de cadena de conexión con SQL Server Native Client.

• Para obtener más información de los agentes de escucha del grupo de disponibilidad, vea Crear o configurar un agente de escucha del grupo de disponibilidad (SQL Server).

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 administración" 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 datos cumple las necesidades de los usuarios del informe.

Parte superior

Diseñador de informes y grupos de disponibilidad

Al diseñar los informes en Generador de informes de SQL Server para SQL Server 2012 o un proyecto de informe en Herramientas de datos de SQL Server (SSDT), un usuario puede configurar una cadena de conexión del origen de datos de informe para que contenga las nuevas propiedades de conexión proporcionadas por Grupos de disponibilidad AlwaysOn. La compatibilidad con las nuevas propiedades de conexión depende de si un usuario obtiene la vista previa del informe.

• Vista previa local: Generador de informes de SQL Server para SQL Server 2012 y Herramientas de datos de SQL Server (SSDT) usan .Net framework 4.0 y admiten las propiedades de la cadena de conexión de Grupos de disponibilidad AlwaysOn.

• Vista previa en modo servidor o remoto: si tras publicar informes en el servidor de informes o usar la vista previa en Generador de informes de SQL Server para SQL Server 2012, ve un error similar al siguiente, es una indicación de que está obteniendo la vista previa de los informes con el servidor de informes y la revisión .Net Framework 3.5 SP1 para Grupos de disponibilidad AlwaysOn no se ha instalado en el servidor de informes.

Mensaje de error: “La palabra clave no se admite ‘applicationintent’”

Parte superior

Bases de datos del servidor de informes y grupos de disponibilidad

Reporting Services ofrece compatibilidad limitada para usar Grupos de disponibilidad AlwaysOn con bases de datos del servidor de informes. Las bases de datos del servidor de informes se pueden configurar en AG para ser 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 produce 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 estas acciones se completen, algunas características del servidor de informes pueden no funcionar de forma correcta tras la conmutación por error de Grupos de disponibilidad AlwaysOn.

[!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.

 

Parte superior

Diferencias entre el modo nativo de SharePoint

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

Un servidor de informes de SharePoint crea las bases de datos de 3 para cada aplicación de servicios 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 de 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 acerca de cómo configurar SharePoint con Grupos de disponibilidad AlwaysOn, vea Configurar y administrar los grupos de disponibilidad de SQL para SharePoint Server (https://go.microsoft.com/fwlink/?LinkId=245165).

[!NOTA]

Los servidores de informes de modo de SharePoint usan un proceso de sincronización entre las bases de datos de aplicación de servicio 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.

Parte superior

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 un Grupos de disponibilidad AlwaysOn:

• 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. Esto incluye

• Réplicas secundarias: cree una o varias réplicas secundarias. La solución habitual para copiar las bases de datos de la réplica principal a la secundaria es restaurar las bases de datos en cada réplica secundaria usando ‘RESTORE WITH NORECOVERY’. Para obtener más información acerca de 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 Reporting Services; la cuenta de servicio de Windows Reporting Services, la cuenta de usuario de Windows o la autenticación de SQL Server. Para obtener más información, vea Configurar una conexión a la base de datos del servidor de informes (modo nativo).

• 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 de servidor de base de datos de las aplicaciones de servicio de Reporting Services.

Parte superior

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

Es necesario completar los pasos siguientes tras una conmutación por error de Grupos de disponibilidad AlwaysOn 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 se configura 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 Reporting Services SharePoint.

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

 

Parte superior

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 variará según la carga de Reporting Services en el momento de la conmutación por error, así como lo que Grupos de disponibilidad AlwaysOn tarda en conmutar por error a una réplica secundaria y el administrador del servidor de informes en actualizar 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. Esta versión también incluye suscripciones de Reporting Services, programaciones e instantáneas.

Parte superior

Vea también

Conceptos

Compatibilidad de SQL Server Native Client para la alta disponibilidad con recuperación de desastres

Grupos de disponibilidad AlwaysOn (SQL Server)

Introducción a los grupos de disponibilidad de AlwaysOn (SQL Server)

Usar palabras clave de cadena de conexión con SQL Server Native Client

Compatibilidad de SQL Server Native Client para la alta disponibilidad con recuperación de desastres

Acerca del acceso de conexión de cliente a réplicas de disponibilidad (SQL Server)