目次にジャンプページナビゲーションにジャンプ: 前のページ[アクセスキーp]/次のページ[アクセスキーn]
documentation.suse.com / SUSE Linux Enterprise High Availabilityのドキュメント / 管理ガイド / 付録 / トラブルシューティング
適用項目 SUSE Linux Enterprise High Availability 15 SP6

A トラブルシューティング

時として理解しにくい奇妙な問題が発生することがあります。High Availabilityでの実験を開始したときには、特にそうです。それでも、High Availabilityの内部プロセスを詳しく調べるために使用できる、いくつかのユーティリティがあります。この章では、ソリューションを推奨します。

A.1 インストールと最初のステップ

パッケージのインストールやクラスタのオンライン化では、次のように問題をトラブルシュートします。

HAパッケージはインストールされているか

クラスタの設定と管理に必要なパッケージは、SUSE Linux Enterprise High Availabilityで使用できるHigh Availabilityインストールパターンに付属しています。

『インストールとセットアップクイックスタート』で説明しているように、SUSE Linux Enterprise High Availabilityがそれぞれのクラスタノードにインストールされているかどうか、および高可用性パターンが各マシンにインストールされているかどうかを確認します。

初期設定がすべてのクラスタノードについて同一か

相互に通信するため、第4章 「YaSTクラスタモジュールの使用で説明するように、同じクラスタに属するすべてのノードは同じbindnetaddrmcastaddrおよびmcastportを使用する必要があります。

/etc/corosync/corosync.confで設定されている通信チャネルとオプションがすべてのクラスタノードに関して同一かどうか確認します。

暗号化通信を使用する場合は、/etc/corosync/authkeyファイルがすべてのクラスタノードで使用可能かどうかを確認します。

すべてのcorosync.conf設定(nodeid以外)が同一で、すべてのノードのauthkeyファイルが同一でなければなりません。

ファイアウォールでmcastportによる通信が許可されているか

クラスタノード間の通信に使用されるmcastportがファイアウォールでブロックされている場合、ノードは相互に認識できません。YaSTまたはブートストラップスクリプト(第4章 「YaSTクラスタモジュールの使用インストールとセットアップクイックスタートでそれぞれ説明)で初期セットアップを行っているときに、ファイアウォール設定は通常、自動的に調整されます。

mcastportがファイアウォールでブロックされないようにするには、各ノードのファイアウォールの設定を確認します。

PacemakerとCorosyncが各クラスタノードで開始されているか

通常、Pacemakerを開始すると、Corosyncサービスも開始します。両方のサービスが実行されているかどうかを確認するには、次のコマンドを実行します。

# crm cluster status

両方のサービスが実行されていない場合は、次のコマンドを実行して開始します。

# crm cluster start

A.2 ログ記録

ログファイルはどこにあるか

Pacemakerのログファイルは、/var/log/pacemakerディレクトリに書き込まれます。Pacemakerのメインログファイルは、/var/log/pacemaker/pacemaker.logです。ログファイルが見つからない場合は、Pacemaker独自の設定ファイルである/etc/sysconfig/pacemakerのログ設定を確認してください。PCMK_logfileがそこで設定されている場合、Pacemakerはこのパラメータで定義したパスを使用します。

すべての関連ログファイルを表示するクラスタ全体のレポートが必要な場合は、詳細については、すべてのクラスタノードの分析を含むレポートを作成するにはどうしたらよいですか。を参照してください。

監視を有効にしているのに、ログファイルに監視操作の記録が残っていないのはなぜですか。

pacemaker-execdデーモンは、エラーが発生しない限り、複数の監視操作をログに記録しません。複数の監視操作をすべてログ記録すると、多量のノイズが発生してしまいます。そのため、複数の監視操作は、1時間に1度だけ記録されます。

failedメッセージだけが出ました。詳細情報を取得できますか。

