This web page is no longer maintained. Information presented here exists only to avoid breaking historical links.
The Project stays maintained, and lives on: see the Linux-HA Reference Documentation.
To get rid of this notice, you may want to browse the old wiki instead.

Frequently Asked Questions

関連項目

このwikiには、上記以外のFAQも掲載されています。

Linux-HAのメーリングリストはありますか？

はい。Linux-HAでは、2種類のパブリックメーリングリストが開設されています。連絡先ページにアクセスいただければ、メーリングリストの情報が確認できます。 ContactUs_ja

クラスタとは

HA（ハイアベイラビリティクラスタ） - ハイアベイラビリティの単一（または複数）ホストを実現するクラスタです。つまり、あるノードやそのノードのサービスがダウンした場合に、別のノードがサービスやノードを検出して、障害を起こしたマシンから引き継ぐことができます。http://linux-ha.org/

コンピュータ・クラスタ - Beowulfクラスタなどを指します。汎用コンポーネントで分散コンピューティングを実現することができます。通常は安価なIA32マシンを利用します。

負荷分散クラスタ - Linux Virtual Serverプロジェクトが推進するクラスタを指します。このケースでは、サーバーファームで特定のサーバー（Apacheなど）に負荷分散リクエストを発行するマシンを使用します。

サイトには、それぞれHOWTOがあります。Linuxでのクラスタリング概要については、クラスタリングHOWTOをご参照ください。

リソーススクリプトとは

リソーススクリプトとは、基本的に、（拡張された）System V起動スクリプトのことです。stop、start、およびstatusの各オペレーションをサポートしなければなりません。将来的には、リクエストに応じてサービスを監視できるmonitorオペレーションのサポートも追加する予定です。IPaddrスクリプトは、この新しいmonitorオペレーションを実装しています（ただし、Heartbeatではその関数は使用しません）。詳細については、リソースHOWTOをご参照ください。

リソースがいくつか開始されず、エラーメッセージが表示されません。なぜですか？

おそらく、リソース・エージェント・スクリプトに問題があるのだと思います。「<resource script> status」コマンドで「ok」または「running」が出力されないと、Heartbeatがリソースを実行中と判断し、「<resource script> start」を実行しません。Heartbeatリソースエージェントの詳細については、http://wiki.linux-ha.org/HeartbeatResourceAgent をご参照ください。

リソースの監視方法

リソースの機能が停止すると、サーバーがクラッシュしない限り、Heartbeatも動作しなくなります。Heartbeatでは、どのようにリソースの監視をすればよいのでしょうか。

Heartbeatバージョン2については、Heartbeatバージョン2の「よくある質問と回答」ページをご参照ください。

バージョン1.xのHeartbeatは、リソースを監視するようには設計されていません。最適な方法は、R2スタイルのCRM構成にアップグレードすることです。1.xソフトウェアで一部のリソース（WWWサーバーの可用性など）を監視する必要がある場合には、サードパーティソフトウェアを使用する必要があります。適切なソリューションとしては、Mon があります。

1. http://kernel.org/software/mon/ からMonを入手します。kernel.orgから直接ではなく、ミラーサイトの使用をお勧めします。

2. 記載された必要なモジュールを全て入手してください。モジュールは、最寄りのミラーサイトまたはCPANアーカイブにあります。私(回答者)はPerlに詳しくないので、CPANアーカイブから.tar.gzパッケージとしてダウンロードし、通常の方法でインストールしました（perl Makefile.pl && make && make test && make install）。

3. Monは、さまざまなネットワークリソースを監視するためのソフトウェアです。コンピュータにpingを送信し、さまざまなポートに接続し、WWWやMySQLを監視します。リソースに障害が発生した場合、Monが数種類のスクリプトをトリガします。

4. 適当なディレクトリにMonを展開します。READMEファイルを読むことをお勧めします。完全なドキュメントは、<dir>/docに含まれています。ここでの、<dir>は、Monパッケージを展開した場所のことです。

