このページの内容
Paragon Automationのインストールのトラブルシューティング
以下のトピックでは、インストール中およびインストール後に発生する可能性のある一般的な問題のトラブルシューティング方法について説明します。
コンフィギュレーション・ファイルのマージ競合を解決する
initスクリプトは、テンプレート設定ファイルを作成します。インストールに使用したのと同じconfig-dirディレクトリを使用して既存のインストールを更新すると、initスクリプトが作成するテンプレートファイルは既存の設定ファイルとマージされます。場合によっては、このマージアクションによって、解決しなければならないマージの競合が発生します。スクリプトは、競合を解決する方法についてプロンプトを表示します。プロンプトが表示されたら、以下のオプションの1つを選択します。
-
C - 既存の設定ファイルを保持し、新しいテンプレートファイルを破棄できます。これはデフォルトのオプションです。
-
n—既存の設定ファイルを破棄し、テンプレートファイルを再初期化できます。
-
m—ファイルを手動でマージできます。競合するセクションは、
<<<<<<<<、||||||||、========、>>>>>>>>で始まる行でマークされます。更新を続行する前に、ファイルを編集し、マージマーカーを削除する必要があります。 -
d—競合の解決方法を決定する前に、ファイル間の違いを確認できます。
バックアップと復元に関する一般的な問題を解決する
既存のクラスターを破棄し、同じクラスターノードにソフトウェアイメージを再デプロイするとします。このようなシナリオでは、以前にバックアップされた設定フォルダーから設定を復元しようとすると、復元操作が失敗することがあります。バックアップされた設定のマウントパスが変更されたため、復元操作は失敗します。既存のクラスターを破棄すると、永続ボリュームが削除されます。新しいイメージを再デプロイすると、永続ボリュームは、使用可能なスペースがあればクラスターノードの1つに再作成されますが、必ずしも以前に存在していたのと同じノードにあるとは限りません。その結果、復元操作は失敗します。
これらのバックアップと復元の問題を回避するには、次の手順に従います。
-
新しい永続ボリュームのマウントパスを決定します。
-
前の永続ボリュームのマウントパスの内容を新しいパスにコピーします。
-
復元操作を再試行してください。
インストールログファイルの表示
deployスクリプトが失敗した場合は、config-dirディレクトリ内のインストールログファイルを確認する必要があります。デフォルトでは、config-dirディレクトリには6つのzipログファイルが保存されます。現在のログファイルはlogとして保存され、以前のログファイルはlog.1からlog.5ファイルとして保存されます。deployスクリプトを実行するたびに、現在のログが保存され、最も古いログが破棄されます。
通常、エラーメッセージはログファイルの最後に表示されます。エラーメッセージを表示し、設定を修正します。
Grafanaでログファイルを表示する
Grafanaは、オープンソースのデータ可視化ツールです。Grafana UIを使用して、データの整理と理解に役立つチャート、グラフ、その他のビジュアルを作成および表示します。ダッシュボードを作成してデバイスのステータスを監視したり、UIからデータを照会したり結果を表示したりすることもできます。Grafana UIは、Paragon Automation時系列データベース(TSDB)からデータをレンダリングします。詳細については、 Grafana のドキュメントを参照してください。
Grafana アプリケーションでログを表示するには:
kubectlインターフェイスを使用したトラブルシューティング
kubectl(Kube Control)は、Kubernetes APIと対話するコマンドラインユーティリティであり、Kubernetesクラスターを制御するための最も一般的なコマンドラインです。
インストール直後にプライマリノードでkubectlコマンドを発行できます。ワーカーノードでkubectlコマンドを発行するには、 admin.conf ファイルをコピーして kubeconfig 環境変数を設定するか、 export KUBECONFIG=config-dir /admin.conf コマンドを使用する必要があります。 admin.conf ファイルは、インストールプロセスの一環として、制御ホストの config-dir ディレクトリにコピーされます。
kubectlコマンドラインツールを使用して、Kubernetes APIと通信し、ノード、ポッド、サービスなどのAPIリソースに関する情報を取得し、ログファイルを表示し、それらのリソースを作成、削除、変更します。
kubectl コマンドの構文は次のとおりです。
kubectl [command] [TYPE] [NAME] [flags]
[command]は、単に実行したいアクションです。
次のコマンドを使用して、kubectlコマンドのリストを表示できます。
root@primary-node:/# kubectl [enter]
ヘルプを求めたり、詳細を取得したり、特定のコマンドに関連するすべてのフラグとオプションをリストしたりできます。例えば：
root@primary-node:/# kubectl get -h
Paragon Automationの動作を検証してトラブルシューティングするには、以下のコマンドを使用します。
| [コマンド] | 説明 |
|---|---|
| 取得 | 1つまたは複数のリソースを表示します。 出力は、指定されたリソースに関する最も重要な情報の表を示しています。 |
| 説明 | 特定のリソースまたはリソースグループの詳細を表示します。 |
| 説明 | リソースのドキュメント化。 |
| ログ | ポッド内のコンテナーのログを表示します。 |
| ロールアウト再起動 | リソースのロールアウトを管理します。 |
| 編集 | リソースを編集します。 |
[TYPE] は、表示するリソースのタイプを表します。リソースタイプでは大文字と小文字が区別されず、単数形、複数形、または短縮形を使用できます。
たとえば、ポッド、ノード、サービス、デプロイメントなどです。リソースの完全なリストと許可される省略形(例:pod = po)については、次のコマンドを発行してください。
kubectl api-resources
リソースの詳細については、次のコマンドを発行します。
kubectl explain [TYPE]
例えば：
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] は、特定のリソースの名前(サービスやポッドの名前など)です。名前は大文字と小文字に区別されます。
root@primary-node:/# kubectl get pod pod_name
[flags]コマンドに追加オプションを提供します。たとえば、-oはリソースの属性をさらにリストします。ヘルプ(-h)を使用して、使用可能なフラグに関する情報を取得します。
ほとんどのKubernetesリソース(ポッドやサービスなど)は一部の名前空間に存在し、他の名前空間にはない(ノードなど)存在することに注意してください。
名前空間は、単一のクラスター内でリソースのグループを分離するメカニズムを提供します。リソースの名前は、名前空間内で一意である必要がありますが、名前空間全体では一意ではありません。
名前空間内のリソースでコマンドを使用する場合は、名前空間をコマンドの一部として含める必要があります。名前空間では大文字と小文字が区別されます。適切な名前空間がないと、関心のある特定のリソースが表示されない可能性があります。
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
kubectl get namespaceコマンドを発行すると、すべての名前空間のリストを取得できます。
すべての名前空間のリソースを表示する場合、または関心のある特定のリソースが属している名前空間が不明な場合は、「 --all-namespaces 」または「 - A」と入力します。
Kubernetesの詳細については、以下を参照してください。
- https://kubernetes.io/docs/reference/kubectl/overview/
- https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands
以下のトピックを使用して、kubectl インターフェイスを使用したトラブルシューティングとインストールの詳細の表示を行います。
- ノードステータスの表示
- ポッドのステータスを表示
- ポッドに関する詳細情報の表示
- Pod内のコンテナのログを表示する
- ポッド内のコンテナでコマンドを実行する
- サービスを表示
- よく使うkubectlコマンド
ノードステータスの表示
kubectl get nodesコマンド(略してkubectl get noコマンド)を使用して、クラスターノードの状態を表示します。ノードのステータスはReadyで、ロールはcontrol-planeまたはnoneのいずれかである必要があります。例えば：
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
ノードが Readyしない場合は、kubeletプロセスが実行されているかどうかを確認します。ノードのシステムログを使用して問題を調査することもできます。
kubeletを検証するには: root@primary-node:/# kubelet
ポッドのステータスを表示
ポッドのステータスを表示するには、 kubectl get po –n namespace または kubectl get po -A コマンドを使用します。個々の名前空間( healthbot、 northstar、 commonなど)を指定することも、 -A パラメーターを使用してすべての名前空間のステータスを表示することもできます。例えば：
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
正常なポッドのステータスは Running または Completed である必要があり、準備完了のコンテナーの数は合計と一致する必要があります。ポッドのステータスが Running しない場合、またはコンテナの数が一致しない場合は、 kubectl describe po または kubectl log (POD | TYPE/NAME) [-c CONTAINER] コマンドを使用して問題のトラブルシューティングをさらに進めてください。
ポッドに関する詳細情報の表示
kubectl describe po -n namespace pod-name コマンドを使用すると、特定のポッドに関する詳細情報が表示されます。例えば：
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
…
Pod内のコンテナのログを表示する
kubectl logs -n namespace pod-name [-c container-name]コマンドを使用して、特定のポッドのログを表示します。Pod に複数のコンテナーがある場合は、ログを表示するコンテナーを指定する必要があります。例えば：
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
ポッド内のコンテナでコマンドを実行する
kubectl exec –ti –n namespace pod-name [-c container-name] -- command-line コマンドを使用して、Pod 内のコンテナーでコマンドを実行します。例えば：
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#
execコマンドを実行すると、Postgresデータベースサーバーにbashシェルが取得されます。コンテナー内の bash シェルにアクセスし、コマンドを実行してデータベースに接続できます。すべてのコンテナが bash シェルを提供するわけではありません。SSHのみを提供するコンテナもあれば、シェルを持たないコンテナもあります。
サービスを表示
クラスターサービスを表示するには、 kubectl get svc -n namespace または kubectl get svc -A コマンドを使用します。個々の名前空間( healthbot、 northstar、 commonなど)を指定することも、 -A パラメーターを使用してすべての名前空間のサービスを表示することもできます。例えば：
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 …
この例では、サービスがタイプ別にソートされ、タイプ LoadBalancer のサービスのみが表示されます。クラスターによって提供されるサービスと、それらのサービスにアクセスするためにロードバランサーによって選択された外部IPアドレスを表示できます。
これらのサービスには、クラスターの外部からアクセスできます。外部IPアドレスは公開され、クラスター外のデバイスからアクセスできます。
よく使うkubectlコマンド
-
レプリケーションコントローラーを一覧表示します。
# kubectl get –n namespace deploy
# kubectl get –n namespace statefulset
-
コンポーネントを再起動します。
kubectl rollout restart –n namespace deploy deployment-name -
Kubernetesリソースの編集: デプロイメントまたは任意のKubernetes APIオブジェクトを編集でき、これらの変更はクラスターに保存されます。ただし、クラスターを再インストールしても、これらの変更は保持されません。
# kubectl edit –ti –n namespace deploy deployment-name
Paragon CLIユーティリティを使用したトラブルシューティング
paragon コマンドCLIユーティリティを導入しました。
paragon コマンドは、クラスターの分析、照会、トラブルシューティングを可能にする直感的なコマンドセットです。コマンドを実行するには、いずれかのプライマリ ノードにログインします。一部のコマンドでは、
paragon コマンドユーティリティがkubectlではなくkubecolorコマンドを実行するため、一部のコマンドの出力は色分けされています。出力例については
、図1 を参照してください。
使用可能なコマンドヘルプオプションのセット全体を表示するには、以下のコマンドのいずれかを使用します。
root@primary-node:~# paragon ? root@primary-node:~# paragon --help root@primary-node:~# paragon -h
ヘルプオプションは、どのコマンドレベルでも表示できます(最上位レベルだけでなく)。例えば：
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.
タブオプションを使用して、コマンドのオートコンプリートオプションを表示できます。トップレベル コマンドのオートコンプリートを表示するには、「 paragon 」と入力して Tab キーを押します。例えば：
root@primary-node:~# paragon ambassador describe get pathfinder set common ems insights rookceph
Paragonコマンドが実行する基になるコマンドを表示するには、echoまたは -e オプションを使用します。例えば：
root@primary-node:~# paragon -e get nodes all >>>> command: kubecolor --force-colors get nodes
Paragonコマンドを実行し、それが実行する基になるコマンドを表示するには、debugまたは -d オプションを使用します。例えば：
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
paragonコマンドの全リストと、コマンドが実行される対応する基になるコマンドを表示するには、以下を使用します。
root@primary-node:~# paragon --mapped
paragon例
各コマンドのヘルプセクションにある引数や前提条件など、特定の使用基準に関する指示に従ってください。一部のコマンドには必須の引数が必要です。たとえば、 paragon insights logs devicegroup analytical コマンドには引数 --dg devicegroup-name-with subgroup が必要です。例えば：
paragon insights logs devicegroup analytical --dg controller-0
一部のコマンドには前提条件があります。例えば、 paragon insights get playbooks コマンドを使用する前に、 paragon set username --cred username および paragon set password --cred password コマンドを使用して、ユーザー名とパスワードを設定する必要があります。
コマンドの完全なセットとその使用基準を 表 1 に示します。
| コマンド |
説明 |
|---|---|
|
|
Paragonアンバサダーの使者ポッドを表示します。 |
|
|
すべてのParagonアンバサダーポッドを表示します。 |
|
|
すべてのParagonアンバサダーサービスを表示します。 |
|
|
Postgres ロールを見つけるのに役立ちます。 |
|
|
クラスター内の特定のノードの説明を表示します。
例:
|
|
|
デバイスマネージャーのParagon emsポッドを表示します。 |
|
|
ジョブマネージャーのParagon EMSポッドを表示します。 |
|
|
すべてのParagon EMSポッドを表示します。 |
|
|
すべてのParagon EMSサービスを表示します。 |
|
|
Paragon EMSデバイスマネージャーポッドのログを表示します。
|
|
|
paragon emsジョブマネージャーポッドのログを表示します。 |
|
|
Paragonで使用可能なすべての名前空間を表示します。 |
|
|
クラスター内のすべてのノードのリストを表示します。 |
|
|
kubeletにディスク圧があるかどうかを検証します。
例: |
|
|
kubeletに十分なメモリがあるかどうかを検証します。
例: |
|
|
calico とネットワークに問題がないか確認します。
例: |
|
|
クラスター内で準備ができていないすべてのノードのリストを表示します。 |
|
|
kubeletに十分なPIDが使用可能かどうかを検証します。
例: |
|
|
クラスターで準備が整っているすべてのノードのリストを表示します。 |
|
|
ノード上のすべてのテイントのリストを表示します。 |
|
|
正常なParagonポッドをすべて表示します。 |
|
|
不健全な Paragon ポッドをすべて表示します。 |
|
|
公開されているすべてのParagonサービスを表示します。 |
|
|
Paragon InsightsアラートポッドのCLIにログインします。 |
|
|
BYOIプラグインのCLIにログインします。
|
|
|
Paragon Insights設定サーバーポッドのCLIにログインします。 |
|
|
Paragon Insights grafana ポッドの CLI にログインします。 |
|
|
Paragon Insights influxdbポッドのCLIにログインします。
例: |
|
|
Paragon Insights mgdポッドのCLIにログインします。 |
|
|
Paragon Insightsアラートポッドについて説明します。 |
|
|
Paragon Insights REST APIポッドについて説明します。 |
|
|
Paragon Insights設定サーバーポッドについて説明します。 |
|
|
Paragon Insights grafana ポッドについて説明します。 |
|
|
Paragon Insights influxdbポッドについて説明します。
例: |
|
|
Paragon Insights mgdポッドについて説明します。 |
|
|
Paragon Insightsアラートポッドを表示します。 |
|
|
Paragon Insights REST APIポッドを表示します。 |
|
|
Paragon Insights 設定サーバー ポッドを表示します。 |
|
|
すべてのParagon Insightsデバイスグループを表示します。 デフォルトのユーザー名は 前提として、 |
|
|
すべてのParagon Insightsデバイスを表示します。 デフォルトのユーザー名は 前提として、 |
|
|
Paragon Insights grafana ポッドを表示します。 |
|
|
Paragon Insights influxdbポッドを表示します。 |
|
|
Paragon Insightsネットワークテレメトリの取り込みポッドを表示します。 |
|
|
Paragon Insights mgdポッドを表示します。 |
|
|
すべてのParagon Insightsプレイブックを表示します。 デフォルトのユーザー名は 前提として、 |
|
|
すべてのParagon Insightsポッドを表示します。 |
|
|
すべてのParagon Insightsサービスを表示します。 |
|
|
Paragon Insightsアラートポッドのログを表示します。 |
|
|
Paragon Insights rest APIポッドのログを表示します。 |
|
|
Paragon Insights BYOIプラグインのログを表示します。
|
|
|
Paragon Insights 設定サーバー ポッドのログを表示します。 |
|
|
サービス分析エンジン用のParagon Insightsデバイスグループのログを表示します。
例: この例では、 controller はデバイスグループ名で、 0 はサブグループです。 |
|
|
サービスitsdbのParagon Insightsデバイスグループのログを表示します。
例: この例では、 controller はデバイスグループ名で、 0 はサブグループです。 |
|
|
サービスjtimonのParagon Insightsデバイスグループのログを表示します。
例: この例では、 controller はデバイスグループ名で、 0 はサブグループです。 |
|
|
サービスjtiネイティブのParagon Insightsデバイスグループのログを表示します。
例: この例では、 controller はデバイスグループ名で、 0 はサブグループです。 |
|
|
サービスsyslog用のParagon Insightsデバイスグループのログを表示します。
例: この例では、 controller はデバイスグループ名で、 0 はサブグループです。 |
|
|
Paragon Insights Grafana ポッドのログを表示します。 |
|
|
Paragon Insights influxdbポッドのログを表示します。
例: |
|
|
Paragon Insights mgdポッドのログを表示します。 |
|
|
Paragon Pathfinder BMPコンテナのCLIにログインします。 |
|
|
Paragon Pathfinder ns-configserverコンテナのCLIにログインします。 |
|
|
Paragon Pathfinder cRPDコンテナのCLIにログインします。 |
|
|
Paragon Pathfinder debugutilsコンテナのCLIにログインします。 |
|
|
Paragon Pathfinder netconfコンテナのCLIにログインします。 |
|
|
Paragon Pathfinder ns-pceserverコンテナ(PCEP)サービスのCLIにログインします。 |
|
|
Paragon Pathfinder ns-pcserver(PCS)コンテナのCLIにログインします。 |
|
|
Paragon Pathfinder ns-pcsviewer(Paragon Plannerデスクトップアプリケーション)コンテナのCLIにログインします。 |
|
|
paragon pathfinderスケジューラコンテナのCLIにアクセスします。 |
|
|
Paragon Pathfinder ns-toposerver(トポロジーサービス)コンテナのCLIにログインします。 |
|
|
Paragon Pathfinder ns-webコンテナのCLIにログインします。 |
|
|
BGP-LS に関連する Paragon Pathfinder cRPD ルーティング オプション設定をデバッグします。 |
|
|
BGP-LS に関連する Paragon Pathfinder cRPD ルートをデバッグします。 |
|
|
Paragon Pathfinder debugutils genjvisiondata ヘルプを表示します。 |
|
|
Paragon Pathfinder debugutils genjvisiondata パラメータを表示します。 |
|
|
デバッグのために Paragon Pathfinder PCEP CLI にログインします。 |
|
|
KubernetesクラスターのPostgresステータスを表示します。 |
|
|
rabbitmqctl クラスターのステータスを表示します。 |
|
|
Paragon Pathfinder debugutils ポッドを実行して、AMQP 間でやりとりされるデータをスヌーピングしてデコードします。 |
|
|
Paragon Pathfinderのdebugutilsスヌープヘルプを表示します。 |
|
|
Paragon Pathfinder debugutils podを実行して、Postgres間でやり取りされるデータをスヌーピングしてデコードします。 |
|
|
Paragon Pathfinder debugutils podを実行して、Redisリンク間でやり取りされるデータをスヌーピングしてデコードします。 |
|
|
Paragon Pathfinder debugutils podを実行して、Redis lsp 間でやり取りされるデータをスヌーピングしてデコードします。 |
|
|
Paragon Pathfinder debugutils podを実行して、redisノード間でやり取りされるデータをスヌーピングしてデコードします。 |
|
|
debugutils Paragon Pathfinderヘルプtopo_utilを示します。 |
|
|
debugutils Paragon Pathfinderセーフモードを無効にするためのツールtopo_util示します。 |
|
|
debugutils topo_utilツールParagon Pathfinder実行して、現在のトポロジーを更新します。 |
|
|
debugutils topo_utilツールParagon Pathfinder実行して、現在のトポロジースナップショットを保存します。 |
|
|
cRPDおよびBMPコンテナを含むParagon Pathfinderポッドについて説明します。 |
|
|
構成サーバーコンテナを含むParagon Pathfinderポッドについて説明します。 |
|
|
debugutilsコンテナを含むParagon Pathfinderポッドについて説明します。 |
|
|
ns-netconfdコンテナを含むParagon Pathfinderポッドについて説明します。 |
|
|
ns-pceserverコンテナ(PCEPサービス)を含むParagon Pathfinderポッドについて説明します。 |
|
|
ns-pcserver コンテナ(PCS)を含む Paragon Pathfinder ポッドについて説明します。 |
|
|
ns-pcsviewerコンテナ(Paragon Plannerデスクトップアプリケーション)を含むParagon Pathfinderポッドについて説明します。 |
|
|
スケジューラコンテナを含むParagon Pathfinderポッドについて説明します。 |
|
|
ns-toposerver(トポロジーサービス)コンテナを含むParagon Pathfinderポッドについて説明します。 |
|
|
Webコンテナを含むParagon Pathfinderポッドについて説明します。 |
|
|
cRPDおよびBMPコンテナを含むParagon Pathfinderポッドを表示します。 |
|
|
ns-configserver コンテナと syslog コンテナを含む Paragon Pathfinder ポッドを表示します。 |
|
|
debugutilsコンテナを含むParagon Pathfinderポッドを表示します。 |
|
|
netconfプロセスに関連付けられたParagon Pathfinderポッドを表示します。 |
|
|
ns-pceserverコンテナ(PCEPサービス)を含むParagon Pathfinderポッドを表示します。 |
|
|
ns-pcserver コンテナ(PCS)を含む Paragon Pathfinder ポッドを表示します。 |
|
|
ns-pcsviewerコンテナ(Paragon Plannerデスクトップアプリケーション)を含むParagon Pathfinderポッドを表示します。 |
|
|
すべてのParagon Pathfinderポッドを表示します。 |
|
|
スケジューラプロセスに関連付けられたParagon Pathfinderポッドを表示します。 |
|
|
すべてのParagon Pathfinderサービスを表示します。 |
|
|
ns-toposerverコンテナ(トポロジーサービス)を含むParagon Pathfinderポッドを表示します。 |
|
|
ns-webプロセスに関連付けられたParagon Pathfinderポッドを表示します。 |
|
|
Paragon Pathfinder bmpポッドbmpコンテナのログを表示します。 |
|
|
Paragon Pathfinder bmpポッドcRPDコンテナのログを表示します。 |
|
|
Paragon Pathfinder bmpポッドsyslogコンテナのログを表示します。 |
|
|
Paragon Pathfinder configserver ポッド ns-configserver コンテナのログを表示します。 |
|
|
Paragon Pathfinder configserver ポッドの syslog コンテナのログを表示します。 |
|
|
Paragon Pathfinderのnetconfポッドns-netconfdコンテナのログを表示します。 |
|
|
Paragon Pathfinderのnetconfポッドsyslogコンテナのログを表示します。 |
|
|
Paragon Pathfinder pceserver ポッド ns-pceserver コンテナのログを表示します。 |
|
|
Paragon Pathfinder pceserver pods syslogコンテナのログを表示します。 |
|
|
タイムスタンプ、レベル、メッセージのみを取得する Paragon Pathfinder pceserver ポッド syslog コンテナの処理済みログを表示します。 |
|
|
Paragon Pathfinder pcserver ポッド ns-pcserver コンテナのログを表示します。 |
|
|
Paragon Pathfinder pcserver ポッドの syslog コンテナのログを表示します。 |
|
|
タイムスタンプ、レベル、メッセージのみを含む Paragon Pathfinder pceServer Pods syslog コンテナ取得の処理済みログを表示します。 |
|
|
Paragon Pathfinder pcviewerポッドns-pcviewerコンテナのログを表示します。 |
|
|
Paragon Pathfinder pcviewerポッドsyslogコンテナのログを表示します。 |
|
|
Paragon Pathfinderトポサーバーポッドns-topo-dbinitコンテナのログを表示します。 |
|
|
Paragon Pathfinderトポサーバーポッドns-topo-dbinit-cacheコンテナのログを表示します。 |
|
|
Paragon Pathfinder toposerver Pods ns-toposerver コンテナのログを表示します。 |
|
|
Paragon Pathfinderトポサーバーポッドsyslogコンテナのログを表示します。 |
|
|
Paragon Pathfinderトポサーバーポッドsyslogコンテナフェッチの処理済みログを、タイムスタンプ、レベル、メッセージのみで表示します。 |
|
|
Paragon Pathfinder Web ポッドの ns-web コンテナのログを表示します。 |
|
|
Paragon Pathfinder Web ポッド ns-web-dbinit コンテナのログを表示します。 |
|
|
Paragon Pathfinder Web Podのsyslogコンテナのログを表示します。 |
|
|
フェデレーションステータスを表示します(rabbitmq-0インスタンスから)。GeoHaステータスは、デュアルクラスター設定でのみ使用できます。 |
|
|
Rook および Ceph OSD ファイルシステムのディスク容量の使用状況を報告します。 |
|
|
Rook および Ceph OSD プール統計情報を表示します。 |
|
|
Rook および Ceph OSD ステータスを表示します。 |
|
|
RookとCephのOSDツリーを表示します。 |
|
|
Rook および Ceph OSD の使用率を示します。 |
|
|
Rook と Ceph の pg ステータスを表示します。 |
|
|
Rook と Ceph のステータスを表示します。 |
|
|
Rook および Ceph ツールボックス ポッドの CLI にログインします。 |
|
|
Rook および Ceph ポッドを表示します。 |
|
|
Rook および Ceph サービスを表示します。 |
|
|
これは、期間情報を取得するRADOSゲートウェイユーザー管理ユーティリティです。 |
|
|
これは、メタデータ同期ステータスを取得するRADOSゲートウェイユーザー管理ユーティリティです。 |
|
|
RESTコール認証用のParagon(UIホスト)パスワードを設定します。 この必須のワンタイムパスワード設定コマンドを使用して、 例: |
|
|
Rest呼び出し認証用のParagon(UIホスト)ユーザー名を設定します。デフォルトのユーザー名は
例: |
Ceph と Rook のトラブルシューティング
Ceph には、比較的新しいカーネルバージョンが必要です。Linux カーネルが非常に古い場合は、新しいカーネルをアップグレードまたは再インストールすることを検討してください。
このセクションでは、Ceph と Rook に関する問題のトラブルシューティングを行います。
ディスク容量が不足しています
インストールに失敗する一般的な理由は、オブジェクトストレージデーモン(OSD)が作成されていないことです。OSDは、クラスターノード上のストレージを設定します。OSD は、リソースが不足しているか、ディスク領域が正しくパーティション化されていないという形で、ディスクリソースが利用できないために作成されない場合があります。ノードにパーティション化されていないディスク領域が十分にあることを確認します。
ディスクの再フォーマット
「rook-ceph-osd-prepare-hostname-*」ジョブのログを調べます。ログは記述的なものです。ディスクまたはパーティションを再フォーマットし、Rookを再起動する必要がある場合は、次の手順を実行します。
- 以下の方法のいずれかを使用して、既存のディスクまたはパーティションを再フォーマットします。
- Ceph に使用されるはずのブロックストレージデバイスが、使用不能な状態であったために使用されなかった場合は、ディスクを完全に再フォーマットできます。
$ sgdisk -zap /dev/disk $ dd if=/dev/zero of=/dev/disk bs=1M count=100
- Ceph に使用するはずのディスクパーティションがある場合は、パーティション上のデータを完全にクリアできます。
$ wipefs -a -f /dev/partition $ dd if=/dev/zero of=/dev/partition bs=1M count=100
注:これらのコマンドは、使用しているディスクまたはパーティションを完全に再フォーマットし、それらの上のすべてのデータを失います。
- Ceph に使用されるはずのブロックストレージデバイスが、使用不能な状態であったために使用されなかった場合は、ディスクを完全に再フォーマットできます。
- Rookを再起動して変更を保存し、OSD作成プロセスを再試行します。
$ kubectl rollout restart deploy -n rook-ceph rook-ceph-operator
ポッドのステータスを表示
rook-ceph 名前空間にインストールされている Rook および Ceph Pod のステータスを確認するには、# kubectl get po -n rook-ceph コマンドを使用します。次のポッドはrunning状態である必要があります。
rook-ceph-mon-*—通常、3つのモニターポッドが作成されます。rook-ceph-mgr-*—1つのマネージャーポッドrook-ceph-osd-*—3つ以上のOSDポッドrook-ceph-mds-cephfs-*—メタデータサーバーrook-ceph-rgw-object-store-*- ObjectStore ゲートウェイrook-ceph-tools*—追加のデバッグオプション。ツールボックスに接続するには、次のコマンドを使用します。
$ kubectl exec -ti -n rook-ceph $(kubectl get po -n rook-ceph -l app=rook-ceph-tools \ -o jsonpath={..metadata.name}) -- bashツールボックスで使用できる一般的なコマンドには、次のものがあります。
# ceph status # ceph osd status, # ceph osd df, # ceph osd utilization, # ceph osd pool stats, # ceph osd tree, and # ceph pg stat
Ceph OSD 障害のトラブルシューティング
rook-ceph名前空間にインストールされているポッドのステータスを確認します。
# kubectl get po -n rook-ceph
rook-ceph-osd-* ポッドがErrorまたはCrashLoopBackoff状態の場合は、ディスクを修復する必要があります。
-
rook-ceph-operatorを停止します。# kubectl scale deploy -n rook-ceph rook-ceph-operator --replicas=0 -
失敗したOSDプロセスを削除します。
# kubectl delete deploy -n rook-ceph rook-ceph-osd-number -
ツールボックスに接続します。
$ kubectl exec -ti -n rook-ceph $(kubectl get po -n rook-ceph -l app=rook-ceph-tools -o jsonpath={..metadata.name}) -- bash -
障害が発生しているOSDを特定します。
# ceph osd status -
失敗したOSDをマークします。
[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
-
障害が発生したOSDを削除します。
# ceph osd purge number --yes-i-really-mean-it - 障害が発生したOSDをホストしたノードに接続し、以下のいずれかを実行します。
- ハードウェアに障害が発生した場合は、ハードディスクを交換してください。
- ディスクを完全に再フォーマットします。
$ sgdisk -zap /dev/disk $ dd if=/dev/zero of=/dev/disk bs=1M count=100
- パーティションを完全に再フォーマットします。
$ wipefs -a -f /dev/partition $ dd if=/dev/zero of=/dev/partition bs=1M count=100
-
rook-ceph-operator再起動します。# kubectl scale deploy -n rook-ceph rook-ceph-operator --replicas=1 -
OSD ポッドを監視します。
# kubectl get po -n rook-cephOSDが回復しない場合は、同じ手順でOSDを削除し、ディスクを削除するかパーティションを削除してから
rook-ceph-operator再起動します。
エアギャップ設置失敗のトラブルシューティング
既存の/etc/resolv.confファイルがないため、エアギャップのインストールとkube-apiserverは次のエラーで失敗します。
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>
新しいファイルを作成するには、root ユーザーとして #touch /etc/resolv.conf コマンドを実行し、Paragon Automation クラスターを再デプロイする必要があります。
RabbitMQクラスター障害からの復旧
この状態を確認するには、 kubectl get po -n northstar -l app=rabbitmq コマンドを実行します。このコマンドでは、ステータスが Running という 3 つのポッドが表示されます。例えば：
$ 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
ただし、1 つ以上のポッドのステータスが Error の場合は、次のリカバリー手順を使用します。
-
RabbitMQを削除します。
kubectl delete po -n northstar -l app=rabbitmq -
ポッドのステータスを確認します。
kubectl get po -n northstar -l app=rabbitmq。すべてのポッドのステータスが
Runningになるまで、kubectl delete po -n northstar -l app=rabbitmqを繰り返します。 -
Paragon Pathfinderアプリケーションを再起動します。
kubectl rollout restart deploy -n northstar
OSD 作成中に udevd デーモンを無効にする
udevdデーモンは、ディスク、ネットワークカード、CDなどの新しいハードウェアの管理に使用します。OSD の作成中に、
udevd デーモンは OSD を検出し、完全に初期化される前に OSD をロックできます。Paragon Automation インストーラーは、インストール中に
systemd-udevd を無効にし、Rook が OSD を初期化した後に有効にします。
ノードを追加または置き換えたり、障害が発生したノードを修復したりする場合は、OSD の作成が失敗しないように、 udevd デーモンを手動で無効にする必要があります。OSDの作成後にデーモンを再度有効にできます。
これらのコマンドを使用して、 udevdを手動で無効または有効にします。
- 追加または修復するノードにログインします。
udevdデーモンを無効にします。- udevd が実行されているかどうかを確認します。
# systemctl is-active systemd-udevd udevdアクティブになっている場合は無効にします# systemctl mask system-udevd --now
- udevd が実行されているかどうかを確認します。
-
ノードを修復または交換しても、Ceph 分散ファイルシステムは自動的に更新されません。修復プロセスの一環としてデータディスクが破棄された場合は、それらのデータディスクでホストされているオブジェクトストレージデーモン(OSD)を復元する必要があります。
-
Ceph ツールボックスに接続し、OSD のステータスを表示します。
ceph-toolsスクリプトがプライマリノードにインストールされます。プライマリノードにログインし、kubectlインターフェイスを使用してceph-toolsにアクセスできます。プライマリ ノード以外のノードを使用するには、 admin.conf ファイル(制御ホストの config-dir ディレクトリ内)をコピーしてkubeconfig環境変数を設定するか、export KUBECONFIG=config-dir/admin.confコマンドを使用する必要があります。$ ceph-tools# ceph osd status -
すべてのOSDが
exists,upとしてリストされていることを確認します。OSD が損傷している場合は、 Ceph および Rook のトラブルシューティングで説明されているトラブルシューティング手順に従ってください。
-
- すべてのOSDが作成されていることを確認した後、追加または修復したノードにログインします。
-
ノードで
udevdを再度有効にします。systemctl unmask system-udevd
disable_udevd: trueを設定して、
./run -c config-dir deployコマンドを実行することもできます。
udevdデーモンを無効にするためだけにクラスターを再デプロイすることはお勧めしません。
一般的なユーティリティコマンドのラッパースクリプト
| コマンド | の説明 |
|---|---|
paragon-db [arguments] |
データベースサーバーに接続し、スーパーユーザーアカウントを使用してPostgres SQLシェルを起動します。オプションの引数は、Postgres SQL コマンドに渡されます。 |
pf-cmgd [arguments] |
Paragon PathfinderのCMGDポッドでCLIを起動します。オプションの引数は、CLIによって実行されます。 |
pf-crpd [arguments] |
Paragon Pathfinder cRPDポッドでCLIを起動します。オプションの引数は、CLIによって実行されます。 |
pf-redis [arguments] |
Paragon Pathfinder Redisポッドで(認証された)redis-cliを起動します。オプションの引数は、Redis Pod によって実行されます。 |
pf-debugutils [arguments] |
Paragon Pathfinderのdebugutilsポッドでシェルを起動します。オプションの引数はシェルによって実行されます。Pathfinder debugutils ユーティリティは、config.yml ファイルで設定されている場合install_northstar_debugutils: trueインストールされます。 |
ceph-tools [arguments] |
シェルを起動して Ceph ツールボックスを作成します。オプションの引数はシェルによって実行されます。 |
制御ホストをバックアップする
または、以下のコマンドを使用してクラスターから情報をダウンロードすることで、 インベントリ と config.yml ファイルを再構築することもできます。
# kubectl get cm -n common metadata -o jsonpath={..inventory} > inventory
# kubectl get cm -n common metadata -o jsonpath={..config_yml} > config.yml
SSHキーは復元できません。失敗したキーを新しいキーと置き換える必要があります。
デバッグ用のユーザーサービスアカウント
Paragon Pathfinder、テレメトリマネージャー、およびベースプラットフォームアプリケーションは、内部でテレメトリ収集にParagon Insightsを使用します。これらのアプリケーションに関連する設定の問題をデバッグするために、Paragon Automationのインストール中にデフォルトで3つのユーザーサービスアカウントが作成されます。これらのサービスアカウントの範囲は、対応するアプリケーションのデバッグのみに限定されます。サービスアカウントの詳細を以下の表に示します。
| アプリケーション名と範囲 | アカウントユーザー名 | アカウント デフォルトパスワード |
|---|---|---|
| Paragon Pathfinder(ノーススター) | hb-northstar-admin | 管理者123! |
| テレメトリマネージャー(tm) | hb-tm-admin | |
| ベースプラットフォーム(ems-dmon) | HB-EMS-DMON |
これらのアカウントは、デバッグ目的にのみ使用する必要があります。これらのアカウントを日常的な運用や設定の変更に使用しないでください。セキュリティ上の理由から、ログイン資格情報を変更することをお勧めします。