Reporting Services avec les groupes de disponibilité AlwaysOn (SQL Server)

Cette rubrique contient des informations sur la configuration de Reporting Services en vue d'une utilisation avec Groupes de disponibilité AlwaysOn (groupes de disponibilité) dans SQL Server 2012. Les trois possibilités d'utilisation de Reporting Services et de Groupes de disponibilité AlwaysOn sont les bases de données pour les sources de données de rapport, les bases de données de serveur de rapports et la conception de rapports. Les fonctionnalités prises en charge et la configuration requise diffèrent dans les trois cas.

L'un des principaux avantages d'utiliser Groupes de disponibilité AlwaysOn avec des sources de données Reporting Services réside dans l'exploitation de réplicas secondaires accessibles en lecture en tant que source de données de rapports tandis que, dans le même temps, les réplicas secondaires permettent le basculement vers une base de données principale.

Pour plus d'informations sur Groupes de disponibilité AlwaysOn, consultez le forum aux questions FAQ AlwaysOn pour SQL Server 2012 (https://msdn.microsoft.com/fr-fr/sqlserver/gg508768).

Dans cette rubrique :

  • Conditions préalables requises pour l'utilisation de Reporting Services et des groupes de disponibilité AlwaysOn

  • Sources de données de rapport et groupes de disponibilité

  • Conception de rapports et groupes de disponibilité

  • Bases de données de serveur de rapports et groupes de disponibilité

    • Différences entre le mode natif et le mode SharePoint

    • Préparer les bases de données de serveur de rapports pour les groupes de disponibilité

    • Étapes pour effectuer une récupération d'urgence de bases de données de serveur de rapports

    • Comportement d'un serveur de rapports en cas de basculement

Conditions préalables requises pour l'utilisation de Reporting Services et des groupes de disponibilité AlwaysOn

Pour utiliser Groupes de disponibilité AlwaysOn avec SQL Server 2012 Reporting Services, vous devez télécharger et installer un correctif pour .Net 3.5 SP1. Ce correctif ajoute une prise en charge au client SQL concernant les fonctionnalités de groupes de disponibilité et la prise en charge des propriétés de chaîne de connexion ApplicationIntent et MultiSubnetFailover. Si ce correctif n'est pas installé sur chaque ordinateur qui héberge un serveur de rapports, les utilisateurs qui essaient d'afficher un aperçu des rapports recevront un message d'erreur similaire à celui ci-dessous et ce message sera enregistré dans le fichier journal de traces du serveur de rapports :

Message d'erreur : « Mot clé non pris en charge : applicationintent. »

Ce message s'affiche lorsque vous incluez l'une des propriétés Groupes de disponibilité AlwaysOn dans la chaîne de connexion Reporting Services, mais que le serveur ne reconnaît pas cette propriété. Le message d'erreur indiqué s'affiche lorsque vous cliquez sur le bouton « Tester la connexion » dans les interfaces utilisateur Reporting Services et lorsque vous affichez un aperçu du rapport si des erreurs distantes sont activées sur les serveurs de rapports.

Pour plus d'informations sur le correctif requis, consultez l'article 2654347A de la base de connaissance : Le correctif introduit la prise en charge des fonctionnalités AlwaysOn de SQL Server 2012 vers .NET Framework 3.5 SP1.

Pour plus d'informations sur les autres conditions Groupes de disponibilité AlwaysOn requises, consultez Conditions préalables requises, restrictions et recommandations pour les groupes de disponibilité AlwaysOn (SQL Server).

  

[!REMARQUE]

Les fichiers de configuration Reporting Services, tels que RSreportserver.config, ne sont pas pris en charge dans le cadre de la fonctionnalité Groupes de disponibilité AlwaysOn. Si vous apportez manuellement des modifications à un fichier de configuration sur l'un des serveurs de rapports, vous devez mettre à jour manuellement les réplicas.

Icône de flèche utilisée avec le lien Retour en hautHaut

Sources de données de rapport et groupes de disponibilité

Le comportement de sources de données Reporting Services basées sur Groupes de disponibilité AlwaysOn peut varier selon la manière dont votre administrateur a configuré l'environnement de groupes de disponibilité.

Pour utiliser Groupes de disponibilité AlwaysOn pour les sources de données de rapport que vous devez configurer, la chaîne de connexion de la source de données de rapport doit faire référence au Nom DNS de l'écouteur du groupe de disponibilité. Les sources de données prises en charge sont les suivantes :

  • Source de données ODBC utilisant SQL Native Client.

  • Client SQL, avec le correctif .Net appliqué au serveur de rapports.

