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. インストール時に config.yml ファイルで設定したopendistro_es_admin_userユーザー名と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 には、リソースのより多くの属性が一覧表示されます。ヘルプ (-h) を使用して、使用可能なフラグに関する情報を取得します。

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

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

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

すべての名前空間のリストを取得するには、 kubectl get namespace コマンドを発行します。

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

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

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

ノードステータスの表示

kubectl get no コマンドと略される kubectl get nodes コマンドを使用して、クラスター ノードの状態を表示します。ノードの状態は [Ready] で、ロールは [control-plane] または [none] である必要があります。例えば：

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

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

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

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

正常なポッドの状態は Running または Completed である必要があり、準備完了コンテナーの数は合計と一致する必要があります。ポッドの状態が 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 -n namespace コマンドまたは kubectl get svc -A コマンドを使用して、クラスター・サービスを表示します。個々の名前空間 (healthbot、northstar、common など) を指定することも、-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 ファイルがないため、次のエラーで失敗します。

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

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.

    すべてのポッドの状態が Running になるまで、kubectl delete po -n northstar -l app=rabbitmqを繰り返します。

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

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

udevd デーモンは、ディスク、ネットワーク・カード、CD などの新しいハードウェアを管理するために使用します。OSDの作成中に、 udevdデーモンはOSDを検出し、完全に初期化される前に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.yml ファイル、 およびid_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

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

関連ドキュメント