Aide de Tableau Blueprint

Remarque : cette rubrique s'applique uniquement à Tableau Server.

Tableau Server peut être installé sur site avec des machines physiques ou virtuelles ou dans le cloud, et prend en charge les systèmes d'exploitation Windows et Linux. Pour déterminer quelle plate-forme matérielle utiliser et quelle taille définir, tenez compte des éléments suivants : votre environnement, les sources de données et la gestion nécessaire pour proposer un accès en libre-service, la charge potentielle générée par tous les utilisateurs, et l'utilisation effective des données. Si c'est la première fois que vous déployez Tableau Server, vous devez vous focaliser sur les normes de votre environnement et les sources de données. Pour les déploiements existants, vous devez analyser les données de Tableau Server pour évaluer la charge et l'utilisation, en plus de tenir compte de l'environnement et des sources de données.

Configuration matérielle requise

Quel que soit le type de déploiement que vous choisissez pour Tableau Server, vous devez impérativement déterminer une taille adaptée pour votre matériel. Votre planification doit s'aligner sur les besoins métier en constante évolution, en évaluant l'utilisation du serveur et l'engagement des utilisateurs, en ajustant la taille et en modifiant la topologie plus fréquemment que les autres applications logicielles. Consultez la page correspondant à la plate-forme matérielle adaptée aux normes de votre environnement :

• 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 cloud, 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 nécessaire à vos besoins. Pour un exemple de la manière d'effectuer un tel test, consultez le livre blanc 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 cloud.

Dimensionnement initial

L'équipe chargée de votre compte Tableau se tient à votre disposition pour évaluer vos besoins et la taille de déploiement nécessaire. Pour un déploiement initial, vous devez partir sur une estimation de 600 à 800 utilisateurs Explorer par nœud de 8 cœurs, avec 10 % d'utilisateurs actifs (requêtes d'interaction simultanées envoyées vers Tableau Server, incluant l'utilisation de tableaux de bord sur ordinateur portable ou appareil mobile, la création Web, la connexion et l'interrogation de sources de données publiées). Il ne s'agit là que d'un point de départ et non d'une règle absolue. Pour la mémoire, prévoyez 8 Go de RAM par cœur pour un serveur de production. Pour les clusters de moins de 40 cœurs, utilisez des nœuds de 8 cœurs, et pour les clusters de plus de 40 cœurs, des nœuds de 16 cœurs. La charge relative pour chaque type de licence doit être prise en compte dans le dimensionnement du matériel. En partant du principe qu'un utilisateur Explorer compte pour 1 utilisateur, un utilisateur Creator représente une charge relative de 2,4 utilisateurs, alors qu'un utilisateur Viewer ne représente qu'une charge relative de 0,75 utilisateur. En utilisant ces coefficients, vous pouvez estimer la capacité du cluster. Le tableau suivant présente des exemples de charges équivalentes sur chaque ligne :

La charge 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, ou encore la consultation et l'interaction avec le contenu. À mesure que les utilisateurs sont intégrés et qu'ils commencent à créer et à utiliser du contenu, vous devez surveiller l'utilisation du matériel et du contenu pour prendre des décisions éclairées concernant la taille du serveur, grâce aux données des outils de surveillance du matériel et au référentiel de Tableau Server. Pour en savoir plus, consultez les rubriques Surveillance Tableau et Mesure de l'engagement et de l'adoption des utilisateurs Tableau.

Évolutivité

Pour les nouveaux déploiements comme pour les déploiements existants, l'objectif est de mettre en place de manière proactive une disponibilité, des capacités et un espace suffisants, tout en réduisant au minimum les conflits de ressources. À l'instar d'autres plates-formes d'entreprise, l'évolutivité verticale de Tableau Server passe par l'ajout de processeurs, de mémoire et/ou de capacité de disque, et son évolutivité horizontale par l'ajout de nœuds à un cluster. Tableau Server propose une évolutivité presque linéaire, grâce à l'ajout de ressources matérielles, en fonction de votre environnement, de vos données, de votre charge et de votre utilisation. Vous devez régulièrement effectuer un test de montée en charge et une planification de la capacité, comme prévu dans la rubrique Maintenance de Tableau.

La scalabilité et les performances dépendent fortement des systèmes externes, comme les sources de données, le volume de données, la vitesse du réseau, les charges utilisateur et la conception des classeurs, qui peuvent changer radicalement à mesure que le déploiement évolue. Supposons que nous disposions d'une configuration matérielle correctement dimensionnée pour le déploiement initial. Plusieurs facteurs peuvent venir affecter les performances du serveur et des utilisateurs, notamment l'intégration non planifiée d'utilisateurs, l'utilisation non contrôlée du système, les classeurs inefficaces, la conception d'extraits de données peu optimisée et les actualisations aux heures de pointe peuvent. Le cumul de ces facteurs entraîne une dégradation des performances. Pour en savoir plus, consultez le livre blanc sur l'évolutivité de Tableau Server.

Lorsque vous déployez Tableau Server dans le cloud, vous pouvez tirer parti des fonctionnalités d'évolutivité de la plate-forme, 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 cluster à 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 serveur

En plus de l'environnement de production, Tableau recommande d'utiliser un environnement de test pour tester les mises à niveau et les modifications de topologie du serveur. Votre environnement de production devra à lui seul prendre en charge une analytique moderne composée de projets de production et sandbox, contenant chacun des processus de validation, de promotion et de certification de contenu. Pour en savoir plus sur ces processus de gestion du contenu, consultez la rubrique La gouvernance dans Tableau. Les environnements de production et de test doivent disposer des mêmes caractéristiques matérielles, de la même topologie et de la même configuration. Ainsi, les administrateurs peuvent tester les mises à niveau et participer aux programmes bêta dans l'environnement de test en restaurant le contenu de production.

Certaines entreprises disposent de politiques IT imposant que les trois environnements (développement, assurance qualité et production) isolent les cas d'utilisation pour le développement, le test et l'utilisation de contenu sur trois installations Tableau Server distinctes. Si c'est le cas pour votre entreprise, chacun des trois environnements doit disposer d'une licence distincte, car il s'agit de trois environnements de production aux yeux du contrat de licence de l'utilisateur final Tableau. Les environnements de production et d'assurance qualité doivent disposer des mêmes caractéristiques matérielles, de la même topologie et de la même configuration. Si vous devez utiliser trois environnements distincts, évitez de mettre en place un cycle de développement en cascade traditionnel sur une plate-forme analytique moderne. Les utilisateurs peuvent préférer un environnement d'assurance qualité (pour contourner des politiques strictes ou éviter les retards de mise en production du contenu), et vous devez trouver un bon équilibre en automatisant la migration de contenu vers le serveur de production avec l'outil Content Migration Tool disponible dans Tableau Advanced Management , ou des scripts personnalisés utilisant les API REST Tableau. L'environnement de développement n'a pas besoin de disposer de la même configuration que les environnements de production et d'assurance qualité, à moins qu'il ne soit utilisé pour tester les mises à niveau ou participer aux programmes bêta.

Haute disponibilité

Vous devez installer et configurer Tableau en fonction de vos besoins en matière 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 cluster haute disponibilité (HA) avec un équilibreur de charge externe (Windows | Linux).

Une installation HA de Tableau Server dispose d'au moins trois nœuds et de plusieurs instances redondantes de processus clés (référentiel, répertoire de fichiers/moteur de données et service de coordination) sur des nœuds différents. L'objectif est de réduire au minimum les périodes d'indisponibilité en éliminant chaque point de défaillance, en les détectant avec un basculement lorsque c'est possible. Pour en savoir plus, consultez le livre blanc sur la haute disponibilité de Tableau Server.

Suivez le modèle ci-dessous pour créer votre cluster HA :

1. Installez le nœud initial et laissez le programme d'installation intelligent tenant compte de l'architecture configurer les processus (Windows | Linux). Le référentiel actif réside sur le nœud 1.
2. Reproduisez la configuration de processus sur les autres nœuds VizQL, pour garantir la redondance (Windows | Linux). Le référentiel passif se trouve sur le nœud 2. Les processus du nœud 3 reproduisent ceux des nœuds 1 et 2, mais le nœud 3 ne comporte 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).
   