La chaîne de connexion peut également contenir de nouvelles propriétés de connexion AlwaysOn qui configurent les demandes de requêtes de rapport afin qu'elles utilisent un réplica secondaire pour la création de rapports en lecture seule. L'utilisation d'un réplica secondaire pour les demandes de création de rapports réduit la charge sur un réplica principal en lecture-écriture. L'illustration suivante est un exemple d'une configuration de groupe de disponibilité à trois réplicas dans laquelle les chaînes de connexion de source de données Reporting Services ont été configurées avec ApplicationIntent=ReadOnly. Dans cet exemple, les demandes de requêtes de rapports sont envoyées à un réplica secondaire, et non au réplica principal.

Source de données SSRS à l'aide de groupes AG

 

Voici un exemple de chaîne de connexion, dans laquelle [AvailabilityGroupListenerName] correspond au Nom DNS de l'écouteur qui a été configuré lors de la création des réplicas :

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

Le bouton Tester la connexion dans les interfaces utilisateur Reporting Services permet de valider s'il est possible d'établir une connexion, mais pas de valider une configuration de groupes de disponibilité. Par exemple, si vous incluez ApplicationIntent dans une chaîne de connexion à un serveur qui ne fait pas partie d'un groupe de disponibilité, le paramètre supplémentaire est ignoré et le bouton Tester la connexion ne permet de valider que s'il est possible d'établir une connexion au serveur spécifié.

La manière dont vos rapports ont été créés et publiés détermine l'endroit où vous allez modifier la chaîne de connexion :

  • Mode natif : utilisez le Gestionnaire de rapports pour les sources de données partagées et les rapports qui sont déjà publiés sur un serveur de rapports en mode natif.

  • Mode SharePoint : utilisez les pages de configuration de SharePoint dans les bibliothèques de documents pour les rapports qui sont déjà publiés sur un serveur SharePoint.

  • Conception de rapports : Générateur de rapports SQL Server pour SQL Server 2012 ou Outils de données SQL Server (SSDT) lors de la création de rapports. Pour plus d'informations, consultez la section « Conception de rapports », plus loin dans cette rubrique.

Ressources supplémentaires :

Observations : les réplicas secondaires subissent généralement un retard lors de la réception de modifications de données à partir du réplica principal. Les facteurs suivants peuvent avoir une influence sur la latence de mise à jour entre les réplicas principal et secondaires :

  • Nombre de réplicas secondaires. Le retard s'accentue avec chaque réplica secondaire ajouté à la configuration.

  • Emplacement géographique et distance entre les réplicas principal et secondaires. Par exemple, le retard est généralement plus important si les réplicas secondaires se trouvent dans un centre de données différent, par comparaison à ceux situés dans le même bâtiment que le réplica principal.

  • Configuration du mode de disponibilité pour chaque réplica. Le mode de disponibilité détermine si le réplica principal attend, pour valider des transactions sur une base de données, qu'un réplica secondaire donné ait écrit la transaction sur le disque. Pour plus d'informations, consultez la section « Modes de disponibilité » de Vue d'ensemble des groupes de disponibilité AlwaysOn (SQL Server).

Lors de l'utilisation d'un réplica secondaire en lecture seule en tant que source de données Reporting Services, il est important de veiller à ce que la latence de mise à jour des données corresponde aux besoins des utilisateurs de rapports.

Icône de flèche utilisée avec le lien Retour en hautHaut

Conception de rapports et groupes de disponibilité

Lors de la conception de rapports dans Générateur de rapports SQL Server pour SQL Server 2012 ou d'un projet de rapport dans Outils de données SQL Server (SSDT), un utilisateur peut configurer une chaîne de connexion de source de données de rapport afin qu'elle contienne les nouvelles propriétés de connexion fournies par Groupes de disponibilité AlwaysOn. La prise en charge des nouvelles propriétés de connexion varie selon l'endroit où un utilisateur affiche un aperçu du rapport.

  • Aperçu local : Générateur de rapports SQL Server pour SQL Server 2012 et Outils de données SQL Server (SSDT) utilisent .Net Framework 4.0 et prennent en charge les propriétés de chaîne de connexion Groupes de disponibilité AlwaysOn.

  • Aperçu en mode distant ou serveur : si, après avoir publié des rapports sur le serveur de rapports ou utilisé l'aperçu dans Générateur de rapports SQL Server pour SQL Server 2012, vous voyez une erreur similaire à celle qui suit, cela signifie que vous affichez un aperçu des rapports sur le serveur de rapports et que le correctif .Net Framework 3.5 SP1 pour Groupes de disponibilité AlwaysOn n'a pas été installé sur le serveur de rapports.