5. 手際よく開始するためには、次の操作を実行してください。

   1. <dir>の全てのサブディレクトリを/usr/lib/monにコピーします。

   2. /etc/monディレクトリを作成します。

   3. <dir>/etcから/etc/monにauth.cfをコピーします。

これでMonを実行する準備ができました。独自のmon.cfファイルを作成する必要があります。このファイルで、Monが監視するリソースと、障害が発生した場合およびリソースが再び使用可能になった場合に開始する操作を指定します。全ての監視スクリプトは、/usr/lib/mon/mon.d/に格納されています。スクリプトは、最初に必ず使用方法の説明があります。警告スクリプトは全て、/usr/lib/mon/alert.d/にあります。障害が発生した場合にはトリガされます。ホームページ（http://www.linuxvirtualserver.org/）のIPVS（IP Virtual Server）を使用している方は、IPVS一覧からサーバーを追加または削除するスクリプトをお使いください。

hb_standbyを使用して、障害発生時にサービスを別のノードにフェイルオーバすることを検討してください。

（ケーブル切断、NIC障害、破損など）Ethernet接続が切断された場合に、プライマリノード（サービスを実行しているノード）が健全であるにもかかわらずユーザーがサービスを利用できません。ほかのクラスタノードにサービスをフェイルオーバすることはできますか？

はい。

監視するインターフェースごとに、最低1つの「pingノード」を指定します。クラスタ内の各ノードで、これらのpingノードは監視されます。

R1スタイルのリソースではipfailプラグインを使用します

ノードがpingノードの障害を検出した場合には、ほかのノードに連絡して問題があるかどうかの判定をします。クラスタノードに問題がある場合は、リソース（使用中の場合）をフェイルオーバします。

ipfailを使用するには、以下のコマンドを/etc/ha.d/ha.cfファイルに追加してください。

 respawn hacluster /usr/lib/heartbeat/ipfail
 ping <IPaddr1> <IPaddr2> ... <IPaddrN>

IPaddr1..Nはpingノードです。注：ipfailでは、auto_failbackオプションをonまたはoff（legacy以外）に設定してください。

ipfailの詳細については、 ipfailページをご参照ください。注：ipfailは、R1スタイルのリソースでのみ動作します。

R2スタイルのリソースではpingdプラグインを使用します

R2スタイルのリソースでは、ipfailではなく、pingdデーモンをご使用ください。pingノードは同じ方法で構成されていますが、pingdは、どんな状況で何をフェイルオーバするかという点において、高い柔軟性を備えています。注：pingdは、R2スタイルのリソースでのみ動作します。

マシンがIPエイリアスを解放するたびに、インターフェース全体（eth0）を見失ってしまいます。どうすれば修正できますか？

これはHeartbeatの問題ではなく、net-toolsのバーションの問題です。net-toolsを最新バージョンへアップグレードすれば解決できます。ifconfigを用いて、手動でテストができます。

リソースには、多くのIPアドレス（8個以上）が必要です。最適な方法は？

IPアドレスを数多くフェイルオーバするのではなく、1つのルーターのアドレスだけをフェイルオーバします。ルーターで、「route add -net x.x.x.0/24 gw x.x.x.2」に相当するコマンドを実行します。x.x.x.2は、Heartbeatによって管理されているクラスタIPアドレスです。続いて、両方のクラスタノードで、lo0の恒久的なエイリアスをフェイルオーバする各アドレスをx.x.x.0/24の範囲内に設定します。これは、「ifconfig lo:2 x.x.x.3 netmask 255.255.255.255 -arp」などのコマンドで行います。

ドキュメントではシリアル回線が推奨されていますが、Ethernet接続を2つ使用する方法は問題がありますか？

何らかの原因でEthernet / IPスタックに障害が発生した場合に、両方の接続が失われる恐れがあります。データの重要性に応じて、ケーブルをさまざまな方法で接続する必要があります。ipchainsファイアウォールを実行している場合、設定したルールに誤りがあると、スプリットブレインが発生しやすくなります。現在のところ、シリアルポートがファイアウォールルールの影響を受けることはありません。

