おいぬま日報

このエントリのようにはてブのコメントをブログ内で展開するのってどんなプラグインなのだろう、と思って調べたらHatena bookmark anywhereというものでした。というわけで早速インストールしてみてこんな感じになりました。

前回のApacheでリバースプロキシ(mod_proxy)を活用する(2) – 設定編ではフロントエンドのリバースプロキシとバックエンドのCGIサーバの設定を行ないました。今回は、サイトの負荷が大きくなってきた時にバックエンドのサーバを複数台にする設定を説明します。イメージ図としては下記のような感じです。

バックエンドの準備

まずは負荷分散が確認できるようにバックエンドのサーバを2台に増やします。前回作成した /etc/apache2/httpd_backend_8080.conf をコピーして /etc/apache2/httpd_backend_8081.conf を作成し、このhttpd_backend_8081.confがListenするポートを以下のように8080から8081にします。

--- httpd_backend_8080.conf     2009-04-07 00:32:55.000000000 +0900
+++ httpd_backend_8081.conf     2009-04-07 00:36:09.000000000 +0900
@@ -1,5 +1,5 @@
 #
-# /etc/apache2/httpd_backend_8080.conf
+# /etc/apache2/httpd_backend_8081.conf
 #
 User www-data
 Group www-data
@@ -12,15 +12,15 @@
 LoadModule mime_module /usr/lib/apache2/modules/mod_mime.so
 
 ServerRoot "/etc/apache2"
-Listen 8080
-ServerName localhost:8080
-PidFile /tmp/httpd_backend_8080.pid
+Listen 8081
+ServerName localhost:8081
+PidFile /tmp/httpd_backend_8081.pid
 ServerAdmin example_at_example.com
 DocumentRoot "/var/www/html"
 TypesConfig /etc/mime.types
 LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
-ErrorLog /tmp/error_8080.log
-CustomLog /tmp/access_8080.log combined
+ErrorLog /tmp/error_8081.log
+CustomLog /tmp/access_8081.log combined
 UseCanonicalName Off
 AddHandler cgi-script .pl

ポートを変更したら、下記のコマンドでこの8081でListenするApacheを立ち上げておきます。

$ sudo /usr/sbin/apache2ctl -f /etc/apache2/httpd_backend_8081.conf -k start

8080のサーバも停止しているようであれば起動しておきましょう。

$ sudo /usr/sbin/apache2ctl -f /etc/apache2/httpd_backend_8080.conf -k start

リバースプロキシで負荷分散の設定

バックエンドのサーバを2台に増設したら、その2台にリクエストを振り分けられるようにフロントエンドのリバースプロキシを設定し直します。やり方は色々ありますが、まずは一番シンプルな「リクエストをランダムに2台に振り分ける」というやり方を試してみたいと思います。

前回の設定では

RewriteEngine on
RewriteRule ^/(.+)\.pl$ http://localhost:8080/index.pl [L,P,QSA]
RewriteRule ^/(.+)\.(gif)$ /var/www/html/$1.$2 [L,QSA]

というように、.plファイルへのアクセスを localhost:8080 に振り分ける設定でした。今回はこの部分を変更して、localhost:8080とlocalhost:8081に振り分けるように設定します。具体的には、前回のhttpd.confに対して

RewriteMap server rnd:/usr/local/httpd_proxy_2.2.11/conf/server.txt

という設定をRewriteRuleの前に追加し、RewriteRuleを下記のように変更します。

RewriteRule ^/(.+)\.pl$ http://localhost:8080/index.pl [P,QSA]
            ↓
RewriteRule ^/(.+)\.pl$ http://${server:backend}/index.pl [L,P,QSA]

つまり前回のhttpd.confの設定との差分は下記のようになります。

--- httpd.conf.entry246 2009-04-12 17:22:07.000000000 +0900
+++ httpd.conf  2009-04-12 17:29:49.000000000 +0900
@@ -421,6 +421,7 @@
 </Directory>
 
 RewriteEngine on
-RewriteRule ^/(.+)\.pl$ http://localhost:8080/index.pl [P,QSA]
+RewriteMap server rnd:/usr/local/httpd_proxy_2.2.11/conf/server.txt
+RewriteRule ^/(.+)\.pl$ http://${server:backend}/index.pl [L,P,QSA]
 RewriteRule ^/(.+)\.(gif)$ /var/www/html/$1.$2 [L,QSA]

httpd.confを書き換えたら、RewriteMapで指定した /usr/local/httpd_proxy_2.2.11/conf/server.txt というファイルを作成します。

# echo 'backend localhost:8080|localhost:8081' >  /usr/local/httpd_proxy_2.2.11/conf/server.txt

これらの設定は何を意味するかというと

RewriteRuleで指定したパターンにマッチするリクエストがあった場合、RewriteMapで定義したサーバのどれか1台にランダムでリクエストを転送する

ということです。RewriteMapというディレクティブでは /usr/local/httpd_proxy_2.2.11/conf/server.txt というファイルを指定して、そのファイルの中身は

