Guide de déploiement de Tableau Server en entreprise

Le niveau Web de l’architecture de référence doit inclure les composants suivants :

• Un équilibreur de charge d’application Web qui accepte les requêtes HTTPS des clients Tableau et communique avec les serveurs proxy inverses.
• Serveur proxy inverse : 
  • Nous vous recommandons de déployer la passerelle indépendante de Tableau Server.
  • Nous recommandons un minimum de deux serveurs proxy pour la redondance et pour gérer la charge client.
  • Reçoit le trafic HTTPS de l’équilibreur de charge.
  • Prend en charge la session persistante vers l’hôte Tableau.
  • Configurez le proxy pour l’équilibrage de charge à tour de rôle sur chaque Tableau Server exécutant le processus de passerelle.
  • Gère les demandes d’authentification du fournisseur d’identités externe.
• Proxy de transfert : Tableau Server a besoin d’un accès à Internet pour les licences et les fonctionnalités de carte. Vous devez configurer des listes d’autorisations de proxy de transfert pour les URL de service Tableau. Voir Communication avec Internet (Linux(Le lien s’ouvre dans une nouvelle fenêtre)).
• Tout le trafic lié au client peut être chiffré via https:
  • Équilibreur de charge de client vers application
  • Équilibreur de charge d’application vers serveurs proxy inverses
  • Serveur proxy vers Tableau Server
  • Gestionnaire d’authentification s’exécutant sur le proxy inverse vers le fournisseur d’identités
  • Tableau Server vers le fournisseur d’identités

Passerelle indépendante Tableau Server

Tableau Server version 2022.1 a introduit la passerelle indépendante Tableau Server. La passerelle indépendante est une instance autonome du processus du serveur Tableau Gateway qui agit comme un serveur proxy inverse compatible avec Tableau.

La passerelle indépendante prend en charge l’équilibrage de charge circulaire simple vers les serveurs Tableau Server principaux. Cependant, la passerelle indépendante n’est pas destiné à servir d’équilibreur de charge d’application d’entreprise. Nous vous recommandons d’exécuter la passerelle indépendante derrière un équilibreur de charge d’application d’entreprise.

La passerelle indépendante nécessite une licence de Advanced Management.

Authentification et autorisation

L’architecture de référence par défaut spécifie l’installation de Tableau Server en configurant l’authentification au niveau local. Dans ce modèle, les clients doivent se connecter à Tableau Server de manière à être authentifiés par le processus d’authentification local natif de Tableau Server. Nous vous déconseillons d’utiliser cette méthode d’authentification dans l’architecture de référence, car le scénario exige que des clients non authentifiés communiquent avec le niveau Application, ce qui constitue un risque pour la sécurité.

Nous vous recommandons plutôt de configurer un fournisseur d’identités externe de niveau entreprise couplé à un module AuthN de manière à pré-authentifier tout le trafic vers le niveau Application. Lorsqu’il est configuré avec un fournisseur d’identités externe, le processus d’authentification local natif de Tableau Server n’est pas utilisé. Tableau Server autorise l’accès aux ressources du déploiement une fois que le fournisseur d’identités a authentifié les utilisateurs.

Pré-authentification avec un module AuthN

Dans l’exemple documenté dans ce guide, l’authentification unique SAML est configurée, mais le processus de pré-authentification peut être configuré avec la plupart des fournisseurs d’identités externes et un module AuthN.

Dans l’architecture de référence, le serveur proxy inverse est configuré de manière à créer une session d’authentification client avec le fournisseur d’identités avant de transmettre ces demandes par proxy à Tableau Server. Nous appelons ce processus la phase de pré-authentification. Le proxy inverse redirige vers Tableau Server uniquement les sessions cliente authentifiées. Tableau Server crée ensuite une session, vérifie l’authentification de la session avec le fournisseur d’identités, puis renvoie la demande du client.

Le schéma suivant montre la procédure étape par étape du processus de pré-authentification et d’authentification avec un module AuthN. Le proxy inverse peut être une solution tierce générique ou la passerelle indépendante de Tableau Server :

