11 クラスタの監視 #
この章では、クラスタのヘルスを監視し、その履歴を表示する方法について説明します。
11.1 クラスタの状態の監視 #
Hawk2には、単一のクラスタおよび複数のクラスタを監視するための異なる画面があります:
画面と 画面。11.1.1 単一クラスタの監視 #
単一クラスタを監視するには、
画面を使用します。Hawk2にログインした後で、 画面がデフォルトで表示されます。右上隅のアイコンに、クラスタの状態の概要が表示されます。詳細情報を参照する場合は、次のカテゴリを確認します。- エラー
エラーが発生した場合、ページの上部に表示されます。
- リソース
設定されているリソースが表示されます。その
、 (ID)、 (リソースが実行されているノード)、リソースエージェントの が含まれます。 列で、リソースを開始または停止するか、いくつかのアクションをトリガするか、詳細を表示できます。トリガ可能なアクションには、保守モードへのリソースの設定(または保守モードの削除)、リソースの別のノードへの移行、リソースのクリーンアップ、リソースイベントの表示、またはリソースの編集が含まれます。- ノード
ログイン先のクラスタサイトに属するノードが表示されます。ノードの
および が含まれます。 および 列で、ノードのmaintenance
フラグまたはstandby
フラグを設定または解除できます。 列で、ノードの最新イベントや詳細情報を参照できます。たとえば、それぞれのノードにutilization
、standby
、またはmaintenance
のどの属性が設定されているかを参照できます。- チケット
Geoクラスタリングでの使用向けにチケットを設定した場合にのみ表示されます。
11.1.2 複数のクラスタの監視 #
複数のクラスタを監視するには、Hawk2
を使用します。 画面に表示されるクラスタ情報は、サーバ側に保管されています。これらは、クラスタノード間で同期が取られています(クラスタノード間にパスワード不要のSSHアクセスが設定されている場合)。ただし、Hawk2を実行するマシンは、その目的のためにクラスタの一部である必要はなく、別個の無関係のシステムで構いません。Hawk2で複数のクラスタを監視するには、一般的なHawk2の要件に加え、次の前提条件も満たす必要があります。
Hawk2の
で監視するすべてのクラスタでは、SUSE Linux Enterprise High Availability 15 SP6を実行している必要があります。すべてのクラスタノードにあるHawk2の自己署名証明書を独自の証明書(または公式認証局によって署名された証明書)で置き換えていない場合は、「すべての」クラスタの「すべての」ノードで、少なくとも1回はHawk2にログインします。証明書を検証します(または、ブラウザで例外を追加して警告をスキップします)。そうしない場合、Hawk2はクラスタに接続できません。
Hawk2にログインします。
https://HAWKSERVER:7630/
左のナビゲーションバーから、
› の順に選択します。Hawk2は、現在のクラスタサイトのリソースおよびノードに関する概要を表示します。また、Geoクラスタでの使用向けに設定された
を表示します。このビューで使用されているアイコンについての情報が必要な場合は、 をクリックします。リソースIDを検索するには、 テキストボックスに名前(ID)を入力します。特定のノードのみを表示するには、フィルタアイコンをクリックしてフィルタリングオプションを選択します。図 11.2: 1つのクラスタサイト(amsterdam
)を表示するHawk2ダッシュボード #複数のクラスタにダッシュボードを追加するには、以下の操作を行います。
berlin
。いずれかのノードの完全修飾ホスト名を、2つ目のクラスタに入力します。例、
charlie
。図 11.3: Hawk2がクラスタの詳細を追加する #- 注記: 接続エラー
パスワードを入力してこのノードにログインすることを求めるプロンプトが表示された場合、このノードにはまだ接続したことがなく、自己署名証明書を置き換えていない状態である場合があります。そのような場合は、パスワードを入力しても、接続は次のメッセージを表示して失敗します。
Error connecting to server. Retrying every 5 seconds... '
。続行するには、自己署名証明書の置き換えを参照してください。
クラスタサイトやその管理に関する詳細を参照するには、サイトのタブに切り替えてチェーンアイコンをクリックします。
Hawk2はこのサイトの
ビューを新しいブラウザウィンドウかタブに表示します。この部分のGeoクラスタをそこから管理できます。ダッシュボードからクラスタを削除するには、クラスタの詳細の右側にある
x
アイコンをクリックします。
11.2 クラスタヘルスの確認 #
Hawk2またはcrmshのいずれかを使用してクラスタのヘルスを確認できます。
11.2.1 Hawk2を使用したクラスタヘルスの確認 #
Hawk2は、クラスタの検査と問題点の検出を行うウィザードを提供します。分析が完了すると、Hawk2は詳細なクラスタレポートを作成します。Hawk2によるクラスタヘルスの確認とレポートの生成には、ノード間のパスワード不要のSSHアクセスが必要です。ない場合は、現在のノードのデータのみを収集します。crmシェルが提供するブートストラップスクリプトでクラスタを設定した場合、パスワード不要のSSHアクセスはすでに設定されています。
Hawk2にログインします。
https://HAWKSERVER:7630/
左のナビゲーションバーから、
› の順に選択します。クラスタのルートパスワードを入力して、
をクリックします。Hawk2はレポートを生成します。
11.2.2 crmshを使用したヘルスステータスの取得 #
クラスタまたはノードの「ヘルス」ステータスは、「スクリプト」というもので表示できます。スクリプトは、ヘルスだけに限らず各タスクを実行できます。ただし、このサブセクションでは、ヘルスステータスを取得する方法に焦点を当てます。
health
コマンドに関するすべての詳細を取得するには、describe
を使用します。
#
crm script describe health
このコマンドは、すべてのパラメータの説明とリスト、およびそのデフォルト値を示します。スクリプトを実行するには、run
を使用します。
#
crm script run health
スイートから1つのステップのみを実行したい場合は、describe
コマンドのStepsカテゴリで、使用可能なすべてのステップを一覧表示できます。
たとえば、次のコマンドは、health
コマンドの最初のステップを実行します。さらなる調査のために、出力がhealth.json
に保存されます。
#
crm script run health statefile='health.json'
上記のコマンドは、crm cluster health
でも実行できます。
スクリプトに関する追加情報を表示するには、https://crmsh.github.io/scripts/を参照してください。
11.3 クラスタ履歴の表示 #
Hawk2には、クラスタの過去のイベントを表示する、次のような機能があります(いくつかの詳細さのレベルがあります)。
crmshを使用してクラスタ履歴情報を表示することもできます。
11.3.1 ノードまたリソースの最近のイベントの表示 #
Hawk2にログインします。
https://HAWKSERVER:7630/
左のナビゲーションバーから、
› の順に選択します。 と が一覧表示されます。リソースの最近のイベントを表示するには
リソースの
列で、下矢印ボタンをクリックして を選択します。Hawk2では、新しいウィンドウが開き、最新のイベントのテーブルビューが表示されます。
ノードの最近のイベントを表示するには
ノードの
列で、 を選択します。Hawk2では、新しいウィンドウが開き、最新のイベントのテーブルビューが表示されます。
図 11.4: 最新イベントテーブル #
11.3.2 クラスタレポートのための履歴エクスプローラーの使用 #
左のナビゲーションバーから
› を選択して、 にアクセスします。 では、詳細なクラスタレポートを作成し、遷移情報を表示できます。次のオプションが表示されます。特定の時刻のクラスタレポートを作成します。Hawk2では、
crm report
コマンドをコールして、レポートを生成します。crmシェルで直接作成したか、異なるクラスタ上で作成した
crm report
アーカイブをアップロードできます。
レポートを生成するか、アップロードした後で、これらのレポートは
の下に表示されます。レポートのリストから、レポートの詳細を表示したり、レポートをダウンロードしたり、削除したりできます。Hawk2にログインします。
https://HAWKSERVER:7630/
左のナビゲーションバーから、
› の順に選択します。クラスタレポートを作成するには
レポートを直ちに開始するには、
をクリックします。レポートの時間フレームを変更するには、提案される時間フレームの任意の場所をクリックし、ドロップダウンボックスから別のオプションを選択します。
開始日、終了日、および時間をそれぞれ入力することもできます。レポートを開始するには、 をクリックします。レポートを終了した後で、そのレポートが
の下に表示されます。
クラスタレポートをアップロードするには、Hawk2でアクセス可能なファイルシステム上に
crm report
アーカイブがある必要があります。以下に手順を示します。クラスタレポートアーカイブを
し、 をクリックします。レポートがアップロードされると、そのレポートが
の下に表示されます。
レポートをダウンロードまたは削除するには、
列のレポートの横の各アイコンをクリックします。履歴エクスプローラーのレポート詳細を表示するには、レポートの名前をクリックするか、 列から を選択します。
図 11.6: Hawk2レポートの詳細 #
11.3.3 履歴エクスプローラーの遷移詳細の表示 #
各遷移ごとに、クラスタは状態のコピーを保存し、これをpacemaker-schedulerd
への入力として提供します。このアーカイブへのパスがログ記録されます。すべてのpe-*
ファイルは指定コーディネータ(DC)上に生成されます。DCはクラスタ内で変更可能なため、いくつかのノードからのpe-*
ファイルがある場合があります。すべてのpe-*
ファイルはCIBの保存済みスナップショットであり、pacemaker-schedulerd
による計算の入力として利用されます。
Hawk2では、各pe-*
ファイルの名前と作成時刻、およびそれが作成されたノードを表示できます。また、 では、それぞれのpe-*
ファイルに基づいて、次の詳細をビジュアル化できます。
遷移に属するログインデータのスニペットを表示します。次のコマンドの出力を表示します(リソースエージェントのログメッセージを含む)。
crm history transition peinput
pe-*
ファイルが作成された時刻でクラスタ設定を表示します。選択した
pe-*
ファイルと次のファイル間の設定と状態の相違を表示します。遷移に属するログインデータのスニペットを表示します。次のコマンドの出力を表示します。
crm history transition log peinput
これには、
pacemaker-schedulerd
、pacemaker-controld
およびpacemaker-execd
の各デーモンの詳細が含まれています.遷移のグラフィカルな表現を示します。
をクリックすると、(pacemaker-schedulerd
で実行したのものと同じ)計算がシミュレートされ、図表化されます。
Hawk2にログインします。
https://HAWKSERVER:7630/
左のナビゲーションバーから、
› の順に選択します。レポートがすでに生成またはアップロードされている場合は、これらのレポートが手順 11.2で説明されるように、レポートを生成またはアップロードします。
のリストに表示されます。そうでない場合は、レポート名をクリックするか、履歴エクスプローラーのレポート詳細を開きます。
列から を選択して、遷移詳細にアクセスするには、下に示す遷移タイムラインの遷移ポイントを選択する必要があります。
および アイコンをおよび および アイコンを使用して、興味ある遷移を探します。pe-input*
ファイルの名前、それが作成された時刻およびノードを表示するには、タイムラインの遷移ポイントにマウスポインタを合わせます。履歴エクスプローラーでの遷移詳細を表示するには、さらに知りたい遷移ポイントをクリックします。
履歴エクスプローラーでの遷移詳細で説明されるコンテンツを表示します。
、 、 、 または を表示するには、各ボタンをクリックしてレポートのリストに戻るには、
ボタンをクリックします。
11.3.4 crmshを使用した履歴情報の取得 #
クラスタの履歴の調査は複雑な作業です。この作業を簡素化するために、crmshにはhistory
コマンドとそのサブコマンドが含まれています。これは、SSHが正しく設定されていることが前提となります。
それぞれのクラスタは、状態を移動し、リソースを移行し、または重要なプロセスを開始します。これらすべてのアクションは、history
のサブコマンドによって取得できます。
デフォルトでは、すべてのhistory
コマンドは過去1時間のイベントを確認します。このタイムフレームを変更するには、limit
サブコマンドを使用します。構文は次のとおりです。
#
crm history
crm(live)history#
limit FROM_TIME [TO_TIME]
有効な例として、次のようなものが挙げられます。
limit 4:00pm
,limit 16:00
どちらのコマンドも同じ意味で、今日の午後4時を表しています。
limit 2012/01/12 6pm
2012年1月12日の午後6時。
limit "Sun 5 20:46"
今年の今月の5日日曜日の午後8時46分。
その他の例とタイムフレームの作成方法については、https://labix.org/python-dateutilを参照してください。
info
サブコマンドでは、crm report
によって使用されているすべてのパラメータが表示されます。
crm(live)history#
info
Source: live Period: 2012-01-12 14:10:56 - end Nodes: alice Groups: Resources:
crm report
を特定のパラメータに制限するには、サブコマンドhelp
で使用可能なオプションを表示します。
詳細レベルに絞り込んでいくには、サブコマンドdetail
とレベル数を使用します。
crm(live)history#
detail 1
数値が大きいほど、レポートが詳細になっていきます。デフォルト値は0
(ゼロ)です。
ここまでのパラメータを設定したら、log
を使用してログメッセージを表示します。
最後の遷移を表示するには、次のコマンドを使用します。
crm(live)history#
transition -1
INFO: fetching new logs, please wait ...
このコマンドはログを取得し、dotty
(graphvizパッケージから)を実行して、遷移グラフを表示します。シェルはログファイルを開きます。ログ内は、↓と↑カーソルキーでブラウズできます。
遷移グラフを表示する必要がない場合には、nograph
オプションを使用します。
crm(live)history#
transition -1 nograph
11.4 SysInfo
リソースエージェントによるシステムヘルスの監視 #
ノードがディスク容量が使い尽くし、そこに割り当てられたリソースを管理できなくなることを避けるため、SUSE Linux Enterprise High Availabilityでは、ocf:pacemaker:SysInfo
というリソースエージェントが提供されています。これを使用して、ディスクパーティションに関してノードのヘルスを監視します。SysInfo RAは、#health_disk
という名前のノード属性を作成します。この属性は、監視対象のディスク空き容量が指定された制限を下回るとred
に変更されます。
ノードのヘルスがクリティカルな状態に達した場合のCRMの対応方法を定義するには、グローバルなクラスタオプションであるnode-health-strategy
を使用します。
ノードがディスク容量を使い尽くした場合に、リソースを自動的にノードから移動させるには、次の手順に従います。
ocf:pacemaker:SysInfo
リソースを設定します。primitive sysinfo ocf:pacemaker:SysInfo \ params disks="/tmp /var"1 min_disk_free="100M"2 disk_unit="M"3 \ op monitor interval="15s"
監視対象のディスクパーティション。
/tmp
、/usr
、/var
、/dev
などです。複数のパーティションを属性値として指定するには、空白で区切ります。注記:/
のファイルシステムは常に監視されるdisks
でルートパーティション(/
)を指定する必要はありません。これはデフォルトで常に監視されます。これらのパーティションの必要最小限の空きディスク容量。オプションで、計測に使用する単位を指定できます(上記の例では、メガバイトを表す
M
が使用されています)。指定しない場合、min_disk_free
はdisk_unit
パラメータで定義されている単位にデフォルト設定されます。ディスク容量をレポートする場合の単位。
リソース設定を完了するには、
ocf:pacemaker:SysInfo
のクローンを作成し、各クラスタノードでそれを起動します。node-health-strategy
をmigrate-on-red
に設定します。property node-health-strategy="migrate-on-red"
#health_disk
属性がred
に設定されている場合、pacemaker-schedulerd
によって、そのノードのリソースのスコアに-INF
が追加されます。これにより、このノードからすべてのリソースが移動します。この処理はSTONITHリソースのところで停止しますが、STONITHリソースが実行されていない場合でも、ノードをフェンスすることができます。フェンスでCIBに直接アクセスすることで、動作を続行できるからです。
ノードのヘルス状態がred
になったら、原因となる問題を解決します。次にred
ステータスをクリアして、ノードを再びリソースの実行に適した状態にします。クラスタノードにログインして、次のいずれかの方法を使用します。
次のコマンドを実行します。
#
crm node status-attr NODE delete #health_disk
そのノードでクラスタサービスを再起動します。
ノードを再起動します。
ノードがサービスに復帰し、再びリソースを実行できるようになります。