Partie 7 - Validation, outils et dépannage

Cette partie porte sur les étapes de validation après l’installation et les conseils de dépannage.

Validation du système de basculement

Après la configuration de votre déploiement, nous vous conseillons d’exécuter des tests de basculement simples pour valider la redondance du système.

Nous recommandons d’exécuter les étapes suivantes pour valider la fonctionnalité de basculement :

  1. Fermez la première instance de la passerelle indépendante (TSIG1). Le trafic entrant doit être entièrement acheminé par l’intermédiaire de la deuxième instance de la passerelle indépendante (TSIG2).
  2. Redémarrez TSIG1 puis fermez TSIG2. Le trafic entrant doit être entièrement acheminé par l’intermédiaire de TSIG1.
  3. Redémarrez TSIG2.
  4. Fermez le nœud 1 Tableau Server. Le trafic de Vizportal ou du service d’applications basculera entièrement vers le nœud 2.

    Remarque : depuis septembre 2022, la haute disponibilité du nœud 1 est compromise sur certaines version de Tableau Server 2021.4 et versions ultérieures. Les connexions client ne pourront pas être établies si le nœud 1 est désactivé. Ce problème a été résolu dans ces versions de maintenance :

    - 2021.4.15 et versions ultérieures
    - 2022.1.11 et versions ultérieures
    - 2023.1.3 et versions ultérieures

    Pour garantir que votre installation de Tableau Server à l’aide des activations ATR bénéficiera d’une période de grâce de 72 heures après la panne initiale du nœud, installez ou mettez à niveau vers l’une de ces versions. Pour en savoir plus, consultez Tableau Server HA using ATR Does Not Have a Grace Period After the Initial Node Failure(Le lien s’ouvre dans une nouvelle fenêtre) dans la base de connaissances Tableau.

  5. Redémarrez le nœud 1 et fermez le nœud 2. Le trafic de Vizportal ou du service d’applications basculera entièrement vers le nœud 1.
  6. Redémarrez le nœud 2.

Dans ce contexte, « la fermeture » ou le « redémarrage » consiste à éteindre le système d’exploitation ou l’ordinateur virtuel sans tenter au préalable une fermeture progressive de l’application. Il s’agit donc de simuler une panne matérielle ou de l’ordinateur virtuel.

Pour chaque test de basculement, l’étape minimale de validation consiste à s’authentifier avec un utilisateur et à effectuer des opérations essentielles de visualisation.

Une erreur liée au navigateur « Bad Request » (Requête incorrecte) pourra peut-être s’afficher lorsque vous tentez de vous connecter après une simulation de panne. Vous verrez peut-être cette erreur même si vous effacez le cache du navigateur. Ce problème se produit souvent lorsque le navigateur met en cache les données de la session précédente du fournisseur d’identités. Si cette erreur persiste même après la suppression du cache du navigateur local, validez le scénario Tableau en vous connectant avec un autre navigateur.

Récupération automatisée du nœud initial

Tableau Server version 2021.2.4 et versions ultérieures inclut un script de récupération automatisée du nœud initial auto-node-recovery dans le répertoire des scripts (/app/tableau_server/packages/scripts.<version>).

Si vous rencontrez un problème avec le nœud initial et que des processus redondants s’exécutent sur le Nœud 2, il n’y a aucune garantie que Tableau Server continuera de fonctionner. Tableau Server peut continuer à s’exécuter jusqu’à 72 heures suivant la défaillance d’un nœud initial, avant que l’absence du service de licence n’affecte d’autres processus. Si tel est le cas, vos utilisateurs peuvent continuer à se connecter et également voir et utiliser leur contenu après la défaillance du nœud initial. Par contre, vous ne pourrez pas reconfigurer Tableau Server parce que vous n’aurez pas accès au contrôleur d’administration.

Même lorsqu’il est configuré avec des processus redondants, il est possible que Tableau Server cesse de fonctionner après l’échec du nœud initial.

Pour récupérer en cas d’échec du nœud initial (Nœud 1) :

  1. Connectez-vous au Nœud 2 de Tableau Server.

  2. Accédez au répertoire de scripts :

    cd /app/tableau_server/packages/scripts.<version>
  3. Exécutez la commande suivante pour lancer le script :

    sudo ./auto-node-recovery -p node1 -n node2 -k <license keys>

    <license keys> est une liste de valeurs séparées par des virgules (sans espaces) des clés produit pour votre déploiement. Si vous n’avez pas accès à vos clés produit, accédez au portail client Tableau(Le lien s’ouvre dans une nouvelle fenêtre) pour les récupérer. Par exemple :

    sudo ./auto-node-recovery -p node1 -n node2 -k TSB4-8675-309F-TW50-9RUS,TSNM-559N-ULL6-22VE-SIEN