backend localhost:8080|localhost:8081

となっています。ここで定義したバックエンドのサーバをその後ろのRewirteRuleで ${server:backend} として参照しているわけです。前回の設定では1台にしかリクエストを転送していませんでしたが、このような設定をすることで「どれか1台にランダムで」という形で負荷分散することが可能になります。

というわけで、設定が完了したら mod_proxyサーバを再起動します。

$ sudo /usr/local/httpd_proxy_2.2.11/bin/apachectl -k restart

動作確認

サーバが起動したらブラウザから http://example/index.pl に何回かアクセスしてみましょう。(exampleの部分は自身のホスト名に適宜変更してください)

/tmp/access_8080.logと/tmp/access_8081.log の両方に下記のようなログが残っているはずです。

127.0.0.1 - - [12/Apr/2009:17:46:35 +0900] "GET /index.pl HTTP/1.1" 200 129 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; ja-JP-mac; rv:1.9.0.8) Gecko/2009032608 Firefox/3.0.8"

これが確認できれば localhost:8080 と localhost:8081 の2台のバックエンドのサーバでの負荷分散環境が構築できたということになります。(なお、例によってそのままの設定だとセキュリティに問題があるので、作業が終了したら起動したApacheのプロセスは止めておくことをお奨めします)

まとめ

mod_proxyを使った負荷分散環境の構築は、バックエンドのサーバさえしっかり準備ができていればリバースプロキシの設定はかなり簡単だったのではないでしょうか。このような複数台のバックエンドのサーバにリクエストを振り分けるような設定は負荷分散としても有効ですが、その他の使い道として「バックエンドのサーバを1台メンテナンスで一時的に止めたい」というような時にサイトを止めることなくメンテナンスが可能になります。(具体的には、server.txtからメンテナンス対象のサーバを削除するだけでリクエストが転送されなくなります)

このように、リバースプロキシの用途は単純な負荷分散以外にもあるので、設定の仕方を知っておくだけでサイトの運用に非常に役立つと思います。

タイトルの通りまたまた渋谷ビックカメラのsofmapで売ってきました。

• 204P 1GB PC3-8500: ¥1000
• MSI 761GM2-V(廉価なMicroATXのマザー): ¥700

マザーボードは購入価格が¥7000ぐらいだったと思いますが、バックパネルや説明書、箱がそろっていれば¥1000ぐらいで売れるようです。いらなくなったPCパーツを売却でも書きましたが、PCのパーツは以外と古くて型落ちしまくってても結構高値で売れるので、今までそのまま粗大ゴミ出していたような人はちゃんとバラして売るといいかもしれません。

アルカーナな日々 » 経営者とビジネスとのエントリーの

経営者は、組織を考え、人事を考え、事業の総体を考える。そして、その上に（あるいは下に）ビジネスがのっかってくる。多分、その上のような気もするが、どっちもどっちかもしれない。

という文章を読んで、はっと思う感じでした。事業を開発し育てる能力は確かに経営者に必要なスキルの一つだと思いますが、経営者は組織開発の能力にも長けている必要があると思います。組織開発というものは、自分の部下を育てたり、メンバーが気持ちよく仕事ができる環境を用意してあげたり、様々な方法で人を支援する仕事なのかなと。そういう組織の上で事業の成果が出て行くのではないでしょうか。

というようなことを最近ずっと考えていて、この不況でも業績を伸ばしている企業というのは、やっぱり組織開発がうまいのではないのかなぁと思っています。こういう成功要因について、企業が情報発信してくれるとそれを参考にすることで、日本の企業が活性化するのではないかのかなと思ったりしています。

Web上からチマチマ登録するのもあれだったので、CSVのユーザ情報を一括で users テーブルにぶち込むためのスクリプトを作りました。作った後にタイムゾーンとかの設定が users テーブルじゃなくて user_preferences にあることを知りましたが、あまり細かいことを追求する時間はなかったので、とりあえずcodereposにアップしました。ご自由にお使い下さい。

Redmine(というかRails)的にこういう類のスクリプトをどこに保存するべきかわからなかったので、codereposには platform/redmine/contrib というディレクトリをでっち上げています。「作法的にはここだろ」というものがあれば教えてもらえると嬉しいです。

Railsは ver 1.2以来さわっていなかったのですが、ActiveRecordは以外に変わっていなかったのですんなり書けました。でもPerl の手癖が抜けなくて 変数宣言に my つけたり、行末にセミコロンつけたり(これは動くけど)で大変でした。

ここ最近Nagiosを設定する機会があったのですが、なかなか設定を覚えるのに時間がかかったので備忘録的な自分へのメモ。

そもそもNagiosって？

サーバや特定のポートの死活監視を行うソフトウェア。死んでいる場合は設定した連絡先にメールを送ったりすることができます。昔はNetSaintという名前でした。

インストール

