Guide de récupération de l'hôte de Server
Ce guide est destiné aux administrateurs Server pour la récupération d'une instance Server en cas de défaillance d'un ou plusieurs hôtes d'origine lors du passage à une nouvelle instance Server mise à niveau, du passage d'une instance Server locale à un serveur cloud et dans d'autres situations de changement de votre infrastructure.
La récupération de Server vous permet d'exécuter une nouvelle instance de Server avec vos utilisateurs, workflows, planifications, etc. d'origine. Pour cela, vous devez disposer des éléments suivants de votre Server d'origine :
Jeton de contrôleur
Fichier
RuntimeSettings.xml
depuis le nœud du contrôleurSauvegarde MongoDB
Vous trouverez ci-dessous les détails de chaque étape du processus :
2 - Récupération du fichier RuntimeSettings.xml
4 - Restauration d'autres fichiers et paramètres
5 - Lancement d'Alteryx Server
Champ d'application
Récupération à la suite de l'échec d'une installation unique et par défaut de Server en utilisant MongoDB intégré.
Sauvegarde disponible avec les informations nécessaires intactes.
Les machines cibles peuvent être écrasées.
Hors champ d'application
Environnement Server à plusieurs nœuds ou MongoDB ou SQL Server géré par l'utilisateur. Contactez le service clientèle pour obtenir de l'aide.
Fusion de bases de données de fichiers de connexion.
Sauvegarde ou restauration des pilotes ODBC.
Sauvegarde ou restauration des DSN utilisateur ou système.
Sauvegarde ou restauration d'autres alias stockés dans Windows qui existent en dehors d'Alteryx.
Conditions préalables
Installation de tous les pilotes de base de données et les logiciels nécessaires au fonctionnement du workflow avant de suivre les étapes décrites dans ce guide afin de réduire les temps d'arrêt.
Droits d'administrateur sur l'instance Server cible.
Accès à toutes les informations d'identification utilisées pour l'usurpation d'identité, y compris le compte de service (si ce n'est pas le système local), l'utilisateur « Exécuter en tant que » et toutes les informations d'identification définies/utilisées pour le workflow.
Jeton contrôleur du Server d'origine.
Accès au fichier RuntimeSettings.xml du Server d'origine situé dans :
%ProgramData%\Alteryx\RRuntimeSettings.xml
.Sauvegarde de MongoDB à partir du Server d'origine. Découvrez comment effectuer une sauvegarde.
Vérification que le Server cible est défini sur le même fuseau horaire que le Server d'origine dans les paramètres de fuseau horaire Windows. S'il n'est pas défini sur le même fuseau horaire, cela peut entraîner des erreurs dans les vues de planification.
Facultatif
Les éléments suivants n'ont peut-être pas été utilisés dans le Server d'origine. Vérifiez si la fonctionnalité a été utilisée et suivez les étapes correspondantes ayant un caractère facultatif dans le présent guide.
Utilisateur de connexion au service, le cas échéant.
Informations sur l'utilisateur « Exécuter en tant que » pour la configuration de Worker :
Domaine
Nom d'utilisateur
Mot de passe
Nom d'utilisateur et mot de passe du serveur SMTP pour la configuration de Server.
Connecteurs à partir de
%ProgramData%\Alteryx\Tools
.Alias de connexion Alteryx basés sur le système et en base de données du Server d'origine.
Connexions de données système en base de données, voir le fichier
%ProgramData%\Alteryx\Engine\SystemConnections.xml
Connexions de données système, voir le fichier
%ProgramData%\Alteryx\Engine\SystemAlias.xml
Alias de connexion Alteryx basés sur l'utilisateur et en base de données du Server d'origine : les informations ci-dessous peuvent être pertinentes pour chaque compte utilisateur avec identifiants de workflow ou « Exécuter en tant que ».
Connexions aux données utilisateur, voir le fichier
C:\Users\[username]\AppData\Roaming\Alteryx\Engine\UserConnections.xml
Connexions aux données utilisateur en base de données, voir le fichier
C:\Users\[username]\AppData\Roaming\Alteryx\Engine\UserAlias.xml
Étape 1 : préparation
# | Étape | Détails |
---|---|---|
1.1 | Définir le fuseau horaire de la machine | Le fuseau horaire Windows de la nouvelle machine doit correspondre à celui de la machine d'origine. |
1.2 | Assurer l'accès à Alteryx | Assurez-vous que la machine peut contacter whitelist.alteryx.com, utilisé par le système de licences Alteryx. |
1.3 | Installer la même version de Server | Effectuez une installation en règle de la même version de Server qui a généré la sauvegarde Mongo. Utilisez la dernière version de maintenance du trimestre. Par exemple, si votre sauvegarde provient de la version 2022.4.2 et que la version de maintenance 2022.4.5 est disponible, utilisez cette dernière. Si votre version n'est pas encore disponible sur http://downloads.alteryx.com, contactez-nous à l'adresse fulfillment@alteryx.com. Installation ou mise à niveau de Server Vérifiez que l'interface utilisateur Server apparaît dans le navigateur. Inutile de vous connecter. |
1.4 | Résoudre des problèmes Erreur de clé de licence « En cours d'utilisation » | Si votre clé de licence est toujours liée à votre ancien Server, vous devrez la désactiver sur la machine en question. Si cette machine est inaccessible, contactez votre administrateur de licence pour libérer la licence. |
Étape 2 : récupération du fichier RuntimeSettings.xml
# | Étape | Détails |
---|---|---|
2.1 | Ouvrir l'invite de commande 1 dans le dossier « bin » | Ouvrez une invite de commande en tant qu'administrateur et accédez au dossier Alteryx\bin, saisissez les commandes ci-dessous (à ajuster en fonction de votre emplacement d'installation).
|
2.2 | Arrêter le service | Saisissez la commande
En cas de succès, vous devriez voir le message |
2.3 | Sauvegarder le fichier RuntimeSettings.xml existant | Saisissez la commande
|
2.4 | Restaurer le fichier RuntimeSettings.xml | Copiez le fichier RuntimeSettings.xml depuis votre Server d'origine dans le répertoire |
2.5 | Effacer le jeton contrôleur | Modifiez le fichier RuntimeSettings.xml que vous venez de copier et supprimez tout ce qui se trouve entre les balises <ServerSecretEncrypted>, en ne laissant que les balises comme indiqué ci-dessous : Enregistrez et fermez le fichier. |
2.6 | Restaurer le jeton contrôleur | Saisissez la commande à l'aide du jeton contrôleur de votre Server d'origine.
Dépannage : La version 2021.3+ peut produire une erreur à cette étape : « Set server secret failed: Error in CryptImportKey(3): Bad Data. (-2146893819) ». Pour corriger ce problème, reportez-vous à l'étape précédente pour vous assurer que la valeur a bien été retirée entre les balises. |
2.7 | Restaurer les clés de stockage chiffrées | La valeur |
2.8 | Restaurer la fonction Exécuter en tant qu'utilisateur | Si vous disposiez de la fonction Exécuter en tant qu'utilisateur sur le Server d'origine, saisissez la commande ci-après. Sinon, ignorez cette étape. |
2.9 | Restaurer le mot de passe SMTP | Si vous avez renseigné Paramètres système Alteryx > Server UI (Interface utilisateur Server) > SMTP > Password (Mot de passe) (même si la case à cocher SMTP n'a pas été cochée), saisissez la commande suivante. Sinon, ignorez cette étape. |
2.10 | Enregistrer RuntimeSettings.xml | Enregistrez le fichier RuntimeSettings.xml. |
2.11 | Transférer la clé de chiffrement Cette fonctionnalité n'est disponible que dans les versions suivantes :
| Important Veuillez noter qu'AlteryxService doit être exécuté sur votre nœud de contrôleur du Server d'origine et que votre nouveau Server doit pouvoir y accéder via le réseau. Les étapes décrites dans la section Processus de transfert de la clé de chiffrement vous permettent de transférer la clé de chiffrement de votre contrôleur existant vers votre nouveau contrôleur. |
2.12 | Rester sur la ligne de commande | Pour l'étape 3, vous devez vous trouver dans une ligne de commande Administrateur dans le dossier |
Étape 3 : récupération de MongoDB
# | Étape | |
---|---|---|
3.1 | Obtenir la sauvegarde MongoDB | Copiez la sauvegarde Mongo du Server d'origine vers un dossier |
3.2 | Restaurer dans un nouveau dossier | Restaurez la base de données Mongo depuis le dossier de sauvegarde vers un nouveau dossier de restauration. Le dernier paramètre, ,10, garantit une utilisation inférieure de la mémoire par MongoDB pendant la restauration. Ce paramètre réduit le risque d'erreurs de mémoire insuffisante, mais peut augmenter le temps de restauration. Si vous supprimez « ,10 », les restaurations seront plus rapides. Dans les deux cas, consultez le fichier mongoRestore.log comme décrit ci-dessous pour vérifier que la restauration s'est correctement effectuée.
|
3.3 | Vérifier que la restauration a réussi | Vérifiez que la restauration a réussi. Attention Il s'agit d'une étape nécessaire, car un échec de restauration ne sera pas signalé à l'étape précédente et peut entraîner une perte de données sur votre Server. Pour vérifier la restauration, consultez le fichier mongoRestore.log dans le dossier MongoDB où les données ont été restaurées. Ouvrez le fichier mongoRestore.log et procédez comme suit :
Si la récupération a échoué, ou si vous trouvez des résultats lorsque vous recherchez les mots clés énumérés ci-dessus, veuillez contacter le support avec toutes les informations que vous avez recueillies. Ne poursuivez pas si la restauration MongoDB a échoué. |
3.4 | Définir le chemin Mongo dans RuntimeSettings.XML | Modifiez le fichier RuntimeSettings.xml et saisissez le chemin d'accès au dossier Exemple : Enregistrez et fermez l'éditeur de texte. |
3.5 | Démarrer MongoDB | Saisissez la commande
Exemple
|
Ne fermez pas la fenêtre d'invite de commande. Si vous fermez la fenêtre à partir de l'étape 3.5, aucune des étapes suivantes ne fonctionnera. | ||
<< Début de la section de la deuxième invite de commande >> | ||
3.6 | Ouvrir la deuxième invite de commande dans le dossier « bin » | Ouvrez une DEUXIÈME invite de commande en tant qu'administrateur et accédez au dossier
|
3.7 | Obtenir le mot de passe Mongo non administrateur | Saisissez la commande et copiez votre MOT DE PASSE MONGO NON ADMINISTRATEUR dans Notepad
|
3.8 | Démarrer la ligne de commande Mongo | Saisissez la commande
Exemple
En cas de succès, vous devriez voir l'invite « |
3.9 | Supprimer les verrous définis par le Server d'origine | Saisissez la commande Mongo
En cas de succès, le message suivant devrait s'afficher : « |
3.10 | Quitter la ligne de commande Mongo et l'invite de commande 2 | Saisissez la commande
Fermez Command_Prompt_2 |
<<Fin de la section de la deuxième invite de commande >> | ||
3.11 | Arrêter la base de données Mongo | Dans l'invite de commande d'origine, saisissez la commande clavier
une ou plusieurs fois jusqu'à ce que vous quittiez MongoDB et reveniez à une invite de commande normale. Fermez l'invite de commande. |
Étape 4 : restauration d'autres fichiers et paramètres
# | Étape | Détails |
---|---|---|
4.1 | Aviez-vous un utilisateur de connexion au service sur le Server d'origine ? | Définissez l'utilisateur de connexion au service sur le nouveau Server. Application Windows Services > clic droit sur AlteryxService > Propriétés > Connexion |
4.2 | Ajouter des pilotes de données et des DSN système | Ajoutez des pilotes de même version et des DSN système de même nom pour correspondre au Server d'origine, https://downloads.alteryx.com/. |
Problèmes avancés qui peuvent ne pas s'appliquer à votre récupération : | ||
4.3 | Dans des environnements plus sécurisés, configurez les autorisations Exécuter en tant qu'utilisateur requises. | Toutes les informations d'identification utilisées pour exécuter les workflows (Exécuter en tant que, Connexion au service ou l'ensemble d'informations d'identification lors de l'enregistrement du workflow) doivent disposer d'un accès suffisant. Configurer les autorisations d'exécution utilisateur requises. |
4.4 | Restaurer les alias de connexion basés sur le système et en base de données | Connexion aux données système :
Connexion aux données en base de donnée système :
|
4.5 | Restaurer les alias de connexion basés sur l'utilisateur et en base de données | Connexion aux données utilisateur :
Connexion aux données utilisateur en base de données :
|
4.6 | Les workflows utilisent-ils des connecteurs ? | Copiez les dossiers de connecteurs de votre Server d'origine vers
Contactez le service clientèle pour activer les connecteurs sur votre nouveau Server. |
4.7 | Les workflows utilisent-ils l'outil Python ? | Réinstallez tous les packages Python que les workflows avaient installés. Voir Server Upgrade Python Tool Environment Checklist. |
4.8 | Les workflows utilisent-ils l'outil R ? | Bientôt disponible. |
4.9 | Disposez-vous d'un environnement multi-nœuds ou Mongo géré par l'utilisateur ? | (Bientôt disponible) Contactez votre responsable de compte ou le service clientèle. |
4.10 | Utilisez-vous SSL ? | Si vous effectuez une récupération vers un Server Sandbox pour des tests, utilisez HTTP pour les tests. Si vous migrez vers un nouveau Server, rétablissez votre SSL : Configurer SSL/TLS pour Server Configuration d'Alteryx Server pour SSL : obtention et installation de certificats (15577) |
Étape 5 : lancement d'Alteryx Server
# | Étape | Détails |
---|---|---|
5.1 | Vérifier les paramètres système Alteryx et suspendre les Planifications, si souhaitable | Exécutez les paramètres système Alteryx et parcourez chaque page pour vérifier que les paramètres (comme le jeton contrôleur) contiennent les valeurs attendues. Si vous ne souhaitez pas que les Planifications s'exécutent au démarrage du service, décochez : Worker > General (Général) > Allow machine to run scheduled Alteryx workflows (Autoriser la machine à exécuter les workflows Alteryx planifiés) Lorsque vous sélectionnez Finish (Terminer), AlteryxService doit démarrer et le Server doit être disponible dans un navigateur. |
Important
Portez une attention particulière aux paramètres de configuration de l'interface utilisateur de Server, car un nouveau Server peut avoir une URL différente ou ne pas avoir de certificat SSL.
Étape 6 : test
# | Étape | Détails |
---|---|---|
6.1 | Tests de base | AlteryxService est-il en cours d'exécution ? Pouvez-vous :
|
6.2 | Tests spécifiques aux workflows | Pouvez-vous exécuter des workflows contenant des extensions ou des connexions externes, telles que :
|