Le script auto-node-recovery exécutera environ 20 étapes pour récupérer les services sur le Nœud 2. Chaque étape est affichée dans le terminal au fur et à mesure de la progression du script. Un statut plus détaillé est enregistré dans /data/tableau_data/logs/app-controller-move.log. Dans la plupart des environnements, l’exécution du script prend entre 35 et 45 minutes.

Résolution des problèmes de récupération du nœud initial

Si la récupération de nœud échoue, vous pourrez trouver utile d’exécuter le script de manière interactive pour autoriser ou interdire des étapes discrètes du processus. Par exemple, si le script échoue au cours du processus, vous pouvez consulter le fichier journal, apporter des modifications à la configuration, puis réexécuter le script. Si vous exécutez le mode interactif, vous pouvez alors ignorer toutes les étapes jusqu’à ce que vous arriviez à l’étape qui a échoué.

Pour une exécution en mode interactif, ajoutez le commutateur -i pour passer à l’argument de script.

Reconstruire le nœud défaillant

Après avoir exécuté le script, le nœud 2 exécutera tous les services qui se trouvaient auparavant sur l’hôte du nœud 1 défaillant. Pour ajouter le nœud 4, vous devez déployer un nouvel hôte Tableau Server avec le fichier d’amorçage et le configurer comme vous l’avez fait pour le nœud 2 d’origine, comme spécifié dans la partie 4. Consultez Configurer le Nœud 2.

switchto

Le script switchto est un script conçu par Tim qui permet de passer facilement d’une fenêtre à l’autre.

  1. Copiez le code suivant dans un fichier appelé switchto dans le répertoire de base de votre hôte Bastion.
  2. #!/bin/bash
    #-------------------------------------------------------------------
    # switchto
    #
    # Helper function to simplify SSH into the various AWS hosts when
    # following the Tableau Server Enterprise Deployment Guide (EDG).
    #
    # Place this file on your bastion host and provide your AWS hosts' 
    # internal ip addresses or machine names here.
    # Example: readonly NODE1="10.0.3.187"
    #
    readonly NODE1=""
    readonly NODE2=""
    readonly NODE3=""
    readonly NODE4=""
    readonly PGSQL=""
    readonly PROXY1=""
    readonly PROXY2=""
    				
    usage() {
    echo "Usage: switchto.sh [ node1 | node2 | node3 | node4 | pgsql | proxy1 | proxy2 ]"
    }
    
    
    ip=""
    
    case $1 in
    	node1)
    		ip="$NODE1"
    		;;
    	node2)
    		ip="$NODE2"
    		;;
    	node3)
    		ip="$NODE3"
    		;;
    	node4)
    		ip="$NODE4"
    		;;
    	pgsql)
    		ip="$PGSQL"
    		;;
    	proxy1)
    		ip="$PROXY1"
    		;;
    	proxy2)
    		ip="$PROXY2"
    		;;
    	?)
    		usage
    		exit 0
    		;;
    	*)
    		echo "Unkown option $1."
    		usage
    		exit 1
    		;;
    esac
    
    if [[ -z $ip ]]; then
    echo "You must first edit this file to provide the ip addresses of your AWS hosts."
    exit 1
    fi
    
    ssh -A ec2-user@$ip
  3. Mettez à jour les adresses IP dans le script pour les mapper à vos instances EC2, puis enregistrez le fichier.
  4. Appliquez les autorisations au fichier de script :
  5. sudo chmod +x switchto

Utilisation :

Pour passer à un hôte, exécutez la commande suivante :

./switchto <target>

Par exemple, pour passer au Nœud 1, exécutez la commande suivante :

./switchto node1

Résoudre les problèmes de la passerelle indépendante Tableau Server

La configuration de la passerelle indépendante, d’Okta, de Mellon et de SAML sur Tableau Server peut être propice aux erreurs. La cause première la plus courante des échecs est une erreur de chaîne de caractères. Par exemple, une barre oblique (/) sur les URL Okta spécifiées lors de la configuration peut provoquer une erreur de caractères incompatibles liée à l’assertion SAML. Ceci est juste un exemple. Lors de la configuration, il existe de nombreuses occasions de saisir une chaîne de caractères incorrects dans l’une des applications.

Redémarrez le service tableau-tsig

Commencez (et terminez) systématiquement le dépannage en redémarrant le service tableau-tsig sur les ordinateurs des passerelles indépendantes. Le redémarrage de ce service est rapide et déclenche souvent une mise à jour de la configuration à partir de Tableau Server.

Exécutez les commandes suivantes sur l’ordinateur de la passerelle indépendante :

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

Trouver des chaînes de caractères incorrects

