Aide de Tableau Blueprint

Remarque : Cet article s’applique uniquement à Tableau Server.

Tableau Server peut être installé sur site sur des machines physiques ou virtuelles, ou dans le nuage, et prend en charge les systèmes d’exploitation Windows et Linux. Pour déterminer votre plateforme matérielle et la taille, tenez compte de ces variables : votre environnement, les sources de données et la gestion pour fournir un accès libre-service aux données, la charge de travail potentielle de tous les utilisateurs et les données d’utilisation réelles. Si c’est la première fois que vous déployez Tableau Server, vous devez vous concentrer sur vos normes d’environnement et vos sources de données. Pour les déploiements existants, vous analyserez les données de Tableau Server pour évaluer la charge de travail et l’utilisation en plus de l’environnement et des sources de données.

Configuration matérielle requise

Peu importe l’endroit où vous choisissez de déployer Tableau Server, des ressources matérielles de taille appropriée sont essentielles. Votre planification devrait être alignée sur l’évolution des besoins opérationnels en évaluant l’utilisation des serveurs et l’engagement des utilisateurs plus fréquemment, en prenant de l’ampleur plus fréquemment et en changeant la topologie plus fréquemment que d’autres applications logicielles. Passez en revue le lien correspondant vers la plateforme matérielle qui correspond aux normes de votre entreprise :

• Configurations de base recommandées (Windows | Linux)
• Tableau Server sur VMware VSphere
• Type et taille d’instance AWS (Windows | Linux)

• Type et taille de machine virtuelle Google Compute Engine (Windows | Linux)

• Type et taille de machine virtuelle Microsoft Azure (Windows | Linux)
• Type et taille d’instance Alibaba Cloud ECS (Windows | Linux)

Si vous déployez Tableau Server dans le nuage, l’utilisation d’un matériel dédié et l’allocation statique de la mémoire RAM permet d’éliminer les variations de performances dues aux conflits sur les ressources. Pour des raisons budgétaires, vous pouvez également opter pour du matériel virtuel. Nous vous recommandons de tester votre propre infrastructure pour déterminer la configuration qui convient à vos besoins. Pour un exemple de la manière d’effectuer un tel test, consultez le document technique Tableau at the Speed of EC2. Cette expérience a été menée dans AWS, mais la théorie du test est valable pour tous les fournisseurs infonuagiques.

Dimensionnement initial

L’équipe de votre compte Tableau est à votre disposition pour évaluer vos besoins et vous aider à déterminer les dimensions. Lors d’un premier déploiement de Tableau, vous devriez estimer entre 600 et 800 explorateurs par nœud de 8 cœurs, en supposant 10 % d’utilisateurs actifs (demandes interactives simultanées faites à Tableau Server, y compris la consommation de tableaux de bord sur un ordinateur portable ou un appareil mobile, la création Web, la connexion et l’interrogation des sources de données publiées). Ce n’est qu’un point de départ et ne devrait pas être considéré comme une règle de taille stricte au-delà du déploiement initial. La mémoire doit être d’au moins 8 Go de RAM par cœur pour un serveur de production. Pour les groupements de moins de 40 cœurs, utilisez des nœuds de 8 cœurs, et pour les groupements de plus de 40 cœurs, utilisez des nœuds de 16 cœurs. La charge de travail relative de chaque type de licence doit être prise en compte dans le dimensionnement du matériel. En supposant qu’un Explorer compte comme un seul utilisateur, un Creator a une charge de travail relative de 2,4 utilisateurs, tandis qu’un Viewer a une charge de travail relative de 0,75 utilisateur. En utilisant ces coefficients de charge de travail, vous pouvez estimer la capacité du groupement. Le tableau suivant présente des exemples de charges de travail équivalentes sur chaque ligne :

La charge de travail réelle des utilisateurs Creator, Explorer et Viewer peut varier selon l’utilisation des fonctionnalités de Tableau Server, comme la fréquence de connexion aux données et à la création Web, ainsi que l’affichage et l’interaction avec le contenu. À mesure que les utilisateurs sont intégrés et commencent à créer et à consommer du contenu, vous devez surveiller l’utilisation du matériel et du contenu pour prendre des décisions éclairées sur le dimensionnement des serveurs à l’aide des données tirées des outils de surveillance du matériel et du référentiel Tableau Server. Pour en savoir plus, consultez les articles Surveillance dans Tableau et Mesure de l’engagement et de l’adoption des utilisateurs Tableau

Extensibilité

Dans les scénarios de déploiement nouveaux et existants, l’objectif est de maintenir de façon proactive une disponibilité, une capacité et une marge de manœuvre suffisantes et de réduire au minimum les conflits de ressources. À l’instar d’autres plateformes d’entreprise, l’extensibilité verticale de Tableau Server passe par l’ajout de processeurs, de mémoire et de disques, et son extensibilité horizontale par l’ajout de nœuds à un groupement. Tableau Server évolue presque linéairement avec l’ajout de ressources matérielles, en fonction de votre environnement unique, de vos données, de votre charge de travail et de votre mélange d’utilisation. Les tests de charge et la planification de la capacité doivent être effectués régulièrement, comme indiqué dans Maintenance de Tableau.

