第5回 Pacemakerを運用してみよう！［保守運用編(2)］ | gihyo.jp
ここでは、リソースのmonitor故障検知時の動作について説明します。Pacemakerはリソースのmonitor故障を検知した場合は、故障が発生したサーバにフェイルカウント（フラグ）を立て、リソースのフェイルオーバ処理を実施します。 図1 リソース故障 故障を発生させてみよう では、実際にリソース故障を発生させて、Pacemakerの動きを見てみましょう。今回はリソース故障を擬似的に起こすため、Pacemaker稼働中にhttpdを停止します。 # /etc/init.d/httpd stop httpd停止後crm_monコマンドを実行すると、pm01でhttpdのmonitor故障を検知したため、故障回数と故障内容が表示され、リソースがpm02にフェイルオーバしていることが確認できます。 Online: [ pm01 pm02 ] Resource Group: web vip (o
第4回 Pacemakerを運用してみよう！［保守運用編(1)］ | gihyo.jp
※ スプリットブレインなどで相手のサーバを一切認識できなくなったり、Pacemakerが停止しているサーバの状態については、表示されなくなります。 故障回数表示 リソースの故障状態が表示されます。リソースの故障を検知すると、故障が発生したサーバと故障リソースの情報を表示します。故障回数表示に表示される故障情報は、サーバでリソース故障が起きたというフラグにも使用されており、そのフラグのことをフェイルカウントと呼びます。また、migration-threshold が"1"に設定されているため、1回の故障でフェイルオーバが発生していることがわかります。（migration-thresholdについては第2回を参照） 故障内容表示 故障回数表示で表示されたリソースの故障内容として、故障オペレーション（start/monitor/stop）、故障サーバ名、リターンコード（rc）が表示されます
第3回 Pacemakerでいろいろ設定してみよう！［構築応用編］ | gihyo.jp
さて、第2回では単純な1＋1構成と簡単なリソースの起動を試してみましたが、今回はスプリットブレイン対策を考えてみたいと思います。 スプリットブレインって？ Pacemakerを設定する上で欠かせないのがスプリットブレイン対策です。スプリットブレインとはインターコネクト（ハートビート）通信が全て切断された状態のことです。 通常はあるサーバ（DCと呼ぶ）のPacemakerがクラスタ全体の指揮をとっていますが、スプリットブレインになると、各サーバのPacemakerが勝手に指揮をとり始めます。そうなると最悪の場合、各サーバでリソースが起動し、リソースの種類によってはデータの破壊やIPアドレスの競合といった状態を引き起こしてしまいます。 図1 スプリットブレイン こういった状態を避けるためにインターコネクト用LANは冗長化することが望ましいのですが、それでもスプリットブレインになった時の対策とし
第2回 Pacemakerをインストールしてみよう！［構築基本編］ | gihyo.jp
NICは3つ使用します。1つはサービス提供用、残りの2つはインターコネクト通信用です。ネットワーク構成は図1のようになっているとし、サーバからインターネット接続できるようにしてください。 作業はrootユーザで行います。sshでリモート作業する場合には、必要に応じてパスワード入力してください。 作業用にサーバpm01で、ターミナルを1つ起動してください。ほとんどの作業はこのターミナルで行います。 図1 ネットワーク構成 Pacemakerのインストール 第1回でPacemakerは複数のコンポーネントの組み合わせとして提供されるという話をしました。そこで、Linux-HA Japanでは、必要なrpmがすべて入ったyumリポジトリ（Pacemakerリポジトリパッケージ）を配布しています。このyumリポジトリにはLinux-HA Japanで開発したオリジナルパッケージも含まれています。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