Présentation de la configuration

Cette section présente le processus de configuration du niveau Web. Vérifiez la connectivité après chaque étape :

1. Configurez deux serveurs proxy inverses pour fournir un accès HTTP à Tableau Server.
2. Configurez la logique d’équilibrage de charge avec des sessions persistantes sur les serveurs proxy pour vous connecter à chaque instance de Tableau Server exécutant le processus de passerelle.
3. Configurez l’équilibrage de charge des applications avec des sessions persistantes au niveau de la passerelle Internet pour transférer les demandes aux serveurs proxy inverses.
4. Configurez l’authentification avec un fournisseur d’identités externe. Vous pouvez configurer l’authentification SSO ou SAML en installant un gestionnaire d’authentification sur les serveurs proxy inverses. Le module AuthN gère la négociation d’authentification entre le fournisseur d’identités externe et votre déploiement Tableau. Tableau agira également en tant que fournisseur de services IdP et authentifiera les utilisateurs avec le fournisseur d’identités.
5. Pour s’authentifier avec Tableau Desktop dans ce déploiement, vos clients doivent exécuter Tableau Desktop 2021.2.1 ou une version ultérieure.

Exemple de configuration de niveau Web avec passerelle indépendante de Tableau Server

Le reste de cette rubrique présente une procédure de bout en bout qui décrit comment implémenter un niveau Web dans l’exemple d’architecture AWS de référence à l’aide de la passerelle indépendante de Tableau Server. Pour un exemple de configuration utilisant Apache comme proxy inverse, consultez Annexe - Niveau Web avec exemple de déploiement Apache.

L’exemple de configuration est composé des composants suivants :

• Équilibreur de charge d’application AWS
• Passerelle indépendante Tableau Server
• Module d’authentification Mellon
• IdP Okta
• Authentification SAML

Remarque : l’exemple de configuration de niveau Web présenté dans cette section comprend des procédures détaillées pour le déploiement de logiciels et de services tiers. Nous avons tout mis en œuvre pour vérifier et documenter les procédures permettant d’activer le scénario de niveau Web. Il peut toutefois arriver que le logiciel tiers change ou que votre scénario diffère de l’architecture de référence décrite ici. Veuillez vous référer à la documentation du fournisseur tiers pour les détails de configuration et l’assistance.

Les exemples Linux tout au long de cette section montrent des commandes pour les distributions de type RHEL. Plus précisément, les commandes présentées ici ont été développées avec la distribution Amazon Linux 2. Si vous exécutez une distribution Ubuntu, modifiez les commandes en conséquence.

Le déploiement du niveau Web dans cet exemple suit une procédure de configuration et de vérification par étapes. La configuration du niveau Web principal comprend les étapes suivantes pour activer HTTP entre Tableau et Internet. La passerelle indépendante est exécutée et configurée pour un proxy inverse/équilibrage de charge derrière l’équilibrage de charge d’application AWS :

1. Préparer l’environnement
2. Installer la passerelle indépendante
3. Configurer le serveur de passerelle indépendante
4. Configurer l’équilibreur de charge d’application AWS

Une fois que vous avez configuré le niveau Web et vérifié la connectivité avec Tableau, configurez l’authentification avec un fournisseur externe.

Préparer l’environnement

Effectuez les tâches suivantes avant de déployer la passerelle indépendante.

1. Modifications du groupe de sécurité AWS. Configurez le groupe de sécurité public pour autoriser le trafic entrant de gestion interne de la passerelle indépendante (TCP 21319) à partir du groupe de sécurité privé.

2. Installez la version 22.1.1 (ou ultérieure) sur un cluster Tableau Server à quatre nœuds comme documenté dans Partie 4 - Installer et configurer Tableau Server.

3. Configurez les deux instances EC2 du mandataire dans le groupe de sécurité publique comme indiqué dans Configurer les ordinateurs hôtes.