コマンドに--verboseパラメータを追加してください。これを複数回行うと、デバッグ出力がより詳細になります。役立つヒントについては、ログ記録データ(sudo journalctl -n)を参照してください。

ノードとリソースすべての概要を確認するにはどうしたらよいですか。

crm_monコマンドを使用します。次のコマンドは、リソース操作履歴(-oオプション)と非アクティブなリソース(-r)を表示します。

# crm_mon -o -r

表示内容は、ステータスが変わると、更新されます(これをキャンセルするには、CtrlCを押します)。次に例を示します

例 A.1: 停止されたリソース
Last updated: Fri Aug 15 10:42:08 2014
Last change: Fri Aug 15 10:32:19 2014
 Stack: corosync
Current DC: bob (175704619) - partition with quorum
Version: 1.1.12-ad083a8
2 Nodes configured
3 Resources configured

Online: [ alice bob ]

Full list of resources:

my_ipaddress    (ocf:heartbeat:Dummy): Started bob
my_filesystem   (ocf:heartbeat:Dummy): Stopped
my_webserver    (ocf:heartbeat:Dummy): Stopped

Operations:
* Node bob:
    my_ipaddress: migration-threshold=3
      + (14) start: rc=0 (ok)
      + (15) monitor: interval=10000ms rc=0 (ok)
      * Node alice:

https://www.clusterlabs.org/pacemaker/doc/で入手可能な『Pacemaker Explained』PDFは、「How are OCF Return Codes Interpreted?」セクションの3つの異なる回復の種類をカバーしています。

ログはどのように表示しますか。

クラスタで発生している現象をより詳しく表示するには、次のコマンドを使用します。

# crm history log [NODE]

NODEは、調べたいノードに置き換えるか、空のままにします。詳細については、A.5項 「履歴」を参照してください。

A.3 リソース

リソースはどのようにクリーンアップしますか。

次のコマンドを使用してください。

# crm resource list
# crm resource cleanup rscid [node]

ノードを指定しないと、すべてのノードでリソースがクリーンアップされます。詳細については、8.5.2項 「crmshを使用したクラスタリソースのクリーンアップ」を参照してください。

現在既知のリソースを一覧表示するにはどうしたらよいですか。

コマンドcrm resource listを使用して、現在のリソースの情報を表示できます。

リソースを設定しましたが、いつも失敗します。なぜですか。

OCFスクリプトを確認するには、たとえば、次のocf-testerコマンドを使用します。

ocf-tester -n ip1 -o ip=YOUR_IP_ADDRESS \
  /usr/lib/ocf/resource.d/heartbeat/IPaddr

パラメータを増やすには、-oを何回も使用します。必須パラメータとオプションパラメータのリストは、crm ra info AGENTを実行することによって取得できます。次に例を示します。

# crm ra info ocf:heartbeat:IPaddr

ocf-testerを実行する場合は、その前に、リソースがクラスタで管理されていないことを確認してく ださい。

リソースがフェールオーバーせず、エラーが出ないのはなぜですか。

終端ノードはunclean(アンクリーン)と考えられる場合があります。その場合には、それをフェンシングする必要があります。STONITHリソースが動作していない、または存在しない場合、残りのノードはフェンシングが実行されるのを待機することになります。フェンシングのタイムアウトは通常長いので、問題の兆候がはっきりと現れるまでには(仮に現れたとしても)、長い時間がかかることがあります。

さらに別の可能性としては、単にこのノードでのリソースの実行が許可されていないという場合があります。このことは、過去にエラーが発生し、それが正しく解決されていないために生じることがあります。または、以前に行った管理上の操作が原因である場合もあります。つまり、負のスコアを持つ場所の制約のためです。そのような場所の制約は、たとえば、crm resource moveコマンドによって挿入されることがあります。

リソースがどこで実行されるかを予測できないのはなぜですか。

