OSSを活用し高可用性と低価格を両立──PacemakerによるHAクラスタ | gihyo.jp
システムの信頼性確保には二重化が基本 サーバは「止めないこと」が原則です。特に企業の基幹業務に関わる部分や、オンラインサービスを提供している場合、サーバの停止は業務の停止を意味するため、サーバの障害監視と障害発生時の対策は常に意識している必要があります。サーバにはHDD（ハードディスクドライブ）や冷却ファンなどの回転機構のあるパーツ、電源など熱を発生するパーツがあり、しばしば故障の原因となります。 もちろん、こうしたサーバを構成するパーツは故障を前提として作られていますが、実際に障害が発生したときにはサービスを止めずに復旧を行うことが重要になります。特に、障害発生から復旧までのプロセスにおいて、データが失われることは避けなければなりません。そこで、サーバでは二重化（冗長化）が行われています。二重化には、故障しやすいパーツを複数個搭載しておく手法や、サーバそのものを複数台するといった手法があ
［3］Heartbeatで監視、Pacemakerでフェイルオーバー
HAクラスタは、複数のコンピュータ（以下、ノードと呼ぶ）が相互に通信して健全性を確認し、健全なノードのどれかでサービスを提供することによって、全体として可用性を高める。 したがってHAクラスタには、次の2つの要素が不可欠だ（図1）。 ・健全性を相互に確認するためのノード間の通信 ・健全なノードでサービスを動かすための判断と制御の仕組み 前者を担当するのがHeartbeat、後者を担当するのがPacemakerになる。 Heartbeatは「クラスタノード管理システム」として動作する。Heartbeatを実行しているノードは、「ハートビート」と呼ぶパケットを他のノードに向けて定期的に送信する。他のノードは、応答を返す。一定時間以上応答がないノードは、ダウンしたと見なされて、クラスタノードから取り除かれる。 これに加えて、HeartbeatはPacemakerが必要とする通信を仲介し、Hear
［1] オープンソースのクラスタソフトLinux-HA
「障害が発生しても止まらないシステムを実現したい」「災害に備えたリアルタイムの遠隔バックアップやシステムの二重化を行いたい」「大容量データをバックアップしたい」---震災以来、これらはシステムにとっての大きな課題となっている。 これらを実現するHA（高可用性）システムは、無償で利用できるオープンソースソフトウエア（OSS）で実現できる。そのためのOSS群が「Linux-HAクラスタスタック」である。 Linux-HAクラスタスタックは、仮想化環境やクラウド環境で使うこともできる。今回を含めて5回にわたって、Linux-HAクラスタスタックおよびこれを構成するソフトウエアの概要を紹介する。 HAクラスタの仕組み サーバーハードウエアの故障やメンテナンス、ソフトウエアの動作障害については、2台のサーバーを用意して、Linux-HAクラスタスタックのHeartbeatとPacemakerなどのク
第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ページを開く
