Guide de déploiement de Tableau Server en entreprise

L’image suivante montre les processus Tableau Server pertinents et la manière dont ils sont déployés dans l’architecture de référence. Ce déploiement est considéré comme le déploiement Tableau Server minimal adapté à l’entreprise.

Les diagrammes de processus présentés dans cette rubrique sont destinés à montrer les principaux processus de définition de chaque nœud. Il existe de nombreux processus de prise en charge qui s’exécutent également sur des nœuds non affichés dans les diagrammes. Pour une liste de tous les processus, consultez la section de configuration de ce guide, Partie 4 - Installer et configurer Tableau Server.

Processus Tableau Server

L’architecture de référence de Tableau Server est un déploiement de cluster Tableau Server à quatre nœuds avec référentiel externe sur PostgreSQL :

• Nœud initial de Tableau Server (Nœud 1) : exécute les services d’administration et de licence TSM requis qui ne peuvent être exécutés que sur un seul nœud du cluster. Dans le contexte de l’entreprise, le nœud initial de Tableau Server est le nœud principal du cluster. Ce nœud exécute également des services d’application redondants avec le Nœud 2.
• Nœuds d’application Tableau Server (Nœud 1 et Nœud 2) : les deux nœuds traitent les demandes des clients, se connectent aux sources de données et les interrogent, et se connectent aux nœuds de données.
• Nœuds de données Tableau Server (Nœud 3 et Nœud 4) : deux nœuds dédiés à la gestion des données.
• PostgreSQL externe : cet hôte exécute le processus de référentiel Tableau Server. Pour un déploiement haute disponibilité, vous devez exécuter un hôte PostgreSQL supplémentaire pour la redondance active/passive.

  Vous pouvez également exécuter PostgreSQL sur Amazon RDS. Pour plus d’informations sur les différences entre exécuter le référentiel sur une instance RDS plutôt que sur une instance EC2, consultez Référentiel externe Tableau Server (Linux(Le lien s’ouvre dans une nouvelle fenêtre)).

  Le déploiement de Tableau Server avec un référentiel externe nécessite une licence Tableau Advanced Management.

  Si votre entreprise ne dispose pas d’une expertise interne en matière d’administration de bases de données, vous pouvez éventuellement exécuter le processus de référentiel Tableau Server dans la configuration PostgreSQL interne par défaut. Dans le scénario par défaut, le référentiel est exécuté sur un nœud Tableau avec PostgreSQL intégré. Dans ce cas, nous vous recommandons d’exécuter le référentiel sur un nœud Tableau dédié et un référentiel passif sur un nœud dédié supplémentaire pour prendre en charge le basculement du référentiel. Voir Basculement du référentiel (Linux(Le lien s’ouvre dans une nouvelle fenêtre)).

  À titre d’exemple, l’implémentation AWS décrite dans ce guide explique comment déployer le référentiel externe sur PostgreSQL s’exécutant sur une instance EC2.

• Facultatif : si votre entreprise utilise un stockage externe, vous pouvez déployer le répertoire de fichiers externe Tableau en tant que service externe. Ce guide n’inclut pas le répertoire de fichiers externe dans le scénario de déploiement principal. Consultez Installer Tableau Server avec un répertoire de fichiers externe (Linux(Le lien s’ouvre dans une nouvelle fenêtre)).

  Le déploiement de Tableau Server avec un magasin de fichiers externe nécessite une licence Tableau Advanced Management.

Référentiel PostgresSQL

Le référentiel Tableau Server est une base de données PostgresSQL qui stocke les données de serveur. Ces données comprennent des informations sur les utilisateurs, les groupes, les affectations de groupes, les autorisations, les projets, les sources de données, les métadonnées d’extraits et les informations d’actualisation Tableau Server.

Le déploiement PostgresSQL par défaut consomme près de 50 % des ressources de mémoire système. Selon son utilisation (pour la production et les grands déploiements de production), la consommation des ressources peut augmenter. Pour cette raison, nous vous recommandons d’exécuter le processus de référentiel sur un ordinateur qui n’exécute pas d’autre composant serveur exigeant beaucoup de ressources tel que VizQL, Backgrounder ou le moteur de données. L’exécution du processus de référentiel avec l’un de ces composants créera des conflits d’E/S, des contraintes de ressources et dégradera les performances globales du déploiement.

Nœud 1 : Nœud initial

Le nœud initial exécute un petit nombre de processus importants et partage la charge des applications avec le Nœud 2.

Le premier ordinateur sur lequel vous installez Tableau, le « nœud initial », présente certaines caractéristiques uniques. Trois processus s’exécutent uniquement sur le nœud initial et ne peuvent pas être déplacés vers un autre nœud, sauf en situation d’échec : le service de licences (Gestionnaire de licences), le service d’activation et le contrôleur TSM (contrôleur d’administration).

Basculement du Nœud 1 et restauration automatisée

Les services Licence, Activation et Contrôleur TSM sont essentiels à l’intégrité d’un déploiement Tableau Server. En cas de défaillance du Nœud 1, les utilisateurs pourront toujours se connecter au déploiement de Tableau Server, car une architecture de référence correctement configurée acheminera les demandes vers le Nœud 2. Cependant, sans ces services de base, le déploiement sera dans un état critique d’échec imminent. Consultez Récupération automatisée du nœud initial.