Installer la passerelle indépendante

La passerelle indépendante de Tableau Server nécessite une licence de Advanced Management.

Le déploiement de la passerelle indépendante de Tableau Server consiste à installer et à exécuter le package .rpm, puis à configurer l’état initial. La procédure incluse dans ce guide fournit des conseils prescriptifs pour le déploiement dans l’architecture de référence.

Si votre déploiement diffère de l’architecture de référence, consultez la documentation principale de Tableau Server, Installer Tableau Server avec une passerelle indépendante (Linux(Le lien s’ouvre dans une nouvelle fenêtre)).

Important : La configuration de la passerelle indépendante peut être un processus propice aux erreurs. Il est très difficile de résoudre les problèmes de configuration sur deux instances de serveurs de passerelle indépendante. Pour cette raison, nous vous recommandons de configurer un serveur de passerelle indépendante à la fois. Après avoir configuré le premier serveur et vérifié la fonctionnalité, vous devez ensuite configurer le deuxième serveur de passerelle indépendante.

Même si vous allez configurer chaque serveur de passerelle indépendante séparément, exécutez cette procédure d’installation sur les deux instances EC2 que vous avez installées dans le groupe de sécurité public : 

1. Exécutez la mise à jour pour appliquer les derniers correctifs au système d’exploitation Linux :

   sudo yum update

2. Si Apache a été installé, supprimez-le :

    sudo yum remove httpd

3. Copiez le package d’installation de la passerelle indépendante version 2022.1.1 (ou version ultérieure) depuis la page Téléchargement Tableau(Le lien s’ouvre dans une nouvelle fenêtre) sur l’ordinateur hôte qui exécutera Tableau Server.

   Par exemple, sur un ordinateur fonctionnant sur un système d’exploitation Linux de type RHEL, exécutez

   wget https://downloads.tableau.com/esdalt/2022<version>/tableau-server-tsig-<version>.x86_64.rpm

4. Exécutez le programme d’installation. Par exemple, sur un système d’exploitation Linux de type RHEL, exécutez :

   sudo yum install <tableau-tsig-version>.x86_64.rpm

5. Passez au répertoire /opt/tableau/tableau_tsig/packages/scripts.<version_code>/ et exécutez le script initialize-tsig qui s’y trouve. En plus de l’indicateur --accepteula, vous devez inclure la plage d’adresses IP des sous-réseaux sur lesquels le déploiement de Tableau Server est en cours d’exécution. Utilisez l’option -c pour spécifier la plage IP. L’exemple ci-dessous montre la commande avec les exemples de sous-réseaux AWS spécifiés :

   sudo ./initialize-tsig --accepteula -c "ip 10.0.30.0/24 10.0.31.0/24"

6. Une fois l’initialisation terminée, ouvrez le fichier tsighk-auth.conf et copiez le secret d’authentification dans le fichier. Vous devrez soumettre ce code pour chaque instance de passerelle indépendante dans le cadre de la configuration principale de Tableau Server :

   sudo less /var/opt/tableau/tableau_tsig/config/tsighk-auth.conf

7. Après avoir exécuté les étapes précédentes sur les deux instances de la passerelle indépendante, préparez le fichier de configuration tsig.json. Le fichier de configuration consiste en un tableau « independentGateways ». Le tableau contient des objets de configuration qui définissent chacun les détails de connexion pour une instance de passerelle indépendante.

   Copiez le JSON suivant et personnalisez-le en fonction de votre environnement de déploiement. L’exemple ici montre un fichier comme exemple d’architecture de référence AWS.

   L’exemple de fichier JSON ci-dessous inclut uniquement l’information de connexion d’une seule passerelle indépendante. Plus tard dans le processus, vous inclurez l’information de connexion du deuxième serveur de passerelle indépendante.

   Enregistrez le fichier sous tsig.json pour les procédures qui suivent.

   {
   "independentGateways": [
    {
    	"id": "ip-10-0-1-169.ec2.internal",
    	"host": "ip-10-0-1-169.ec2.internal",
    	"port": "21319",
    	"protocol" : "http",
    	"authsecret": "13660-27118-29070-25482-9518-22453"
    	}]
    }

   • "id" - Le nom DNS privé de l’instance AWS EC2 exécutant la passerelle indépendante.
   • "host"- identique à "id" .
   • "port"- Le port de maintenance, par défaut, "21319".
   • "protocol"- Le protocole pour le trafic client. Conservez http pour la configuration initiale.
   • "authsecret"- Le secret que vous avez copié à l’étape précédente.