Message d'erreur : « Mot clé non pris en charge : applicationintent. »

Icône de flèche utilisée avec le lien Retour en hautHaut

Bases de données de serveur de rapports et groupes de disponibilité

Reporting Services offre une prise en charge limitée concernant l'utilisation de Groupes de disponibilité AlwaysOn avec des bases de données de serveur de rapports. Les bases de données de serveur de rapports peuvent être configurées dans les groupes de disponibilité afin de les intégrer à un réplica ; toutefois, Reporting Services n'utilisera pas automatiquement un réplica différent pour les bases de données de serveur de rapports en cas de basculement.

Il est nécessaire de recourir à des actions manuelles ou à des scripts d'automatisation personnalisés pour mener à bien le basculement et la récupération. Tant que ces actions n'ont pas été effectuées, certaines fonctionnalités du serveur de rapports peuvent ne pas fonctionner correctement après le basculement Groupes de disponibilité AlwaysOn.

[!REMARQUE]

Lors de la planification d'un basculement et d'une récupération d'urgence pour les bases de données de serveur de rapports, il est recommandé de toujours sauvegarder une copie de la clé de chiffrement du serveur de rapports.

 

Icône de flèche utilisée avec le lien Retour en hautHaut

Différences entre le mode natif et le mode SharePoint

Cette section résume les différences qu'il existe entre la manière dont les serveurs de rapports en mode SharePoint et en mode natif interagissent avec Groupes de disponibilité AlwaysOn.

Un serveur de rapports SharePoint crée 3 bases de données pour chaque application de service Reporting Services que vous créez. La connexion aux bases de données de serveur de rapports en mode SharePoint est configurée dans l'Administration centrale de SharePoint lorsque vous créez l'application de service. Les noms par défaut des bases de données incluent le GUID associé à l'application de service. Voici des exemples de noms de bases de données pour un serveur de rapports en mode SharePoint :

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6TempDB

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6_Alerting

Les serveurs de rapports en mode natif utilisent 2 bases de données. Voici des exemples de noms de bases de données pour un serveur de rapports en mode natif :

  • ReportServer

  • ReportServerTempDB