ただし、転送データの容量の問題で、ほとんどのCRMスタイル構成が、シリアル構成では適切には動作できません。お試しになる際は、ボーレートをできるだけ高く設定してください。

Ipchainsファイアウォールとともに使用する方法

HeartbeatをIpchainsとともに実行するには、694 UDPポートの受信および送信トラフィックを許可する必要があります。以下のようなコマンドを追加してください。

/sbin/ipchains -A output -i ethN -p udp -s <source_IP> -d <dest_IP>  -j ACCEPT
/sbin/ipchains -A input -i ethN -p udp -s <source_IP> -d <dest_IP>  -j ACCEPT

「ERROR: No local heartbeat. Forcing shutdown」というメッセージが表示され、原因不明でHeartbeatが終了してしまいます。

Heartbeatは原因不明で終了することはありません。このような現象は、Heartbeatが正常に動作していないことで起こります。これまでに、以下のような原因が確認されています。

• 過剰なI/O負荷のかかったシステム。
• カーネルのバグ

過剰な負荷への対処方法については、ja/FAQ_ja#heavy_load 次のFAQ項目をご参照ください。このメッセージが表示されているのに、システムに過剰な負荷がかかっていない場合には、カーネルのバグが考えられます。2.4.18-2.4.20 Linuxカーネルには、システムのアイドル時に長期間にわたってHeartbeatをスケジュールできないというバグがありました。これに該当する場合は、バグを修正したカーネルを入手してください。

過剰な負荷がかかったシステムで、Heartbeatを調整し、スプリットブレインを回避する方法

過剰な負荷がかかった「No local heartbeat」または「Cluster node returning after partition」のエラーは、deadtimeの間隔が狭すぎるか、またはHeartbeatのバージョンが古いことが原因です。バージョン1.2.0以降を実行しているかどうかをご確認ください。以下は、推奨しているdeadtimeの調整方法です。

• deadtimeを60秒以上に設定します。

• warntimeをdeadtimeの4分の1から2分の1に設定します。

• システムに過剰な負荷をかけ、数週間稼働させます。
• ログを見て、システムがハートビートを検出せずに動作していた最長時間を確認します。「late heartbeat」のメッセージが表示されない場合は、選択したdeadtimeは適切です。そのままご使用ください。
• deadtimeを1.5～2倍に設定します。

• warntimeをkeepaliveの2倍に設定します。

• 長いHeatbeat時間に警告がないかどうか、ログの監視を続けます。実行しないと、「Cluster node ... returning after partition」と表示され、クラスタ内の全てのマシンでHeartbeatが再起動します。この現象は、ほぼ確実な頻度で発生します。

通常は、マシンのメモリ増設が有効ですが、負荷制限も有効です。この点については、1.2.x以前のバージョンよりも、新しいバージョンのHeartbeatの方が正しく動作します。1.2.3のアプリケーションではdeadtimeをサブ秒単位で設定できるとの報告もありますが、効果は環境によって異なります。

Heartbeatの起動時に、ログに「WARN: process_clustermsg: node [<ホスト名>] failed authentication」というエラーメッセージが表示されます。これはどういう意味ですか？

このメッセージはパケットが損傷していることを意味するものです。一般的に、Heartbeatの起動時にシリアルインターフェースを立ち上げると、最初のパケットが損傷したものを受信することがあります。その発生を示すインジケータです。このような現象は、特に異常ではありません。ほかの状況でも発生することがありますが、ときどきであれば（1時間に1度程度）、特に問題はありません。頻繁に発生するようでしたら、別の原因が考えられますので、調査して修正する必要があります。

Heartbeatの起動時に、「Starting High-Availability services: Heartbeat failure [rc=1]. Failed.」というメッセージが表示されますが、ログファイルには何も記録されず、メッセージも表示されません。何が問題なのでしょうか？

authkeysにパーミッションの問題が考えられます。リード・オンリー・モード（400、600、または700）に設定する必要があります。問題を検出した場所とタイミングによって、メッセージはさまざまな場所に出力されます。

