タグ

GihyoとLinuxとLinux-HAに関するwasaiのブックマーク (2)

  • 第4回 Pacemakerを運用してみよう![保守運用編(1)] | gihyo.jp

    ※ スプリットブレインなどで相手のサーバを一切認識できなくなったり、Pacemakerが停止しているサーバの状態については、表示されなくなります。 故障回数表示 リソースの故障状態が表示されます。リソースの故障を検知すると、故障が発生したサーバと故障リソースの情報を表示します。故障回数表示に表示される故障情報は、サーバでリソース故障が起きたというフラグにも使用されており、そのフラグのことをフェイルカウントと呼びます。また、migration-threshold が"1"に設定されているため、1回の故障でフェイルオーバが発生していることがわかります。(⁠migration-thresholdについては第2回を参照) 故障内容表示 故障回数表示で表示されたリソースの故障内容として、故障オペレーション(start/monitor/stop⁠)⁠、故障サーバ名、リターンコード(rc)が表示されます

    第4回 Pacemakerを運用してみよう![保守運用編(1)] | gihyo.jp
    wasai
    wasai 2011/04/28
  • 第3回 Pacemakerでいろいろ設定してみよう![構築応用編] | gihyo.jp

    さて、第2回では単純な1+1構成と簡単なリソースの起動を試してみましたが、今回はスプリットブレイン対策を考えてみたいと思います。 スプリットブレインって? Pacemakerを設定する上で欠かせないのがスプリットブレイン対策です。スプリットブレインとはインターコネクト(ハートビート)通信が全て切断された状態のことです。 通常はあるサーバ(DCと呼ぶ)のPacemakerがクラスタ全体の指揮をとっていますが、スプリットブレインになると、各サーバのPacemakerが勝手に指揮をとり始めます。そうなると最悪の場合、各サーバでリソースが起動し、リソースの種類によってはデータの破壊やIPアドレスの競合といった状態を引き起こしてしまいます。 図1 スプリットブレイン こういった状態を避けるためにインターコネクト用LANは冗長化することが望ましいのですが、それでもスプリットブレインになった時の対策とし

    第3回 Pacemakerでいろいろ設定してみよう![構築応用編] | gihyo.jp
    wasai
    wasai 2011/04/14
    松尾さんの記事
  • 1