Le mode natif ne prend pas en charge et n'utilise pas les bases de données d'alerte et les fonctionnalités qui y sont associées. Pour configurer les serveurs de rapports en mode natif, faites appel au Gestionnaire de configuration Reporting Services. En mode SharePoint, configurez le nom de la base de données de l'application de service pour qu'il corresponde au nom du « point d'accès client » que vous avez créé dans le cadre de la configuration de SharePoint. Pour plus d'informations sur la configuration de SharePoint avec Groupes de disponibilité AlwaysOn, consultez Configurer et gérer des groupes de disponibilité SQL Server pour le serveur SharePoint (https://go.microsoft.com/fwlink/?LinkId=245165).

[!REMARQUE]

Les serveurs de rapports en mode SharePoint utilisent un processus de synchronisation entre les bases de données d'application de service Reporting Services et les bases de données de contenu SharePoint. Il est important de conserver les bases de données de serveur de rapports et les bases de données de contenu ensemble. Pensez à les configurer dans les mêmes groupes de disponibilité afin qu'elles soient basculées et récupérées en tant qu'ensemble. Examinez le cas suivant :

  • Vous effectuez la restauration ou le basculement vers une copie des la base de données de contenu qui n'a pas reçu les mêmes mises à jour récentes que celles reçues par la base de données de serveur de rapports.

  • Le processus de synchronisation de Reporting Services détecte les différences entre la liste des éléments dans la base de données de contenu et celle des bases de données de serveur de rapports.

  • Le processus de synchronisation supprime ou met à jour les éléments dans la base de données de contenu.

Icône de flèche utilisée avec le lien Retour en hautHaut

Préparer les bases de données de serveur de rapports pour les groupes de disponibilité

La section suivante décrit les étapes de base permettant la préparation et l'ajout de bases de données de serveur de rapports à Groupes de disponibilité AlwaysOn :

  • Créez votre groupe de disponibilité et configurez un nom DNS de l'écouteur.

  • Réplica principal : configurez les bases de données de serveur de rapports afin qu'elles fassent partie d'un groupe de disponibilité unique et créez un réplica principal incluant toutes les bases de données de serveur de rapports. Cela inclut :

  • Réplicas secondaires : créez un ou plusieurs réplicas secondaires. La méthode la plus courante pour copier les bases de données à partir du réplica principal vers le ou les réplicas secondaires consiste à restaurer les bases de données sur chaque réplica secondaire à l'aide de « RESTORE WITH NORECOVERY ». Pour plus d'informations sur la création de réplicas secondaires et la vérification du bon fonctionnement de la synchronisation des données, consultez Démarrer un mouvement de données sur une base de données secondaire AlwaysOn (SQL Server).

  • Informations d'identification de serveur de rapports : vous devez créer les informations d'identification appropriées de serveur de rapports sur les réplicas secondaires que vous avez créés sur le réplica principal. La procédure exacte varie selon le type d'authentification que vous utilisez dans votre environnement Reporting Services ; compte de service Windows Reporting Services, compte d'utilisateur Windows ou authentification SQL Server. Pour plus d'informations, consultez Configurer une connexion à la base de données du serveur de rapports (en mode natif).

  • Mettez à jour la connexion à la base de données pour utiliser le nom DNS de l'écouteur. Pour les serveurs de rapports en mode natif, remplacez Nom de la base de données du serveur de rapports dans le gestionnaire de configuration Reporting Services. En mode SharePoint, remplacez le nom du serveur de base de données pour les applications de service Reporting Services.

Icône de flèche utilisée avec le lien Retour en hautHaut

Étapes pour effectuer une récupération d'urgence de bases de données de serveur de rapports

La procédure suivante doit être effectuée après un basculement de Groupes de disponibilité AlwaysOn vers un réplica secondaire :

  1. Arrêtez l'instance du service SQL Agent qui était utilisée par le moteur de la base de données principale hébergeant les bases de données Reporting Services.

  2. Démarrez le service SQL Agent sur l'ordinateur qui correspond au nouveau réplica principal.

  3. Arrêtez le service Report Server.

    Si le serveur de rapports est en mode natif, arrêtez le serveur Windows du serveur de rapports à l'aide du gestionnaire de configuration Reporting Services.

    Si le serveur de rapports est configuré pour le mode SharePoint, arrêtez le service partagé Reporting Services dans l'Administration centrale de SharePoint.

  4. Démarrez le service du serveur de rapports ou le service Reporting Services SharePoint.

  5. Vérifiez que les rapports peuvent s'exécuter sur le nouveau réplica principal.

 

Icône de flèche utilisée avec le lien Retour en hautHaut

Comportement d'un serveur de rapports en cas de basculement

Lors du basculement de bases de données de serveur de rapports, et si vous avez mis à jour l'environnement du serveur de rapports afin qu'il utilise le nouveau réplica principal, des problèmes opérationnels résultant du processus de basculement et de récupération peuvent survenir. L'impact de ces problèmes varie selon la charge de Reporting Services au moment du basculement, ainsi que de la durée nécessaire à Groupes de disponibilité AlwaysOn pour effectuer le basculement vers un réplica secondaire et celle nécessaire à l'administrateur du serveur de rapports pour mettre à jour l'environnement de création de rapports afin qu'il utilise le nouveau réplica principal.

  • L'exécution du traitement en arrière-plan peut avoir lieu plusieurs fois en raison d'une logique de nouvelle tentative et d'une incapacité du serveur de rapports à marquer le travail planifié comme terminé pendant le basculement.

  • L'exécution du traitement en arrière-plan qui aurait normalement été déclenchée pendant le basculement n'a pas lieu car SQL Server Agent n'est pas en mesure d'écrire des données dans la base de données de serveur de rapports et que ces données ne sont pas synchronisées avec le nouveau réplica principal.

  • Une fois que le basculement de la base de données est terminé et que le service du serveur de rapports a été redémarré, les travaux de SQL Server Agent sont recréés automatiquement. Tant que les travaux de SQL Server Agent n'ont pas été recréés, les exécutions en arrière-plan associées aux travaux de SQL Server Agent ne sont pas traitées. Cela inclut les abonnements Reporting Services, les planifications et les instantanés.

Icône de flèche utilisée avec le lien Retour en hautHaut

Voir aussi

Concepts

Prise en charge des fonctionnalités de récupération d'urgence, haute disponibilité par SQL Server Native Client

Groupes de disponibilité AlwaysOn (SQL Server)

Commencer à utiliser les groupes de disponibilité AlwaysOn (SQL Server)

Utilisation de mots clés de chaîne de connexion avec SQL Server Native Client

Prise en charge des fonctionnalités de récupération d'urgence, haute disponibilité par SQL Server Native Client

À propos de l'accès de la connexion client aux réplicas de disponibilité (SQL Server)