| ■ 【ぷろじぇくと ぞうさん】 〜E-Bananaサーバ 構築日記〜
|
第３３日目：〜外伝V〜 ロードバランサーを作れ！ (その１１)〜
|
どうも、('A`)です。
えーと、root兄(・∀・)と共にFreeBSD 7.0Rのサーバ構築を進めていましたが、ちょっと
落ち着いてきたので、今回は並行して開発していたロードバランサーの方を報告します。
(やっとお話できる様になりました。。。)
あと、7.0Rの構築の状況は日記の最後の方で報告します。
引き続き64ビット機(2、3号機)を作っていますが、ちょっとおかしな状況が発生しています。
(詳細はココを参照して下さい。)
第２６日目の日記でも取り上げましたが、「フロントの自動切り離し・復旧」機能を
「自分たちで作ってみよー！」と仕様を考えました。
そこで”perl使い”のroot兄(・∀・)にスクリプトを書いてもらい、こんなスクリプトを作りました。
(社内では「兄貴スクリプトv1」と呼んでます。)
では「兄貴スクリプト」がどう動くのかを(ちょっと縦長になっちゃいましたが)図解してみます。
【兄貴スクリプトの処理(流れ図)】
ここで３点補足説明をおこないます。
1) 「兄貴スクリプト」及びその環境は一般ユーザ権限で制御する。
matdが設置されているサーバ上に一般ユーザを１つ作成します。
('A`)が現在テストしているサーバには「aniki」というユーザを作っています。
そして以下の４つのファイルを設置します。
matd.cf は一般ユーザのディレクトリ下にrootユーザの所有者権限で設置する。
(1)「兄貴スクリプト」 (matd_manage.pl)
所有者権限は一般ユーザで、パーミッションは755
(2)matd.cf 本体 (matd.cf)
所有者権限はrootユーザで、パーミッションは644
(3)matd.cf 雛型 (matd.cf.master)
所有者権限は一般ユーザで、パーミッションは644
(4)サーバ一覧リスト (server.list)
所有者権限は一般ユーザで、パーミッションは644
ファイル内には以下の項目が記載されている。
[サーバ名] [URL] [MACアドレス] [重み] [タイムアウト秒]
各ファイルは一般ユーザのディレクトリの以下の場所に設置します。
(1) /home/一般ユーザ名/bin
(2)〜(4) /home/一般ユーザ名/ctrl
「matd.cf本体を一般ユーザのディレクトリにおいて大丈夫なの？」、
「matd.cfの所有者が違うけど、ファイル更新できるの？」という疑問は
後ほど回答します。
2)matdはdaemontools配下で稼働する。
daemontoolsで動かす為に以下の作業をおこなう。
(a) /var/matd を作成する。
(所有者はroot、グループはwheel、パーミッションは755)
(b) /var/matd に以下のファイル、ディレクトリを設置する。
・run ファイル
matdを動かす為のシェルスクリプト、内容は以下の通り
(所有者はroot、グループはwheel、パーミッションは755)
----------------------------------------------------------------
#!/bin/sh
exec env - /usr/local/sbin/matd -F -f /home/aniki/ctrl/matd.cf
----------------------------------------------------------------
・supervise ディレクトリ
(所有者はroot、グループはwheel、パーミッションは700)
ディレクトリだけ作って、中には何もファイルは設置しない。
(c) /var/service に以下のシンボリックリンクを作成する。
matd (リンク先は /var/matd)
3) rootユーザで動くcronとして以下のシェルスクリプトを登録する。
・matd_check.sh
(/root 下に設置、所有者はroot、グループはwheel、パーミッションは700)
----------------------------------------------------------------------
#!/bin/sh
perl /home/aniki/bin/matd_manage.pl
----------------------------------------------------------------------
・rootのcrontab.txtの内容
----------------------------------------------------------------------
#!/bin/sh
* * * * * /root/matd_check.sh > /dev/null
----------------------------------------------------------------------
今回開発したスクリプトはroot権限で起動する事によって所有者がrootのファイル
(つまり matd.cf)を編集できるようになる事がポイントです。
あと、対象サーバのリストを一般ユーザ(というか管理ユーザと言うべきかなあ)が
編集できる事によって、各フロントエンドサーバの重みとかサーバの追加・削除
などが柔軟に対応できる事も狙いました。
ただ１つ弱点としては、フロントエンドサーバがダウンした事を検知するのに
最短でも１分はかかってしまう、という事です。
(これは「兄貴スクリプト」をcronで実行している関係上の制約になります。)
そして実際にbanana260(matdを動かしているサーバ)上で「兄貴スクリプト」を
動かしてみましたが、成功しました。
3台のフロントエンドサーバのうち１台のApacheを停止した処、次のタイミングで
稼働したスクリプトで matd.cf が2台体制の内容に修正され、かつdaemontoolsから
matdが再起動された事も確認しました。
これで切り離し部分の機能はできたかな、と思います。
ただロードバランサー自体がダウンした場合には、今のままだと「皆お亡くなり」と
なってしまいます。なのでロードバランサーの二重化が必要になってきます。
いよいよロードバランサーの二重化に進みたいと思います。
二重化に際してはロードバランサーがお互いを監視する為のネットワークを作る
必要があります。まずはその準備から次回はお話しようと思います。
(本業の方も急にバタバタしてきたし、大丈夫かなあ・・・)
それでは、また
|
|
[FreeBSD 7.0R サーバの構築状況]
FreeBSD 7.0Rの64ビット(amd64)機をいま２台作っています。(2、3号機になる予定)
しかし、製作過程において1号機と違う現象が出ています。
どんな現象が発生しているかというと、、、
・全体として動きが「もっさり」している。
・topコマンドを実行してもCPU使用割合(WCPU)が1%を超える。
(通常だと最大で0.05%くらいだから、ちょっとCPU使い過ぎ・・・)
今回製作している2号機、3号機について1号機との相違点は以下の２つです。
-----------------------------------------------------------------
1) CPUの型が違う。(1号機：Core2 Duo E6300、2・3号機： E6320)
2) メモリの構成が違う。(1号機： 1GB x 4、2・3号機： 2GB x2)
---------------------------------------------------------
メモリについて言えば「差し込むスロットの位置が間違ってるんじゃないの？」という
疑いも考えましたが、PIEのメンバーにメモリスロットの状態を目視で確認してもらったら
ちゃんと正しい位置(通常メモリスロットはチャネル毎に色分けされています)に
2・3号機ともメモリが刺さっていました。
うーん。。。刺さっているメモリの規格違いとか無いかなあ？
もう一度見てもらうの、お願いしようかなあ
引き続きroot兄(・∀・)と共にサーバの状況を調べていますが、すぐには解決しないかも。
たしか6.2Rでも似たような問題が起きていた様な気がするので、その時の記録を
掘り返してみます。
(でもなあ、1号機を作る時の方法(メモリを4->2GBにして、セットアップ&カーネル再構築し、
終わったら再びメモリを2GB->4GBに戻す)を実行したのですが、なんでこんなに挙動が違う
サーバができちゃうんだろう・・・謎だ。)
[16:00 追記]
試しに2号機で弊社スクリプトを使いベンチマークを取ってみました。
同じ7.0R 64ビットのサーバである1号機と比べて、はるかに悪い結果が出ました。。。
==========================================================
7.0R amd64 (1号機) 126 wallclock secs
( 0.00 usr 0.05 sys + 0.00 cusr 0.02 csys = 0.07 CPU)
7.0R amd64 (2号機) 205 wallclock secs
( 0.02 usr 1.00 sys + 0.13 cusr 0.05 csys = 1.20 CPU)
==========================================================
1号機と2号機の性能比でいうと、2号機は1号機の1/17しか性能が出ていません。
(親プロセスのシステム(sys)で 1.00 も使っているなんて、、、)
メモリが原因なのかなあ？それともCPU？
7.0Rの32ビット機(banana3254：ex25)は2・3号機と同じハード構成なのに
安定して動いてるんだけどなあ・・・
何が悪さをしているんだろう。
[17:50 追記]
「もしかしたら2GBだとうまく動いて、4GBだと動かないのか？」
これを確かめる為に今から3号機を使って検証作業を始めます。
結果は後ほど報告します。
[18:00 追記]
3号機をメモリ2GBにして、再度弊社スクリプトを使いベンチマークを取ってみました。
なんと、1号機とほぼ同じ結果(ほんのちょっとですが早い)になりました。
==========================================================
7.0R amd64 (1号機) 126 wallclock secs
( 0.00 usr 0.05 sys + 0.00 cusr 0.02 csys = 0.07 CPU)
7.0R amd64 (2号機) 122 wallclock secs <-- メモリ2GBバージョン
( 0.01 usr 0.04 sys + 0.00 cusr 0.02 csys = 0.07 CPU)
==========================================================
うーん、、、もう一度メモリの規格が同じか確認してみるか。
あるいは既にある規格が同じメモリに全部付け替えなおしてどうなるか調べようかなあ。
でも4GBで再び性能がダウンになったら・・・何が原因なんだろう(泣
[19:00 追記]
試しに3号機のメモリを全部取り換えてみましたが、サーバが不安定になる(重くなる)
現象は再現されます。
えーと、メモリ構成を変更して 1GB x 4 だったらどうなるかテストしてみたいなあ。
それで解決したらうれしいけど、解決しなかったら・・・お先真っ暗です(涙
(あ、メモリの在庫ってあったかなあ。。。後で確認してみよう。)
|
|
|
|
|
32日目に戻る。 34日目に続く。
解析
|