次のような場所に出力される傾向があります。

1. stdout/stderr
2. セットアップで指定した場所

3. /var/log/messages

新しいリリース（1.0以降）では、構成した場所に加えて、stderrにも起動メッセージを出力する機能が向上しています。

同じネットワークセグメントで複数のクラスタを実行する方法

マルチキャストを使用し、それぞれに独自のマルチキャストグループを割り当てます。ブロードキャストを使用する場合は、それぞれのクラスタを別のポート番号で実行します。マルチキャストを使用した構成例では、ha.cfファイルに以下があります。

 mcast eth0 224.1.2.3 694 1 0

上記のコマンドは、マルチキャストを送信するインターフェースとしてeth0、マルチキャストグループとして224.1.2.3（同じクラスタのノードごとに同じ）、UDPポート694（Heartbeatのデフォルト）、生存時間1（マルチキャストをローカルネットワークセグメントに限定し、ルーターには伝播させない）、マルチキャストループバックを無効（通常の設定）に設定しています。

最新版CVSバージョンの入手方法

Linux-HAには、CVSレポジトリがあります。http://cvs.linux-ha.org/viewcvs/viewcvs.cgi/linux-ha/ にあります。ログイン名guest、パスワードguest、モジュール名linux-haを使用して、リードオンリーアクセスを実行します。詳細は、HeartbeatCVSページをご参照ください。

他のOSへの対応方法

Heartbeatはautomakeを使用しており、全般的に、移植性が高くなっています。ご利用のプラットフォームへの移植に関する情報については、Linux-HA-devLinux-HA-dev メーリングリストから入手できます。

linux-ha.org Heartbeat RPMをインストールしようとすると、すでにインストールしているパッケージの依存関係に関するエラーが表示されます。どうすればいいでしょうか？

ディストリビューションのRPMパッケージ名が異なりますので、これを回避することはできません。STONITHを使用していない場合は、RPMで「--nodeps」オプションを使用します。あるいは、Heartbeatのソースを使用して独自のRPMをビルドしてください。autoconf 2.53以降とlibnet（http://www.packetfactory.net/libnet から入手）の依存関係を追加します。HeartbeatのソースRPMを使用する（推奨）か、またはHeartbeatのソースを展開してトップディレクトリから./ConfigureMe rpmを実行します。これによりRPMがビルドされ、ディストリビューションごとに慣例的な場所に配置されます。ほかのパッケージが見つからない場合にも通知が表示されます。

クラスタを自動的にフェイルオーバしたくないのですが、フェイルオーバ前にユーザー確認を要求するには？

ha.cfファイルで「ミートウェア」のSTONITHデバイスを構成します。ミートウェアのSTONITHデバイスは、ダウンしたマシンの電源をリセットするかどうか、ユーザーに確認します。ユーザーがマシンをリセットしたら、ミートウェアSTONITHプラグインにリセットを実行したことを通知するコマンドを発行します。Heartbeatは、ユーザーがリセット実行を通知するまで、いつまでも待機します。この間、リソースは引き継がれず、何も実行されません。

STONITHとは？なぜ必要ですか？

STONITHはフェンシングの一種であり、Shoot The Other Node In The Headの頭字語です。クラスタ内の一方のノードに相手ノードをリセットさせることができます。共有ディスクを使用している場合、ディスクデータの整合性を保護するためにはフェンシングが不可欠です。Heartbeatでは、STONITHフェンシングと自己分離型のリソースをサポートしています。両方のマシンが同時にリソースをアクティブにしようとして、損傷を受ける可能性があるクラスタリソースがある場合は、特定のフェンシングを構成してください。ご不明な点がある場合は、ja/ContactUs_ja Linux-HAメーリングリストをチェックしてください。

STONITHデバイスの判定方法とデバイスの構成方法

サポートされているSTONITHデバイスの一覧を表示するには、以下のコマンドを発行します。

stonith -L