ソースからインストールする場合はNagios3.0xで監視サーバを作る – 02 Nagiosインストールの前準備を参考にすると良いでしょう。

用語

• host: 監視対象となるサーバ、ルータなど
• hostgroup: Webインターフェースでhostをグループ化して表示するためのもの
• service: hostで動いているサービス。HTTP, SMTP, FTPなどのポートでLISTENしているサービスであったり、pingの応答性やディスクの空き容量などが該当する。ようは監視する対象となるもの。
• servicegroup: Webインターフェースでserviceをグループ化して表示するためのもの
• contact: serviceに問題がある際の通知先の定義。
• contactgroup: 複数のcontactをグループ化したもの。serviceに問題がある場合、このcontactgroupで定義した連絡先に通知を送る。
• timeperiod: serviceの監視を行う時間帯や問題があった時に通知を送る時間帯の定義
• command: サービスをチェックする時のコマンドの定義

servicedependencyとかserviceescalationは必要性が良くわかってないので使ってません。

定義の継承

監視対象のホストやサービスを定義するために

define host {
    name hoge
}

のように定義を書きますが、このhostやserviceの定義に必要な項目がけっこう多いです。そのためか、Nagiosでは「定義の継承」という仕組みがあって、テンプレート的に不完全な定義を作っておいてそれを継承する、ということができます。

と書いてもわかりにくいので実際の例を書くと

define host {
    name                      myserver
    notifications_enabled     1
    event_handler_enabled     1
    flap_detection_enabled    1
    process_perf_data         1
    retain_status_information 1
    retain_nonstatus_information 1
    check_command             check-host-alive
    max_check_attempts        3
    notification_interval     20
    notification_period       24x7
    notification_options      d,u,r
    contact_groups            mycontact-group
    check_command check-host-alive
    register 0           ; これが重要
}

な感じで host の定義のテンプレートを作っておくと、実際の host の定義は以下のように簡潔なものになります。

define host {
    use myserver   ; use で使用するテンプレートを指定
    host_name localhost
    alias localhost
    address 127.0.0.1
}

Nagiosの設定項目は多岐にわたるので、このような定義の継承の仕組みは、設定の記述を簡略化する目的では非常に便利です。

設定ファイルの構造

Nagiosが例えば /usr/local/nagios にインストールされている場合、設定ファイルはetc/nagios.cfg になります。下記のように cfg_dir=hogehoge.cfg という感じで、このファイルからさらに色々なファイルをインクルードしています。

cfg_file=/usr/local/nagios/etc/objects/commands.cfg
cfg_file=/usr/local/nagios/etc/objects/contacts.cfg
cfg_file=/usr/local/nagios/etc/objects/timeperiods.cfg
cfg_file=/usr/local/nagios/etc/objects/templates.cfg

自分はデフォルトの設定ファイルを汚したくないので

• objects/mycommands.cfg: 独自のcommandを定義しているファイル
• myconfig.cfg: hostやserviceの定義のテンプレート+contactgroupの定義
• hosts/localhost.cfg: localhostのhost, serviceの設定

という風にファイルを作ってこれらを nagios.cfg からインクルードしています。

追加で定義しているコマンド

httpsとmemcached(ポート11211)を監視するコマンドを自分用に追加しています。

# 'check_https' command definition
define command {
    command_name    check_https
    command_line    $USER1$/check_http -I $HOSTADDRESS$ $ARG1$ -S
}
 
# 'check_memcached' command definition
define command {
    command_name    check_memcached
    command_line    $USER1$/check_tcp -H $HOSTADDRESS$ -p 11211 -t 5
}

まとめ

Nagiosは設定項目が複雑な分色々とカスタマイズできるので、あらゆる類のサービスの監視ができるでしょう。また、バージョンも3になって機能的にも非常に枯れたソフトウェアになっているので、割と安心して使えるものだなと感じました。

2年間使っていたau W43HをW63Hに機種変しました。W43Hに特に不満はなかったのですが、さすがに2年間変えてないのと変な強迫観念が生まれてきたので…

W63Hは最新機種の一つ前の世代ですが、普通に使う分には問題はない感じですが、幾つか特徴を書くとこんな感じ。

解像度が高い

3.1インチの液晶でかつ解像度が高いです。画面は非常に見やすいです。もちろんワンセグも綺麗に見えます。

日本語変換が優秀

W43Hと比べると、変換の予測の精度が高い気がします。

W43Hに比べると動作がもっさり

メールやezwebを開いたりキャンセルボタンを押したりした時に一瞬「うっ」っていう感じで待たされます。自分的にはギリギリストレスにはならないぐらいですが、これがKCP+の代償なんでしょう。

バッテリーの減りが早い

一日中ヘビーに使っていると、バッテリーのメモリが3から2になってしまうぐらい減りが早いです。

自分はメール＋電話＋Web見るぐらいにしか使わないので、今のところは満足です。正直iPhoneに変えようかとも思ったのですが、GoogleのAndroid携帯がauから出るはずなので、これに期待しています。