Nœuds 1 et 2 : Serveurs d’applications

Les Nœuds 1 et 2 exécutent les processus Tableau Server qui traitent les demandes des clients, interrogent les sources de données, génèrent des visualisations, gèrent le contenu et l’administration, et exécutent la logique métier principale de Tableau. Les serveurs d’applications ne stockent pas de données utilisateur.

Remarque : Le terme « Serveur d’applications » fait également référence à un processus Tableau Server répertorié dans TSM. Le processus sous-jacent pour le « Serveur d’applications » est VizPortal.

Exécutés en parallèle, les Nœuds 1 et 2 s’adaptent aux demandes de service de la logique d’équilibrage de charge exécutée sur les serveurs proxy inverses. En tant que nœuds redondants, si l’un de ces nœuds échoue, les demandes des clients et la maintenance sont gérées par le nœud restant.

L’architecture de référence a été conçue pour que les processus d’applications supplémentaires s’exécutent sur le même ordinateur. Cela signifie que les processus ne sont pas en concurrence pour les ressources informatiques et ne créent pas de conflits.

Par exemple, VizQL, un service de traitement de cœurs sur les serveurs d’applications, est étroitement lié au processeur et à la mémoire et utilise près de 60-70 % du processeur et de la mémoire de l’ordinateur. Pour cette raison, l’architecture de référence est conçue de manière à ce qu’aucun autre processus lié à la mémoire ou au processeur ne se trouve sur le même nœud que VizQL. Les tests montrent que la quantité de charge ou le nombre d’utilisateurs n’affecte pas la mémoire ou l’utilisation du processeur sur les nœuds VizQL. Par exemple, la réduction du nombre d’utilisateurs simultanés dans notre test de charge affecte uniquement les performances du tableau de bord ou le processus de chargement de visualisation, mais ne réduit pas l’utilisation des ressources. Par conséquent, en fonction de la mémoire et du processeur disponibles lors des pics d’utilisation, vous pouvez envisager d’ajouter d’autres processus VizQL. Comme point de départ pour des classeurs standard, allouez 4 cœurs par processus VizQL.

Mise à l’échelle des serveurs d’applications

L’architecture de référence est conçue pour une échelle basée sur un modèle basé sur l’utilisation. Comme point de départ général, nous recommandons un minimum de deux serveurs d’applications, chacun prenant en charge jusqu’à 1000 utilisateurs. Au fur et à mesure que la base d’utilisateurs augmente, prévoyez d’ajouter un serveur d’applications pour chaque 1000 utilisateurs supplémentaires. Surveillez l’utilisation et les performances pour ajuster la base d’utilisateurs par hôte pour votre entreprise.

Nœuds 3 et 4 : Serveurs de données

Les processus du répertoire de fichiers, du moteur de données (Hyper) et du Backgrounder sont co-localisés sur les Nœuds 3 et 4 pour les raisons suivantes :

• Optimisation des extraits : l’exécution de Backgrounder, de Hyper et du répertoire de fichiers sur le même nœud optimise les performances et la fiabilité. Pendant le processus d’extraction, le Backgrounder interroge la base de données cible, crée le fichier Hyper sur le même nœud, puis le télécharge dans le répertoire de fichiers. En co-localisant ces processus sur le même nœud, le workflow de création d’extrait ne nécessite pas la copie de quantités de données sur le réseau ou les nœuds.
• Équilibrage des ressources complémentaire : le Backgrounder exige principalement des ressources processeur. Le moteur de données est un processus qui exige beaucoup de mémoire. Le couplage de ces processus permet une utilisation maximale des ressources sur chaque nœud.
• Consolidation des processus de données : chacun de ces processus étant des processus de données back-end, il est logique de les exécuter dans le niveau de données le plus sécurisé. Dans les futures versions de l’architecture de référence, les serveurs d’applications et les serveurs de données fonctionneront dans des niveaux distincts. Cependant, en raison des dépendances des applications dans l’architecture Tableau, les serveurs d’applications et de données doivent s’exécuter dans le même niveau à ce moment-là.

Mise à l’échelle des serveurs de données

Comme pour les serveurs d’applications, la planification des ressources requises pour les serveurs de données Tableau nécessite une modélisation basée sur l’utilisation. En général, partez de l’hypothèse que chaque serveur de données peut prendre en charge jusqu’à 2000 travaux d’actualisation d’extrait par jour. Au fur et à mesure que vos travaux d’extraction augmentent, ajoutez des serveurs de données supplémentaires sans le service Répertoire de fichiers. En règle générale, le déploiement du serveur de données à deux nœuds convient aux déploiements qui utilisent le système de fichiers local pour le service Répertoire de fichiers. Notez que l’ajout de serveurs d’applications supplémentaires n’a pas d’impact linéaire sur les performances ou l’évolutivité des serveurs de données. En fait, à l’exception d’une surcharge due aux requêtes utilisateur supplémentaires, l’impact de l’ajout d’hôtes d’application et d’utilisateurs supplémentaires est minime.