2006年10月05日
keepalivedの運用ノウハウお見せします 〜 割当管理を簡単にしたい
keepalivedの設定ファイルは、以下のようなエントリをひたすら並べなくてはいけないので、規模が大きくなるほど可読性が落ちます。
RealServerが10台以上もあるような大きなサイトだと、ひとつのサーバグループの設定だけでも1画面に収まり切らないほどの量になってしまうんです。こんな巨大な設定ファイルを人間が書き換えなければならないなんてとてもとても我慢できません。サイトを増やそうとしてどっかの設定をコピペしたままうっかり書き換え忘れるような事故が起きることは容易に想像がつきます。
DSASの特徴のひとつとして、「サーバの増減が容易である」というものがあります。
その実体が 「keepalived.confの編集」だと「どこが容易やねん！」という突っ込みが入ることは目に見えていますよね（笑
DSASでは、設定ファイルの編集ミスによる事故を防止するためと、管理者の負担を軽くするために、様々な工夫をしています。
virtual_server_group SITE1 {
a.b.c.d 80
}
virtual_server group SITE1 {
delay_loop 3
lb_algo wlc
lb_kind DR
nat_mask 255.255.252.0
protocol TCP
persistence_timeout 0
real_server 192.168.8.1 80 {
weight 1
inhibit_on_failure
HTTP_GET {
url {
path /s/health.jsp
status_code 200
}
connect_port 80
connect_timeout 5
nb_get_retry 1
delay_before_retry 2
}
real_server 192.168.8.2 80 {
weight 1
inhibit_on_failure
HTTP_GET {
url {
path /s/health.jsp
status_code 200
}
connect_port 80
connect_timeout 5
nb_get_retry 1
delay_before_retry 2
}
}
RealServerが10台以上もあるような大きなサイトだと、ひとつのサーバグループの設定だけでも1画面に収まり切らないほどの量になってしまうんです。こんな巨大な設定ファイルを人間が書き換えなければならないなんてとてもとても我慢できません。サイトを増やそうとしてどっかの設定をコピペしたままうっかり書き換え忘れるような事故が起きることは容易に想像がつきます。
DSASの特徴のひとつとして、「サーバの増減が容易である」というものがあります。
その実体が 「keepalived.confの編集」だと「どこが容易やねん！」という突っ込みが入ることは目に見えていますよね（笑
DSASでは、設定ファイルの編集ミスによる事故を防止するためと、管理者の負担を軽くするために、様々な工夫をしています。
まず最初に考えた事は、「人にやさしい記述方法ってどんなんだ？」ということです。
この際、keepalived.conf の書式は一切考慮せず、サーバ割当をどのような記述で扱うのが理想なのかを考えます。いろいろ考えた結果、DSAS では以下のような形式にするのが楽かも、という結論になりました。
左端の w10[1-5] というのがサーバ名です。
各サイトには SITE[1-3] とういう名前（案件名）を付けておきます。
これをもう少しわかりやすく表現すると、
こんな意味合いになります。
この設定ファイル（以後、MATRIXと呼びます）を編集し、あるコマンドを実行するだけでkeepalivedの設定に反映されるような仕組みを作れば、運用がとても楽になると思いませんか？
keepalived.confに限らずとも、人がメンテするのが面倒な設定ファイルに関しては、なんらかの形で自動生成すべきだと思います。簡単な手法としては、設定を細かく分けて cat でつなげるとか、プリプロセッサに渡して変数を展開させる等もあります。大抵はそれでいけますし、DSAS内の別のシステムでもやってますが、keepalivedに関しては設定の容易さに加え「現状把握が容易であること」も求められる事があります。ipvsadm -L で確認はできますが、それだとLVSマシンのrootしか使えないので、案件担当者が自分のサイトの実サーバを確認するのが困難だという背景もあったりするわけです。
つまり、
・サーバの割当状況は誰でも（非技術者でも）簡単に確認できなければいけない
・サーバの割当変更が容易でなければならない
・サイトの追加が容易でなければならない
これらのニーズを満たすため、MATRIXという名の割当管理設定ファイルを定義し、これを元にしてkeepalived.confを生成する仕組みにしてみました。どうせ自動生成するのなら、なるべく人に優しい仕組みを目指すのも面白いものです。
問題は「keepalived は MATRIX を見ているわけではない」というところでしょうか。
まあ、当たり前なんですが、スクリプトに不具合があって keepalived.conf の生成をミスったら少々やっかいです。なにせ、あの巨大なファイルを眺めながら原因を見つけないといけないですから・・・
たしかに運用は楽なんですが、開発者は少々頭を悩ませていたりもします。
Includeがあればねぇ、、、、ってまだ言ってるし（笑
まあ、無ければ無いなりにどうにでもしますが、Includeがあれば各サイトの定義を個別に出力しておいて、keepalived.conf の本体には 各エントリの Include を並べるだけで良くなるので、全体の見通しが良くなりデバッグも楽になるんですよねえ・・・・・
この際、keepalived.conf の書式は一切考慮せず、サーバ割当をどのような記述で扱うのが理想なのかを考えます。いろいろ考えた結果、DSAS では以下のような形式にするのが楽かも、という結論になりました。
w101: SITE1
w102: SITE1
w103: SITE2
w104: SITE2 SITE3
w105: SITE2 SITE3
左端の w10[1-5] というのがサーバ名です。
各サイトには SITE[1-3] とういう名前（案件名）を付けておきます。
これをもう少しわかりやすく表現すると、
SITE1(例えばどっかの着メロサイトとか) は w101,w102 に負荷分散する
SITE2(例えばどっかの着うたサイトとか) は w103,w104,w105 に負荷分散する
SITE3(例えばなんかのキャンペーンサイトとか) は w104,w105 に負荷分散する
こんな意味合いになります。
この設定ファイル（以後、MATRIXと呼びます）を編集し、あるコマンドを実行するだけでkeepalivedの設定に反映されるような仕組みを作れば、運用がとても楽になると思いませんか？
keepalived.confに限らずとも、人がメンテするのが面倒な設定ファイルに関しては、なんらかの形で自動生成すべきだと思います。簡単な手法としては、設定を細かく分けて cat でつなげるとか、プリプロセッサに渡して変数を展開させる等もあります。大抵はそれでいけますし、DSAS内の別のシステムでもやってますが、keepalivedに関しては設定の容易さに加え「現状把握が容易であること」も求められる事があります。ipvsadm -L で確認はできますが、それだとLVSマシンのrootしか使えないので、案件担当者が自分のサイトの実サーバを確認するのが困難だという背景もあったりするわけです。
つまり、
・サーバの割当状況は誰でも（非技術者でも）簡単に確認できなければいけない
・サーバの割当変更が容易でなければならない
・サイトの追加が容易でなければならない
これらのニーズを満たすため、MATRIXという名の割当管理設定ファイルを定義し、これを元にしてkeepalived.confを生成する仕組みにしてみました。どうせ自動生成するのなら、なるべく人に優しい仕組みを目指すのも面白いものです。
問題は「keepalived は MATRIX を見ているわけではない」というところでしょうか。
まあ、当たり前なんですが、スクリプトに不具合があって keepalived.conf の生成をミスったら少々やっかいです。なにせ、あの巨大なファイルを眺めながら原因を見つけないといけないですから・・・
たしかに運用は楽なんですが、開発者は少々頭を悩ませていたりもします。
Includeがあればねぇ、、、、ってまだ言ってるし（笑
まあ、無ければ無いなりにどうにでもしますが、Includeがあれば各サイトの定義を個別に出力しておいて、keepalived.conf の本体には 各エントリの Include を並べるだけで良くなるので、全体の見通しが良くなりデバッグも楽になるんですよねえ・・・・・