これらのSTONITHデバイス名の意味や構成方法の詳細を表示するには、以下のコマンドを発行します。

stonith -h

共有ディスクは使うのですが、STONITHは使いたくありません。お勧めの構成は？

これについてはHeartbeatが直接サポートする内容ではありませんが、いくつかの「自己分離型」リソースがあります。つまり、リソースをアクティブにすると、ほかのノードからそのリソース自身を分離するものです。このfenceフェンシングはリソースエージェントで実行されるために、Heartbeatはそれを検出しません（検出の必要がないのです）。ハードウェアのソリューションとしては、IBMのServeRAID RAIDコントローラとICP Vortex RAIDコントローラがありますが、ご自身でお調べください。ご不明な点がある場合は、メーリングリストをチェックしてください。

アクティブ/アクティブ構成で構成できますか？可能な場合、haresourcesスクリプトは各ボックスで同一でなければならず、どのように構成すればよいのでしょうか？

はい、構成は可能です。Heartbeatでは最初のリリース時からアクティブ/アクティブ構成をサポートしています。アクティブ/アクティブクラスタを構成する際には、haresourcesファイル内の各リソースグループの前に、そのサービスを実行するサーバー名が付きます。「 auto_failback yes (またはlegacy)」（または古いスタイルの「nice_failback off」）構成では、クラスタノードは起動時に、haresourcesファイルに「normal master」と表示されているリソースを引き継ぎます。以下に、Apache/MySQL構成での実行例を示します。

server1 10.10.10.1 mysql
server2 10.10.10.2 apache

この場合、IPアドレス10.10.10.1をMySQLサーバーのIPアドレスに置き換え、10.10.10.2をwebサーバーのIPアドレスに置き換えます。server1が起動していれば、MySQLサービスが実行されます。server2が起動していれば、Apacheサービスが実行されます。server1とserver2の両方が起動している場合には、両方のサーバーがアクティブになります。以前のnice_failback onパラメータとは一致しないことにご注意ください。hb_standby foreignをサポートする新しいリリースでは、auto_failback offを設定すれば、手動でアクティブ/アクティブ構成にフェイルバックすることができます。管理者は、より安全・便利な時間帯にカスタマイズされた方法で実行でき、高い柔軟性が確保できます。

インターフェースの開始時および終了時に、インターフェース名が短縮されるのはなぜですか？

Heartbeatは、ifconfigを使用してインターフェースを管理するように作られています。プラットフォームへの移植性には優れていますが、ifconfigは何らかの原因でインターフェース名を短縮します。エイリアスが10個未満の場合は、インターフェース名を7文字に、100個未満の場合はインターフェース名を6文字に制限してください。または、IPaddr2リソーススクリプトを使用することもできます。

このauto_failbackパラメータは何ですか？以前のnice_failbackパラメータはどうなったのでしょうか？

auto_failbackパラメータは、nice_failbackパラメータを置き換えるものです。以前の値nice_failback onは、auto_failback offに置き換えられます。以前の値nice_failback offは、新しいauto_failback onパラメータに置き換えられます。以前のnice_failback offとは異なり、新しいauto_failback onでは、ipfailおよびhb_standby機能をご利用になれます。

nice_failbackからauto_failbackにアップグレードする際には、以下のアップグレード手順でauto_failbackをlegacyに設定しなければならない場合があります。

nice_failbackをサポートするバージョンLinux-HAから、auto_failbackをサポートするバージョンへとアップグレードしています。このアップグレードでフラッシュカットを避ける方法は？

auto_failback以前のバージョンのHeartbeatからauto_failbackをサポートするバージョンへとアップグレードするには、以下の手順を実行して、クラスタ全体でフラッシュカットを避けることをお勧めします。

1. クラスタの一方のノードでHeartbeatを停止します。

2. このノードをアップグレードします。もう一方のノードのにnice_failback onが設定されている場合は、新しいha.cfファイルでauto_failback offを設定します。クラスタのもう一方のノードにnice_failback offが設定されている場合は、新しいha.cfファイルでauto_failback legacyを設定してください。

