Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Paragon Automationのインストールのトラブルシューティング

概要 以下のトピックを読んで、インストール中およびインストール後に発生する可能性のある一般的な問題のトラブルシューティング方法について説明します。

構成ファイルのマージの競合を解決する

このスクリプトによって init 、テンプレート構成ファイルが作成されます。インストールに使用したのと同じ config-dir ディレクトリを使用して既存のインストールを更新する場合、スクリプトが init 作成するテンプレート ファイルは既存の構成ファイルとマージされます。場合によっては、このマージ アクションによって、解決が必要なマージの競合が発生します。スクリプトは、競合を解決する方法についてプロンプトを表示します。プロンプトが表示されたら、次のいずれかのオプションを選択します。

  • C - 既存のコンフィギュレーション ファイルを保持し、新しいテンプレート ファイルを破棄できます。これはデフォルトのオプションです。

  • n:既存のコンフィギュレーション ファイルを破棄し、テンプレート ファイルを再初期化できます。

  • m - ファイルを手動でマージできます。競合するセクションは、"<<<<<<<<"、"||||||||"、"========"、および ">>>>>>>>" で始まる行でマークされます。更新を続行する前に、ファイルを編集し、差し込みマーカーを削除する必要があります。

  • d - 競合の解決方法を決定する前に、ファイル間の相違点を表示できます。

バックアップと復元に関する一般的な問題の解決

既存のクラスタを破棄し、同じクラスタ ノードにソフトウェア イメージを再展開するとします。このような場合、以前にバックアップした設定フォルダから設定を復元しようとすると、復元操作が失敗することがあります。バックアップされた構成のマウント パスが変更されているため、復元操作が失敗します。既存のクラスターを破棄すると、永続ボリュームは削除されます。新しいイメージを再デプロイすると、永続ボリュームは、使用可能な領域があるクラスター ノードの 1 つに再作成されますが、必ずしも以前と同じノードに存在する必要はありません。その結果、復元操作は失敗します。

これらのバックアップと復元の問題を回避するには:

  1. 新しい永続ボリュームのマウント パスを決定します。

  2. 以前の永続ボリュームのマウントパスの内容を新しいパスにコピーします。

  3. 復元操作を再試行します。

インストールログファイルの表示

スクリプトが失敗した場合deployは、ディレクトリ内のconfig-dirインストール ログ ファイルを確認する必要があります。既定では、ディレクトリには config-dir 6 つの圧縮されたログ ファイルが格納されます。現在のログ ファイルは log として保存され、以前のログ ファイルは log.1 から log.5 ファイルとして保存されます。 スクリプトを実行するdeployたびに、現在のログが保存され、最も古いログは破棄されます。

通常、エラー メッセージはログ ファイルの末尾にあります。エラー メッセージを表示し、構成を修正します。

キバナでログファイルを表示する

Open ディストリビューションを使用して、アプリケーション ログを統合し、インデックスを作成します。Kibana アプリケーションは、キーワードとフィルターを使用してログを検索するために使用できる視覚化ツールです。

Kibana アプリケーションでログを表示するには:

  1. Kibana にアクセスするには、次のいずれかの方法を使用します。
    • イングレス コントローラーの仮想 IP(VIP)アドレスを使用する: ブラウザーを開き、[URL] フィールドに 「https://vip-of-ingress-controller-or-hostname-of-main-web-application/kibana 」と入力します。
    • [ログ] ページを使用する:Paragon Automation UIで、左側のナビゲーション バーにある [ ログ>監視 ] をクリックします。
  2. opendistro_es_admin_userインストール時に config.yml ファイルで設定したユーザー名とパスワードopendistro_es_admin_passwordを入力します。デフォルトのユーザー名は admin です。

    パスワードを構成 opendistro_es_admin_password しない場合、インストーラーはランダムなパスワードを生成します。パスワードは、次のコマンドを使用して取得できます。

    # kubectl -n kube-system get secret opendistro-es-account -o jsonpath={..password} | base64 -d

  3. 初めてログインする場合は、[インデックス パターンの作成] オプションをクリックしてインデックス パターンを作成します。
  4. 索引パターン名」フィールドに logstash-* と入力し、「次のステップ>」をクリックします。
  5. [時間フィールド] ボックスの一覧から [@timestamp] を選択し、[インデックス パターンの作成] をクリックしてインデックス パターンを作成します。
  6. ハンバーガー アイコンをクリックし、左側のナビゲーション バーから [検出] を選択してログ ファイルを参照し、必要に応じてフィルターを追加または削除します。

