AWS上で監視システムにZabbixを動かしておられる方も多いかと思います。AWSとZabbixは相性が良いので今後も増えていくと予想されます。しかしZabbix単体では冗長構成をとる機能が無い為、Zabbixが停止すると監視も止まります。「ちょっとくらい監視がとまっても業務は止まらないから良い。」と割り切れる場合はOKですが、監視が止まったら困るケースもあります。監視をサービス提供している場合は特にそうなります。じゃあ冗長化しましょうという事になりますが、商用のクラスタソフトはなかなかお高く手が出しづらい状況です。そこでオープンソースのツールを使って冗長化します。

Pacemaker（Heartbeat）で無料でZabbixを冗長化

Linuxでは古くからLinux-HAというプロジェクトがありHeartbeatというツールがあります。HeartbeatV1→V2→V3と進化してミドルウェアの制御部分を分離してPacemakerとなりました。V2（たぶんV3も）まではHeartbeatがミドルウェア部分も制御していました。
（V2までしか触ってなかったのでここらへんの知識はあいまい。）
歴史がありますので実績も十分です。（商用環境でも採用されています。）
HeartbeatとLVS（LinuxVirtualServer）を組み合わせてロードバランサーを安価に構築したりする事も可能です。
ただ、昔は実機のロードバランサーが高価だった為に結構構築されていましたが、今はAWSでELBとか出てきたのであまり見かけなくなりました。

HeartbeatV1

初期のころのHeartbeatでOS単位で冗長化出来ます。フェイルオーバー時に待機系でキックするミドルウェアを指定可能です。（メジャーなミドルウェア最初からリソースエージェントが用意されています。無い場合は作りますがシンプルなので容易に作成できると思います。）

但しフェイルオーバーのトリガーに出来るのはOSの死活のみでミドルウェアが停止してもOSが生きていたらフェイルオーバーはしてくれません。この為当時は別途シェルスクリプトなどと連携させてミドルウェアが停止したらHeartbeatの切替コマンドを実行させるなどで強引に対応しました。また、クラスタ構成は1対1の2台構成までです。

HeartbeatV2～

V2になって進化してミドルウェアもフェイルオーバー対象に出来るようになりました。クラスタ構成も1対Nが
可能になり、3台クラスター、5台クラスターという構成も可能になりました。但しcib.xmlファイルというものを作成する必要があり、更には冗長構成にするには色々と複雑な設定をしていく必要がありました。この為、この時代でもHeartbeatV1を利用しているケースが結構ありました。ただ、メジャーなミドルウェアは最初からOCF（OpenClusterFramework）というものが用意されているのでこちらを利用すると冗長化はしやすいです。（無い場合は自分で作成）

Pacemaker

V2にあったミドルウェアを制御するcrm（クラスタリソースマネージャ）分離してpacemakerになり、GUIで設定出来たり、crm configureで簡単にクラスタ構成を組めるようになったようです。何故「～ようです」と書いたかというと使ってみた感じ劇的に簡単になったか？と聞かれると微妙・・・。cib.xmlを書いた経験のある方ならcib.xmlを手書きしてしまっても構わないような感じではあります。ちなみにGUI版は触った事ないのでわかりません。

AWS上でHeartbeatで冗長化するには？

前置きが長くなりましたが、ここからAWSで冗長化を考えます。Heartbeat及びpacemakerはクラウドとか流行るより昔に生まれたので実機（オンプレミス）での冗長構成を念頭に開発されている部分があります。（シリアルケーブルで死活通信が可能など。）
どのサーバがサービス稼働中なのかの区別にサービス稼働中にVIPをつける方式がとても多いです。WEBサーバを冗長構成で組んでいるとして、エンドユーザにはVIPにアクセスさせます。Heartbeatがフェイルオーバー時に待機系にVIPを付け替える事によってエンドユーザはサーバが切り替わっても継続したサービスを受けれる仕組みです。しかしAWSではこの方式だと問題があります。

AWSはマルチキャストのパケットが通らない。

仕様上許しておらずマルチキャストパケットは破棄されます。何が困るかというとVIPを付け替える際にブロードキャストして知らせるわけですが、AWSでは破棄されるので勝手にVIP名乗っているだけで誰も（周りのサーバは）VIPを知らないので通信できません。ですので、