Passerelle indépendante : connexion directe contre par relais

Avant de continuer, vous devez décider du schéma de connexion à configurer dans votre déploiement : connexion directe ou par relais. Chaque option est brièvement décrite ici, ainsi que les points de données de décision pertinents.

Connexion par relais : vous pouvez configurer la passerelle indépendante de manière à relayer la communication du client sur un seul port vers le processus de passerelle sur Tableau Server. Dans ce document, nous parlons de connexion par relais :

• Le processus par relais entraîne un saut supplémentaire de la passerelle indépendante vers le processus principal de la passerelle Tableau Server. Le saut supplémentaire dégrade les performances par rapport à la configuration de connexion directe.
• TLS est pris en charge pour le mode relais. Toutes les communications en mode relais sont limitées à un seul protocole (HTTP ou HTTPS) et peuvent donc être chiffrées et authentifiées avec TLS.

Connexion directe : la passerelle indépendante peut communiquer directement avec les processus principaux de Tableau Server sur plusieurs ports. Dans ce document, nous parlons de connexion directe :

• Étant donné que la connexion est directe à l’instance principale de Tableau Server, les performances du client sont nettement améliorées par rapport à l’option de connexion par relais.
• Nécessite l’ouverture de plus de 16 ports des sous-réseaux publics aux sous-réseaux privés pour une communication de processus directe de la passerelle indépendante aux ordinateurs Tableau Server.
• TLS n’est pas encore pris en charge sur les processus de la passerelle indépendante vers Tableau Server.

Vérification : configuration de la topologie de base

Vous devriez pouvoir accéder à la page d’administration de Tableau Server en accédant à http://<gateway-public-IP-address>.

Si la page de connexion à Tableau Server ne se charge pas, ou si Tableau Server ne démarre pas, suivez les étapes de dépannage ci-après :

Réseau : 

• Vérifiez la connectivité entre le déploiement Tableau et l’instance de la passerelle indépendante en exécutant la commande wget à partir du nœud1 Tableau Server : wget http://<internal IP address of Independent Gateway>:21319, par exemple :

   wget http://ip-10-0-1-38:21319

  Si la connexion n’est pas établie ou si elle échoue, vérifiez que le groupe de sécurité Public est configuré pour autoriser le trafic de maintenance de la passerelle indépendante (TCP 21319) provenant du groupe de sécurité Privé.

  Si le groupe de sécurité est configuré correctement, vérifiez alors que vous avez indiqué les adresses IP ou les plages d’adresses IP correctes lors du lancement de la passerelle indépendante. Vous pouvez afficher et modifier cette configuration dans le fichier environment.bash situé dans /etc/opt/tableau/tableau_tsig/environment.bash. Si vous apportez une modification à ce fichier, redémarrez le service tsig-http en suivant les étapes décrites ci-dessous.

Sur l’hôte Proxy 1 :

1. Remplacez le fichier httpd.conf par le fichier de remplacement de la passerelle indépendante :

   cp /var/opt/tableau/tableau_tsig/config/httpd.conf.stub /var/opt/tableau/tableau_tsig/config/httpd.conf

2. Redémarrez tsig-httpd comme première étape de dépannage :

   sudo su - tableau-tsig
   systemctl --user restart tsig-httpd
   exit

Sur le nœud 1 Tableau

