Guide de déploiement de Tableau Server en entreprise

L’image suivante montre les processus Tableau Server pertinents et leur déploiement dans l’architecture de référence. Ce déploiement est considéré comme le déploiement Tableau Server minimal adapté à l’entreprise.

Les schémas de processus du serveur de cette rubrique sont destinés à montrer les principaux processus du serveur qui définissent chaque nœud. De nombreux processus du serveur sont pris en charge et s’exécutent également sur des nœuds qui n’apparaissent pas dans les schémas. Pour une liste de tous les processus, consultez la section de configuration du présent 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 groupement 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 groupement. Dans le contexte de l’entreprise, le nœud initial de Tableau Server est le nœud principal du groupement. 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’information 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 d’AWS décrite dans ce guide explique comment déployer le référentiel externe sur PostgreSQL exécuté sur une instance EC2.

• Facultatif : si votre entreprise utilise un stockage externe, vous pouvez déployer le stockage de fichiers externe Tableau en tant que service externe. Ce guide n’inclut pas le stockage de fichiers externe dans le scénario de déploiement principal. Consultez Installer Tableau Server avec un stockage 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, le gestionnaire de processus en arrière-plan 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 de licence, d’activation et de contrôleur TSM sont essentiels à la santé 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 : « Serveur d’applications » est un terme qui fait également référence à un processus du serveur 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 central sur les serveurs d’applications, est fortement lié à l’unité centrale de traitement et à la mémoire. VizQL utilise près de 60 à 70 % de l’unité centrale de traitement et de la mémoire de l’ordinateur personnel. Pour cette raison, l’architecture de référence est conçue de sorte qu’aucun autre processus du serveur lié à la mémoire ou à l’unité centrale de traitement 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 l’utilisation de la mémoire ou de l’unité centrale de traitement sur les nœuds VizQL. Par exemple, la réduction du nombre d’utilisateurs simultanés dans notre test de charge n’affecte que les performances du tableau de bord ou le processus de chargement des visualisations, mais ne réduit pas l’utilisation des ressources. Par conséquent, en fonction de la mémoire et de l’unité centrale de traitement disponibles lors des pics d’utilisation, vous pouvez envisager d’ajouter des processus du serveur VizQL supplémentaires. Comme point de départ pour des classeurs typiques, affectez 4 cœurs par processus du serveur 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 stockage de fichiers, du moteur de données (Hyper) et du gestionnaire de processus en arrière-plan sont co-localisés sur les Nœuds 3 et 4 pour les raisons suivantes :

• Optimisation des extraits : l’exécution du gestionnaire de processus en arrière-plan, d’Hyper et du stockage de fichiers sur le même nœud optimise les performances et la fiabilité. Pendant le processus d’extraction, le gestionnaire de processus en arrière-plan interroge la base de données cible, crée le fichier Hyper sur le même nœud, puis le téléverse dans le stockage de fichiers. En co-localisant ces processus du serveur, la routine de création d’extrait ne nécessite pas la copie de flux de données sur le réseau ou les nœuds.
• Équilibrage des ressources complémentaire : le gestionnaire de processus en arrière-plan exige principalement des ressources processeur. Le moteur de données est un processus qui exige beaucoup de mémoire. Le couplage de ces processus du serveur 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. À mesure que vos tâches d’extraction augmentent, ajoutez des serveurs de données supplémentaires sans le service de stockage de fichiers. Généralement, 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 stockage 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.