L’extensibilité et le rendement dépendent fortement des systèmes externes, comme les sources de données, le volume de données et la vitesse du réseau, les charges de travail des utilisateurs et la conception des classeurs, qui peuvent changer rapidement à mesure que les déploiements progressent. Par exemple, en supposant une configuration matérielle de bonne taille pour le déploiement initial, l’intégration d’utilisateurs imprévus, l’utilisation non surveillée, les classeurs inefficaces, la conception d’extraction de données sous-optimale, et les horaires d’actualisation aux heures de pointe peuvent avoir un impact majeur sur les performances du serveur et l’expérience utilisateur, ce qui entraîne une dégradation des performances par rapport à l’effet cumulatif d’incidents séparés. Pour en savoir plus, consultez le document technique sur l’extensibilité de Tableau Server.

Lorsque vous déployez Tableau Server dans le nuage, vous pouvez tirer parti des fonctionnalités d’extensibilité de la plateforme, comme la topologie dynamique. En redémarrant simplement le serveur, vous pouvez également changer les machines sous-jacentes du serveur, tant que leur adresse IP publique reste la même.

Pour les déploiements à nœud unique, vous pouvez également désactiver des machines Tableau Server pendant les périodes d’indisponibilité, pour réduire les coûts. Si vous faites cela avec un groupement à plusieurs nœuds, Tableau passera en état dégradé. Vous pouvez néanmoins utiliser la topologie dynamique pour ajuster l’allocation des ressources de Tableau Server, et ainsi adapter l’équilibre entre coûts des machines et besoins en capacité. La fonctionnalité de mise à l’échelle automatique qui permet de retirer ou d’instancier les machines en fonction de la demande n’est pas prise en charge.

Environnements de serveurs

En plus de votre environnement de production, Tableau recommande un environnement de test pour les mises à niveau de test et les changements de topologie des serveurs. Votre environnement de production prendra en charge l’analytique moderne à l’aide de projets de production et de bac de sable avec des processus de validation, de promotion et de certification du contenu, le tout dans un seul environnement. Pour en savoir plus sur ces processus de gestion de contenu, consultez l’article sur La gouvernance dans Tableau. Les environnements de production et de test doivent avoir des spécifications matérielles, une topologie de serveur et une configuration identiques. Cela permettra aux administrateurs de tester les mises à niveau et de participer aux programmes bêta dans l’environnement de test en restaurant le contenu de production.

Certaines organisations ont des stratégies informatiques qui nécessitent trois environnements – Développement, AQ et Production – afin d’isoler les cas d’utilisation pour le développement, la mise à l’essai et la consommation de contenu dans des installations Tableau Server distinctes. S’il s’agit d’une exigence de votre organisation, chacun des trois environnements doit faire l’objet d’une licence distincte, car ils seraient considérés comme trois environnements de production tels que définis dans le contrat de licence d’utilisateur final de Tableau. Les environnements de production et d’assurance de la qualité doivent avoir des spécifications, une topologie de serveur et une configuration identiques. Si vous devez exécuter trois environnements distincts, essayez de ne pas reproduire un cycle de développement en cascade traditionnel avec une plateforme d’analyse moderne. Les utilisateurs peuvent privilégier l’environnement d’assurance de la qualité pour contourner des stratégies strictes ou éviter des retards de mise en production du contenu, alors travaillez à atteindre un bon équilibre en automatisant la migration de contenu vers le serveur de production avec l’outil Content Migration Tool dans le module Tableau Advanced Management ou des scripts de flux de travail personnalisés à l’aide des API REST de Tableau. L’environnement de développement n’a pas besoin d’avoir des spécifications matérielles identiques à celles des environnements de production et d’assurance qualité, sauf si l’environnement de développement est utilisé pour les tests de mise à niveau ou la participation à des programmes bêta.

Haute disponibilité

Vous devez installer et configurer Tableau en fonction de vos besoins de disponibilité et ajouter des nœuds supplémentaires pour la capacité et/ou la haute disponibilité (Windows | Linux). Pour prendre en charge les cas d’utilisation critiques, vous devez déployer une configuration de groupement haute disponibilité (HA) avec un répartiteur de charge externe (Windows | Linux).

Une installation HA de Tableau Server comporte au moins trois nœuds et plusieurs instances redondantes de processus clés (dépôt, stockage de fichiers/moteur de données et service de coordination) sur différents nœuds. L’objectif est de réduire au minimum les temps d’arrêt du système en éliminant les points de défaillance uniques et en permettant la détection des défaillances avec basculement si possible. Pour en savoir plus, consultez le document technique sur la haute disponibilité de Tableau Server.

Suivez le schéma ci-dessous pour construire votre groupement HA :