kubectl インターフェイスを使用したトラブルシューティング

kubectl(Kube Control)は、Kubernetes APIと対話するコマンドラインユーティリティであり、最も一般的なコマンドラインはKubernetesクラスターを制御するために使用されました。

kubectl コマンドは、インストール直後に 1 次ノードで発行できます。ワーカー ノードで kubectl コマンドを発行するには、admin.conf ファイルをコピーして環境変数を設定するkubeconfigか、エクスポート 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]

例えば:

[NAME] は、特定のリソースの名前 (サービスやポッドの名前など) です。名前では大文字と小文字が区別されます。

root@primary-node:/# kubectl get pod pod_name

[flags] コマンドの追加オプションを提供します。たとえば、リソースの -o より多くの属性を一覧表示します。help(-h)を使用して、使用可能なフラグに関する情報を取得します。

ほとんどの Kubernetes リソース (ポッドやサービスなど) は一部の名前空間にありますが、他の名前空間 (ノードなど) にはないことに注意してください。

名前空間は、1 つのクラスター内でリソースのグループを分離するためのメカニズムを提供します。リソースの名前は、名前空間内で一意である必要がありますが、名前空間間で一意である必要はありません。

名前空間内のリソースでコマンドを使用する場合は、コマンドの一部として名前空間を含める必要があります。名前空間では大文字と小文字が区別されます。適切な名前空間がないと、目的の特定のリソースが表示されない場合があります。

コマンドを発行 kubectl get namespace すると、すべての名前空間の一覧を取得できます。

すべての名前空間のリソースを表示する場合、または関心のある特定のリソースがどの名前空間に属しているかわからない場合は、 または - Aを入力--all-namespacesできます。

Kubernetes の詳細については、以下を参照してください。

kubectl インターフェイスを使用してインストールの詳細をトラブルシューティングおよび表示するには、次のトピックを使用します。

ノードステータスの表示

kubectl get nodesコマンド(コマンドとkubectl get no略される)を使用して、クラスターノードのステータスを表示します。ノードのステータスは でなければならずReady、役割は または noneのいずれかでなければなりませんcontrol-plane。例えば:

ノードが でない場合は Ready、kubeletプロセスが実行されているかどうかを確認します。ノードのシステム ログを使用して問題を調査することもできます。

kubeletを検証するには: root@primary-node:/# kubelet

ポッドのステータスの表示

kubectl get po –n namespaceまたは kubectl get po -A コマンドを使用して、ポッドのステータスを表示します。個々の名前空間 (healthbotnorthstarcommon、 など) を指定することも、このパラメーター-Aを使用してすべての名前空間の状態を表示することもできます。例えば:

正常なポッドの状態は または Completedである必要がありRunning、準備完了コンテナーの数は合計と一致する必要があります。ポッドのステータスが でない場合Running、またはコンテナの数が一致しない場合は、 kubectl describe po または kubectl log (POD | TYPE/NAME) [-c CONTAINER] コマンドを使用して問題をさらにトラブルシューティングします。

ポッドに関する詳細情報の表示

kubectl describe po -n namespace pod-nameコマンドを使用して、特定のポッドに関する詳細情報を表示します。例えば:

ポッド内のコンテナーのログを表示する

kubectl logs -n namespace pod-name [-c container-name]コマンドを使用して、特定のポッドのログを表示します。ポッドに複数のコンテナーがある場合は、ログを表示するコンテナーを指定する必要があります。例えば:

ポッド内のコンテナーでコマンドを実行する

kubectl exec –ti –n namespacepod-name [-c container-name] -- command-lineコマンドを使用して、ポッド内のコンテナーでコマンドを実行します。例えば:

execコマンドを実行すると、Postgresデータベースサーバーにbashシェルが取得されます。コンテナー内の bash シェルにアクセスし、コマンドを実行してデータベースに接続できます。すべてのコンテナがbashシェルを提供するわけではありません。一部のコンテナはSSHのみを提供し、一部のコンテナにはシェルがありません。

サービスを見る

または kubectl get svc -A コマンドを使用して、kubectl get svc -n namespaceクラスター・サービスを表示します。個別の名前空間 (healthbotnorthstarcommon、 など) を指定することも、このパラメーター-Aを使用してすべての名前空間のサービスを表示することもできます。例えば:

この例では、サービスはタイプ別にソートされ、タイプの LoadBalancer サービスのみが表示されます。クラスターによって提供されるサービスと、それらのサービスにアクセスするためにロードバランサーによって選択された外部 IP アドレスを表示できます。

