Linux-HA Japan

Pacemakerでは現在、Primitive, Clone, Master/Slave という大きく分けて3つの種類のリソース、および、PrimitiveをまとめたGroupというリソースを定義することができます。これらのリソースの違いについて簡単に説明します。

これらの概念は、Pacemaker-1.0系およびPacemaker-1.1系で共通です。

Primitive

まず、一番よく使われるのがこの Primitive リソースです。これは全てのリソース定義の基礎になります。

これは、通常のAct-Standby構成で用いるリソースで、どこか一カ所のノードで動くことができます。よって、クラスタ全体のある1ノードだけで動いていればよいリソースに使用し、リソースが故障すれば、他のノードにフェールオーバーさせることができます。データベースやメールサーバのようなものをHAクラスタリングする場合は通常このリソースを定義することになります。

 

Clone

Cloneリソース は、Primitive リソースを複数のノードで動作させたい場合に使用します。そのため定義方法は、まずPrimitive を定義し、それをClone化するという流れになります。

あるアプリケーションを複数のノードで動かしたい場合、Primitiveだけで実現しようとすると、動かしたいノード数分だけ定義する必要がありますが、Cloneの場合は1つのCloneリソースを定義するだけで動かすことができます。

代表的な使用例として、ネットワークの疎通監視に使用するpingd リソースエージェント(以下RA) があります。ネットワーク越しにサービスを提供するAct-Standby 構成において、ActのPrimitiveリソースが故障し、Standby ノードにフェールオーバーしても、Standby ノードのネットワークが切れていては意味がありません。こういった事態を避けるために、pingd RA を全てのノードで動作させ、サービスを提供していないノードでもネットワークを監視し、ネットワークが故障してしまった場合は、そのノードにサービスがフェールオーバーしないようにするのが通常の使い方です。

なお、RAの実装としては、Primitive, Clone に違いはないため、動作が保証されているかは別として、Primitive で定義できる RAはClone化できます。

 

Master/Slave

Master/Slave リソースは、Clone リソースをさらに発展させたもので、Cloneリソースで親子の関係があるリソースに使用します。定義方法は、まずPrimitive を定義し、それをMaster/Slave化するという流れになります。

代表的な使用例としては、データのレプリケーションに使用するDRBD用のRA があります。DRBDでは、PrimaryとSecondaryと呼ばれる状態があり、Primaryではデータの読み書き、SecondaryではPrimaryからレプリケーション用のデータを受信し、ディスクに書き込みます。そのため、DRBDは複数のノードで動いている必要があり、さらにPrimaryとSecondaryの状態を区別する必要が出てきます。これをPacemakerのMaster/Slave を使って実現しています。

また、PostgreSQL用のRA(pgsql)でストリーミングレプリケーションを制御する際にもMaster/Slaveリソースを使用します。ストリ－ミングレプリケーションでは片方のPostgreSQLをMaster(読み書き可能)、もう片方をSlave(書き込み不可)とし、Masterに書き込まれたデータをSlaveに転送し続けることで、両系のデータを常に同じになるよう保っています。PostgreSQLのストリーミングレプリケーションとPacemaker(pgsql RA)を連携・制御する構成をPG-REXと呼称しています。詳細はPG-REXコミュニティ(日本語)で。

なお、Master/Slave では、Primitive, Clone 用のRAに実装されている、start, stop というリソースの起動・停止操作に追加して、promote, demote という親に昇格、子どもに降格させる操作がRAに実装されている必要があるため、Primitive や Clone 用のRAをそのままMaster/Slave 化することはできません。

 

Group

Group リソースは、複数のPrimitiveリソースを１つのグループとしてまとめたリソースです。
同じグループとなったPrimitiveリソースは必ず同じノードで、定義された順番に起動／停止します。

Pacemaker内部の動作としては「colocation(同居)制約」と「order(順序)制約」の両制約をかけたのと同等です。
制約について詳しくは、こちらを参照ください。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Continue reading Pacemaker で扱えるリソースの種類 (Primitive, Clone, Master/Slave, Group)

みなさんおはようございます。こんにちは。こんばんは。前回からまさに半年かかってますが遅ればせながら第２回です。前回はHAクラスタを組む上で必要な知識として、HA環境について考えてみましたが、今回はこれから初めてLinux-HA環境の構築に挑戦しようとしている読者の方に向けて、具体的に最も基本的なHA環境の構築方法を紹介したいと思います。

基本的なHA環境

Linux-HAを学習する上で基本となる構成は、サービスを提供する「アクティブサーバ」と、いざという時のために予備機として待機している「スタンバイサーバ」の２台で構成される「アクティブ／スタンバイ」型のHA環境です。基本的なサーバといっても考えることはたくさんあるので、ちょっとここに列挙してみます。

