Dépannage de l’installation de Paragon Automation
RÉSUMÉ Lisez les rubriques suivantes pour savoir comment résoudre les problèmes typiques que vous pouvez rencontrer pendant et après l’installation.
Résoudre les conflits de fusion du fichier de configuration
Le init script crée les fichiers de configuration du modèle. Si vous mettez à jour une installation existante à l’aide du même config-dir répertoire que celui utilisé pour l’installation, les fichiers de modèle créés par le init script sont fusionnés avec les fichiers de configuration existants. Parfois, cette action de fusion crée un conflit de fusion que vous devez résoudre. Le script vous invite à résoudre le conflit. Lorsque vous y êtes invité, sélectionnez l’une des options suivantes :
-
C : vous pouvez conserver le fichier de configuration existant et ignorer le nouveau fichier de modèle. Il s’agit de l’option par défaut.
-
n : vous pouvez ignorer le fichier de configuration existant et réinitialiser le fichier de modèle.
-
m : vous pouvez fusionner les fichiers manuellement. Les sections en conflit sont marquées par des lignes commençant par
<<<<<<<<,||||||||,========et>>>>>>>>. Vous devez modifier le fichier et supprimer les marqueurs de fusion avant de procéder à la mise à jour. -
d : vous pouvez afficher les différences entre les fichiers avant de décider comment résoudre le conflit.
Résoudre les problèmes courants de sauvegarde et de restauration
Supposons que vous détruisiez un cluster existant et que vous redéployiez une image logicielle sur les mêmes noeuds de cluster. Dans un tel scénario, si vous essayez de restaurer une configuration à partir d’un dossier de configuration précédemment sauvegardé, l’opération de restauration peut échouer. L’opération de restauration échoue car le chemin de montage de la configuration sauvegardée est maintenant modifié. Lorsque vous détruisez un cluster existant, le volume persistant est supprimé. Lorsque vous redéployez la nouvelle image, le volume persistant est recréé dans l’un des noeuds du cluster chaque fois qu’il y a de l’espace disponible, mais pas nécessairement dans le même noeud que précédemment. Par conséquent, l’opération de restauration échoue.
Pour contourner ces problèmes de sauvegarde et de restauration :
-
Déterminez le chemin de montage du nouveau volume persistant.
-
Copiez le contenu du chemin de montage du volume persistant précédent vers le nouveau chemin.
-
Relancez l’opération de restauration.
Afficher les fichiers journaux d’installation
Si le deploy script échoue, vous devez vérifier les fichiers journaux d’installation dans le config-dir répertoire. Par défaut, le config-dir répertoire stocke six fichiers journaux compressés. Le fichier journal actuel est enregistré en tant que journal et les fichiers journaux précédents sont enregistrés en tant que fichiers log.1 à log.5 . Chaque fois que vous exécutez le deploy script, le journal actuel est enregistré et le journal le plus ancien est supprimé.
Vous trouverez généralement des messages d’erreur à la fin d’un fichier journal. Affichez le message d’erreur et corrigez la configuration.
Afficher les fichiers journaux dans Grafana
Grafana est un outil de visualisation de données open-source. L’interface utilisateur de Grafana vous permet de créer et d’afficher des tableaux, des graphiques et d’autres éléments visuels afin d’organiser et de comprendre les données. Vous pouvez créer des tableaux de bord pour surveiller l’état des appareils, et vous pouvez également interroger des données et afficher les résultats à partir de l’interface utilisateur. L’interface utilisateur Grafana restitue les données de la base de données de séries chronologiques (TSDB) de Paragon Automation. Pour plus d’informations, reportez-vous à la documentation Grafana.
Pour afficher les journaux dans l’application Grafana :
Dépannage à l’aide de l’interface kubectl
kubectl (Kube Control) est un utilitaire de ligne de commande qui interagit avec l’API Kubernetes, et la ligne de commande la plus courante utilisée pour contrôler les clusters Kubernetes.
Vous pouvez émettre des commandes kubectl sur le nœud principal juste après l’installation. Pour exécuter des commandes kubectl sur les nœuds de travail, vous devez copier le fichier admin.conf et définir la variable d’environnement kubeconfig ou utiliser la commande export KUBECONFIG=config-dir /admin.conf . Le fichier admin.conf est copié dans le répertoire config-dir de l’hôte de contrôle dans le cadre du processus d’installation.
Vous utilisez l’outil de ligne de commande kubectl pour communiquer avec l’API Kubernetes et obtenir des informations sur les ressources de l’API telles que les nœuds, les pods et les services, afficher les fichiers journaux, ainsi que créer, supprimer ou modifier ces ressources.
La syntaxe des commandes kubectl est la suivante :
kubectl [command] [TYPE] [NAME] [flags]
[command] est simplement l’action que vous souhaitez exécuter.
Vous pouvez utiliser la commande suivante pour afficher une liste de commandes kubectl :
root@primary-node:/# kubectl [enter]
Vous pouvez demander de l’aide, pour obtenir des détails et lister tous les drapeaux et options associés à une commande particulière. Par exemple:
root@primary-node:/# kubectl get -h
Pour vérifier et dépanner les opérations dans Paragon Automation, vous allez utiliser les commandes suivantes :
| [commande] | Description |
|---|---|
| Avoir | Affichez une ou plusieurs ressources. La sortie affiche un tableau des informations les plus importantes sur les ressources spécifiées. |
| décrire | Afficher les détails d’une ressource spécifique ou d’un groupe de ressources. |
| expliquer | Documentation des ressources. |
| Journaux | Affichez les journaux d’un conteneur dans un pod. |
| redémarrage du déploiement | Gérer le déploiement d’une ressource. |
| éditer | Modifier une ressource. |
[TYPE] représente le type de ressource que vous souhaitez afficher. Les types de ressources ne sont pas sensibles à la casse et vous pouvez utiliser des formes singulières, plurielles ou abrégées.
Par exemple, pod, nœud, service ou déploiement. Pour obtenir la liste complète des ressources et des abréviations autorisées (par exemple, pod = po), exécutez la commande suivante :
kubectl api-resources
Pour en savoir plus sur une ressource, exécutez la commande suivante :
kubectl explain [TYPE]
Par exemple:
root@primary-node:/# kubectl explain pod
KIND: Pod
VERSION: v1
DESCRIPTION:
Pod is a collection of containers that can run on a host. This resource is
created by clients and scheduled onto hosts.
---more---
[NAME] est le nom d’une ressource spécifique, par exemple, le nom d’un service ou d’un pod. Les noms sont sensibles à la casse.
root@primary-node:/# kubectl get pod pod_name
[flags] fournir des options supplémentaires pour une commande. Par exemple, -o répertorie d’autres attributs pour une ressource. Utilisez help (-h) pour obtenir des informations sur les drapeaux disponibles.
Notez que la plupart des ressources Kubernetes (telles que les pods et les services) se trouvent dans certains espaces de noms, tandis que d’autres ne le sont pas (telles que les nœuds).
Les espaces de noms permettent d’isoler des groupes de ressources au sein d’un même cluster. Les noms des ressources doivent être uniques au sein d’un espace de noms, mais pas entre les espaces de noms.
Lorsque vous utilisez une commande sur une ressource qui se trouve dans un espace de noms, vous devez inclure l’espace de noms dans le cadre de la commande. Les espaces de noms sont sensibles à la casse. Sans l’espace de noms approprié, la ressource spécifique qui vous intéresse risque de ne pas s’afficher.
root@primary-node:/# kubectl get services mgd Error from server (NotFound): services "mgd" not found root@primary-node:/# kubectl get services mgd -n healthbot NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE mgd ClusterIP 10.102.xx.12 <none> 22/TCP,6500/TCP,8082/TCP 18h
Vous pouvez obtenir une liste de tous les espaces de noms en exécutant la kubectl get namespace commande.
Si vous souhaitez afficher les ressources de tous les espaces de noms, ou si vous n’êtes pas sûr des espaces de noms auxquels appartient la ressource spécifique qui vous intéresse, vous pouvez entrer --all-namespaces ou - A.
Pour plus d’informations sur Kubernetes, consultez :
- https://kubernetes.io/docs/reference/kubectl/overview/
- https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands
Utilisez les rubriques suivantes pour dépanner et afficher les détails de l’installation à l’aide de l’interface kubectl.
- Afficher l’état du noeud
- Afficher l’état du pod
- Afficher des informations détaillées sur un pod
- Afficher les journaux d’un conteneur dans un pod
- Exécuter une commande sur un conteneur dans un pod
- Voir les services
- Commandes kubectl fréquemment utilisées
Afficher l’état du noeud
Utilisez la kubectl get nodes commande, abrégée en kubectl get no commande, pour afficher l’état des nœuds du cluster. L’état des noeuds doit être Ready, et les rôles doivent être soit control-plane ou none. Par exemple:
root@primary-node:~# kubectl get no NAME STATUS ROLES AGE VERSION 10.49.xx.x1 Ready control-plane,master 5d5h v1.20.4 10.49.xx.x6 Ready <none> 5d5h v1.20.4 10.49.xx.x7 Ready <none> 5d5h v1.20.4 10.49.xx.x8 Ready <none> 5d5h v1.20.4
Si ce n’est pas Readyle cas d’un nœud, vérifiez si le processus kubelet est en cours d’exécution. Vous pouvez également utiliser le journal système du nœud pour examiner le problème.
Pour vérifier kubelet : root@primary-node:/# kubelet
Afficher l’état du pod
Utilisez la kubectl get po –n namespace commande ou kubectl get po -A pour afficher l’état d’un pod. Vous pouvez spécifier un espace de noms individuel (par exemple healthbot, , northstaret common) ou utiliser le -A paramètre pour afficher l’état de tous les espaces de noms. Par exemple:
root@primary-node:~# kubectl get po -n northstar NAME READY STATUS RESTARTS AGE bmp-854f8d4b58-4hwx4 3/3 Running 1 30h dcscheduler-55d69d9645-m9ncf 1/1 Running 1 7h13m
L’état des gousses saines doit être Running ou Completed, et le nombre de conteneurs prêts doit correspondre au total. Si l’état d’un pod n’est pas Running ou si le nombre de conteneurs ne correspond pas, utilisez la kubectl describe po commande ou kubectl log (POD | TYPE/NAME) [-c CONTAINER] pour résoudre le problème plus avant.
Afficher des informations détaillées sur un pod
Utilisez la kubectl describe po -n namespace pod-name commande pour afficher des informations détaillées sur un pod spécifique. Par exemple:
root@primary-node:~# kubectl describe po -n northstar bmp-854f8d4b58-4hwx4
Name: bmp-854f8d4b58-4hwx4
Namespace: northstar
Priority: 0
Node: 10.49.xx.x1/10.49.xx.x1
Start Time: Mon, 10 May 2021 07:11:17 -0700
Labels: app=bmp
northstar=bmp
pod-template-hash=854f8d4b58
…
Afficher les journaux d’un conteneur dans un pod
Utilisez la kubectl logs -n namespace pod-name [-c container-name] commande pour afficher les journaux d’un pod particulier. Si un pod comporte plusieurs conteneurs, vous devez spécifier le conteneur pour lequel vous souhaitez afficher les journaux. Par exemple:
root@primary-node:~# kubectl logs -n common atom-db-0 | tail -3
2021-05-31 17:39:21.708 36 LOG {ticks: 0, maint: 0, retry: 0}
2021-05-31 17:39:26,292 INFO: Lock owner: atom-db-0; I am atom-db-0
2021-05-31 17:39:26,350 INFO: no action. i am the leader with the lock
Exécuter une commande sur un conteneur dans un pod
Utilisez la kubectl exec –ti –n namespacepod-name [-c container-name] -- command-line commande pour exécuter des commandes sur un conteneur à l’intérieur d’un pod. Par exemple:
root@primary-node:~# kubectl exec -ti -n common atom-db-0 -- bash
____ _ _
/ ___| _ __ (_) | ___
\___ \| '_ \| | |/ _ \
___) | |_) | | | (_) |
|____/| .__/|_|_|\___/
|_|
This container is managed by runit, when stopping/starting services use sv
Examples:
sv stop cron
sv restart patroni
Current status: (sv status /etc/service/*)
run: /etc/service/cron: (pid 29) 26948s
run: /etc/service/patroni: (pid 27) 26948s
run: /etc/service/pgqd: (pid 28) 26948s
root@atom-db-0:/home/postgres#
Après avoir exécuté exec la commande, vous obtenez un shell bash dans le serveur de base de données Postgres. Vous pouvez accéder à l’interpréteur de commandes bash à l’intérieur du conteneur et exécuter des commandes pour vous connecter à la base de données. Tous les conteneurs ne sont pas équipés d’une coque bash. Certains conteneurs ne fournissent que SSH, et d’autres conteneurs n’ont pas de shell.
Voir les services
Utilisez la kubectl get svc -n namespace commande ou kubectl get svc -A pour afficher les services de cluster. Vous pouvez spécifier un espace de noms individuel (par healthbotexemple, , northstaret common), ou vous pouvez utiliser le -A paramètre pour afficher les services de tous les espaces de noms. Par exemple:
root@primary-node:~# kubectl get svc -A --sort-by spec.type NAMESPACE NAME TYPE EXTERNAL-IP PORT(S) … healthbot tsdb-shim LoadBalancer 10.54.xxx.x3 8086:32081/TCP healthbot ingest-snmp-proxy-udp LoadBalancer 10.54.xxx.x3 162:32685/UDP healthbot hb-proxy-syslog-udp LoadBalancer 10.54.xxx.x3 514:31535/UDP ems ztpservicedhcp LoadBalancer 10.54.xxx.x3 67:30336/UDP ambassador ambassador LoadBalancer 10.54.xxx.x2 80:32214/TCP,443:31315/TCP,7804:32529/TCP,7000:30571/TCP northstar ns-pceserver LoadBalancer 10.54.xxx.x4 4189:32629/TCP …
Dans cet exemple, les services sont triés par type et seuls les services de type LoadBalancer sont affichés. Vous pouvez afficher les services fournis par le cluster et les adresses IP externes sélectionnées par l’équilibreur de charge pour accéder à ces services.
Vous pouvez accéder à ces services depuis l’extérieur du cluster. L’adresse IP externe est exposée et accessible à partir d’appareils extérieurs au cluster.
Commandes kubectl fréquemment utilisées
-
Répertorier les contrôleurs de réplication :
# kubectl get –n namespace deploy
# kubectl get –n namespace statefulset
-
Redémarrez un composant :
kubectl rollout restart –n namespace deploy deployment-name
-
Modifier une ressource Kubernetes : vous pouvez modifier un déploiement ou n’importe quel objet API Kubernetes, et ces modifications sont enregistrées dans le cluster. Toutefois, si vous réinstallez le cluster, ces modifications ne sont pas conservées.
# kubectl edit –ti –n namespace deploy deployment-name
Dépannage à l’aide de l’utilitaire CLI paragon
paragon 'utilitaire CLI de commande pour exécuter des commandes sur les pods en cours d'exécution dans le système. Il
paragon s’agit d’un ensemble de commandes intuitives qui vous permettent d’analyser, d’interroger et de dépanner votre cluster. Pour exécuter les commandes, connectez-vous à l’un des nœuds principaux. La sortie de certaines commandes est codée par couleur car, pour certaines commandes, l’utilitaire
paragon de commande exécute les commandes kubecolor au lieu de kubectl, kubecolor code par couleur votre sortie de commande kubectl. Reportez-vous à la
Figure 1 pour obtenir un exemple de sortie.
Pour afficher l’ensemble des options d’aide des commandes disponibles, utilisez l’une des commandes suivantes :
root@primary-node:~# paragon ? root@primary-node:~# paragon --help root@primary-node:~# paragon -h
Vous pouvez afficher les options d’aide à n’importe quel niveau de commande (pas seulement au niveau supérieur). Par exemple:
root@primary-node:~# paragon insights cli ? paragon insights cli alerta => Gets into the CLI of paragon insights alerta pod. paragon insights cli byoi => Gets into the CLI of byoi plugin.Usage : --byoi <BYOI plugin name>. paragon insights cli configserver => Gets into the CLI of paragon insights config-server pod. paragon insights cli grafana => Gets into the CLI of paragon insights grafana pod. paragon insights cli influxdb => Gets into the CLI of paragon insights InfluxDB pod.Use Argument: --influx <influxdb-nodeip> to specify the node ip ,else the command will use first influx node as default.Eg: --influx influxdb-172-16-18-21 paragon insights cli mgd => Gets into the CLI of paragon insights mgd pod.
Vous pouvez utiliser l’option de tabulation pour afficher les options d’autocomplétion possibles pour les commandes. Pour afficher l’auto-complétion des commandes de niveau supérieur, tapez paragon et appuyez sur la touche de tabulation. Par exemple:
root@primary-node:~# paragon ambassador describe get pathfinder set common ems insights rookceph
Pour afficher la commande sous-jacente exécutée par une commande paragon, utilisez l’écho ou -e l’option. Par exemple:
root@primary-node:~# paragon -e get nodes all >>>> command: kubecolor --force-colors get nodes
Pour exécuter une commande paragon et afficher la commande sous-jacente qu’elle exécute, utilisez l’option debug or -d . Par exemple:
root@primary-node:~# paragon -d get nodes all >>>> command: kubecolor --force-colors get nodes NAME STATUS ROLES AGE VERSION ix-pgn-pr-01 Ready control-plane,etcd,master 17d v1.26.6+rke2r1 ix-pgn-pr-02 Ready control-plane,etcd,master 17d v1.26.6+rke2r1 ix-pgn-pr-03 Ready control-plane,etcd,master 17d v1.26.6+rke2r1 ix-pgn-wo-01 Ready <none> 17d v1.26.6+rke2r1
Pour afficher la liste complète des paragon commandes et les commandes sous-jacentes correspondantes qu’elles exécutent, utilisez :
root@primary-node:~# paragon --mapped
paragon sortie de commande
Suivez les instructions relatives aux critères d’utilisation spécifiques tels que les arguments ou les conditions préalables, le cas échéant, dans la section d’aide de chaque commande. Certaines commandes ont besoin d’arguments obligatoires. Par exemple, la paragon insights logs devicegroup analytical commande a besoin de l’argument --dg devicegroup-name-with subgroup. Par exemple:
paragon insights logs devicegroup analytical --dg controller-0
Certaines commandes ont des conditions préalables. Par exemple, avant d’utiliser la paragon insights get playbooks commande, vous devez définir le nom d’utilisateur et le mot de passe à l’aide des paragon set username --cred username commandes and paragon set password --cred password .
L’ensemble complet des commandes ainsi que leurs critères d’utilisation sont répertoriés dans le tableau 1.
| Commander |
Description |
|---|---|
|
|
Affiche les capsules d’émissaire ambassadeur Paragon. |
|
|
Affiche tous les pods ambassadeurs Paragon. |
|
|
Affiche tous les services d’ambassadeur Paragon. |
|
|
Aide à trouver les rôles Postgres. |
|
|
Affiche la description d’un noeud particulier dans le cluster. Utilisez l’argument Exemple: Vous pouvez utiliser la |
|
|
Affiche les pods Paragon ems du gestionnaire de périphériques. |
|
|
Affiche les pods Paragon EMS du gestionnaire de tâches. |
|
|
Affiche tous les pods Paragon EMS. |
|
|
Affiche tous les services Paragon EMS. |
|
|
Affiche les journaux des pods du gestionnaire de périphériques Paragon EMS. Utilisez l’argument pour obtenir des |
|
|
Affiche les journaux du pod paragon ems job manager. Utilisez l’argument pour obtenir des |
|
|
Affiche tous les espaces de noms disponibles dans Paragon. |
|
|
Affiche la liste de tous les noeuds du cluster. |
|
|
Valide si kubelet a une pression sur le disque. Utilisez l’argument Exemple: |
|
|
Valide si kubelet dispose d’une mémoire suffisante. Utilisez l’argument Exemple: |
|
|
Vérifie s’il y a des problèmes avec calico et le réseau. Utilisez l’argument Exemple: |
|
|
Affiche la liste de tous les noeuds qui ne sont pas prêts dans le cluster. |
|
|
Valide si kubelet dispose d’un PID suffisant. Utilisez l’argument Exemple: |
|
|
Affiche la liste de tous les noeuds prêts dans le cluster. |
|
|
Affiche la liste de toutes les souillures sur les nœuds. |
|
|
Affiche tous les pods de parangon sains. |
|
|
Affiche tous les pods Paragon malsains. |
|
|
Affiche tous les services Paragon exposés. |
|
|
Se connecte à la CLI du module alerta de Paragon Insights. |
|
|
Se connecte à la CLI du plug-in BYOI. Utilisez l’argument |
|
|
Se connecte à la CLI du pod config-server de Paragon Insights. |
|
|
Se connecte à l’interface de ligne de commande du pod grafana Paragon Insights. |
|
|
Se connecte à l’interface de ligne de commande du pod influxdb de Paragon Insights. Utilisez l’argument Exemple: |
|
|
Se connecte à l’interface de ligne de commande du pod mgd de Paragon Insights. |
|
|
Décrit le module alerta de Paragon Insights. |
|
|
Décrit le pod API REST de Paragon Insights. |
|
|
Décrit le pod serveur de configuration Paragon Insights. |
|
|
Décrit le module grafana de Paragon Insights. |
|
|
Décrit le pod influxdb de Paragon Insights. Utilisez l’argument Exemple: |
|
|
Décrit le pod mgd de Paragon Insights. |
|
|
Affiche le module alerta de Paragon Insights. |
|
|
Affiche le module API REST de Paragon Insights. |
|
|
Affiche le pod serveur de configuration Paragon Insights. |
|
|
Affiche tous les groupes d’appareils Paragon Insights. Le nom d’utilisateur par défaut est Au préalable, exécutez la |
|
|
Affiche tous les appareils Paragon Insights. Le nom d’utilisateur par défaut est Au préalable, exécutez la |
|
|
Affiche le module grafana de Paragon Insights. |
|
|
Affiche le pod influxdb de Paragon Insights. |
|
|
Affiche les pods d’ingestion de télémétrie réseau Paragon Insights. |
|
|
Affiche le module mgd de Paragon Insights. |
|
|
Affiche tous les playbooks Paragon Insights. Le nom d’utilisateur par défaut est Au préalable, exécutez la |
|
|
Affiche tous les modules Paragon Insights. |
|
|
Affiche tous les services Paragon Insights. |
|
|
Affiche les journaux du module alerta de Paragon Insights. |
|
|
Affiche les journaux du pod API REST de Paragon Insights. |
|
|
Affiche les journaux du plug-in BYOI de Paragon Insights. Utilisez l’argument |
|
|
Affiche les journaux du pod serveur de configuration Paragon Insights. |
|
|
Affiche les journaux du groupe d’équipements Paragon Insights pour le moteur d’analyse des services. Utilisez l’argument Exemple: Dans l’exemple, controller est le nom du groupe de périphériques et 0 est le sous-groupe. |
|
|
Affiche les journaux du groupe d’appareils Paragon Insights pour le service itsdb. Utilisez l’argument
Exemple: Dans l’exemple, controller est le nom du groupe de périphériques et 0 est le sous-groupe. |
|
|
Affiche les journaux du groupe d’appareils Paragon Insights pour le service jtimon. Utilisez l’argument Exemple: Dans l’exemple, controller est le nom du groupe de périphériques et 0 est le sous-groupe. |
|
|
Affiche les journaux du groupe d’appareils Paragon Insights pour service jti natif. Utilisez l’argument Exemple: Dans l’exemple, controller est le nom du groupe de périphériques et 0 est le sous-groupe. |
|
|
Affiche les journaux du groupe de périphériques Paragon Insights pour le syslog de service. Utilisez l’argument Exemple: Dans l’exemple, controller est le nom du groupe de périphériques et 0 est le sous-groupe. |
|
|
Affiche les journaux du module Grafana de Paragon Insights. |
|
|
Affiche les journaux du pod influxdb de Paragon Insights. Utilisez l’argument Exemple: |
|
|
Affiche les journaux du module mgd de Paragon Insights. |
|
|
Se connecte à l’interface de ligne de commande du conteneur BMP Paragon Pathfinder. |
|
|
Se connecte à la CLI du conteneur ns-configserver de Paragon Pathfinder. |
|
|
Se connecte à l’interface de ligne de commande du conteneur cRPD Paragon Pathfinder. |
|
|
Se connecte à l’interface de ligne de commande du conteneur debugutils de Paragon Pathfinder. |
|
|
Se connecte à la CLI du conteneur netconf de Paragon Pathfinder. |
|
|
Se connecte à la CLI des services de conteneur ns-pceserver (PCEP) de Paragon Pathfinder. |
|
|
Se connecte à la CLI du conteneur Paragon Pathfinder ns-pcserver (PCS). |
|
|
Se connecte à l’interface de ligne de commande du conteneur ns-pcsviewer (application de bureau Paragon Planner) de Paragon Pathfinder. |
|
|
Permet d’accéder à l’interface de ligne de commande du conteneur du planificateur Paragon Pathfinder. |
|
|
Se connecte à l’interface de ligne de commande du conteneur ns-toposerver (service de topologie) de Paragon Pathfinder. |
|
|
Se connecte à la CLI du conteneur ns-web de Paragon Pathfinder. |
|
|
Débogue la configuration des options de routage cRPD de Paragon Pathfinder associée à BGP-LS. |
|
|
Débogue les routes cRPD de Paragon Pathfinder associées à BGP-LS. |
|
|
Affiche l’aide de Paragon Pathfinder debugutils genjvisiondata. |
|
|
Affiche les paramètres de Paragon Pathfinder debugutils genjvisiondata. |
|
|
Se connecte à l’interface de ligne de commande PCEP de Paragon Pathfinder pour le débogage. |
|
|
Affiche l’état Postgres du cluster Kubernetes. |
|
|
Affiche l’état du cluster rabbitmqctl. |
|
|
Exécute le pod debugutils Paragon Pathfinder pour espionner et décoder les données échangées entre AMQP. |
|
|
Affiche l’aide de Paragon Pathfinder debugutils snoop. |
|
|
Exécute le pod debugutils Paragon Pathfinder pour espionner et décoder les données échangées entre Postgres. |
|
|
Exécute le pod debugutils Paragon Pathfinder pour espionner et décoder les données échangées entre le lien Redis. |
|
|
Exécute le pod debugutils Paragon Pathfinder pour espionner et décoder les données échangées entre Redis lsp. |
|
|
Exécute le pod debugutils Paragon Pathfinder pour espionner et décoder les données échangées entre les nœuds Redis. |
|
|
Affiche Paragon Pathfinder debugutils topo_util aide. |
|
|
Affiche Paragon Pathfinder outil debugutils topo_util pour désactiver le mode sans échec. |
|
|
Exécute Paragon Pathfinder outil debugutils topo_util pour actualiser la topologie actuelle. |
|
|
Exécute Paragon Pathfinder outil debugutils topo_util pour enregistrer l’instantané de la topologie actuelle. |
|
|
Décrit le module Paragon Pathfinder, y compris les conteneurs cRPD et BMP. |
|
|
Décrit le pod Paragon Pathfinder, y compris le conteneur de serveur de configuration. |
|
|
Décrit le pod Paragon Pathfinder, y compris le conteneur debugutils. |
|
|
Décrit le module Paragon Pathfinder avec le conteneur ns-netconfd. |
|
|
Décrit le module Paragon Pathfinder, y compris le conteneur ns-pceserver (services PCEP). |
|
|
Décrit le pod Paragon Pathfinder, y compris le conteneur ns-pcserver (PCS). |
|
|
Décrit le pod Paragon Pathfinder, y compris le conteneur ns-pcsviewer (application de bureau Paragon Planner). |
|
|
Décrit le module Paragon Pathfinder, y compris le conteneur du planificateur. |
|
|
Décrit le module Paragon Pathfinder, y compris le conteneur ns-toposerver (service de topologie). |
|
|
Décrit le module Paragon Pathfinder, y compris le conteneur Web. |
|
|
Affiche le module Paragon Pathfinder, y compris les conteneurs cRPD et BMP. |
|
|
Affiche le module Paragon Pathfinder, y compris les conteneurs ns-configserver et syslog. |
|
|
Affiche le module Paragon Pathfinder, y compris le conteneur debugutils. |
|
|
Affiche le pod Paragon Pathfinder associé au processus netconf. |
|
|
Affiche le module Paragon Pathfinder, y compris le conteneur ns-pceserver (services PCEP). |
|
|
Affiche le module Paragon Pathfinder, y compris le conteneur ns-pcserver (PCS). |
|
|
Affiche le module Paragon Pathfinder, y compris le conteneur ns-pcsviewer (application de bureau Paragon Planner). |
|
|
Affiche tous les modules Paragon Pathfinder. |
|
|
Affiche le module Paragon Pathfinder associé au processus de planification. |
|
|
Affiche tous les services Paragon Pathfinder. |
|
|
Affiche le module Paragon Pathfinder, y compris le conteneur ns-toposerver (service de topologie). |
|
|
Affiche le module Paragon Pathfinder associé au processus ns-web. |
|
|
Affiche les journaux des pods bmp de Paragon Pathfinder conteneur bmp. Utilisez l’argument pour obtenir des |
|
|
Affiche les journaux du conteneur cRPD des pods bmp de Paragon Pathfinder. Utilisez l’argument pour obtenir des |
|
|
Affiche les journaux du conteneur syslog des pods bmp de Paragon Pathfinder. Utilisez l’argument pour obtenir des |
|
|
Affiche les journaux des pods configserver de Paragon Pathfinder conteneur ns-configserver. Utilisez l’argument pour obtenir des |
|
|
Affiche les journaux du conteneur syslog des pods configserver de Paragon Pathfinder. Utilisez l’argument pour obtenir des |
|
|
Affiche les journaux des pods netconf de Paragon Pathfinder conteneur ns-netconfd. Utilisez l’argument pour obtenir des |
|
|
Affiche les journaux du conteneur syslog des pods netconf de Paragon Pathfinder. Utilisez l’argument pour obtenir des |
|
|
Affiche les journaux des pods pceserver de Paragon Pathfinder conteneur ns-pceserver. Utilisez l’argument pour obtenir des |
|
|
Affiche les journaux du conteneur syslog des pods pceserver de Paragon Pathfinder. Utilisez l’argument pour obtenir des |
|
|
Affiche les journaux traités des pods pceserver de Paragon Pathfinder conteneur syslog récupérant uniquement l’horodatage, le niveau et le message. Utilisez l’argument pour obtenir des |
|
|
Affiche les journaux de Paragon Pathfinder pcserver pods ns-pcserver container. Utilisez l’argument pour obtenir des |
|
|
Affiche les journaux de Paragon Pathfinder pcserver pods syslog container. Utilisez l’argument pour obtenir des |
|
|
Affiche les journaux traités des pods pceserver de Paragon Pathfinder récupère le conteneur syslog uniquement avec l’horodatage, le niveau et le message. Utilisez l’argument pour obtenir des |
|
|
Affiche les journaux des pods pcviewer de Paragon Pathfinder conteneur ns-pcviewer. Utilisez l’argument pour obtenir des |
|
|
Affiche les journaux du conteneur syslog des pods pcviewer de Paragon Pathfinder. Utilisez l’argument pour obtenir des |
|
|
Affiche les journaux des pods toposerver de Paragon Pathfinder conteneur ns-topo-dbinit. Utilisez l’argument pour obtenir des |
|
|
Affiche les journaux des pods toposerver de Paragon Pathfinder conteneur ns-topo-dbinit-cache. Utilisez l’argument pour obtenir des |
|
|
Affiche les journaux des pods toposerver de Paragon Pathfinder conteneur ns-toposerver. Utilisez l’argument pour obtenir des |
|
|
Affiche les journaux du conteneur syslog des pods toposerver de Paragon Pathfinder. Utilisez l’argument pour obtenir des |
|
|
Affiche les journaux traités des pods de toposerveur Paragon Pathfinder récupère le conteneur syslog uniquement avec l’horodatage, le niveau et le message. Utilisez l’argument pour obtenir des |
|
|
Affiche les journaux du conteneur ns-web pods de Paragon Pathfinder. Utilisez l’argument pour obtenir des |
|
|
Affiche les journaux des pods Web ns-web-dbinit du conteneur ns-web-dbinit de Paragon Pathfinder. Utilisez l’argument pour obtenir des |
|
|
Affiche les journaux du conteneur syslog des pods Web de Paragon Pathfinder. Utilisez l’argument pour obtenir des |
|
|
Affiche l’état de la fédération (à partir de l’instance rabbitmq-0). L’état GeoHa n’est disponible que pour une configuration à double cluster. |
|
|
Signale l’utilisation de l’espace disque du système de fichiers Rook et Ceph OSD. |
|
|
Affiche les statistiques des pools OSD Rook et Ceph. |
|
|
Affiche l’état de l’OSD de la tour et du Ceph. |
|
|
Affiche l’arbre OSD de la tour et de Ceph. |
|
|
Affiche l’utilisation de l’OSD Rook et Ceph. |
|
|
Affiche l’état de la tour et de la figure de Ceph. |
|
|
Affiche l’état de la tour et du ceph. |
|
|
Se connecte à l’interface de ligne de commande du pod de boîte à outils Rook et Ceph. |
|
|
Affiche les pods Rook et Ceph. |
|
|
Affiche les services Rook et Ceph. |
|
|
Il s’agit de l’utilitaire d’administration des utilisateurs de passerelle RADOS qui récupère les informations sur la période. |
|
|
Il s’agit de l’utilitaire d’administration des utilisateurs de passerelle RADOS qui obtient l’état de synchronisation des métadonnées. |
|
|
Définit le mot de passe Paragon (hôte de l’interface utilisateur) pour l’authentification des appels REST. Utilisez cette commande set password unique obligatoire pour définir le mot de passe à l’aide de l’argument Exemple: |
|
|
Définit le nom d’utilisateur Paragon (hôte de l’interface utilisateur) pour l’authentification des appels Rest. Le nom d’utilisateur par défaut est Utilisez l’argument Exemple: |
Dépannage de Ceph et Rook
Ceph nécessite des versions relativement récentes du noyau. Si votre noyau Linux est très ancien, envisagez de le mettre à niveau ou d’en réinstaller un nouveau.
Utilisez cette section pour résoudre les problèmes liés à Ceph et Rook.
Espace disque insuffisant
Une raison courante de l’échec de l’installation est que les démons de stockage d’objets (OSD) ne sont pas créés. Un OSD configure le stockage sur un nœud de cluster. Les OSD peuvent ne pas être créés en raison de la non-disponibilité des ressources disque, sous la forme de ressources insuffisantes ou d’un espace disque mal partitionné. Assurez-vous que les nœuds disposent d’un espace disque non partitionné suffisant.
Reformater un disque
Examinez les journaux des tâches « rook-ceph-osd-prepare-hostname-* ». Les journaux sont descriptifs. Si vous avez besoin de reformater le disque ou la partition et de redémarrer Rook, effectuez les opérations suivantes :
- Utilisez l’une des méthodes suivantes pour reformater un disque ou une partition existante.
- Si vous avez un périphérique de stockage par bloc qui aurait dû être utilisé pour Ceph, mais qui n'a pas été utilisé parce qu'il était dans un état inutilisable, vous pouvez reformater complètement le disque.
$ sgdisk -zap /dev/disk $ dd if=/dev/zero of=/dev/disk bs=1M count=100
- Si vous avez une partition de disque qui aurait dû être utilisée pour Ceph, vous pouvez effacer complètement les données de la partition.
$ wipefs -a -f /dev/partition $ dd if=/dev/zero of=/dev/partition bs=1M count=100
Note:Ces commandes reformatent complètement le disque ou les partitions que vous utilisez et vous perdrez toutes les données qu’ils contiennent.
- Si vous avez un périphérique de stockage par bloc qui aurait dû être utilisé pour Ceph, mais qui n'a pas été utilisé parce qu'il était dans un état inutilisable, vous pouvez reformater complètement le disque.
- Redémarrez Rook pour enregistrer les modifications et relancez le processus de création de l’OSD.
$ kubectl rollout restart deploy -n rook-ceph rook-ceph-operator
Afficher l’état du pod
Pour vérifier l’état des pods Rook et Ceph installés dans l’espace rook-ceph de noms, utilisez la # kubectl get po -n rook-ceph commande. Les pods suivants doivent être dans l’état running .
rook-ceph-mon-*: en règle générale, trois pods de moniteur sont créés.rook-ceph-mgr-*—Un pod de gestionnairerook-ceph-osd-*: trois pods OSD ou plusrook-ceph-mds-cephfs-*—Serveurs de métadonnéesrook-ceph-rgw-object-store-*—Passerelle ObjectStorerook-ceph-tools*: pour des options de débogage supplémentaires.Pour vous connecter à la boîte à outils, utilisez la commande :
$ kubectl exec -ti -n rook-ceph $(kubectl get po -n rook-ceph -l app=rook-ceph-tools \ -o jsonpath={..metadata.name}) -- bashVoici quelques-unes des commandes courantes que vous pouvez utiliser dans la boîte à outils :
# ceph status # ceph osd status, # ceph osd df, # ceph osd utilization, # ceph osd pool stats, # ceph osd tree, and # ceph pg stat
Dépannage de la défaillance de l’OSD Ceph
Vérifiez l’état des pods installés dans l’espace rook-ceph de noms.
# kubectl get po -n rook-ceph
Si un rook-ceph-osd-* pod est à l’état Error ou CrashLoopBackoff , vous devez réparer le disque.
-
Arrêtez le
rook-ceph-operatorfichier .# kubectl scale deploy -n rook-ceph rook-ceph-operator --replicas=0 -
Supprimez les processus OSD défaillants.
# kubectl delete deploy -n rook-ceph rook-ceph-osd-number -
Connectez-vous à la boîte à outils.
$ kubectl exec -ti -n rook-ceph $(kubectl get po -n rook-ceph -l app=rook-ceph-tools -o jsonpath={..metadata.name}) -- bash -
Identifiez l’OSD défaillant.
# ceph osd status -
Marquez l’OSD qui a échoué.
[root@rook-ceph-tools-/]# ceph osd out 5 marked out osd.5. [root@rook-ceph-tools-/]# ceph osd status ID HOST USED AVAIL WR OPS WR DATA RD OPS RD DATA STATE 0 10.xx.xx.210 4856M 75.2G 0 0 0 0 exists,up 1 10.xx.xx.215 2986M 77.0G 0 0 1 89 exists,up 2 10.xx.xx.98 3243M 76.8G 0 0 1 15 exists,up 3 10.xx.xx.195 4945M 75.1G 0 0 0 0 exists,up 4 10.xx.xx.170 5053M 75.0G 0 0 0 0 exists,up 5 10.xx.xx.197 0 0 0 0 0 0 exists
-
Retirez l’OSD défaillant.
# ceph osd purge number --yes-i-really-mean-it - Connectez-vous au nœud qui a hébergé l’OSD défaillant et effectuez l’une des opérations suivantes :
- Remplacez le disque dur en cas de panne matérielle.
- Reformatez complètement le disque.
$ sgdisk -zap /dev/disk $ dd if=/dev/zero of=/dev/disk bs=1M count=100
- Reformatez complètement la partition.
$ wipefs -a -f /dev/partition $ dd if=/dev/zero of=/dev/partition bs=1M count=100
-
Redémarrez
rook-ceph-operator.# kubectl scale deploy -n rook-ceph rook-ceph-operator --replicas=1 -
Surveillez les modules OSD.
# kubectl get po -n rook-cephSi l’OSD ne se rétablit pas, utilisez la même procédure pour supprimer l’OSD, puis retirez le disque ou supprimez la partition avant de redémarrer
rook-ceph-operator.
Résoudre les problèmes liés à l’échec de l’installation de l’entrefer
L’installation de l’entrefer ainsi que le kube-apiserver échoue avec l’erreur suivante car vous n’avez pas de fichier existant /etc/resolv.conf .
TASK [kubernetes/master : Activate etcd backup cronjob] ******************************************************************** fatal: [192.xx.xx.2]: FAILED! => changed=true cmd: - kubectl - apply - -f - /etc/kubernetes/etcd-backup.yaml delta: '0:00:00.197012' end: '2022-09-13 13:46:31.220256' msg: non-zero return code rc: 1 start: '2022-09-13 13:46:31.023244' stderr: The connection to the server 192.xx.xx.2:6443 was refused - did you specify the right host or port? stderr_lines: <omitted> stdout: '' stdout_lines: <omitted>
Pour créer un fichier, vous devez exécuter la #touch /etc/resolv.conf commande en tant qu’utilisateur racine, puis redéployer le cluster Paragon Automation.
Récupérer après une défaillance de cluster RabbitMQ
Pour vérifier cette condition, exécutez la kubectl get po -n northstar -l app=rabbitmq commande. Cette commande doit afficher trois pods dont l’état est Running. Par exemple:
$ kubectl get po -n northstar -l app=rabbitmq NAME READY STATUS RESTARTS AGE rabbitmq-0 1/1 Running 0 10m rabbitmq-1 1/1 Running 0 10m rabbitmq-2 1/1 Running 0 9m37s
Toutefois, si l’état d’un ou de plusieurs pods est Error, utilisez la procédure de récupération suivante :
-
Supprimez RabbitMQ.
kubectl delete po -n northstar -l app=rabbitmq -
Vérifiez l’état des pods.
kubectl get po -n northstar -l app=rabbitmq.Répétez l’opération
kubectl delete po -n northstar -l app=rabbitmqjusqu’à ce que l’état de toutes les pods soitRunning. -
Redémarrez les applications Paragon Pathfinder.
kubectl rollout restart deploy -n northstar
Désactiver le démon udevd lors de la création de l’OSD
udevd nouveaux matériels tels que des disques, des cartes réseau et des CD. Lors de la création des OSD, le
udevd démon détecte les OSD et peut les verrouiller avant qu’ils ne soient complètement initialisés. Le programme d’installation de Paragon Automation se désactive
systemd-udevd pendant l’installation et l’active une fois que Rook a initialisé les OSD.
Lors de l’ajout ou du remplacement de noeuds et de la réparation de noeuds défaillants, vous devez désactiver manuellement le démon afin que la udevd création de l’OSD n’échoue pas. Vous pouvez réactiver le démon une fois les OSD créés.
Utilisez ces commandes pour désactiver et activer udevdmanuellement .
- Connectez-vous au nœud que vous souhaitez ajouter ou réparer.
- Désactivez le
udevddémon.- Vérifiez si udevd est en cours d’exécution.
# systemctl is-active systemd-udevd - Si
udevdest actif, désactivez-le.# systemctl mask system-udevd --now
- Vérifiez si udevd est en cours d’exécution.
-
Lorsque vous réparez ou remplacez un nœud, les systèmes de fichiers distribués Ceph ne sont pas automatiquement mis à jour. Si les disques de données sont détruits dans le cadre du processus de réparation, vous devez récupérer les démons de stockage d’objets (OSD) hébergés sur ces disques de données.
-
Connectez-vous à la boîte à outils Ceph et affichez l’état des OSD. Le
ceph-toolsscript est installé sur un noeud principal. Vous pouvez vous connecter au nœud principal et utiliser l’interface kubectl pour accéderceph-toolsà . Pour utiliser un noeud autre que le noeud principal, vous devez copier le fichier admin.conf (dans le config-dir répertoire de l’hôte de contrôle) et définir la variable d’environnementkubeconfigou utiliser laexport KUBECONFIG=config-dir/admin.confcommande.$ ceph-tools# ceph osd status -
Vérifiez que tous les OSD sont répertoriés sous la forme
exists,up. Si les OSD sont endommagés, suivez les instructions de dépannage expliquées dans Dépannage de Ceph et Rook.
-
- Connectez-vous au nœud que vous avez ajouté ou réparé après avoir vérifié que tous les OSD sont créés.
-
Réactiver
udevdsur le noeud.systemctl unmask system-udevd
disable_udevd: true dans le
config.yml et exécuter la
./run -c config-dir deploy commande. Nous vous déconseillons de redéployer le cluster uniquement pour désactiver le
udevd démon.
Scripts wrapper pour les commandes utilitaires courantes
| Description de la commande | |
|---|---|
paragon-db [arguments] |
Connectez-vous au serveur de base de données et démarrez le shell SQL Postgres à l’aide du compte de superutilisateur. Les arguments facultatifs sont transmis à la commande Postgres SQL. |
pf-cmgd [arguments] |
Démarrez l’interface de ligne de commande dans le module CMGD Paragon Pathfinder. Les arguments facultatifs sont exécutés par l’interface de ligne de commande. |
pf-crpd [arguments] |
Démarrez l’interface de ligne de commande dans le module cRPD Paragon Pathfinder. Les arguments facultatifs sont exécutés par l’interface de ligne de commande. |
pf-redis [arguments] |
Démarrez le redis-cli (authentifié) dans le pod Redis de Paragon Pathfinder. Les arguments facultatifs sont exécutés par le pod Redis. |
pf-debugutils [arguments] |
Démarrez l’interpréteur de commandes dans le pod debugutils de Paragon Pathfinder. Les arguments optionnels sont exécutés par le shell. Les utilitaires Pathfinder debugutils sont installés s’il install_northstar_debugutils: true est configuré dans le fichier config.yml . |
ceph-tools [arguments] |
Démarrez le shell dans la boîte à outils Ceph. Les arguments optionnels sont exécutés par le shell. |
Sauvegarder l’hôte de contrôle
Vous pouvez également reconstruire l’inventaire et les fichiers config.yml en téléchargeant des informations à partir du cluster à l’aide des commandes suivantes :
# kubectl get cm -n common metadata -o jsonpath={..inventory} > inventory
# kubectl get cm -n common metadata -o jsonpath={..config_yml} > config.yml
Vous ne pouvez pas récupérer les clés SSH ; Vous devez remplacer les clés défectueuses par de nouvelles clés.
Comptes de service utilisateur pour le débogage
Paragon Pathfinder, le gestionnaire de télémétrie et les applications de la plate-forme de base utilisent en interne Paragon Insights pour la collecte de télémétrie. Pour déboguer les problèmes de configuration associés à ces applications, trois comptes de service utilisateur sont créés, par défaut, lors de l’installation de Paragon Automation. La portée de ces comptes de service est limitée au débogage de l’application correspondante uniquement. Les détails des comptes de service sont répertoriés dans le tableau suivant.
| Nom et portée de l’application Nom | d’utilisateur du compte | Mot de passe par défaut du compte |
|---|---|---|
| Paragon Pathfinder (northstar) | hb-northstar-admin | Admin123 ! |
| Gestionnaire de télémétrie (tm) | hb-tm-admin | |
| Plate-forme de base (ems-dmon) | hb-ems-dmon |
Vous devez utiliser ces comptes uniquement à des fins de débogage. N’utilisez pas ces comptes pour des opérations quotidiennes ou pour modifier une configuration. Nous vous recommandons de modifier les identifiants de connexion pour des raisons de sécurité.