Un déploiement HA de Tableau Server à 3 nœuds (Remarque : le service de coordination et le service de fichiers client ne sont pas explicitement affichés)

Les besoins en matière de nœuds spécialisés évoluent avec le temps. Les charges avec beaucoup d'extraits ou avec des actualisations d'extraits fréquentes doivent être isolées du reste des charges de rendu de visualisations interactives. Dans un environnement avec beaucoup d'extraits, la plupart des sources de données sont des extraits. Par « beaucoup d'extraits », on sous-entend le fait d'avoir quelques extraits très volumineux ou de disposer d'un très grand nombre d'extraits de petite taille. Les déploiements dans lesquels les extraits sont fréquemment actualisés, par exemple plusieurs fois par jour pendant les heures de service, doivent être isolés sur des nœuds backgrounder spécialisés. Pour isoler la charge du processus backgrounder, ajoutez des nœuds backgrounder spécialisés pour garantir la redondance, comme indiqué dans les nœuds 4 et 5 ci-dessous. À l'aide de rôles de nœuds, vous pouvez déterminer l'endroit où certains types de charges seront traités dans votre installation de 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 en savoir plus sur la configuration de rôles de nœud dans backgrounder et dans le répertoire de fichiers, consultez la rubrique Gestion de la charge de travail via les rôles des nœuds.

Un déploiement HA de Tableau Server à 5 nœuds (Remarque : le service de coordination et le service de fichiers client ne sont pas explicitement affichés)

À partir de Tableau 2019.3, vous pouvez déployer le référentiel Tableau Server vers Amazon Relational Database Service (RDS). Le référentiel Tableau Server est une base de données PostgreSQL qui stocke des données sur toutes les interactions des utilisateurs, les actualisations d'extraits et bien d'autres opérations. Amazon RDS offre scalabilité, fiabilité, haute disponibilité et sécurité de manière intégrée à PostgreSQL. Grâce à l'intégration avec AWS pour configurer le référentiel externe Tableau Server, vous pourrez profiter des avantages supplémentaires du déploiement du cloud. Pour plus d’informations, consultez Référentiel externe Tableau Server.

Lorsque vous déployez Tableau Server dans un cloud public, vous avez différentes options pour limiter encore plus 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 vos données et votre communauté. Tableau Server ne prend pas en charge le déploiement d'un cluster à plusieurs nœuds dans des régions différentes.

Reprise après sinistre

Lorsque vous planifiez la reprise après sinistre (DR) dans votre environnement Tableau, vous devez tenir compte de deux facteurs : l'objectif de délai de récupération (RTO) et l'objectif de point de récupération (RPO). Le RTO est une mesure de la durée de la période d'indisponibilité que votre entreprise peut accepter avant une récupération totale, et influence la fréquence à laquelle vous restaurez vos sauvegardes sur un autre cluster et le volume des investissements dans l'infrastructure. Le RPO est une mesure du volume de perte de données que votre entreprise peut tolérer, et influence la fréquence à laquelle vous devez 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 indique comment adapter votre planification en fonction de différents besoins en RTO :

Que vous hébergiez Tableau Server sur site ou dans le cloud, 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 lire des livres blancs sur le sujet.