Contents
このwikiには、上記以外のFAQも掲載されています。
はい。Linux-HAでは、2種類のパブリックメーリングリストが開設されています。連絡先ページにアクセスいただければ、メーリングリストの情報が確認できます。 ContactUs_ja[1]
HA（ハイアベイラビリティクラスタ） - ハイアベイラビリティの単一（または複数）ホストを実現するクラスタです。つまり、あるノード[2]やそのノードのサービスがダウンした場合に、別のノードがサービスやノードを検出して、障害を起こしたマシンから引き継ぐことができます。http://linux-ha.org/[3]
コンピュータ・クラスタ - Beowulf[4]クラスタなどを指します。汎用コンポーネントで分散コンピューティングを実現することができます。通常は安価なIA32マシンを利用します。
負荷分散クラスタ - Linux Virtual Server[5]プロジェクトが推進するクラスタを指します。このケースでは、サーバーファームで特定のサーバー（Apacheなど）に負荷分散リクエストを発行するマシンを使用します。
サイトには、それぞれHOWTOがあります。Linuxでのクラスタリング概要については、クラスタリングHOWTOをご参照ください。
リソーススクリプトとは、基本的に、（拡張された）System V[6]起動スクリプトのことです。stop、start、およびstatusの各オペレーションをサポートしなければなりません。将来的には、リクエストに応じてサービスを監視できるmonitorオペレーションのサポートも追加する予定です。IPaddr[7]スクリプトは、この新しいmonitorオペレーションを実装しています（ただし、Heartbeat[8]ではその関数は使用しません）。詳細については、リソースHOWTOをご参照ください。
おそらく、リソース・エージェント・スクリプトに問題があるのだと思います。「<resource script> status」コマンドで「ok」または「running」が出力されないと、Heartbeat[8]がリソース[9]を実行中と判断し、「<resource script> start」を実行しません。Heartbeatリソースエージェントの詳細については、http://wiki.linux-ha.org/HeartbeatResourceAgent[10] をご参照ください。
リソース[9]の機能が停止すると、サーバーがクラッシュしない限り、Heartbeat[8]も動作しなくなります。Heartbeatでは、どのようにリソースの監視をすればよいのでしょうか。
Heartbeat[8]バージョン2[11]については、Heartbeatバージョン2の「よくある質問と回答」[12]ページをご参照ください。
バージョン1.xのHeartbeatは、リソースを監視するようには設計されていません。最適な方法は、R2スタイルのCRM[13]構成にアップグレードすることです。1.xソフトウェアで一部のリソース（WWWサーバーの可用性など）を監視する必要がある場合には、サードパーティソフトウェアを使用する必要があります。適切なソリューションとしては、Mon[14] があります。
http://kernel.org/software/mon/[15] からMonを入手します。kernel.orgから直接ではなく、ミラーサイトの使用をお勧めします。
記載された必要なモジュールを全て入手してください。モジュールは、最寄りのミラーサイトまたはCPANアーカイブにあります。私(回答者)はPerlに詳しくないので、CPANアーカイブ[16]から.tar.gzパッケージとしてダウンロードし、通常の方法でインストールしました（perl Makefile.pl && make && make test && make install）。
Mon[14]は、さまざまなネットワークリソースを監視するためのソフトウェアです。コンピュータにpingを送信し、さまざまなポートに接続し、WWWやMySQLを監視します。リソースに障害が発生した場合、Monが数種類のスクリプトをトリガします。
適当なディレクトリにMon[14]を展開します。READMEファイルを読むことをお勧めします。完全なドキュメントは、<dir>/docに含まれています。ここでの、<dir>は、Monパッケージを展開した場所のことです。
<dir>の全てのサブディレクトリを/usr/lib/monにコピーします。
/etc/monディレクトリを作成します。
<dir>/etcから/etc/monにauth.cfをコピーします。
これでMon[14]を実行する準備ができました。独自のmon.cfファイルを作成する必要があります。このファイルで、Monが監視するリソース[9]と、障害が発生した場合およびリソースが再び使用可能になった場合に開始する操作を指定します。全ての監視スクリプトは、/usr/lib/mon/mon.d/に格納されています。スクリプトは、最初に必ず使用方法の説明があります。警告スクリプトは全て、/usr/lib/mon/alert.d/にあります。障害が発生した場合にはトリガされます。ホームページ（http://www.linuxvirtualserver.org/）の[17]IPVS（IP Virtual Server）を使用している方は、IPVS一覧からサーバーを追加または削除するスクリプトをお使いください。
hb_standby[18]を使用して、障害発生時にサービスを別のノードにフェイルオーバ[19]することを検討してください。
はい。
監視するインターフェースごとに、最低1つの「pingノード[20]」を指定します。クラスタ[21]内の各ノード[22]で、これらのpingノードは監視されます。
ノードがpingノードの障害を検出した場合には、ほかのノードに連絡して問題があるかどうかの判定をします。クラスタノードに問題がある場合は、リソース[9]（使用中の場合）をフェイルオーバ[19]します。
ipfail[23]を使用するには、以下のコマンドを/etc/ha.d/ha.cf[24]ファイルに追加してください。
respawn hacluster /usr/lib/heartbeat/ipfail ping <IPaddr1> <IPaddr2> ... <IPaddrN>
IPaddr1..Nはpingノードです。注：ipfail[23]では、auto_failback[25]オプションをonまたはoff（legacy以外）に設定してください。
ipfail[23]の詳細については、 ipfailページ[23]をご参照ください。注：ipfail[23]は、R1スタイルのリソースでのみ動作します。
R2スタイルのリソースでは、ipfail[23]ではなく、pingd[26]デーモンをご使用ください。pingノードは同じ方法で構成されていますが、pingd[26]は、どんな状況で何をフェイルオーバするかという点において、高い柔軟性を備えています。注：pingdは、R2スタイルのリソースでのみ動作します。
これはHeartbeat[8]の問題ではなく、net-toolsのバーションの問題です。net-toolsを最新バージョンへアップグレードすれば解決できます。ifconfigを用いて、手動でテストができます。
IPアドレスを数多くフェイルオーバ[19]するのではなく、1つのルーターのアドレスだけをフェイルオーバします。ルーターで、「route add -net x.x.x.0/24 gw x.x.x.2」に相当するコマンドを実行します。x.x.x.2は、Heartbeat[8]によって管理されているクラスタ[21]IPアドレスです。続いて、両方のクラスタノード[22]で、lo0の恒久的なエイリアスをフェイルオーバする各アドレスをx.x.x.0/24の範囲内に設定します。これは、「ifconfig lo:2 x.x.x.3 netmask 255.255.255.255 -arp」などのコマンドで行います。
何らかの原因でEthernet / IPスタックに障害が発生した場合に、両方の接続が失われる恐れがあります。データの重要性に応じて、ケーブルをさまざまな方法で接続する必要があります。ipchainsファイアウォールを実行している場合、設定したルールに誤りがあると、スプリットブレインが発生しやすくなります。現在のところ、シリアルポートがファイアウォールルールの影響を受けることはありません。
ただし、転送データの容量の問題で、ほとんどのCRMスタイル構成が、シリアル構成では適切には動作できません。お試しになる際は、ボーレートをできるだけ高く設定してください。
Heartbeat[8]をIpchains[27]とともに実行するには、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
Heartbeat[8]は原因不明で終了することはありません。このような現象は、Heartbeatが正常に動作していないことで起こります。これまでに、以下のような原因が確認されています。
過剰な負荷への対処方法については、ja/FAQ_ja#heavy_load 次のFAQ項目[28]をご参照ください。このメッセージが表示されているのに、システムに過剰な負荷がかかっていない場合には、カーネルのバグが考えられます。2.4.18-2.4.20 Linuxカーネルには、システムのアイドル時に長期間にわたってHeartbeatをスケジュールできないというバグがありました。これに該当する場合は、バグを修正したカーネルを入手してください。
過剰な負荷がかかった「No local heartbeat」または「Cluster node returning after partition」のエラーは、deadtime[29]の間隔が狭すぎるか、またはHeartbeat[8]のバージョンが古いことが原因です。バージョン1.2.0以降を実行しているかどうかをご確認ください。以下は、推奨しているdeadtimeの調整方法です。
deadtime[29]を60秒以上に設定します。
warntimeをkeepalive[31]の2倍に設定します。
長いHeatbeat時間に警告がないかどうか、ログの監視を続けます。実行しないと、「Cluster node ... returning after partition」と表示され、クラスタ[21]内の全てのマシンでHeartbeatが再起動します。この現象は、ほぼ確実な頻度で発生します。
通常は、マシンのメモリ増設が有効ですが、負荷制限も有効です。この点については、1.2.x以前のバージョンよりも、新しいバージョンのHeartbeatの方が正しく動作します。1.2.3のアプリケーションではdeadtimeをサブ秒単位で設定できるとの報告もありますが、効果は環境によって異なります。
このメッセージはパケットが損傷していることを意味するものです。一般的に、Heartbeat[8]の起動時にシリアルインターフェースを立ち上げると、最初のパケットが損傷したものを受信することがあります。その発生を示すインジケータです。このような現象は、特に異常ではありません。ほかの状況でも発生することがありますが、ときどきであれば（1時間に1度程度）、特に問題はありません。頻繁に発生するようでしたら、別の原因が考えられますので、調査して修正する必要があります。
authkeys[32]にパーミッションの問題が考えられます。リード・オンリー・モード（400、600、または700）に設定する必要があります。問題を検出した場所とタイミングによって、メッセージはさまざまな場所に出力されます。
次のような場所に出力される傾向があります。
/var/log/messages
新しいリリース（1.0以降）では、構成した場所に加えて、stderrにも起動メッセージを出力する機能が向上しています。
マルチキャスト[33]を使用し、それぞれに独自のマルチキャストグループを割り当てます。ブロードキャストを使用する場合は、それぞれのクラスタ[21]を別のポート番号で実行します。マルチキャストを使用した構成例では、ha.cf[24]ファイルに以下があります。
mcast eth0 224.1.2.3 694 1 0
上記のコマンドは、マルチキャストを送信するインターフェースとしてeth0、マルチキャストグループとして224.1.2.3（同じクラスタのノード[22]ごとに同じ）、UDPポート694（Heartbeatのデフォルト）、生存時間1（マルチキャストをローカルネットワークセグメントに限定し、ルーターには伝播させない）、マルチキャストループバックを無効（通常の設定）に設定しています。
Linux-HAには、CVS[34]レポジトリがあります。http://cvs.linux-ha.org/viewcvs/viewcvs.cgi/linux-ha/[35] にあります。ログイン名guest、パスワードguest、モジュール名linux-haを使用して、リードオンリーアクセスを実行します。詳細は、HeartbeatCVS[36]ページをご参照ください。
Heartbeat[8]はautomakeを使用しており、全般的に、移植性が高くなっています。ご利用のプラットフォームへの移植に関する情報については、Linux-HA-devLinux-HA-dev メーリングリスト[37]から入手できます。
ディストリビューションのRPM[38]パッケージ名が異なりますので、これを回避することはできません。STONITH[39]を使用していない場合は、RPMで「--nodeps」オプションを使用します。あるいは、Heartbeatのソースを使用して独自のRPMをビルドしてください。autoconf 2.53以降とlibnet（http://www.packetfactory.net/libnet[40] から入手）の依存関係を追加します。Heartbeat[8]のソースRPMを使用する（推奨）か、またはHeartbeatのソースを展開してトップディレクトリから./ConfigureMe rpmを実行します。これによりRPMがビルドされ、ディストリビューションごとに慣例的な場所に配置されます。ほかのパッケージが見つからない場合にも通知が表示されます。
ha.cf[24]ファイルで「ミートウェア」のSTONITH[39]デバイスを構成します。ミートウェアのSTONITHデバイスは、ダウンしたマシンの電源をリセットするかどうか、ユーザーに確認します。ユーザーがマシンをリセットしたら、ミートウェアSTONITHプラグインにリセットを実行したことを通知するコマンドを発行します。Heartbeatは、ユーザーがリセット実行を通知するまで、いつまでも待機します。この間、リソース[9]は引き継がれず、何も実行されません。
STONITH[39]はフェンシング[41]の一種であり、Shoot The Other Node In The Headの頭字語です。クラスタ[21]内の一方のノード[22]に相手ノードをリセットさせることができます。共有ディスクを使用している場合、ディスクデータの整合性を保護するためにはフェンシングが不可欠です。Heartbeat[8]では、STONITHフェンシングと自己分離型のリソース[9]をサポートしています。両方のマシンが同時にリソースをアクティブにしようとして、損傷を受ける可能性があるクラスタリソースがある場合は、特定のフェンシングを構成してください。ご不明な点がある場合は、ja/ContactUs_ja Linux-HAメーリングリスト[42]をチェックしてください。
サポートされているSTONITH[39]デバイスの一覧を表示するには、以下のコマンドを発行します。
stonith -L
これらのSTONITHデバイス名の意味や構成方法の詳細を表示するには、以下のコマンドを発行します。
stonith -h
これについてはHeartbeat[8]が直接サポートする内容ではありませんが、いくつかの「自己分離型」リソース[9]があります。つまり、リソースをアクティブにすると、ほかのノード[22]からそのリソース自身を分離するものです。このfence[41]フェンシングはリソースエージェントで実行されるために、Heartbeatはそれを検出しません（検出の必要がないのです）。ハードウェアのソリューションとしては、IBMのServeRAID[43] RAIDコントローラとICP Vortex RAIDコントローラがありますが、ご自身でお調べください。ご不明な点がある場合は、メーリングリスト[37]をチェックしてください。
はい、構成は可能です。Heartbeatでは最初のリリース時からアクティブ/アクティブ[44]構成をサポートしています。アクティブ/アクティブ[44]クラスタ[21]を構成する際には、haresources[45]ファイル内の各リソースグループ[46]の前に、そのサービスを実行するサーバー名が付きます。「 auto_failback[25] yes (またはlegacy)」（または古いスタイルの「nice_failback off」）構成では、クラスタノード[22]は起動時に、haresources[45]ファイルに「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を設定すれば、手動でアクティブ/アクティブ[44]構成にフェイルバック[47]することができます。管理者は、より安全・便利な時間帯にカスタマイズされた方法で実行でき、高い柔軟性が確保できます。
Heartbeat[8]は、ifconfigを使用してインターフェースを管理するように作られています。プラットフォームへの移植性には優れていますが、ifconfigは何らかの原因でインターフェース名を短縮します。エイリアスが10個未満の場合は、インターフェース名を7文字に、100個未満の場合はインターフェース名を6文字に制限してください。または、IPaddr2[48]リソーススクリプトを使用することもできます。
auto_failback[25]パラメータは、nice_failbackパラメータを置き換えるものです。以前の値nice_failback onは、auto_failback offに置き換えられます。以前の値nice_failback offは、新しいauto_failback onパラメータに置き換えられます。以前のnice_failback offとは異なり、新しいauto_failback onでは、ipfail[23]およびhb_standby[18]機能をご利用になれます。
nice_failbackからauto_failbackにアップグレードする際には、以下のアップグレード手順[49]でauto_failbackをlegacyに設定しなければならない場合があります。
auto_failback以前のバージョンのHeartbeat[8]からauto_failback[25]をサポートするバージョンへとアップグレードするには、以下の手順を実行して、クラスタ[21]全体でフラッシュカットを避けることをお勧めします。
クラスタの一方のノード[22]でHeartbeatを停止します。
このノードをアップグレードします。もう一方のノードのにnice_failback onが設定されている場合は、新しいha.cf[24]ファイルでauto_failback offを設定します。クラスタのもう一方のノードにnice_failback offが設定されている場合は、新しいha.cf[24]ファイルでauto_failback legacyを設定してください。
クラスタの2つ目のノードを新バージョンのHeartbeatにアップグレードします。上記の手順と同様に、auto_failbackを設定します。
auto_failbackをonまたはoffに設定した場合は、これで完了です。
ha.cf[24]ファイルでauto_failback legacyを設定した場合は、以下の手順に進んでください。
スケジュールの時間に、両方のノードを停止させ、両方のノードでha.cf[24]ファイルのauto_failbackの値をonに変更します。
これで完了です。これでipfail[23]を使い、hb_standby[18]コマンドを使用して手動でリソース[9]を移動できます。
解決できない問題がある場合には、以下のことを行ってください。
ドキュメントおよび検索したメーリングリストのアーカイブ[37]を全て読んでください。それでも解決方法が見つからない場合には、メーリングリスト[37]に質問を投稿いただけます。まず、不審な動作や予期しない動作について、簡潔・明確に説明する電子メールを作成してください。英語が得意でない方もいらっしゃるかもしれませんが、ご心配はありません。理路整然と、できるだけ分かりやすく説明してください。長い文章や段落は使わないでください。情報を明確に説明することは、参加者全員の役に立つことになります。また、電子メールは、HTMLではなく、プレーンテキストで送信してください。HTMLメールは一部のユーザー環境にご迷惑をかけることがありますので、プレーンテキストの方が適しています。以下の情報を記入してください。
Heartbeat[8]のインストール方法（tar.gz、rpm、src.rpm、または手動インストール）
両方のマシンの構成ファイル。authkeys[32]は省略可。text/plain添付ファイルとして送信します。
「整形した」ログを送信しないでください。実際のログには、整形したものと比べ、より多くの情報が含まれています。全員が完全な情報を得られるよう、少なくとも、該当するイベントの前後にある無関係なデータについては、残しておいてください。できればログから取得したタイムスタンプを付けて、いつどんな操作を実行したかを説明してください。セキュリティ上の理由がない限りは、ログは編集しないでください。5～8ファイルを添付してください。
デバッグ出力が通常の出力と同じファイルに出力されるR1クラスタでは5ファイル、デバッグ出力が同じファイルに出力されるR1クラスタでは6ファイル、デバッグ出力が単一ファイルに出力されるR2クラスタでは7ファイル、それ以外のクラスタでは8ファイルをご用意ください。各マシンについて、以下を送信します。
ha.cf[24]
cibadmin -Qlの出力またはharesources[45]（R1クラスタの場合）
バグレポートを提出する場合は、コンタクト情報[50] でbugzilla情報の詳細をご覧ください。
パッチのご提供を募集しています。お勧めしている方法は以下のとおりです。
パッチに関するご質問がある場合は、まずLinux-HA-Devメーリングリスト[37]で回答をチェックします。
最新のCVS[34]ソースに変更を加えます。
cvs -q diff -u >patchname.txt
Linux-HA-Devメーリングリスト[37]に、[text/plain]添付ファイルとしてパッチを添付した電子メールを送信します。メーラーがzip圧縮した場合は元に戻します。
バグレポートに添付してパッチを送信することもできます。バグ・レポート・システムへのアクセス方法については、ContactUs[51]をご参照ください。上記どちらも実行していただいても構いません。
マスターノード（paul）を再インストールしたら、スレーブノード[22]（silas - リソース[9]を含む）でHeartbeat[8]（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[52]機能によるものです。両方のノードでHeartbeatを再起動しても構いません。
paul（再インストールを実行したマシン）のhb_generationnファイルのcurgenに適当な数値を加えて再起動すれば、Heartbeatは正常に動作します。
bondingデバイスを使用すれば設定できます。詳細については、IpFailoverChannelBonding[53]をご覧ください。
HA NFSの構成方法とそれに対応するテスト結果については、HaNFS[54]ページでご覧になれます。
CTSおよびRTSリードがシリアルケーブルの終端間を適切に通っていないことが考えられます。Heartbeat[8]は、データ損失を避けるため、これらのリードを要求します。詳細は、シリアルケーブルページをご参照ください。
現在のマシンAとBを、それぞれCとDに変更したい場合
A：A（Cに変更したいホスト）で全てのサービスをアクティブにする：hb_takeover[55]
B：/etc/init.d/heartbeat stop; vi /etc/ha.d/ha.cf[24] /etc/ha.d/haresources[45] # CとDのエントリを追加し、4つのホストが表示されるようにする B:/etc/init.d/heartbeat start
B: hb_takeover[55]
A：/etc/init.d/heartbeat stop; vi /etc/ha.d/ha.cf[24] # CとDのエントリを追加し、4つのホストが表示されるようにする A:/etc/init.d/heartbeat start A：hostname C # 1つ目のホストの名前を変更する # 必ず/etc/hostnameをCに変更する
A: hb_takeover[55]
B：/etc/init.d/heartbeat stop; vi /etc/ha.d/ha.cf[24] /etc/ha.d/haresources[45] # 両方のファイルでCとDだけを残し、AとBを削除する B：hostname D # 2つ目のホストの名前を変更する # 必ず/etc/hostnameをDに変更する B：/etc/init.d/heartbeat start
B: hb_takeover[55]
A：/etc/init.d/heartbeat stop; vi /etc/ha.d/ha.cf[24] /etc/ha.d/haresources[45] # 両方のファイルでCとDだけを残し、AとBを削除する A：/etc/init.d/heartbeat start
A: hb_takeover[55] # 必要な場合は、ホストAをアクティブなロードバランサーとして残す
一般的なケースでは、R1スタイルの構成は多少面倒なのですが、以下の方法は1.2.xシリーズ以降で動作します。ただし、R2スタイルのCRM構成を使用すれば正確に動作します。
リソースを削除または追加せずに再編成する場合は、次の手順に従ってください。
一方のノードでhb_standby[18]を実行します。
両方のノードでharesources[45]を更新します。
リソースを実行中のノードを変更する場合は、次の手順に従ってください。
ノードAでhb_standby[18] foreignを実行します（完了まで待ってください）。
ノードBでhb_standby[18] foreignを実行します。
リソースを追加または削除する場合は、次の手順に従ってください。
ノードAでhb_standby[18]を実行します。
ノードAのharesources[45]ファイルを更新します。
ノードBでhb_standby[18]を実行します（完了まで待ってください）。
ノードBでharesources[45]ファイルを更新します。
ノードAでhb_standby[18] foreignを実行します（完了まで待ってください）
ノードBでhb_standby[18] 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[56]
| [1] | http://www.linux-ha.org/ja/FAQ_ja/ja/ContactUs_ja |
| [2] | http://www.linux-ha.org/ja/ClusterNode_ja |
| [3] | http://linux-ha.org/ |
| [4] | http://www.beowulf.org/ |
| [5] | http://www.linuxvirtualserver.org/ |
| [6] | http://ja.wikipedia.org/wiki/System_V |
| [7] | http://www.linux-ha.org/ja/HeartbeatResourceAgent/IPaddr_ja |
| [8] | http://www.linux-ha.org/ja/Heartbeat_ja |
| [9] | http://www.linux-ha.org/ja/resource_ja |
| [10] | http://wiki.linux-ha.org/HeartbeatResourceAgent |
| [11] | http://www.linux-ha.org/ja/v2_ja |
| [12] | http://www.linux-ha.org/ja/v2/faq_ja |
| [13] | http://www.linux-ha.org/ja/CRM_ja |
| [14] | http://www.linux-ha.org/ja/mon_ja |
| [15] | http://kernel.org/software/mon/ |
| [16] | http://www.cpan.org |
| [17] | http://www.linuxvirtualserver.org/）の |
| [18] | http://www.linux-ha.org/ja/hb_standby_ja |
| [19] | http://en.wikipedia.org/wiki/Failover |
| [20] | http://www.linux-ha.org/ja/PingNode_ja |
| [21] | http://ja.wikipedia.org/wiki/コンピュータ・クラスター |
| [22] | http://www.linux-ha.org/ja/node_ja |
| [23] | http://www.linux-ha.org/ja/ipfail_ja |
| [24] | http://www.linux-ha.org/ja/ha.cf_ja |
| [25] | http://www.linux-ha.org/ja/ha.cf/AutoFailbackDirective_ja |
| [26] | http://www.linux-ha.org/ja/pingd_ja |
| [27] | http://en.wikipedia.org/wiki/Ipchains |
| [28] | http://www.linux-ha.org/ja/FAQ_ja#heavy_load+%E6%AC%A1%E3%81%AEFAQ%E9%A0%85%E7%9B%AE |
| [29] | http://www.linux-ha.org/ja/ha.cf/DeadtimeDirective_ja |
| [30] | http://www.linux-ha.org/ja/ha.cf/WarntimeDirective_ja |
| [31] | http://www.linux-ha.org/ja/ha.cf/KeepaliveDirective_ja |
| [32] | http://www.linux-ha.org/ja/authkeys_ja |
| [33] | http://www.linux-ha.org/ja/ha.cf/McastDirective_ja |
| [34] | http://www.linux-ha.org/ja/CVS_ja |
| [35] | http://cvs.linux-ha.org/viewcvs/viewcvs.cgi/linux-ha/ |
| [36] | http://www.linux-ha.org/ja/HeartbeatCVS_ja |
| [37] | http://www.linux-ha.org/ja/ContactUs_ja |
| [38] | http://ja.wikipedia.org/wiki/RPM_Package_Manager |
| [39] | http://www.linux-ha.org/ja/STONITH_ja |
| [40] | http://www.packetfactory.net/libnet |
| [41] | http://www.linux-ha.org/ja/fencing_ja |
| [42] | http://www.linux-ha.org/ja/ContactUs_ja_Linux-HA%E3%83%A1%E3%83%BC%E3%83%AA%E3%83%B3%E3%82%B0%E3%83%AA%E3%82%B9%E3%83%88 |
| [43] | http://www.linux-ha.org/ja/ServeRAID_ja |
| [44] | http://www.linux-ha.org/ja/ActiveActive_ja |
| [45] | http://www.linux-ha.org/ja/haresources_ja |
| [46] | http://www.linux-ha.org/ja/ResourceGroup_ja |
| [47] | http://www.linux-ha.org/ja/failback_ja |
| [48] | http://www.linux-ha.org/ja/HeartbeatResourceAgent/IPaddr2_ja |
| [49] | http://www.linux-ha.org/ja/FAQ_ja#auto_failback_upgrade |
| [50] | http://www.linux-ha.org/ja/ContactUs_ja#bugzilla |
| [51] | http://www.linux-ha.org/ContactUs |
| [52] | http://www.linux-ha.org/ReplayAttackProtection |
| [53] | http://www.linux-ha.org/IpFailoverChannelBonding |
| [54] | http://www.linux-ha.org/ja/HaNFS_ja |
| [55] | http://www.linux-ha.org/ja/hb_takeover_ja |
| [56] | http://www.linux-ha.org/CategoryHowto |
This information provided courtesy of the Linux-HA project at http://linux-ha.org/