3. このノードで、新しいバージョンのHeartbeatを開始します。
4. クラスタのもう一方のノードでHeartbeatを停止します。

5. クラスタの2つ目のノードを新バージョンのHeartbeatにアップグレードします。上記の手順と同様に、auto_failbackを設定します。

6. クラスタの2つ目のノードでHeartbeatを開始します。

7. auto_failbackをonまたはoffに設定した場合は、これで完了です。

8. ha.cfファイルでauto_failback legacyを設定した場合は、以下の手順に進んでください。

   1. クラスタ全体を数秒間シャットダウンする時間をスケジュールします。

   2. スケジュールの時間に、両方のノードを停止させ、両方のノードでha.cfファイルのauto_failbackの値をonに変更します。

   3. 両方のノードをほぼ同時に再起動します。

   4. これで完了です。これでipfailを使い、hb_standbyコマンドを使用して手動でリソースを移動できます。

解決方法が見つからない場合は？

パッチを提出したいのですが、どうすればいいですか？

パッチのご提供を募集しています。お勧めしている方法は以下のとおりです。

• パッチに関するご質問がある場合は、まずLinux-HA-Devメーリングリストで回答をチェックします。

• 最新のCVSソースに変更を加えます。

• 変更をテストして動作することを確認します。
• 以下の方法でパッチを作成します。

   cvs -q diff -u >patchname.txt

• Linux-HA-Devメーリングリストに、[text/plain]添付ファイルとしてパッチを添付した電子メールを送信します。メーラーがzip圧縮した場合は元に戻します。

バグレポートに添付してパッチを送信することもできます。バグ・レポート・システムへのアクセス方法については、ContactUsをご参照ください。上記どちらも実行していただいても構いません。

マシンを再インストールした後、「attempted replay attack」メッセージが表示されます

マスターノード（paul）を再インストールしたら、スレーブノード（silas - リソースを含む）でHeartbeat（1.2.0）に次のメッセージが表示されました。

Mar 16 19:31:43 silas heartbeat[12561]: ERROR: should_drop_message: attempted replay attack [paul]?  
              [gen = 1, curgen = 10] 
Mar 16 19:32:15 silas last message repeated 38 times 
Mar 16 19:33:17 silas last message repeated 62 times

リソースをマスターノードに戻すにはどうすればよいですか？

paulの/var/lib/heartbeat/hb_generationに11（curgen+1）を入力します。このログから判断すると、現状では1（gen）になっているようです。

上記メッセージのcurgenの数値に1を加えた数値にします。

それから、マスターノード（paul）のHeartbeatを再起動すれば、順調に動作します。この現象の原因は、ReplayAttackProtection機能によるものです。両方のノードでHeartbeatを再起動しても構いません。

paul（再インストールを実行したマシン）のhb_generationnファイルのcurgenに適当な数値を加えて再起動すれば、Heartbeatは正常に動作します。

1台のマシンに複数のEthernetカードを搭載している場合、1つのノード内でIPフェイルオーバを実現するには？

bondingデバイスを使用すれば設定できます。詳細については、IpFailoverChannelBondingをご覧ください。

ハイアベイラビリティNFSサーバーでLinux-HAを使用するには？

HA NFSの構成方法とそれに対応するテスト結果については、HaNFSページでご覧になれます。

両方のノードが動作し、シリアルケーブルもテスト済みなのに、「TTY write timeout on [/dev/ttyxxx]」というメッセージが表示されました

CTSおよびRTSリードがシリアルケーブルの終端間を適切に通っていないことが考えられます。Heartbeatは、データ損失を避けるため、これらのリードを要求します。詳細は、シリアルケーブルページをご参照ください。

サービスを中断することなく、クラスタ内のホスト名を変更するには？

現在のマシンAとBを、それぞれCとDに変更したい場合