• Revérifiez le fichier tsig.json. Si vous trouvez des erreurs, corrigez-les, puis exécutez tsm topology external-services gateway update -c tsig.json .
• Si vous exécutez une connexion directe, vérifiez que les ports TCP répertoriés dans proxy_targets.csv sont configurés en tant que ports d’entrée des groupes de sécurité Public vers Privé.

Configurer l’équilibreur de charge d’application AWS

Mettre à jour le DNS avec l’URL publique de Tableau

Utilisez le nom de zone DNS de votre domaine dans la description de l’équilibreur de charge AWS pour créer une valeur CNAME dans votre DNS. Le trafic vers votre URL (tableau.example.com) doit être envoyé au nom DNS public AWS.

Vérifier la connectivité

Une fois vos mises à jour DNS terminées, vous devriez pouvoir accéder à la page de connexion Tableau Server en saisissant votre URL publique, par exemple https://tableau.example.com.

Exemple de configuration d’authentification : SAML avec fournisseur d’identités externe

L’exemple suivant décrit comment installer et configurer SAML avec un fournisseur d’identités Okta et un module d’authentification Mellon pour un déploiement Tableau exécuté dans l’architecture de référence AWS.

Cet exemple s’inspire de la section précédente et suppose que vous configurez une passerelle indépendante à la fois.

L’exemple décrit comment configurer Tableau Server et la passerelle indépendante sur HTTP. Okta enverra la demande à l’équilibreur de charge AWS via HTTPS, mais tout le trafic interne transitera via HTTP. Lors de la configuration de ce scénario, tenez compte des protocoles HTTP et HTTPS lors de la définition des chaînes d’URL.

Cet exemple utilise Mellon comme module de fournisseur de services de pré-authentification sur les serveurs de la passerelle indépendante. Cette configuration garantit que seul le trafic authentifié se connecte à Tableau Server, qui fait également office de fournisseur de services avec le fournisseur d’identités Okta. Par conséquent, vous devez configurer deux applications de fournisseur d’identités : une pour le fournisseur de services Mellon et une pour le fournisseur de services Tableau.

Installer Mellon pour la pré-authentification

Cet exemple utilise mod_auth_mellon, module open source largement répandu. Certaines distributions Linux contiennent des versions obsolètes de mod_auth_mellon provenant d’un référentiel plus ancien. Ces versions obsolètes peuvent contenir des vulnérabilités de sécurité inconnues ou des problèmes fonctionnels. Si vous choisissez d’utiliser mod_auth_mellon, vérifiez que vous utilisez une version à jour.

Le module mod_auth_mellon est un logiciel tiers. Nous avons tout mis en œuvre pour vérifier et documenter les procédures permettant d’activer ce scénario. Il peut toutefois arriver que le logiciel tiers change ou que votre scénario diffère de l’architecture de référence décrite ici. Veuillez vous référer à la documentation du fournisseur tiers pour les détails de configuration et l’assistance.

1. Sur l’instance EC2 active qui exécute le serveur de la passerelle indépendante, installez une version courante du module d’authentification Mellon.

2. Créez le répertoire /etc/mellon :

   sudo mkdir /etc/mellon

Configurer Mellon comme module de pré-authentification

Exécutez cette procédure sur la première instance de la passerelle indépendante.

Vous devez avoir une copie du fichier pre-auth_idp_metadata.xml que vous avez créé à partir de la configuration Okta.

1. Changez de répertoire :

   cd /etc/mellon

2. Créez les métadonnées du fournisseur de services. Exécutez le script mellon_create_metadata.sh. Vous devez inclure l’ID d’entité et l’URL de retour de votre entreprise dans la commande.

   L’URL de retour est appelée URL d’authentification unique dans Okta. Le dernier élément du chemin dans l’URL de retour est appelé MellonEndpointPath dans le fichier de configuration mellon.conf présenté plus loin dans cette procédure. Dans cet exemple, nous spécifions sso comme chemin de point de terminaison.

   Par exemple :

   sudo /usr/libexec/mod_auth_mellon/mellon_create_metadata.sh https://tableau.example.com "https://tableau.example.com/sso"

   Le script renvoie le certificat du fournisseur de services, la clé et les fichiers de métadonnées.