リソースに対して場所の制約が設定されていない場合、その配置は、(ほとんど)ランダムなノード選択によって決まります。どのノードでリソースを実行することが望ましいか、常に明示的に指定することをお勧めします。このことは、すべてのリソースに対して、場所の初期設定を行う必要があるという意味ではありません。関連する(コロケーション)リソースのセットに対して優先指定を設定すれば十分です。ノードの優先指定は次のようになります。

location rsc-prefers-alice rsc 100: alice

A.4 STONITHとフェンシング

STONITHリソースが開始しないのはなぜですか。

開始(または有効化)操作には、デバイスのステータスのチェックが含まれます。デバイスの準備ができていない場合、STONITHリソースの開始は失敗します。

同時に、STONITHプラグインは、ホストリストを生成するように要求されます。リストが空の場合、STONITHリソースが対象にできるものがないことになるので、いずれにせよシューティングは行われません。STONITHが動作しているホストの名前は、リストから除外されます。ノードが自分自身をシューティングすることはできないからです。

停電デバイスのような、シングルホスト管理デバイスを使用する場合、フェンシングの対象とするデバイスではSTONITHリソースの動作を許可しないようにしてください。-INFINITYの、ノードの場所優先設定(制約)を使用してください。クラスタは、STONITHリソースを、起動できる別の場所に移動します。その際にはそのことが通知されます。

STONITHリソースを設定したのにフェンシングが行われないのはなぜですか。

それぞれのSTONITHリソースは、ホストリストを持つ必要があります。このリストは、手動でSTONITHリソースの設定に挿入される場合、またはデバイス自体から取得される場合があります(たとえば出力名から)。この点は、STONITHプラグインの性質に応じて決まります。pacemaker-fencedは、このリストを基に、どのSTONITHリソースがターゲットノードのフェンシングを行えるかを判断します。ノードがリストに含まれている場合に限って、STONITHリソースはノードのシューティング(フェンシング)を行えます。

pacemaker-fencedは、動作しているSTONITHリソースから提供されたホストリスト内にノードを見つけられなかった場合、他のノードのpacemaker-fencedインスタンスに問い合わせます。他のpacemaker-fencedインスタンスのホストリストにもターゲットノードが含まれていなかった場合、フェンシング要求は、開始ノードでタイムアウトのために終了します。

STONITHリソースが失敗することがあるのはなぜですか。

ブロードキャストトラフィックが多すぎると、電源管理デバイスが機能しなくなることがあります。監視操作を少なくして、余裕を持たせてください。フェンシングはごくたまにしか必要ない(そしてできればまったく必要としなければよい)ことを考えると、デバイスのステータスは数時間に1回チェックすれば十分です。

また、この種のデバイスの中には、同時に複数の相手と通信するのを拒否するものもあります。このことは、ユーザが端末またはブラウザセッションを開いたままにしていて、クラスタがステータスのテストを行おうとした場合には、問題となり得ます。

A.5 履歴

障害の発生したリソースからステータス情報またはログを取得するにはどうしたらよいですか。

historyコマンドおよびそのサブコマンドであるresourceを使用します。

# crm history resource NAME1

これにより、指定したリソースのみの完全な遷移ログが得られます。ただし、複数のリソースを調査することも可能です。その場合、最初のリソース名の後に目的のリソース名を追加します。

一定の命名規則(付録B 命名規則を参照してください)に従っていれば、resourceコマンドでリソースのグループを調査するのが容易になります。たとえば、次のコマンドは、dbで始まるすべてのプリミティブを調査します。

# crm history resource db*

/var/cache/crm/history/live/alice/ha-log.txtにログファイルを表示します。

履歴の出力を減らすにはどうしたらよいですか。

historyコマンドには、次の2つのオプションがあります。

  • excludeの利用

  • timeframeの利用

excludeコマンドを使用すると、追加の正規表現を設定して、ログから特定のパターンを除外できます。たとえば、次のコマンドは、SSH、systemd、およびカーネルのメッセージをすべて除外します。

# crm history exclude ssh|systemd|kernel.