1. Installer le nœud initial et permettre à l’installateur intelligent soucieux de l’architecture de configurer les processus (Windows | Linux). Le référentiel actif se trouve sur le nœud 1.
2. Répliquer la configuration du processus à d’autres nœuds VizQL, en assurant la redondance (Windows | Linux). Le référentiel passif se trouve sur le nœud 2. Les processus du nœud 3 refléteront les nœuds 1 et 2, sauf qu’il n’y aura pas de processus de référentiel.
3. Ajouter l’ensemble des services de coordination et le service de fichiers client (Windows | Linux).
4. Ajoutez l’équilibreur de charge externe (Windows | Linux).
   

Déploiement d’un HA Tableau Server à 3 nœuds (Remarque : Le Service de coordination et le Service des dossiers client ne sont pas explicitement indiqués)

Le besoin de nœuds spécialisés évolue avec le temps. Les charges de travail d'actualisation d’extraits lourdes et fréquentes devraient être isolées de la charge de travail interactive de rendu de la visualisation. Dans un environnement exigeant en extraits, la plupart des sources de données sont des extraits. Le fait d’avoir quelques extraits extrêmement volumineux pourrait placer votre déploiement dans cette catégorie, tout comme le fait d’avoir beaucoup de petits extraits. Les déploiements où les extraits sont fréquemment actualisés, comme plusieurs fois par jour pendant les heures d’ouverture, devraient être isolés sur des nœuds spécialisés du gestionnaire de processus en arrière-plan. Pour isoler la charge de travail du processus du gestionnaire de processus en arrière-plan, ajouter des nœuds spécialisés du gestionnaire de processus en arrière-plan, assurant la redondance, comme le montrent les nœuds 4 et 5 ci-dessous. En utilisant les rôles de nœuds, vous pouvez configurer l’emplacement où certains types de charges de travail sont traités dans votre installation Tableau Server. Les fonctions de rôles de nœuds vous permettent de dédier et d’adapter les ressources à des charges de travail spécifiques. Pour plus d’information sur la configuration des rôles de nœud pour le gestionnaire de processus en arrière-plan et le stockage de fichiers, consultez l’article sur la Gestion de la charge de travail à travers les rôles de nœud.

Déploiement d’un HA Tableau Server à 5 nœuds (Remarque : Le Service de coordination et le Service des dossiers client ne sont pas explicitement indiqués)

Depuis la version 2019.3, vous pouvez déployer le référentiel Tableau Server sur le service de base de données relationnelle Amazon (RDS). Le référentiel Tableau Server est une base de données PostgreSQL qui stocke des données sur l’ensemble des interactions utilisateur, des actualisations d’extraits et autre. Amazon RDS offre des fonctions intégrées d’extensibilité, de fiabilité, de haute disponibilité et de sécurité pour PostgreSQL. En vous intégrant à AWS pour configurer le référentiel externe Tableau Server, vous pourrez profiter de ces avantages supplémentaires du déploiement du nuage. Pour plus d’informations, consultez Référentiel externe Tableau Server.

Lorsque vous déployez Tableau Server dans un nuage public, vous avez différentes options pour limiter encore davantage le risque de périodes d’indisponibilité. Vous pouvez, par exemple, déployer chaque nœud de Tableau Server dans son propre réseau virtuel ou dans différentes zones de disponibilités. Néanmoins, en fractionnant votre système, vous risquez d’augmenter la latence entre les différentes parties. Avant de finaliser votre environnement, testez les performances et la disponibilité pour garantir un équilibre adéquat pour votre communauté de données. Tableau Server ne prend pas en charge le déploiement d’un groupement à plusieurs nœuds dans des régions différentes.

Reprise après sinistre

Lors de la planification de la reprise après sinistre (DR) dans votre environnement Tableau, deux facteurs principaux doivent être pris en compte : Objectif de temps de reprise (OTR) et objectif de point de rétablissement (OPR). L’OTR est une mesure du temps d’arrêt que votre entreprise peut accepter avant une reprise complète, et il influence la fréquence à laquelle vous restaurez vos sauvegardes dans un groupement alternatif et le montant de l’investissement dans l’infrastructure. L’OPR, une mesure de la perte de données que votre entreprise peut tolérer, influence la fréquence à laquelle vous devrez effectuer des sauvegardes de votre système. Pour Tableau Server, le RPO ne peut pas être plus court que la durée nécessaire à une sauvegarde complète du serveur. Le tableau ci-dessous illustre comment planifier une gamme d’exigences de RTO :

Que vous hébergiez Tableau Server sur site ou dans le nuage, le processus de sauvegarde reste le même. Utilisez la commande TSM Backup pour générer une sauvegarde de Tableau Server et restaurez cette sauvegarde sur une nouvelle machine. La génération d’un instantané d’une machine Tableau Server en vue d’une restauration sur une nouvelle machine n’est pas prise en charge. Consultez la page Fiabilité exceptionnelle pour en savoir plus sur la haute disponibilité et la reprise après sinistre et pour lire des documents techniques sur le sujet.