3. Renommez les fichiers du fournisseur de services dans le répertoire mellon pour une meilleure lisibilité. Nous désignerons ces fichiers par les noms suivants dans la documentation :

   sudo mv *.key mellon.key
   sudo mv *.cert mellon.cert
   sudo mv *.xml sp_metadata.xml
   

4. Copiez le fichier pre-auth_idp_metadata.xml dans le même répertoire.

5. Modifiez la propriété et les autorisations sur tous les fichiers dans l’annuaire /etc/mellon :

   sudo chown tableau-tsig mellon.key
   sudo chown tableau-tsig mellon.cert
   sudo chown tableau-tsig sp_metadata.xml
   sudo chown tableau-tsig pre-auth_idp_metadata.xml 
   sudo chmod +r * mellon.key
   sudo chmod +r * mellon.cert
   sudo chmod +r * sp_metadata.xml
   sudo chmod +r * pre-auth_idp_metadata.xml 

6. Créez le répertoire /etc/mellon/conf.d :

   sudo mkdir /etc/mellon/conf.d

7. Créez le fichier global.conf dans le répertoire /etc/mellon/conf.d.

   Copiez le contenu du fichier comme indiqué ci-dessous, mais mettez à jourMellonCookieDomain avec votre nom de domaine racine. Par exemple, si le nom de domaine de Tableau est tableau.example.com, entrez example.com pour le domaine racine.

   <Location "/">
   AuthType Mellon
   MellonEnable auth
   Require valid-user
   MellonCookieDomain <root domain>
   MellonSPPrivateKeyFile /etc/mellon/mellon.key
   MellonSPCertFile /etc/mellon/mellon.cert
   MellonSPMetadataFile /etc/mellon/sp_metadata.xml
   MellonIdPMetadataFile /etc/mellon/pre-auth_idp_metadata.xml
   MellonEndpointPath /sso
   </Location>
   
   <Location "/tsighk">
   MellonEnable Off
   </Location>

8. Créez le fichier mellonmod.conf dans le répertoire /etc/mellon/conf.d.

   Ce fichier contient une seule directive qui spécifie l’emplacement du fichier mod_auth_mellon.so. L’emplacement dans l’exemple ici est l’emplacement par défaut du fichier. Vérifiez que le fichier se trouve à cet emplacement ou modifiez le chemin dans cette directive pour qu’il corresponde à l’emplacement réel de mod_auth_mellon.so :

   LoadModule auth_mellon_module /usr/lib64/httpd/modules/mod_auth_mellon.so

Créer une application Tableau Server dans Okta

Définir la configuration du module d’authentification sur Tableau Server

Exécutez les commandes suivantes sur le nœud 1 Tableau Server. Ces commandes indiquent les emplacements des fichiers de configuration Mellon sur l’ordinateur distant de la passerelle indépendante. Vérifiez que les chemins d’accès du fichier indiqués dans ces commandes correspondent aux chemins d’accès et à l’emplacement des fichiers sur l’ordinateur distant de la passerelle indépendante.

tsm configuration set -k gateway.tsig.authn_module_block -v "/etc/mellon/conf.d/mellonmod.conf" --force-keys
tsm configuration set -k gateway.tsig.authn_global_block -v "/etc/mellon/conf.d/global.conf" --force-keys

Pour réduire les temps d’arrêt, n’appliquez pas les modifications tant que vous n’avez pas activé SAML comme décrit dans la section suivante.

Activer SAML sur Tableau Server pour fournisseur d’identités

Redémarrez le service tsig-httpd

Au fur et à mesure que votre déploiement Tableau Server applique les modifications, reconnectez-vous à l’ordinateur de la passerelle indépendante Tableau Server et exécutez les commandes suivantes pour redémarrer le service tsig-httpd :

sudo su - tableau-tsig
systemctl --user restart tsig-httpd
exit