VIPの変わりにELBで代用します。

エンドユーザのアクセスをELBにしてELBのヘルスチェックを使って稼働系のインスタンスへ振り分ける事でこの問題が回避出来きるのでELB＋Pacemaker（HeartbeatV2）を基本設計にAWS上でのZabbixの冗長化を行います。ZabbixをAWSで冗長構成を組むのに大まかに以下のパターンがあります。

1. Pacemaker(HeartbeatV2) + RDS




●　AWS上でVPC内にAvailabilityZoneをActiveとStandbyで分けてZabbixを動かしDR対応させる。
●　AWSではマルチキャストを通さない仕様でVIP方式の冗長が利用出来ない為、ELBによるヘルスチェックを実施。
●　データベースをRDS Multi-Azを採用することにより、汎用性、運用効率を上げる。
●　Pacemakerでミドルウェア単位でグループ化してActive-Standbyの冗長を構成。
　　　グループ：Apache,Zabbix,Swatch
　　　　　　　　※Apacheは常時起動でそれ以下をグループ化してもOK

・・・なんでSwatchがいるの？と言うとやってみて分かった事ですがRDSのフェイルオーバー後はZabbixサーバが止まります。毎回DBに接続するアプリであれば問題は無いのですがZabbixのようなDBに接続しっぱなしのdaemonなどは一旦切断して再接続しないとならないようです。ここにも書いてありました。

Amazon Web Services ブログ
http://aws.typepad.com/aws_japan/2012/05/multi-az-option-for-amazon-rds-for-oracle-database.html

そこでこの問題を、

●　RDSフェイルオーバー時にZabbixの監視が停止する問題をSwatchで対処。している為クラスタグループにSwatchがいます。（他に妙案が浮かばなかった。。）

動かした状態のクラスタモニタ

Online: [ zabbixcluster-1 zabbixcluster-2 ]

 Resource Group: zabbixcluster
     apache     (lsb:httpd):    Started zabbixcluster-1
     zabbix_server      (lsb:zabbix_server):    Started zabbixcluster-1
     swatch     (lsb:swatch):   Started zabbixcluster-1

2. Pacemaker(HeartbeatV2) + DRBD




ゾーンを分けてELBでヘルスチェックまでは基本同じで、
●　データベースをMySQL、データ格納領域をDRBDで同期。
●　Pacemakerでミドルウェア単位でグループ化してActive-Standbyの冗長を構成。　
　　　クラスタグループ：Apache,Zabbix,MySQL,DRBD
　　　　　　　　　　　　※DRBDのMaster／Slave切替もPacemakerで制御。

動かした状態のクラスタモニタ

Online: [ zabbixcluster-1 zabbixcluster-2 ]

 Master/Slave Set: ms_drbd_r0
     Masters: [ zabbixcluster-1 ]
     Slaves: [ zabbixcluster-2 ]
 Resource Group: group_zabbix
     mount_r0   (ocf::heartbeat:Filesystem):    Started zabbixcluster-1
     httpd      (lsb:httpd):    Started zabbixcluster-1
     mysqld     (lsb:mysqld):   Started zabbixcluster-1
     zabbix_server      (lsb:zabbix_server):    Started zabbixcluster-1

3. Pacemaker(HeartbeatV2) + MySQLレプリケーション

ゾーンを分けてELBでヘルスチェックまでは基本同じで、
●　データベースをMySQL、データをレプリケーションでSlaveに同期。（Semi-Sync方式）
●　Pacemakerでミドルウェア単位でグループ化してActive-Standbyの冗長を構成。
　　　クラスタグループ：Apache,Zabbix,MySQL
　　　　　　　　　　　　※MySQLのMaster／Slave切替もPacemakerで制御。

動かした状態のクラスタモニタ

Online: [ zabbixcluster-1 zabbixcluster-2 ]

 Master/Slave Set: ms_mysqld
     Masters: [ zabbixcluster-1 ]
     Slaves: [ zabbixcluster-2 ]
 Resource Group: group_zabbix
     mysqld     (lsb:mysqld):   Started zabbixcluster-1
     httpd      (lsb:httpd):    Started zabbixcluster-1
     zabbix_server      (lsb:zabbix_server):    Started zabbixcluster-1