timeframeコマンドを使用して、出力を特定の範囲に制限します。たとえば、次のコマンドは、8月23日12:00~12:30のイベントをすべて表示します。

# crm history timeframe "Aug 23 12:00" "Aug 23 12:30"
後で検査できるようにセッションを保存するにはどうしたらよいですか。

詳しい調査を要するバグまたはイベントが発生した場合、現在のすべての設定を保存しておくと役に立ちます。このファイルをサポートに送信したり、bzlessで表示したりできます。例:

crm(live)history# timeframe "Oct 13 15:00" "Oct 13 16:00"
crm(live)history# session save tux-test
crm(live)history# session pack
Report saved in '/root/tux-test.tar.bz2'

A.6 Hawk2

自己署名証明書の置き換え

Hawk2の最初の起動で自己署名証明書に関する警告が発行されるのを避けるには、自動生成された証明書を、独自の証明書または公式認証局(CA)によって署名された証明書で置き換えてください。

  1. /etc/hawk/hawk.keyを秘密鍵で置き換えます。

  2. /etc/hawk/hawk.pemをHawk2が提供する証明書で置き換えます。

  3. Hawk2サービスを再起動して、新しい証明書を再ロードします。

    # systemctl restart hawk-backend hawk

root:haclientにファイルの所有権を変更して、そのファイルがグループにアクセスできるようにします。

# chown root:haclient /etc/hawk/hawk.key /etc/hawk/hawk.pem
# chmod 640 /etc/hawk/hawk.key /etc/hawk/hawk.pem

A.7 その他

すべてのクラスタノードでコマンドを実行するにはどうしたらよいですか。

この作業を実行するには、crm cluster runコマンドを使用します。例:

# crm cluster run "ls -l /etc/corosync/*.conf"
INFO: [alice]
-rw-r--r-- 1 root root 812 Oct 27 15:42 /etc/corosync/corosync.conf
INFO: [bob]
-rw-r--r-- 1 root root 812 Oct 27 15:42 /etc/corosync/corosync.conf
INFO: [charlie]
-rw-r--r-- 1 root root 812 Oct 27 15:42 /etc/corosync/corosync.conf

デフォルトでは、指定されたコマンドはクラスタ内のすべてのノードで実行されます。または、特定のノードまたはノードのグループでコマンドを実行することもできます。

# crm cluster run "ls -l /etc/corosync/*.conf" alice bob
クラスタはどのような状態でしょうか。

クラスタの現在のステータスを確認するには、crm_moncrm status のどちらかを使用します。これによって、現在のDCと、現在のノードに認識されているすべてのノードとリソースが表示されます。

クラスタ内の一部のノードが相互に通信できないのはなぜですか。

これにはいくつかの理由が考えられます。

  • まず、設定ファイル/etc/corosync/corosync.confを調べます。マルチキャストまたはユニキャストアドレスがクラスタ内のすべてのノードで同一かどうか確認します(キーinterfaceを含むmcastaddrセクションを調べてください)。

  • ファイアウォール設定を確認します。

  • スイッチがマルチキャストまたはユニキャストアドレスをサポートしているか確認します。

  • ノード間の接続が切断されていないかどうか確認します。その原因の大半は、ファイアウォールの設定が正しくないことです。また、これは「スプリットブレイン」の理由にもなり、クラスタがパーティション化されます。

OCFS2デバイスをマウントできないのはなぜですか。

ログメッセージ(sudo journalctl -n)に次の行があるか確認してください。

Jan 12 09:58:55 alice pacemaker-execd: [3487]: info: RA output: [...]
  ERROR: Could not load ocfs2_stackglue
Jan 12 16:04:22 alice modprobe: FATAL: Module ocfs2_stackglue not found.

この場合、カーネルモジュールocfs2_stackglue.koがありません。インストールしたカーネルに応じて、パッケージocfs2-kmp-defaultocfs2-kmp-pae、またはocfs2-kmp-xenをインストールします。