Si votre chaîne de caractères contient une erreur (erreur copier/coller, chaîne de caractères tronquée, etc.), prenez le temps de parcourir chacun des paramètres que vous avez configurés :

  • Configuration de la pré-authentification Okta. Examinez attentivement les URL que vous avez définies. Vérifiez la présence de barres obliques. Vérifiez la présence de HTTP c. HTTPS.
  • Historique des étagères pour la configuration SAML sur le nœud 1. Examinez la commande tsm authentication saml configure que vous avez exécutée. Vérifiez que toutes les URL correspondent à celles que vous avez configurées dans Okta. Lors de l’examen de l’historique des étagères à partir du nœud 1, vérifiez que les commandes tsm configuration set qui indiquent les chemins d’accès du fichier de configuration Mellon correspondent exactement aux chemins d’accès de fichier où vous avez copié les fichiers sur la passerelle indépendante.
  • Configuration Mellon sur la passerelle indépendante. Examinez l’historique des étagères pour vérifier que vous avez créé les métadonnées avec la même chaîne d’URL que celle que vous avez configurée dans Okta et Tableau SAML. Vérifiez que tous les chemins spécifiés dans /etc/mellon/conf.d/global.conf sont corrects et que le MellonCookieDomain est défini sur votre domaine racine, et non sur votre sous-domaine Tableau.

Rechercher les fichiers journaux pertinents

Si toutes les chaînes semblent être définies correctement, vous devez examiner les fichiers journaux à la recherche d’erreurs.

Tableau Server consigne les erreurs et les événements dans des dizaines de fichiers journaux différents. La passerelle indépendante se connecte également à un ensemble de fichiers locaux. Nous vous recommandons d’examiner ces fichiers journaux dans l’ordre suivant.

Fichiers journaux de la passerelle indépendante

L’emplacement par défaut des fichiers journaux de la passerelle indépendante est /var/opt/tableau/tableau_tsig/logs.

  • access.log : ce fichier journal est utile dans la mesure où il comporte des entrées qui affichent les connexions à partir des nœuds Tableau Server. Si vous obtenez des erreurs de passerelle (défaut de démarrage) lorsque vous essayez de démarrer TSM et que le fichier access.log ne comporte aucune entrée, il existe un problème de connectivité de base. Vérifiez systématiquement la configuration du groupe de sécurité AWS dans un premier temps. Un autre problème courant est la présence d’une faute de frappe dans tsig.json. Si vous effectuez une mise à jour du fichier tsig.json, exécutez tsm stop avant d’exécuter tsm topology external-services gateway update -c tsig.json. Une fois le fichier tsig.json mis à jour, exécutez tsm start.
  • error.log : entre autres entrées, ce fichier journal comprend des erreurs SAML et Mellon.

Fichier journal tabadminagent de Tableau Server

L’ensemble de fichiers tabadminagent (et non tabadmincontroller) inclut les seuls fichiers journaux pertinents pour le dépannage des erreurs liées à la passerelle indépendante.

Vous devez trouver dans quel emplacement les erreurs liées à la passerelle indépendante ont été consignées dans tabdminagent. Ces erreurs peuvent se trouver sur n’importe quel nœud, mais elles ne concernent qu’un seul nœud. Effectuez les étapes suivantes sur chaque nœud du groupement Tableau Server jusqu’à ce que vous trouviez la chaîne "independent" :

  1. Trouvez l’emplacement du fichier journal tabadminagent sur les nœuds 1 à 4 de Tableau Server dans la configuration EDG :

    cd /data/tableau_data/data/tabsvc/logs/tabadminagent
  2. Ouvrez le fichier journal le plus récent et vérifiez qu’il comporte :

    less tabadminagent_nodeN.log

    (remplacez N par le numéro de nœud)

  3. Recherchez toutes les instances de "Independent" et "independent" - en utilisant la chaîne de recherche suivante :

    /ndependent

    S’il n’y a aucune correspondance, passez au nœud suivant et répétez les étapes 1 à 3.

  4. Quand vous obtenez une correspondance : Shift + G pour défiler vers le bas et obtenir les messages d’erreur les plus récents.

Recharger le fichier de remplacement httpd

La passerelle indépendante gère la configuration du fichier de remplacement httpd pour Apache. Une opération générique pouvant aboutir à la réparation des erreurs temporaires consiste à recharger le fichier de remplacement httpd qui constitue la configuration sous-jacente d’Apache. Exécutez les commandes suivantes sur les deux instances de la passerelle indépendante.

  1. Recopiez le fichier de remplacement httpd.conf :

    cp /var/opt/tableau/tableau_tsig/config/httpd.conf.stub /var/opt/tableau/tableau_tsig/config/httpd.conf
  2. Redémarrez le service de passerelle indépendante :

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

Supprimer ou déplacer des fichiers journaux