それぞれのメリット／デメリット

RDS採用のメリット／デメリット
●　メリット

1. AWSコンソールからLaunch出来るので導入がし易い。
2. バックアップ／リカバリの方法もスナップショットで行える。
3. EC2インスタンスとRDSが分離しているのでEC2インスタンスだけインスタンスタイプを変更したり、RDSだけインスタンスタイプを変更したりといった運用が可能。

●　デメリット

1. EC2インスタンスとRDSインスタンスの料金が発生する。Multi-AZにする場合は更に費用が発生。

　　　　　※結構馬鹿にならない料金になります。ここが最大のネック。

2. RDSはデータベースの管理者権限が取得出来ない為、それに伴う諸々の不便さが存在する。
3. RDSは時刻がUTCだったりと日本仕様で無い部分があり対策が必要。
4. フェイルオーバーにかかる時間がDRBDやMySQLレプリケーションより遅い。

DRBD採用のメリット／デメリット
●　メリット

1. 離れたディスク（Volume）をRAID1のように利用出来る為、データの整合性が高い。
2. カーネルモジュールで動作する為、CPUやメモリへの負担が小さい。
3. Volume間を繋ぐ回線速度が速いほどデータのディスク性能を上げる事が出来る。
4. RDS採用よりもコストを抑えられる。

●　デメリット

1. ディスク性能が回線速度に大きく依存する為、速い回線にする必要がある。AWSではインスタンスタイプで回線速度が決まっている為、CPU、メモリに余裕があってもDRBDの為だけにインスタンタイプを高スペックにする必要がある。
2. データを同時に書き込む仕様で不整合が発生しにくいはずだが、AWSでは発生しやすく、同期がはずれてStandAloneの状態になりやすい。

※特に大きいファイルが一瞬で書き終わる時に発生しやすい模様。有り得ない早さで書き終わる時があるのでAWS側のパフォーマンスを上げる為の仕組みか何かが作用しているかもしれません。ストレージゲートウェイでも似たような事象があるのでEC2インスタンスもデータを書き込む時にキャッシュしたりしてるかもしれません。

3. 不整合発生時のリカバリ時など運用面で効率はRDSに劣る。

MySQLレプリケーションのメリット／デメリット
●　メリット

1. 広く利用されてきた方式の為、情報が豊富で導入や運用がし易い。
2. DRBDよりも同期速度は速い。
3. MySQL5.5以降の機能のSemi-Syncを使うとデータの整合性が高くなる。
4. RDS採用よりもコストを抑えられる。

●　デメリット

1. DRBD程ではないが、性能は回線速度に依存する。
2. CPUやメモリへの負担はDRBDよりも高い。
3. Semi-Syncを採用してもDRBDより整合性では劣る。
4. 不整合発生時のリカバリ時など運用面で効率はRDSに劣る。

これらを踏まえて実際に構築して比べてみると性能面では、

RDS　＞　MySQLレプリ　＞　DRBD

耐障害性（フェイルオーバーの迅速さ）では、

DRBD　＞　MySQLレプリ　＞　RDS

導入の容易さや運用効率では、

RDS　＞　MySQLレプリ　＞　DRBD

と、感じましたがここらへんはもっと時間をかけて調査しないと何とも言えない部分もあります。。
DRBDはmicroだとかなり厳しいパフォーマンスでしたが、largeに上げたら一昔前のハードディスクくらいの性能出しましたし、MySQLレプリもSemi-SyncだとDRBDじゃなくても良いんじゃないか？という整合性を保ってくれます。更にはAWSのDRBDは単に構築した段階ではうまく同期とれているように見えましたが、ディスクに大きいデータを書き込むような状況下では不整合しやすかったりなど（DRBDって同時書込みのはずなのに）
まだまだテストや工夫しないとならないようです。

では、各パターンの実際の設定やちょっとしたテストに入って行きたいと思いますが、長くなりましたので次回書きます。次回はパターンの1つめの、

Pacemaker(HeartbeatV2) + RDS

の設定とテスト結果を書きます。