Valider la fonctionnalité SAML

Pour valider la fonctionnalité SAML de bout en bout, connectez-vous à Tableau Server avec l’URL publique (par exemple, https://tableau.example.com) en utilisant le compte administrateur Tableau que vous avez créé au début de cette procédure.

Si TSM ne démarre pas (« erreur liée à la passerelle ») ou si vous obtenez des erreurs liées au navigateur lors d’une tentative de connexion, consultez Résoudre les problèmes de la passerelle indépendante Tableau Server.

Configurer le module d’authentification sur la deuxième instance de la passerelle indépendante

Lorsque vous avez correctement configuré la première instance de passerelle indépendante, déployez la deuxième instance. Dans le cas présent, il s’agit du processus final d’installation du scénario AWS/Mellon/Okta décrit dans cette rubrique. La procédure suppose que vous avez déjà installé la passerelle indépendante sur la deuxième instance, comme décrit précédemment dans cette rubrique ( Installer la passerelle indépendante).

Le processus de déploiement de la deuxième passerelle indépendante nécessite de suivre les étapes ci-après :

1. Sur la deuxième instance de la passerelle indépendante : installez le module d’authentification Mellon.

   Ne configurez pas le module d’authentification Mellon comme décrit précédemment dans cette rubrique. Au lieu de cela, vous devez cloner la configuration en suivant la description des étapes suivantes.

2. Sur la (première) instance configurée de la passerelle indépendante :

   Prenez une copie du fichier tar de la configuration Mellon existante. La sauvegarde avec tar conservera toute la hiérarchie des répertoires et les autorisations. Exécutez les commandes suivantes :

   cd /etc

   sudo tar -cvf mellon.tar mellon

   Copiez le fichier mellon.tar dans la deuxième instance de la passerelle indépendante.

3. Sur la deuxième instance de passerelle indépendante :

   Extrayez (« décompressez ») le fichier tar dans la deuxième instance du répertoire /etc. Exécutez les commandes suivantes :

   cd /etc

   sudo tar -xvf mellon.tar

4. Sur le nœud 1 du déploiement de Tableau Server : mettez à jour le fichier de connexion (tsig.json) avec l’information de connexion de la deuxième passerelle indépendante. Vous devrez récupérer la clé d’authentification comme décrit précédemment dans cette rubrique ( Installer la passerelle indépendante).

   Un exemple de fichier de connexion (tsig.json) est illustré ici :

   {
   "independentGateways": [
    {
      "id": "ip-10-0-1-169.ec2.internal",
      "host": "ip-10-0-1-169.ec2.internal",
      "port": "21319",
      "protocol" : "http",
      "authsecret": "13660-27118-29070-25482-9518-22453"
    },
    {
      "id": "ip-10-0-2-230.ec2.internal",
      "host": "ip-10-0-2-230.ec2.internal",
      "port": "21319",
      "protocol" : "http",
      "authsecret": "9055-27834-16487-27455-30409-7292"
    }]
    }

5. Sur le nœud 1 du déploiement de Tableau Server : exécutez les commandes suivantes pour mettre à jour la configuration :

   tsm stop

   tsm topology external-services gateway update -c tsig.json
   

   tsm start

6. Sur les deux instances de la passerelle indépendante : pendant le démarrage de Tableau Server, redémarrez le processus tsig-httpd :

   sudo su - tableau-tsig

   systemctl --user restart tsig-httpd

   exit

7. Dans AWS EC2>Groupes cibles : mettez à jour le groupe cible pour inclure l’instance EC2 exécutant la deuxième instance de la passerelle indépendante.

   Sélectionnez le groupe cible que vous venez de créer, puis cliquez sur l’onglet Cibles. 

   • Cliquez sur Modifier.
   • Sélectionnez l’instance EC2 de l’ordinateur personnel de la deuxième passerelle indépendante, puis cliquez sur Ajouter aux instances enregistrées. Cliquez sur Enregistrer.