• A：A（Cに変更したいホスト）で全てのサービスをアクティブにする：hb_takeover

  B：/etc/init.d/heartbeat stop; vi /etc/ha.d/ha.cf /etc/ha.d/haresources # CとDのエントリを追加し、4つのホストが表示されるようにする B:/etc/init.d/heartbeat start

  B: hb_takeover

  A：/etc/init.d/heartbeat stop; vi /etc/ha.d/ha.cf # CとDのエントリを追加し、4つのホストが表示されるようにする A:/etc/init.d/heartbeat start A：hostname C # 1つ目のホストの名前を変更する # 必ず/etc/hostnameをCに変更する

  A: hb_takeover

  B：/etc/init.d/heartbeat stop; vi /etc/ha.d/ha.cf /etc/ha.d/haresources # 両方のファイルでCとDだけを残し、AとBを削除する B：hostname D # 2つ目のホストの名前を変更する # 必ず/etc/hostnameをDに変更する B：/etc/init.d/heartbeat start

  B: hb_takeover

  A：/etc/init.d/heartbeat stop; vi /etc/ha.d/ha.cf /etc/ha.d/haresources # 両方のファイルでCとDだけを残し、AとBを削除する A：/etc/init.d/heartbeat start

  A: hb_takeover # 必要な場合は、ホストAをアクティブなロードバランサーとして残す

リソースのライブ変更を行うには？

一般的なケースでは、R1スタイルの構成は多少面倒なのですが、以下の方法は1.2.xシリーズ以降で動作します。ただし、R2スタイルのCRM構成を使用すれば正確に動作します。

リソースを削除または追加せずに再編成する場合は、次の手順に従ってください。

1. 一方のノードでhb_standbyを実行します。

2. 両方のノードでharesourcesを更新します。

リソースを実行中のノードを変更する場合は、次の手順に従ってください。

1. ノードAでhb_standby foreignを実行します（完了まで待ってください）。

2. ノードBでhb_standby foreignを実行します。

リソースを追加または削除する場合は、次の手順に従ってください。

1. ノードAでhb_standbyを実行します。

2. ノードAのharesourcesファイルを更新します。

3. ノードBでhb_standbyを実行します（完了まで待ってください）。

4. ノードBでharesourcesファイルを更新します。

5. ノードAでhb_standby foreignを実行します（完了まで待ってください）

6. ノードBでhb_standby foreignを実行します。

両方のノードが起動しているのに、どちらのノードも停止していると認識されます。どうすれば修正できますか？

多くの場合、原因はファイアウォールルールにあります。気付かずに、ファイアウォールルールを実行している可能性があります。現行ディストリビューションの大半は、デフォルトでファイアウォールルールが有効になっています。まずは、ファイアウォールルールをチェックしてください。

ファイアウォールルールをチェックするには、「iptables-save」コマンドを使用して、現在のファイアウォールルールをダンプします。ファイアウォールルールを設定していない場合は、次のような出力が表示されます。

  [2] guin:~# iptables-save
  # Generated by iptables-save v1.3.0 on Fri Dec 30 16:29:07 2005
  *filter
  :FORWARD ACCEPT [0:0]
  :INPUT ACCEPT [16:1935]
  :OUTPUT ACCEPT [19:1790]
  COMMIT
  # Completed on Fri Dec 30 16:29:07 2005
  [2] guin:~#

Red HatおよびFedora Coreシステムでは、「/etc/init.d/iptables stop」を実行してファイアウォールルールを無効にすることができます。この方法は、テストの目的でのみお勧めするものです。テスト以外のときには、システムのファイアウォールは常時実行しておく必要があります。

上記を確認後、それでも問題が解決しない場合、サポートを求める際には、まず、ファイアウォールルールが設定されていないことを確認するために行ったことを説明してください。ほとんどの場合、原因は、やはりファイアウォールなのですが、そうではないと主張されるユーザーがいらっしゃいます。もう一度、ファイアウォールルールをよくチェックし、その結果をコミュニティサポートまでご報告ください。

---

CategoryHowto

Linux-HA サイト built by the Linux-HA crowd. HTML4 / CSS2