これらのサービスには、クラスターの外部からアクセスできます。外部 IP アドレスは公開され、クラスター外のデバイスからアクセスできます。

頻繁に使用される kubectl コマンド

  • レプリケーション コントローラーを一覧表示します。

  • コンポーネントを再起動します。

  • Kubernetes リソースの編集: デプロイまたは任意の Kubernetes API オブジェクトを編集でき、これらの変更はクラスターに保存されます。ただし、クラスターを再インストールした場合、これらの変更は保持されません。

CephとRookのトラブルシューティング

Cephには、比較的新しいカーネルバージョンが必要です。Linuxカーネルが非常に古い場合は、新しいカーネルのアップグレードまたは再インストールを検討してください。

このセクションを使用して、CephとRookに関する問題のトラブルシューティングを行います。

ディスク容量の不足

インストールが失敗する一般的な理由は、オブジェクトストレージデーモン(OSD)が作成されないことです。OSDは、クラスタノード上のストレージを設定します。OSDは、リソースが不足しているか、ディスク領域が正しくパーティション化されていないという形で、ディスクリソースが利用できないために作成されない可能性があります。ノードに十分な空きディスク・スペースがあることを確認します。

ディスクを再フォーマットする

「rook-ceph-osd-prepare-hostname-*」ジョブのログを調べます。ログは説明的です。ディスクまたはパーティションを再フォーマットしてRookを再起動する必要がある場合は、次の手順を実行します。

  1. 次のいずれかの方法を使用して、既存のディスクまたはパーティションを再フォーマットします。
    • Cephに使用するはずだったブロックストレージデバイスがあるが、使用できない状態であったために使用されなかった場合は、ディスクを完全に再フォーマットできます。
    • Cephに使用するはずのディスクパーティションがある場合は、パーティション上のデータを完全にクリアできます。
    メモ:

    これらのコマンドは、使用しているディスクまたはパーティションを完全に再フォーマットし、それらの上のすべてのデータが失われます。

  2. Rookを再起動して変更を保存し、OSDの作成プロセスを再試行します。

ポッドのステータスの表示

名前空間にインストールされている rook-ceph RookポッドとCephポッドのステータスを確認するには、 コマンドを使用します # 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-*- オブジェクトストア・ゲートウェイ
  • 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 状態の場合は、ディスクを修復する必要があります。

  1. を停止 rook-ceph-operatorします。

    # kubectl scale deploy -n rook-ceph rook-ceph-operator --replicas=0

  2. 問題のあるOSDプロセスを削除します。

    # kubectl delete deploy -n rook-ceph rook-ceph-osd-number

  3. ツールボックスに接続します。

    $ kubectl exec -ti -n rook-ceph $(kubectl get po -n rook-ceph -l app=rook-ceph-tools -o jsonpath={..metadata.name}) -- bash

  4. 問題のあるOSDを特定します。

    # ceph osd status

  5. 障害が発生したOSDをマークアウトします。

  6. 障害が発生したOSDを取り外します。

    # ceph osd purge number --yes-i-really-mean-it

  7. 障害が発生したOSDをホストしていたノードに接続し、次のいずれかを実行します。
    • ハードウェア障害が発生した場合にハードディスクを交換してください。
    • ディスクを完全に再フォーマットします。
    • パーティションを完全に再フォーマットします。
  8. 再起動します rook-ceph-operator

    # kubectl scale deploy -n rook-ceph rook-ceph-operator --replicas=1

  9. OSDポッドを監視します。

    # kubectl get po -n rook-ceph

    OSDが回復しない場合は、同じ手順でOSDを取り外し、ディスクを取り外すかパーティションを削除してから再起動 rook-ceph-operatorします。

エアギャップ設置失敗のトラブルシューティング

エアギャップのインストール kube-apiserver と は、既存の /etc/resolv.conf ファイルがないため、次のエラーで失敗します。

新しいファイルを作成するには、rootユーザーとしてコマンドを実行し、Paragon Automationクラスタを再デプロイする必要があります #touch /etc/resolv.conf

RabbitMQ クラスターの障害から復旧する

Paragon Automationクラスタに障害が発生した場合(停電など)、RabbitMQメッセージバスが正しく再起動しないことがあります。

この状態を確認するには、 コマンドを実行します kubectl get po -n northstar -l app=rabbitmq 。このコマンドにより、状態 Runningが . として 3 つのポッドが表示されます。例えば:

ただし、1 つ以上のポッド Errorのステータスが の場合は、次のリカバリ手順を使用します。

  1. RabbitMQを削除します。

    kubectl delete po -n northstar -l app=rabbitmq

  2. ポッドの状態を確認します。

    kubectl get po -n northstar -l app=rabbitmq.

    すべてのポッドのステータスが になるまで繰り返し kubectl delete po -n northstar -l app=rabbitmq ます Running

  3. Paragon Pathfinderアプリケーションを再起動します。

OSD作成中にudevdデーモンを無効にする

デーモンは udevd 、ディスク、ネットワークカード、CD などの新しいハードウェアを管理するために使用します。OSDの作成中に、デーモンは udevd OSDを検出し、完全に初期化される前にロックできます。Paragon Automationインストーラは systemd-udevd インストール中に無効になり、RookがOSDを初期化した後に有効になります。

ノードを追加または交換し、障害が発生したノードを修復する場合は、OSDの作成が失敗しないように、デーモンを手動で無効に udevd する必要があります。OSDの作成後にデーモンを再度有効にすることができます。

これらのコマンドを使用して、 を手動で無効または有効に udevdします。

  1. 追加または修復するノードにログインします。
  2. デーモンを無効にします udevd
    1. udevdが実行されているかどうかを確認してください。

      # systemctl is-active systemd-udevd

    2. がアクティブな場合は udevd 、無効にします。 # systemctl mask system-udevd --now
  3. ノードを修復または交換しても、Ceph分散ファイルシステムは自動的に更新されません。修復プロセスの一環としてデータ・ディスクが破壊された場合は、それらのデータ・ディスクでホストされているオブジェクト・ストレージ・デーモン(OSD)をリカバリする必要があります。

    1. Cephツールボックスに接続し、OSDのステータスを表示します。スクリプトは ceph-tools プライマリノードにインストールされます。プライマリノードにログインし、kubectl インターフェイス ceph-toolsを使用して にアクセスできます。1 次ノード以外のノードを使用するには、 admin.conf ファイル(制御ホスト上のディレクトリー内 config-dir )をコピーして環境変数を設定するか、 kubeconfig コマンドを使用する必要があります export KUBECONFIG=config-dir/admin.conf

      $ ceph-tools# ceph osd status

    2. すべてのOSDがとして表示 exists,upされていることを確認します。OSDが破損している場合は、 CephとRookのトラブルシューティングで説明されているトラブルシューティング手順に従ってください。

  4. すべてのOSDが作成されたことを確認した後、追加または修復したノードにログインします。
  5. ノードで再度有効にします udevd

    systemctl unmask system-udevd

または、 config.ymlで設定 disable_udevd: trueしてコマンドを実行 ./run -c config-dir deployすることもできます。デーモンを無効にする udevdためだけにクラスターを再デプロイすることはお勧めしません。

共通ユーティリティコマンドのラッパースクリプト

/ usr/local/bin にインストールされている以下のラッパースクリプトを使用して、システムで実行されているポッドに接続してコマンドを実行できます。
コマンド の説明
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 ポッドによって実行されます。
pf-debugutils [arguments] Paragon Pathfinder debugutils ポッドでシェルを起動します。オプションの引数はシェルによって実行されます。Pathfinder debugutils ユーティリティは、config.yml ファイルで設定されている場合install_northstar_debugutils: trueにインストールされます。
ceph-tools [arguments] シェルを起動してCephツールボックスに移動します。オプションの引数はシェルによって実行されます。

制御ホストのバックアップ

制御ホストに障害が発生した場合は、クラスターを再構築できるように、 config-dir ディレクトリをリモートの場所にバックアップする必要があります。には config-dirインベントリconfig.ymlid_rsa ファイルが含まれています。

または、次のコマンドを使用してクラスターから情報をダウンロードして、 インベントリ ファイルと 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つのユーザーサービスアカウントが作成されます。これらのサービス アカウントのスコープは、対応するアプリケーションのデバッグのみに限定されます。サービス アカウントの詳細を次の表に示します。

表 1: サービス アカウントの詳細
アプリケーション名とスコープ アカウントユーザー名 アカウントのデフォルトパスワード
パラゴンパスファインダー(北極星) HB-ノーススター-管理者 管理者123!
テレメトリ マネージャー (tm) hb-tm-admin
ベースプラットフォーム(ems-dmon) HB-EMS-DMON

これらのアカウントは、デバッグ目的でのみ使用する必要があります。これらのアカウントは、日常的な操作や構成の変更には使用しないでください。セキュリティ上の理由から、ログイン資格情報を変更することをお勧めします。