La passerelle indépendante consigne tous les événements d’accès. Vous devrez gérer le stockage des fichiers journaux pour éviter de saturer l’espace disque. En cas d’encombrement de l’espace disque, la passerelle indépendante ne pourra pas écrire des événements d’accès, ce qui se traduira par un échec. Le message suivant sera consigné dans le fichier error.log de la passerelle indépendante :

(28)No space left on device: [client 10.0.2.209:54332] AH00646: Error writing to /var/opt/tableau/tableau_tsig/logs/access.%Y_%m_%d_%H_%M_%S.log

Cette erreur se traduit par un état DEGRADED pour le nœud external lorsque vous exécutez tsm status -v sur le nœud 1 Tableau. Le nœud external dans la sortie d’état fait référence à la passerelle indépendante.

Pour résoudre ce problème, supprimez ou effacez les fichiers access.log du disque. Les fichiers access.log sont enregistrés sur /var/opt/tableau/tableau_tsig/logs. Une fois le disque effacé, redémarrez le service tableau-tsig.

Erreurs liées au navigateur

Requête incorrecte : une erreur courante pour ce scénario est une erreur « Bad Request » (Requête incorrecte) d’Okta. Ce problème se produit souvent lorsque le navigateur met en cache les données de la session Okta précédente. Par exemple, si vous gérez les applications Okta en tant qu’administrateur Okta, puis tenez d’accéder à Tableau à l’aide d’un autre compte compatible Okta, les données de session provenant des données de l’administrateur peuvent provoquer l’erreur « Bad Request ». Si cette erreur persiste même après la suppression du cache du navigateur local, essayez de valider le scénario Tableau en vous connectant avec un autre navigateur.

Une autre cause de l’erreur « Demande incorrecte » est une faute de frappe dans l’une des nombreuses URL que vous saisissez lors des processus de configuration Okta, Mellon et SAML. Vérifiez que vous avez saisi tous ces éléments sans aucune erreur.

Souvent le fichier error.log sur le serveur de la passerelle indépendante spécifiera quelle URL est à l’origine de l’erreur.

Introuvable - L’URL demandée était introuvable sur ce serveur : cette erreur indique l’une des nombreuses erreurs de configuration possibles.

Si l’utilisateur est authentifié avec Okta, puis reçoit cette erreur, il est probable que vous ayez téléversé l’application de pré-authentification Okta sur Tableau Server lorsque vous avez configuré SAML. Vérifiez que vous avez configuré les métadonnées de l’application Okta Tableau Server sur Tableau Server, et non pas les métadonnées de l’application de pré-authentification Okta

Autres étapes de dépannage :

  • Passez en revue les paramètres de l’application de pré-authentification Okta. Assurez-vous que les protocoles HTTP vs HTTPS sont définis comme spécifié dans cette rubrique.
  • Redémarrez tsig-httpd sur les deux serveurs de passerelle indépendante.
  • Vérifiez que sudo apachectl configtest renvoie « Syntaxe OK » sur les deux passerelles indépendantes.
  • Vérifiez que l’utilisateur test est affecté aux deux applications dans Okta.
  • Vérifiez que l’adhérence est activée sur l’équilibreur de charge et les groupes cibles associés.

Vérifier la connexion TLS entre Tableau Server et la passerelle indépendante

Utilisez la commande wget pour vérifier la connectivité et l’accès de Tableau Server à la passerelle indépendante. Des variantes de cette commande peuvent vous aider à comprendre si des problèmes de certificat sont à l’origine de problèmes de connexion.

Par exemple, exécutez la commande suivante wget pour vérifier le protocole de gestion interne (HK) depuis Tableau Server :

wget https://ip-10-0-1-38.us-west-1.compute.internal:21319

Créez une URL avec la même adresse hôte que celle que vous avez incluse pour l’option hôte du fichier tsig.json. Spécifiez le protocole https, et ajoutez l’URL ainsi que le port HK21319.

Pour vérifier la connectivité et ignorer la vérification du certificat :

wget https://ip-10-0-1-38.us-west-1.compute.internal:21319 --no-check-certificate

Pour vérifier que le certificat CA racine pour TSIG est valide :

wget https://ip-10-0-1-38.us-west-1.compute.internal:21319 --ca-certificate=tsigRootCA.pem

Si Tableau est capable de communiquer, il est toujours possible que des erreurs liées au contenu se produisent, mais pas des erreurs liées à la connexion. Si Tableau ne parvient pas du tout à se connecter, commencez par vérifier la configuration du protocole dans les groupes de pare-feu/sécurité. Par exemple, les règles entrantes du groupe de sécurité où réside la passerelle indépendante doivent autoriser le protocole TCP 21319.

Merci de vos commentaires!Votre commentaire s été envoyé avec succès. Merci!