ハードウェア障害を何処まで想定するか
制御するソフトウェアは何が必要か（適用範囲）
監視するソフトウェアの監視項目
データの共有はどうするか
障害発生から、サービス切り替えまでの所要時間（希望時間）
予期せぬ障害により系が切り替わらなかったときの対処

最低でも以上の事は考慮した上で、HA環境を設計しなくてはなりません。上の項目について考慮した上で基本的なHA環境を設計するとなんとなく次のような感じになります。

電源落ちたらフェイルオーバーしよう
カーネルパニックとかマシンがおかしくなったらフェイルオーバーしよう
ソフトウェアはとりあえずPIDのチェックだけにしてPIDが認識できなかったら再起動しよう
ソフトウェアの再起動が不可能な状態だったらフェイルオーバーしよう
データの共有はDRBDを使ってネットワークミラーリングでやろう
障害発生からサービス切り替え実行までの時間は、5分くらいがいいな
とりあえず今回はサービスが切り替わらない程の問題が発生したら手動で対応しなくちゃいけないな

構成図としては…

こんな感じが基本的な所でしょうか。深く追求していくと、結構きりがないので、有る程度の所で落としどころを見つけて設計しないと…

障害に対して敏感すぎる構成

や

監視することがサーバに負荷をかけて障害を起こす

という、「健康のためなら死んでも良い」的な構成になってしまいます。よくあるのが、サーバ障害発生時のダウン時間を短くしようとしすぎて、少しでも負荷がかかるとそれに反応してフェイルオーバーしてしまう環境です。くれぐれも、Linux-HA自体が「障害点」になってしまわないように考慮して設計するようにしましょう。

とりあえず設定してみよう

前置きが長くなりましたが、具体的な設定をしてみましょう。今回の環境は前回の予告にも有るとおり以下の環境で構成します。リソースはUnboundだとデータを持たないのでApacheに変更します。

OS
CentOS5.5 x86_84

クラスタソフト
Heartbeat 3.0.4 / Pacemaker 1.0.10

データ同期
DRBD8.3.10

制御対象
仮想IP / Apache

監視用インターフェース
eth1 / . . . → Read More: 第2回やってみようLinux-HA「HAの基本構成」

はじめてのLinux-HA

みなさんはじめまして。はじめましてじゃない方はこんにちわ。橘べるちぇです。このコーナーはLinux-HAという小難しいよくわからないものを誰でも簡単に試してみることができることをモットーに、私橘べるちぇが考えていることをダダ漏れにしながらみなさんと一緒にLinux-HAを学習していきたいと思います。

HAクラスタを考える

HAクラスタって何でしょうか。皆さんの目的は一様にして「この可愛いキャラクターはなんだろう」疑問を持って…基、「サービスが落ちたら困る」という問題に対していろいろなソリューションを探してLinux-HAというものにたどり着いているのではないかと思います。

ではLinux-HAを導入したらサービスは落ちなくなるのか？という所ですが、それは断じてないとここでアピールしておきます。

Linux-HAってなんだろうなぁ…とたまに考える時があるのですが、HAクラスタって簡単に言うと「落ちたときにどうしようかね」というのを対処してくれるソリューションなんだと思っています。サーバが落ちる原因はいろいろあってハードウェア故障だったりソフトウェアのバグ踏んだり、宇宙から変な粒子が飛んできてそれの影響で落ちたりいろいろなんだと思います。想定できる問題っていうのはある程度想定してしまっているから「落ちる」という原因については100％想定外な事象なんだというのも感じています。

いざサーバが落ちたとき、HAクラスタ環境を導入していないと100％次の日なり気付いたときに対処を講じるまでサービスはダウンしてしまいます。HAクラスタを導入すると、その気付いたときに行う対処を60％くらいの確立で自動でやってくれて、40％分くらいサービスの復旧が早くなる。という程度で考えています。たったの60％？と思われるかもしれないですが、100％復旧しないということと、60％くらいの確立でサービスが自動復旧するということの差は天地の差があると思います。

業務で使用する場合も趣味で使う場合も、Linux-HAを導入した上でサービスダウンに対しての対応策は考えるべきであって、

自動的にサービスが復旧してくれた「ラッキー♪」

と思っているくらいが、重大な損害を出さないサーバ運用に繋がるものなんだと思います。業務で使う場合は「落ちないようにする努力」と「落ちたときちゃんと切り替わる努力」と「切り替わらなかった時でも対応できる準備」の３つの要素をちゃんと考えるようにしましょう。

「そんなこともあろうかと！」

と言える準備はしておくにこしたことないですよね。

※ . . . → Read More: 第１回やってみようLinux-HA「プロローグ」