以前のまとめは、深いとこまでツッコミ過ぎているのと、理解できずに書いているので上手くまとまっていない。
この機会にまとめ直す。
引用部分は内容が細かくなってしまった部分なのでざっと読む場合は飛ばして良し。
クラスタリングと言った際、本質は「房」であり、複数のサーバを1台に見せることであるが、
実務的にはHAクラスタが重要なんじゃなかろうか（というかそれ以外知らない。。。）
HAクラスタリングは、厳密には負荷分散もフェールオーバーも含んでいる？気がする。
(なんとなくHAクラスタ:フェールオーバと負荷分散クラスタを分けて記述しているものもある気がする。)
HA＝高可用性、であるので、根本はサービスを止めない為に、
- なるべく壊れない様にする
- 壊れてもサービスを継続する
の２本柱になり、それぞれに対応するのが、
- 負荷分散（ロードバランサ） → LSV等
- フェールオーバー → keepalived , pacemaker
となる。
フェールオーバークラスタとは、同じ構成のサーバをAct-Stanby方式で用意し(2台とは限らない)、
Act（マスター）機が壊れた際にそれを検知してStanby（スレーブ）機にサービス提供させる仕組みを言う。
クライアント-サーバ構成を考えた時、クライアントはAct機が壊れても、それを意識せずにサービスを教授出来る。
これは仮想的なIPアドレスをAct機に割り当てていて、Act機の故障をクラスタが検知すると、
Stanby機に仮想IPを割り当てる（フェールオーバする）ことで実現できる。この時の仮想IPを 「リソース」 と呼び、リソースの割り当て及び管理がフェールオーバクラスタの基本。
リソースは仮想IPの他にも、サービスによってWebサービス(Apache,Nginx等)や、AP、DB、ディスク等が考えられる。故障の検知には、 インターコネクト という専用ネットワークを使用する。
これはサービス提供用のネットワークとは別に、サーバ間での通信に使用されるもので、
このサーバ間の通信を持ってAct機の状態を監視している。※仮想IPについては以前のまとめを参照のこと。
※仮想IPだけでは不足することがある。仮想MACアドレスを割り当てる方法もあるらしい。
（これによってTCP/IPのレイヤ以外でもクラスタが使える。以前のまとめを参照）
※単にマスターとスレーブで別れていれば良いが、あるサービスはAサーバをマスターに、
別のサービスはBサーバをスレーブに、とした場合はもっと複雑になる。
負荷分散や、ロードバランサと呼ばれるものは基本的にクライアントとサーバの間に置かれる。
主な役割はその名の通り、負荷を分散させることで、サービスを壊れにくくさせる事。
例えば、同じ構成のサーバが2台あった時、1台だけで処理を行っていると、アクセスが集中した際に壊れやすくなる。
これを解決するために、クライアントからの要求をロードバランサが受け、どちらのサーバに処理をさせるか決める。
以上が負荷分散の基本的な仕事。
上記の様に、クライアントからアクセスする際にはロードバランサが宛先になるが、
サーバからのレスポンスは、ロードバランサを介さないこともある。基本的にはロードバランサは死活監視（サーバが生きているかどうかを監視する）機能を持たない。
その為、ロードバランサとフェールオーバクラスタをセットで使うことが多い。上記のフェールオーバクラスタの説明では、サービス提供サーバをフェールオーバしているが、
ロードバランサ・フェールオーバクラスタをセットで使う場合、
ロードバランサ自体を冗長化し、マスターのロードバランサが壊れた場合に備えることが常。つまり、ロードバランサのサービス自体をリソースとして管理するということ。
ロードバランサは専用の筐体がある。
しかし高価なため、ロードバランサ機能を提供するソフトウェアをサーバに導入する場合ことも多い。
冒頭でも書いたように、
- フェールオーバクラスタ → (keepalived,) pacemaker
- 負荷分散 → Linux Virtual Server（LVS）, keepalived
がよく使用されるらしい。
-
pacemaker
pacemakerは、corosync又はheartbeatとセットで使用する。
pacemakerが リソースの監視・制御 を行うのに対し、
corosync/heartbeatは 通信層制御＝ノードの死活監視 を行うらしい。
つまり、pacemaker+corosync/pacemaker+heartbeatとして冗長化 機能 が完遂する。
現在は pacemaker+corosync が推奨されている。pacemakerについては訳わからんというのが正直なところで、
歴史的な位置づけではHeartbeatの後継（機能の一部を切り分けてpacemakerとしたらしい）。
このため、pacemakerとHeartbeat又はCorosyncを組み合わせて使用するらしい。機能 としては以上だが、 管理コマンドとして、 pcs と crm が存在する。
ここが一番意味不明な部分で、pacemakerの公式的なところでは、推奨が crm となっているのに、
RHEL/CentOS７としては推奨が pcs となっている。訳わからん。pcsを使用するなら、
yum install pcs fence-agents-allとすれば依存関係で必要な物は全て揃うらしい。
crmなら、tarファイルダウンロードからのローカルインストールかな？
crmはエクセルファイルとかをインポートして設定ファイルにするらしい。 -
LVS
予め設定した条件を元にクライアントからのリクエストをサーバに流すソフトウェア。
LVSはRedhatやCentOSではデフォルトでカーネルに 機能 が組み込まれている模様。
この機能を使用する為、設定や管理を行うコマンドが ipvsadm コマンド。
コマンドはyum等でインストール可能。 -
keepalived
役割は、 ロードバランサ機能及びHAクラスタ機能の実現
つまり、 LVSで負荷分散しているサーバの死活監視と仮想IPを用いたLVS自身の冗長化 を行う。
色々あるが、LVSとVRRPを管理するためのツールと認識すればおｋkeepalivedでも冗長化構成のフェールオーバクラスタを組むことは出来るらしい。
(ただリソースは仮想IPのみ？)
しかし、LVS＋keeepalivedとして語られる事が多く、そもそもkeepalivedはLVSをラッピングして管理しやすくしてくれるもの
という記述もある。LVS前提で開発されてるっぽいし。
実際にLVSの設定を動的に変更する機能もあるみたい。
VRRPという仕組みを実装していて、サーバ間でVRRPを行い死活監視をする。
本来はVRRPはルータ冗長化の仕組みだが、サーバ冗長化に応用可能。どちらかと言えばLVSがロードバランサの機能寄りな分、keepalivedが冗長化寄りな気がするだけかもしれないが、
そうやって理解してもあんまり問題にならないような気がする。