Partager via

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

  • Article

Cette rubrique contient des informations sur la configuration des Reporting Services pour qu’ils fonctionnent avec Always On groupes de disponibilité (AG) dans SQL Server 2014. Les trois scénarios d’utilisation des groupes de disponibilité Reporting Services et Always On sont les bases de données pour les sources de données de rapport, les bases de données du 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 de l’utilisation de groupes de disponibilité Always On avec des sources de données Reporting Services est de tirer parti des réplicas secondaires lisibles en tant que source de données de création de rapports, tandis que, dans le même temps, les réplicas secondaires fournissent un basculement pour une base de données primaire.

Pour obtenir des informations générales sur les groupes de disponibilité Always On, consultez faq AlwaysOn pour SQL Server 2012 (https://msdn.microsoft.com/sqlserver/gg508768).

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

Pour utiliser Always On groupes de disponibilité avec SQL Server Reporting Services 2014, vous devez télécharger et installer un correctif logiciel 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. »

Le message se produit lorsque vous incluez l’une des propriétés Always On groupes de disponibilité dans la chaîne de connexion Reporting Services, mais que le serveur ne reconnaît pas la 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 une préversion 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 exigences des groupes de disponibilité Always On, consultez Prérequis, restrictions et recommandations pour les groupes de disponibilité AlwaysOn (SQL Server).

Notes

Reporting Services fichiers de configuration tels que RSreportserver.config ne sont pas pris en charge dans le cadre de Always On fonctionnalité groupes de disponibilité. 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.

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

Le comportement de Reporting Services sources de données en fonction de Always On groupes de disponibilité peut varier en fonction de la façon dont votre administrateur a configuré l’environnement du groupe de disponibilité.

Pour utiliser Always On groupes de disponibilité pour les sources de données de rapport, vous devez configurer la chaîne de connexion à la source de données de rapport pour utiliser le 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 de 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 utilisant des groupes de groupe

Voici un exemple de chaîne de connexion, dans laquelle [AvailabilityGroupListenerName] correspond au Nom DNS de l’écouteur qui a été configuré au moment 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 rapport : SQL Server Report Builder pour SQL Server 2012 ou SQL Server Data Tools (SSDT) lorsque vous créez des rapports. Pour plus d’informations, consultez la section « Conception de rapports », plus loin dans cette rubrique.

Ressources supplémentaires :

Considérations : 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.

Conception de rapports et groupes de disponibilité

Lors de la conception de rapports dans SQL Server Report Builder pour SQL Server 2012 ou d’un projet de rapport dans SQL Server Data Tools (SSDT), un utilisateur peut configurer une chaîne de connexion de source de données de rapport pour contenir de nouvelles propriétés de connexion fournies par Always On groupes de disponibilité. La prise en charge des nouvelles propriétés de connexion varie selon l'endroit où un utilisateur affiche un aperçu du rapport.

  • Préversion locale : SQL Server Report Builder pour SQL Server 2012 et SQL Server Data Tools (SSDT) utilisent .Net Framework 4.0 et prennent en charge les propriétés de chaîne de connexion des groupes de disponibilité Always On.

  • Préversion du mode serveur ou distant : Si après avoir publié des rapports sur le serveur de rapports ou utilisé la préversion dans SQL Server Report Builder pour SQL Server 2012, vous voyez une erreur similaire à ce qui suit, cela indique que vous affichez un aperçu des rapports sur le serveur de rapports et le correctif logiciel .Net Framework 3.5 SP1 pour Always On Les groupes de disponibilité n’ont pas été installés sur le serveur de rapports.

Message d’erreur : « mot clé non pris en charge : applicationintent. »

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

Reporting Services offre une prise en charge limitée de l’utilisation des groupes de disponibilité Always On avec les bases de données du 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 ne sont pas terminées, certaines fonctionnalités du serveur de rapports peuvent ne pas fonctionner correctement après le basculement des groupes de disponibilité Always On.

Notes

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.

Différences entre le mode natif et le mode SharePoint

Cette section récapitule les différences entre la façon dont les serveurs de rapports en mode SharePoint et en mode natif interagissent avec Always On groupes de disponibilité.

Un serveur de rapports SharePoint crée 3 des 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, dans le Gestionnaire de configuration de Reporting Services. Pour le mode SharePoint, vous configurez le nom de la base de données de l’application de service pour qu’il soit le 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 des groupes de disponibilité Always On, consultez Configurer et gérer SQL Server groupes de disponibilité pour SharePoint Server (https://go.microsoft.com/fwlink/?LinkId=245165).

Notes

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.

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

Voici les étapes de base de la préparation et de l’ajout des bases de données du serveur de rapports à un Always On groupes de disponibilité :

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

  • 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 fonctionnement de la synchronisation des données, consultez Démarrer le déplacement des 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 (Gestionnaire de configuration de SSRS)

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

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

Les étapes suivantes doivent être effectuées après un basculement des groupes de disponibilité Always On 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.

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 en fonction de la charge Reporting Services au moment du basculement, ainsi que de la durée nécessaire à Always On groupes de disponibilité pour basculer vers un réplica secondaire et selon que l’administrateur du serveur de rapports met à jour l’environnement de création de rapports pour utiliser la nouvelle réplica principale.

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

Voir aussi

SQL Server Native Client prise en charge de la haute disponibilité, desgroupes de disponibilité AlwaysOn de récupération d’urgence (SQL Server)Prise en main avec les groupes de disponibilité AlwaysOn (SQL Server)Utilisation de mots clés de chaîne de connexion avec SQL Server Native ClientSQL Server Native Client prise en charge de la haute disponibilité, de la récupération d’urgenceà propos de l’accès des connexions clientes aux réplicas de disponibilité (SQL Server)