A トラブルシューティング #
時として理解しにくい奇妙な問題が発生することがあります。High Availabilityでの実験を開始したときには、特にそうです。それでも、High Availabilityの内部プロセスを詳しく調べるために使用できる、いくつかのユーティリティがあります。この章では、さまざまなソリューションを推奨します。
A.1 インストールと最初のステップ #
パッケージのインストールやクラスタのオンライン化では、次のように問題をトラブルシュートします。
- HAパッケージはインストールされているか
クラスタの構成を管理に必要なパッケージは、High Availability Extensionで使用できる
High Availability
インストールパターンに付属しています。High Availability Extensionが各クラスタノードにSUSE Linux Enterprise Server 15 SP4の拡張としてインストールされているか、 パターンが『インストールおよびセットアップクイックスタート』で説明するように各マシンにインストールされているか、確認します。
- 初期設定がすべてのクラスタノードについて同一か
相互に通信するため、第4章 「YaSTクラスタモジュールの使用」で説明するように、同じクラスタに属するすべてのノードは同じ
bindnetaddr
、mcastaddr
、mcastport
を使用する必要があります。/etc/corosync/corosync.conf
で設定されている通信チャネルとオプションがすべてのクラスタノードに関して同一かどうか確認します。暗号化通信を使用する場合は、
/etc/corosync/authkey
ファイルがすべてのクラスタノードで使用可能かどうかを確認します。すべての
corosync.conf
設定(nodeid
以外)が同一で、すべてのノードのauthkey
ファイルが同一でなければなりません。- ファイアウォールで
mcastport
による通信が許可されているか クラスタノード間の通信に使用されるmcastportがファイアウォールでブロックされている場合、ノードは相互に認識できません。YaSTまたはブートストラップスクリプト(第4章 「YaSTクラスタモジュールの使用」とインストールおよびセットアップクイックスタートでそれぞれ説明)で初期セットアップを行っているときに、ファイアウォール設定は通常、自動的に調整されます。
mcastportがファイアウォールでブロックされないようにするには、各ノードのファイアウォールの設定を確認します。
- PacemakerとCorosyncが各クラスタノードで開始されているか
通常、Pacemakerを開始すると、Corosyncサービスも開始します。両方のサービスが実行されているかどうかを確認するには、次のコマンドを実行します。
root #
crm
cluster status両方のサービスが実行されていない場合は、次のコマンドを実行して開始します。
root #
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
)を表示します。root #
crm_mon
-o -r表示内容は、ステータスが変わると、更新されます(これをキャンセルするには、Ctrl–C を押します)。次に例を示します
例 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:
『 Explained (Pacemaker )』PDF (http://www.clusterlabs.org/pacemaker/doc/から入手可能)では、「How are OCF Return Codes Interpreted?」セクションで3つの異なる復元タイプを説明しています。
- ログはどのように表示しますか。
クラスタで発生している現象をより詳しく表示するには、次のコマンドを使用します。
root #
crm
history log [NODE]NODEは、調べたいノードに置き換えるか、空のままにします。詳細については、A.5項 「履歴」を参照してください。
A.3 リソース #
- リソースはどのようにクリーンアップしますか。
次のコマンドを使用してください。
root #
crm
resource list crm resource cleanup rscid [node]ノードを指定しないと、すべてのノードでリソースがクリーンアップされます。詳細については、8.4.4項 「リソースのクリーンアップ」を参照してください。
- 現在既知のリソースを一覧表示するにはどうしたらよいですか。
コマンド
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の実行によって取得できます。たとえば、次のようにします。root #
crm
ra info ocf:heartbeat:IPaddrocf-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
を使用します。root #
crm
history resource NAME1これにより、指定したリソースのみの完全な遷移ログが得られます。ただし、複数のリソースを調査することも可能です。その場合、最初のリソース名の後に目的のリソース名を追加します。
一定の命名規則(を参照してください)に従っていれば、
resource
コマンドでリソースのグループを調査するのが容易になります。たとえば、次のコマンドは、db
で始まるすべてのプリミティブを調査します。root #
crm
history resource db*/var/cache/crm/history/live/alice/ha-log.txt
のログファイルを表示します。- 履歴の出力を減らすにはどうしたらよいですか。
history
コマンドには、次の2つのオプションがあります。exclude
を使用するtimeframe
を使用する
exclude
コマンドを使用すると、追加の正規表現を設定して、ログから特定のパターンを除外できます。たとえば、次のコマンドは、SSH、systemd、およびカーネルのメッセージをすべて除外します。root #
crm
history exclude ssh|systemd|kernel.timeframe
コマンドを使用して、出力を特定の範囲に制限します。たとえば、次のコマンドは、8月23日12:00~12:30のイベントをすべて表示します。root #
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-testcrm(live)history#
session
pack Report saved in '/root/tux-test.tar.bz2'
A.6 Hawk2 #
- 自己署名証明書の置き換え置換
Hawk2の最初の起動で自己署名証明書に関する警告が発行されるのを避けるには、自動生成された証明書を、独自の証明書または公式認証局(CA)によって署名された証明書で置き換えてください。
/etc/hawk/hawk.key
を秘密鍵で置き換えます。/etc/hawk/hawk.pem
をHawk2が提供する証明書で置き換えます。Hawk2サービスを再起動して、新しい証明書を再ロードします。
root #
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 その他 #
- すべてのクラスタノードでコマンドを実行するにはどうしたらよいですか。
この作業を実行するには、
pssh
コマンドを使用します。必要であれば pssh.ファイル(たとえばhosts.txt
)を作成し、その中に操作する必要のあるノードのIPアドレスまたはホスト名を含めます。ssh
を使用してhosts.txt
ファイルに含まれている各ホストにログインしていることを確認します。準備ができたら、pssh
を実行します。hosts.txt
ファイルを(オプション-h
で)指定し、対話モードを使用してください(オプション-i
)。次のようになります。pssh -i -h hosts.txt "ls -l /corosync/*.conf" [1] 08:28:32 [SUCCESS] root@venus.example.com -rw-r--r-- 1 root root 1480 Nov 14 13:37 /etc/corosync/corosync.conf [2] 08:28:32 [SUCCESS] root@192.168.2.102 -rw-r--r-- 1 root root 1480 Nov 14 13:37 /etc/corosync/corosync.conf
- クラスタはどのような状態でしょうか。
クラスタの現在のステータスを確認するには、
crm_mon
かcrm
status
のどちらかを使用します。これによって、現在のDCと、現在のノードに認識されているすべてのノードとリソースが表示されます。- クラスタ内の一部のノードが相互に通信できないのはなぜですか。
これにはいくつかの理由が考えられます。
まず、設定ファイル
/etc/corosync/corosync.conf
を調べます。マルチキャストまたはユニキャストアドレスがクラスタ内のすべてのノードで同一かどうか確認します(キーmcastaddr
を含むinterface
セクションを調べてください)。ファイアウォール設定を確認します。
スイッチがマルチキャストまたはユニキャストアドレスをサポートしているか確認します。
ノード間の接続が切断されていないかどうか確認します。その原因の大半は、ファイアウォールの設定が正しくないことです。また、これはスプリットブレインの理由にもなり、クラスタがパーティション化されます。
- 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-default
、ocfs2-kmp-pae
、またはocfs2-kmp-xen
をインストールします。- すべてのクラスタノードの分析を含むレポートを作成するにはどうしたらよいですか。
crmシェルで、
crm report
を使用してレポートを作成します。このツールは以下を収集します。クラスタ全体のログファイル
パッケージ状態
DLM/OCFS2状態
システム情報
CIB履歴
コアダンプレポートの解析(debuginfoパッケージがインストールされている場合)
通常は、次のコマンドで
crm report
を実行します。root #
crm report
-f 0:00 -n alice -n bobこのコマンドは、ホストaliceおよびbob上の午前0時以降のすべての情報を抽出し、現在のディレクトリに
crm_report-
DATE.tar.bz2という名前の*.tar.bz2
アーカイブを作成します(例:crm_report-Wed-03-Mar-2012
)。特定のタイムフレームのみを対象とする場合は、-t
オプションを使用して終了時間を追加します。警告: 機密の情報は削除してくださいcrm report
ツールは、CIBとPE入力ファイルから機密の情報を削除しようと試みますが、すべてを知ることはできません。機密性の高い情報がある場合は、-p
オプションを使用して追加のパターンを指定してください(マニュアルページを参照)。ログファイルとcrm_mon
、ccm_tool
、およびcrm_verify
の出力は、フィルタされません。データをいずれの方法でも共有する前に、アーカイブをチェックして、公表したくない情報があればすべて削除してください。
さらに追加のオプションを使用して、コマンドの実行をカスタマイズします。たとえば、Pacemakerクラスタがある場合は、確実にオプション
-A
を追加する必要があるでしょう。別のユーザがクラスタに対するパーミッションを持っている場合は、(root
およびhacluster
に加えて)-u
オプションを使用してこのユーザを指定します。非標準のSSHポートを使用する場合は、-X
オプションを使用して、ポートを追加します(たとえば、ポート3479では、-X "-p 3479"
を使用)。その他のオプションは、crm report
のマニュアルページに記載されています。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
のコピーが保存されます。引数を単純化する必要がある場合は、設定ファイル
/etc/crm/crm.conf
のセクションreport
にデフォルト値を設定します。詳細は、マニュアルページman 8 crmsh_hb_report
に記載されています。
A.8 詳細の参照先 #
クラスタリソースの設定、およびHigh Availabilityクラスタの管理とカスタマイズなど、Linuxの高可用性に関するその他の情報については、http://clusterlabs.org/wiki/Documentationを参照してください。