クラスタの構成を管理に必要なパッケージは、High Availability Extensionで使用できるHigh Availabilityインストールパターンに付属しています。

High Availability Extensionが各クラスタノードにアドオンとしてSUSE Linux Enterprise Server 12 にインストールされているか、High Availabilityパターンが3.3項 「アドオンとしてのインストール」で説明するように各マシンにインストールされているか、確認します。

相互に通信するため、で説明するように、同じクラスタに属するすべてのノードは同じbindnetaddr、mcastaddr、mcastport3.5項 「手動のクラスタセットアップ(YaST)」を使用する必要があります。

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

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

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

クラスタノード間の通信に使用されるmcastportがファイアウォールでブロックされている場合、ノードは相互に認識できません。3.5項 「手動のクラスタセットアップ(YaST)」と3.4項 「自動のクラスタセットアップ(ha-cluster-bootstrap)」で説明されているように、YaSTまたはブートストラップスクリプトで初期セットアップを設定しているときに、ファイアウォール設定は通常、自動的に調整されます。

mcastportがファイアウォールでブロックされないようにするには、各ノードの/etc/sysconfig/SuSEfirewall2の設定を確認します。または、各クラスタノードのYaSTファイアウォールモジュールを起動します。許可されるサービス › 詳細をクリックして、mcastportを許可されたUDPポートのリストに追加し、変更を確定します。

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

root # systemctl status pacemaker.service corosync.service

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

root # systemctl start pacemaker.service

Pacemakerログファイルの場合は、/etc/corosync/corosync.confのloggingセクションで指定されている設定を参照してください。ここで指定したログファイルをPaceacemakerで無視する場合は、Pacemaker独自の設定ファイル/etc/sysconfig/pacemakerのログ記録設定を確認してください。PCMK_logfileがそこで設定されている場合、Pacemakerはこのパラメータで定義したパスを使用します。

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

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

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

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

root # crm_mon -o -r

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

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 barett-2
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:

『Pacemaker Explained (Pacemaker 1.1 for Corosync 2.x and crmsh)』PDF (http://www.clusterlabs.org/doc/から入手可能)では、「How are OCF Return Codes Interpreted?」セクションで3つの異なる復元タイプを説明しています。

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

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

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

コマンド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:IPaddr

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

クラスタが2ノードクラスタの場合、一方のノードを強制停止すると、残りのノードがクォーラムのない状態になります。no-quorum-policyプロパティをignoreに設定していない限り、何も起こりません。2ノードクラスタの場合、次のように設定することが必要です。

property no-quorum-policy="ignore"

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

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

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

location rsc-prefers-alice rsc 100: alice

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

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

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

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

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

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

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

この作業を実行するには、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と、現在のノードに認識されているすべてのノードとリソースが表示されます。

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

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

Jan 12 09:58:55 alice lrmd: [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またはhb_reportを使用してレポートを作成します。ツールを使用して次のリソースをコンパイルします。

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

root # crm_report -f 0:00 -n jupiter -n venus

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

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

crm_reportツールは、CIBと入力ファイルから機密の情報を削除しようと試みますが、完全に削除できるわけではありません。他にも機密の情報が含まれている場合には、付加的なパターンを指定してください。ログファイルとcrm_mon、ccm_tool、およびcrm_verifyの出力は、フィルタされません。

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

さらに追加のオプションを使用して、コマンドの実行をカスタマイズします。たとえば、Pacemakerクラスタがある場合は、確実にオプション-Aを追加する必要があるでしょう。別のユーザがクラスタに対するパーミッションを持っている場合は、(rootおよびhaclusterに加えて)-uオプションを使用してこのユーザを指定します。非標準のSSHポートを使用する場合は、-Xオプションを使用して、ポートを追加します(たとえば、ポート3479では、-X "-p 3479"を使用)。その他のオプションは、crm_reportのマニュアルページに記載されています。

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

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