A.8 クラスタレポート

すべてのクラスタノードの分析を含むレポートを作成するにはどうしたらよいですか。

crmシェルで、crm reportを使用してレポートを作成します。このツールは以下を収集します。

  • クラスタ全体のログファイル

  • パッケージ状態

  • DLM/OCFS2状態

  • システム情報

  • CIB履歴

  • コアダンプレポートの解析(debuginfoパッケージがインストールされている場合)

通常は、次のコマンドでcrm reportを実行します。

# crm report -f 0:00 -n alice -n bob

このコマンドは午前0時以降、ホストaliceとbobに関するすべての情報を抽出し、現在のディレクトリにcrm_report-DATE.tar.bz2という名前の*.tar.bz2アーカイブを作成します(例: crm_report-Wed-03-Mar-2012)。特定のタイムフレームのみを対象とする場合は、-tオプションを使用して終了時間を追加します。

警告
警告: 機密の情報は削除してください

crm reportツールは、CIBとPE入力ファイルから機密の情報を削除しようと試みますが、すべてを知ることはできません。機密性の高い情報がある場合は、-pオプションを使用して追加のパターンを指定してください(マニュアルページを参照)。ログファイルおよびcrm_monccm_tool、およびcrm_verifyの出力からの機密の情報の削除は「行われません」。

データをいずれの方法でも共有する前に、アーカイブをチェックして、公表したくない情報があればすべて削除してください。

さらに追加のオプションを使用して、コマンドの実行をカスタマイズします。たとえば、rootおよびhacluster以外にクラスタに対する特権を持つ別のユーザがいる場合、-uオプションを使用してこのユーザを指定します。標準とは異なるSSHポートがある場合、-Xオプションを使用してそのポートを追加します。引数を単純化する必要がある場合は、設定ファイル/etc/crm/crm.confのセクションreportにデフォルト値を設定します。詳細については、crm reportのマニュアルページを参照してください。

手順 A.1: カスタムSSHポートを使用したクラスタレポートの生成
  1. カスタムSSHポートを使用する場合、-Xcrm reportを使用して、クライアントのSSHポートを変更します。たとえば、カスタムSSHポートが5022の場合、次のコマンドを使用します。

    # crm report -X "-p 5022" [...]
  2. crm reportのカスタムSSHポートを永続的に設定するには、crm対話型シェルを開始します。

    # crm options
  3. 次のように入力します。

    crm(live)options#  set core.report_tool_options "-X -oPort=5022"

crm reportで、関連するすべてのログファイルを分析し、ディレクトリ(またはアーカイブ)を作成したら、ERRORという文字列(大文字)があるかどうかログファイルをチェックします。レポートの最上位ディレクトリにある最も重要なファイルは次のとおりです。

analysis.txt

すべてのノードで同一である必要があるファイルを比較します。

corosync.txt

Corosync設定ファイルのコピーを格納します。

crm_mon.txt

crm_monコマンドの出力を格納します。

description.txt

ノード上のすべてのクラスタパッケージのバージョンを格納します。ノード固有のsysinfo.txtファイルもあります。これは最上位ディレクトリにリンクしています。

このファイルは、発生した問題を説明してhttps://github.com/ClusterLabs/crmsh/issuesに送信するためのテンプレートとして使用できます。

members.txt

すべてのノードのリストです。

sysinfo.txt

関連するすべてのパッケージ名とそのバージョンのリストが記述されています。さらに、元のRPMパッケージとは異なる設定ファイルのリストもあります。

ノード固有のファイルは、ノードの名前を持つサブディレクトリに保存されます。ここには、それぞれのノードのディレクトリ/etcのコピーが保存されます。

A.9 詳細の参照先

クラスタリソースの設定、およびHigh Availabilityクラスタの管理とカスタマイズなど、Linuxの高可用性に関するその他の情報については、https://clusterlabs.org/wiki/Documentationを参照してください。