Browse Month: August 2008

Bacula を試してみた

trombik さんのエントリーをみて、たしかに ssh + tar のバックアップは 20 世紀までだと思ったので、おすすめさせれていた Bacula を試してみた。ONLamp.com の記事もおすすめそうなので、概要を把握したら英文を読む訓練に読んでみるといいと思います。

今回は、僕が管理しているサーバで今は ssh+ tar などで MySQL や SVN リポジトリなど重要なデータをバックアップしているが、これを Bacula で置き換えるように検討してみた。

OS は、CentOS 5.1 x86_64。

まずは、インストールは、Bacula 公式サイトで SRPM が提供されているので、これを使うことにする。いくつか rpm があるが、今回の OS にある RPM がないので、ビルドしてみる。

bacula-2.4.2-2.src.rpm をダウンロードして、まずは RPM を作ってみる。


$ rpm -i bacula-2.4.2-2.src.rpm
$ rpmbuild -ba ~/rpm/SPECS/bacula.spec

ここで、次のエラーがでた。


error:  You must specify a platform. Please examine the spec file.
error: line 164: Unknown tag: exit 1

spec ファイルをみると、それぞれの OS ごとに define が定義されていて、どれも定義されていないときにエラーみたなので、CentOS で定義したが、条件のところもおかしかったのでなおした。

ビルドするために、必要なパッケージをインストールした。


$ sudo yum install pango-devel atk-devel gtk2-devel libgnomeui-devel ORBit2-devel libbonobo-devel libbonoboui-devel bonobo-activation-devel GConf2-devel linc-devel

再度ビルドすると、linc-devel がまだ必要と言われて調べてみると、たしかに CentOS ではパッケージが見つからない。どうやら、linc は、CentOS4 でパッケージから削除されてしまったらしい。めんどくさい。

SPEC ファイルをよくてみると、同じ条件がおかしいことが分かったので再修正した。

bacula.spec の diff は、次のとおり。本家にフィードバックする予定。

ビルドしてできた RPM は、次のとおり。


~/rpm/RPMS/x86_64/bacula-client-2.4.2-2.x86_64.rpm
~/rpm/RPMS/x86_64/bacula-debuginfo-2.4.2-2.x86_64.rpm
~/rpm/RPMS/x86_64/bacula-mtx-2.4.2-2.x86_64.rpm
~/rpm/RPMS/x86_64/bacula-mysql-2.4.2-2.x86_64.rpm
~/rpm/RPMS/x86_64/bacula-updatedb-2.4.2-2.x86_64.rpm

それぞれの rpm を qilp オプションでインストールされるファイルの一覧を調べてみた。

bacula-client: バックアップ対象のサーバにインストールする、クライアントデーモンのみインストールされる
bacula-debuginfo: ビルドしたときのデバッグ情報を含むソースコード
bacula-mtx: mtx テープデバイス用のユーティリティ
bacula-mysql: bacula のカタログデータベースに MySQL を使うためのパッケージ、サーバとクライアントのすべて含まれている、このパッケージをインストールするには bacula-mtx が必要
bacula-updatedb: bacula の過去のカタログデータベース用のアップデートユーティリティ

デフォルトだと、–with-openssl オプションが指定されて、TLS 通信を行うようになっている。

さっそく、インストールと設定をしてみる。

$ sudo rpm -ivh ~/rpm/RPMS/x86_64/bacula-mysql-2.4.2-2.x86_64.rpm ~/rpm/RPMS/x86_64/bacula-mtx-2.4.2-2.x86_64.rpm

あと、デフォルトだとインストール後に bacula の MySQL データベースを作成するようになっていたので、コメントにしておいた。なぜなら、今回はデータベースサーバと bacula のサーバは、別のサーバでやりたいから。bacula の MySQL データベースは、次のプログラムを順番に実行するだけでいい。ただし、次のプログラムは、ローカルホストを前提としていたり、MySQL 接続ユーザのパスワードが空だったり、無制限に接続を許可していたりと、そのまま使うにはセキュリティリスクが大きすぎると思ったので、1 と 2 は使わずに手動で行い、3 は変更して使った。


1. /usr/lib64/bacula/grant_mysql_privileges
2. /usr/lib64/bacula/create_mysql_database
3. /usr/lib64/bacula/make_mysql_tables

なので、僕は手動で bacula のデータベース設定をした。MySQL に接続してから、次のコマンドを実行して、データベースと接続ユーザの作成、権限の設定をした。

mysql>  grant all on bacula.* to bacula@’接続を許可するサーバ’ identified by ‘パスワード’;

mysql> create database bacula;

あとは、bacula のテーブルを作成する、これは make_mysql_tables を変更して実行した。

さっそく設定をしてみる。bacula-mysql パッケージをインストールすると、次の3種類の init.d スクリプトがインストールされる。

  • bacula-dir: bacula ディレクターデーモン、bacula のサーバで起動させるデーモン、カタログデータベースにアクセスしてファイルデーモンに命令を送る
  • bacula-fd: bacula ファイルデーモン、バックアップ対象のサーバで起動させるデーモン、ストレージデーモンに命令を送ってバックアップする
  • bacula-sd: bacula ストレージデーモン、バックアップするストレージがあるサーバで起動させるデーモン

それで、まずはどんなバックアップをしたいかというと、毎晩、とあるサーバの普通のファイルが入っているとあるディレクトリをフルバックアップと MySQL のデータ(マスターとスレーブ、それぞれ)を物理的に違うサーバにバックアップをしたい。

まずは、bacula-dir の設定から、設定ファイルは /etc/bacula/bacula.conf で行う。設定ファイルのリファレンスは、本家のドキュメントを参考しながら設定してみる。設定パラメータ名がなかなか分かりやすく、ドキュメントもしっかりとしていていい。日本語版があるとうれしいかもしれない。

まず、Directory リソースタイプの設定。これは基本的にデフォルトのままでよいが、Name だけ別の名前に切り替えた。


Director {
Name = hoge-dir
# where we listen for UA connections
DIRport = 9101
QueryFile = "/usr/lib64/bacula/query.sql"
WorkingDirectory = "/var/lib/bacula"
PidDirectory = "/var/run"
Maximum Concurrent Jobs = 1
# Console password
Password = "ランダムなパスワード、このパスワードは bconsole 用に使われる"
Messages = Daemon
}

次に JobDefs リソースタイプの設定。これは、Job リソースタイプで省略されたときのデフォルト設定をするための任意の設定。Job リソースタイプは、複数設定することが多いので、JobDefs リソースタイプは設定した方が便利。
変更したのは、Client は各 Job で定義した方がよさそうなので削除、Message も各 Job でユニークな設定にしたいので削除した。バックアップするファイルを設定する FileSet リソースタイプと Write Bootstrap というジョブを実行しているときに作られるファイルは汎用的に設定した。Storage は、実際にバックアップしたファイルを置くストレージを定義する。


JobDefs {
Name = "DefaultJob"
Type = Backup
Level = Incremental
FileSet="Full Set"
Messages = Daemon
Schedule = "DailyCycle"
Storage = hoge-sd
Pool = Default
Priority = 10
Write Bootstrap = "/var/lib/bacula/%c_%n.bsr"
}

次に Job リソースタイプ。スケジューラから実行させたいので、Enabled = Yes を定義して、hoge-fd というクライアントをバックアップ対象に設定した。


Job {
Name = "BackupTest"
JobDefs = "DefaultJob"
Enabled = Yes
Client = hoge-fd
}

次のクライアントでバックアップするファイルの対象を設定する FileSet リソースタイプ。/home/hoge というディレクトリをバックアップするという設定をした。FileSet では、バックアップからはずしたいファイルやディレクトリも設定できるので、とても便利。


FileSet {
Name = "Full Set"
Include {
Options {
signature = MD5
}

File = /home/hoge
}

次にスケジュール。毎晩バックアップしたので、DailyCycle というスケジュールを設定した。


Schedule {
Name = "DailyCycle"
Run = Full at daily 3:33
}

次にバックアップ対象のクライアントを設定する。Address に実際に接続するバックアップ対象のクライアントを設定する。


Client {
Name = hoge-fd
Address = hoge
FDPort = 9102
Catalog = MyCatalog
# password for FileDaemon
Password = "ファイルデーモンにアクセスするためのパスワード"
File Retention = 30 days # 30 days
Job Retention = 6 months # six months
AutoPrune = yes # Prune expired Jobs/Files
}

次のバックアップするストレージを設定する。


Storage {
Name = hoge-sd
# N.B. Use a fully qualified name here
# Do not use "localhost" here
Address = hoge
SDPort = 9103
Password = "ストレージデーモンにアクセスするためのパスワード"
Device = FileStorage
Media Type = File
}

次のカタログデータベースの設定。今回は、別のデータベースサーバに設定した。


Catalog {
Name = MyCatalog
dbname = "bacula"
dbuser = "bacula"
dbpassword = "パスワード"
DB Address = データベースサーバのホスト名
}

あとは、デフォルトの設定ファイルのまま。設定したら、起動してみる。


$ sudo /etc/init.d/bacula_dir start

もし失敗すると、設定ファイルのどこがおかしいか親切に表示してくれるので、メッセージをみながら設定ファイルを直すことができる。

ディレクターデーモンが起動したら、次はファイルデーモンの設定をする。設定ファイルは、/etc/bacula/bacula-fd.conf。

まず、ディレクターの設定。Name は、bacula-dir.conf の Director リソースタイプの Name と同じものを設定して、Password は、bacula-dir.conf の Client リソースタイプで設定した Password とまったく同じものを設定すること。


Director {
Name = hoge-dir
Password = "ファイルデーモンにアクセスするためのパスワード"
}

次にファイルデーモンの設定。Name を変更した。


FileDaemon { # this is me
Name = hoge-fd
FDport = 9102 # where we listen for the director
WorkingDirectory = /var/lib/bacula
Pid Directory = /var/run
Maximum Concurrent Jobs = 20
}

あとは Messages リソースタイプは、デフォルトのままで問題なし。設定したら、ファイルデーモンも起動してみる。


$ sudo /etc/init.d/bacula-fd start

最後にストレージデーモンの設定。設定ファイルは、/etc/bacula/bacula-sd.conf。

まず、ストレージの設定。Name は、必ず bacula-dir.conf の Storage リソースタイプと同じ Name を設定する。


Storage { # definition of myself
Name = hoge-sd
SDPort = 9103 # Director's port
WorkingDirectory = "/var/lib/bacula"
Pid Directory = "/var/run"
Maximum Concurrent Jobs = 20
}

次に、ディレクターの設定。Name は、bacula-dir.conf の Director リソースタイプと同じ Name を設定、Password は bacula-dir.conf の Storage リソースタイプと同じ Password を設定する。このあたりは、少々混乱しやすいので注意する。


Director {
Name = hoge-dir
Password = "ストレージデーモンにアクセスするためのパスワード"
}

次にストレージの設定。今回は、ディレクトリを普通に使うので次のように設定した。/var/backup/hoge にファイルとしてバックアップする。事前にこのディレクトリは bacula ユーザが書き込めるようにしておく必要がある。


Device {
Name = FileStorage
Media Type = File
Archive Device = /var/backup/hoge
LabelMedia = yes; # lets Bacula label unlabeled media
Random Access = yes;
AutomaticMount = yes; # when device opened, read it
RemovableMedia = no;
AlwaysOpen = no;
}

最後に Message リソースタイプも必要だが、これはデフォルトのままで問題ない。さっそう、ストレージデーモンも起動してみる。


$ sudo /etc/init.d/bacula-sd start

さあ、これで準備が整った。あとは、動作テストをする。動作テストをするには、bacula に付属している bconsole というプログラムを使うと便利。bconsole を使う前に、設定ファイル /etc/bacula/bconsole.conf を変更する必要がある。

設定は、Directory リソースタイプだけだが、Name に bacula-dir.conf の Director リソースタイプの Name と同じ設定、Address はディレクターデーモンが起動しているホスト名、Password には bacula-dir.conf の Director リソースタイプの Password と同じパスワードを設定する。


Director {
Name = hoge-dir
DIRport = 9101
address = hoge
Password = "ランダムなパスワード、このパスワードは bconsole 用に使われる"
}

設定したら、さっそく bconsole を起動してみる。bsonsole は root でしか実行できない。


Connecting to Director hoge:9101
1000 OK: hoge-dir Version: 2.4.2 (26 July 2008)
Enter a period to cancel a command.
*

上の表示されば、ディレクターデーモンに接続できたことになる。さらにストレージ、ファイルデーモンに接続できるか確認するには、status コマンドを使う。


Connecting to Director hoge:9101
1000 OK: hoge-dir Version: 2.4.2 (26 July 2008)
Enter a period to cancel a command.
*status all
hoge-dir Version: 2.4.2 (26 July 2008) x86_64-redhat-linux-gnu redhat
Daemon started 29-Aug-08 23:51, 0 Jobs run since started.
Heap: heap=135,168 smbytes=30,882 max_bytes=30,882 bufs=148 max_bufs=148

Scheduled Jobs:
Level Type Pri Scheduled Name Volume
===================================================================================
Full Backup 10 30-Aug-08 03:33 BackupTest test1
====
...

こんな感じで、それぞれのステータスが表示できれば問題なし。もちろん、個別のステータスも確認できる。ディレクターデーモンは status dir、ファイルデーモンは status file、ストレージデーモンは status storage コマンドを使う。help コマンドを実行すると、利用可能なコマンド一覧が表示される。

次に実際のバックアップジョブが正しく動作するかどうか調べる。バックアップジョブを動作させるには、run コマンドを使えばいいが、事前に label コマンドでバックアップボリュームの設定が必要になる。


1000 OK: backup-dir Version: 2.4.2 (26 July 2008)
Enter a period to cancel a command.
*label
Automatically selected Catalog: MyCatalog
Using Catalog "MyCatalog"
Automatically selected Storage: hoge-sd
Enter new Volume name: test
Defined Pools:
1: Default
2: Scratch
Select the Pool (1-2): 1
Connecting to Storage daemon hoge-sd at hoge:9103 ...
Sending label command for Volume "test" Slot 0 ...
3000 OK label. VolBytes=200 DVD=0 Volume="test" Device="FileStorage" (/var/backup/hoge)
Catalog record for Volume "test", Slot 0 successfully created.
Requesting to mount FileStorage ...
3906 File device "FileStorage" (/home/hoge) is always mounted.

*run
A job name must be specified.
Automatically selected Job: BackupTest
Run Backup job
JobName: BackupTest
Level: Incremental
Client: hoge-fd
FileSet: Full Set
Pool: Default (From Job resource)
Storage: hoge-sd (From Job resource)
When: 2008-08-29 23:59:22
Priority: 10
OK to run? (yes/mod/no): yes

Job queued. JobId=1

こんな感じでバックアップジョブを実行することができる。実行結果を知るには、status dir コマンドを実行すればいい。あとは、バックアップ先のディレクトリをみてみると、なんかバイナリのデータでバックアップがとれている。restore もできるようだが、バイナリではなくてファイルそのものをバックアップしたい。

おそらく、FileSet か Pool リソースタイプあたりに設定があるはずなので、引き続き調べて結果をブログにアップしたいと思います。

bacula をテキストで設定するのはめんどうだという人は、QT で書かれた bat という GUI プログラムがあるので、bat を使うといいと思います。

bacula、とてもよくできていてシステムのバックアップツールとしては自分の中でデファクトスタンダードになりそうです。

Inside Echo をみて

Microblog Con #1 で、Inside Echo の動画をみた。

すでに、mixi ブログなどで既出の情報があったが、その中でユーザに遅延を感じさせて二重書き込みを防ぐために memcached に自分自身の発言を1件だけのせてデータベースからの結果と merge して表示しているという説明があったが、なるほどと感心した。

サービスを使ってもらっているユーザに遅延を感じさせない工夫はとても大事だし、memcached を使うと手軽にできるものなので、これをやらない手はないと思った。

 

tiarra を導入してみた

最近、社内で IRC がはやっていることもあって、IRC をよく使っている。

twitter や wassr の情報も IRC で集められる net-irc という id:cho45 さんの tig.rbwig.rb があることを知った。これを使えば、すべて IRC にまとめらると思って、さっそく導入してみた。

環境は、FreeBSD 7.0-RELEASE。

 

0. ruby-gems や ruby gem の json がインストールされていない場合は、インストールする

  $ sudo portinstall devel/ruby-gems

  $ sudo gem install json

1. coderepos から net-irc/trunk を checkout する

   $ svn co http://svn.coderepos.org/share/lang/ruby/net-irc/trunk net-irc

2. net-irc は gem でもインストールできるが、更新頻度が高いのでその場所で実行する方法を選んだ、まずは twitter の tig.rb、使い方は –help オプションをつけると分かる

  $ cd net-irc

  $ ruby ./examples/tig.rb –help

3. 自分のサーバで常駐させたいため、他のコンピュータからも接続する可能性があるので、–host オプションをサーバのホスト名を指定する、–host オプションをつけないと他のコンピュータからは接続できなかった

  $ ruby ./examples/tig.rb –host hogehoge

4. あとは、IRC クライアント(僕は LimeChat for OSX を愛用しています)で、サーバ名に hogehoge、ポート番号に 16668 を指定、TwitterIrcGateway を参照しながらニックネームやパスワードを設定して、IRC クライアントで自分が follow しているユーザのタイムラインが流れていること、ステータスをアップデートできることは確認する

5. wassr 版の wig.rb も同じ要領で設定する

 

ここで、tig.rb と wig.rb は、とても便利なんだけれど、tig.rb と wig.rb の接続するポートが違うので IRC クライアントからそれぞれのサーバを追加するのがめんどう。どうせなら、一つずつチャンネルにしてほしい。これを実現するのが、IRC Proxy ソフトウェアの tiarra。tiarra の公式ホームページは、こちら

さっそく、tiarra も導入してみる。

1. coderepos から tiarra を checkout する

  $ svn co http://svn.coderepos.org/share/lang/perl/tiarra/trunk/ tiarra

2. tiarra のサンプル設定ファイル sample.conf を tiarra.conf としてコピーする

  $ cp sample.conf tiarra.conf

3. tiarra.conf で、tig.rb と wig.rb を使えるように設定する、具体的な設定方法は tig.rb、wig.rb のコメントに書いてある

僕は、次のような感じで設定した。general の encoding の設定はしておかないと、tig.rb とかで文字化けするので注意。ホスト名には、–host オプションで指定したホスト名を設定する。


general {
nick: 共通のニックネーム
user: 共通のユーザ名
name: 共通の名前
tiarra-password: tiarra に接続するときのパスワード
client-allowed: *
tiarra-port: 16667
notice-error-messages: 1
conf-encoding: utf8
server-in-encoding: utf8
server-out-encoding: utf8
client-in-encoding: utf8
client-out-encoding: utf8
}

networks {
multi-server-mode: 1
name: twitter
name: wassr
}

twitter {
host: ホスト名
port: 16668
name: athack tid ratio=32:1 replies=6
password:
in-encoding: utf8
out-encoding: utf8
}

 

wassr {
host: ホスト名
port: 16670
name: athack tid=10 ratio=10:3:5
password:
in-encoding: utf8
out-encoding: utf8
}

 

4. あとは、tiarra を起動して、IRC クライアントソフトで接続して、#twitter@twitter チャンネルと #wassr@wassr チャンネルに接続できることを確認する

  $ tiarra/tiarra –config=設定ファイル名

 

これでかなりに便利になった。しかし、tiarra を起動する前に tig.rb と wig.rb を起動しておかないといけない。サーバを再起動したときなんかに毎回手動で起動するのはかなり面倒なので、freebsd の rc スクリプトを書いて一発でまとめて起動するようにして、 coderepos に tiarra_with_net-irc としてコミットした。

freebsd の rc スクリプトは、初めてまともに書いたが、とても簡単に書けて、なかなか楽しかった。

tiarra_with_net_irc の使い方は、次のとおり。

1. tiarra_with_net_irc を checkout する

  $ svn co http://svn.coderepos.org/share/config

2. tiarra_with_net-irc を /usr/local/etc/rc.d へコピーする

3. tiarra_with_net-irc スクリプトの最初にある3つの変数を設定する

  USER=<tiarra を実行するユーザ、通常ユーザで充分です>

  ROOTDIR=<CodeRepos を checkout してあるルーとディレクトリ、このディレクトリに net-irc と tiarra が checkout されていることを前提としています>

  CONFIG=<tiarra の設定ファイルの場所>

4. 起動できるように /etc/rc.conf に、次の設定を追加する

  tiarra_enable=”YES”

5. オプションとして、tig.rb、wig.rb、の制御も可能になっているので、必要なら /etc/rc.conf へ設定す、デフォルトは全部起動するようになっている

6. あとは、起動するだけ

  $ sudo /usr/local/etc/rc.d/tiarra_with_net-irc start

sudo する理由は、tig.rb や tiarra をデーモンとして起動させるために、FreeBSD の daemon コマンドを使って実行ユーザを指定しているため。

 

さらに、今日はてなハイクAPIが公開されたわけですが、この API を作った id:cho45 さんが hig.rb をもう作ってくれました!すげぇー、スピードで驚いた。というか、API を作っていたとは…。

そこで、さっそく hig.rb も導入してみた。はてなハイクの場合投稿専用のメールアドレスを登録しないと使えないので注意。

tiarra.conf には、次のように設定する。
haiku {
host: ホスト名
port: 16679
name: はてなID athack tid=10 ratio=10:3:5
password: はてなハイク専用のパスワード
in-encoding: utf8
out-encoding: utf8
}

これで、はてなハイクも IRC クライアントから追えるようになった。

net-irc 作者の id:cho45 さんと、tiarra 作者の Topia さんに感謝。

 

tirra の freebsd ports はとても古いので、tiarra と net-irc をまとめた FreeBSD ports を作ると ports の勉強になっていいかもしれないが、マニアックすぎて誰も使ってくれないかも。

 

なぜシリコンバレーではゴミを分別しないのか

瀧口さんのシリコンバレー通信をまとめた本「なぜシリコンバレーではゴミを分別しないのか」を読んだ。

この本を読んで、最近のシリコンバレーの事情も変わってきているんだなと思った。まず驚いたのは、グリーンバレーとも呼ばれていること。そして、アメリカの政治に大きな影響を与えているということ。
たくさんの短編集の集まりなので、シリコンバレーに興味のある人は読んでおくべき本だと思います。

あと、ステーブジョブズがどうしていつも同じ服を着ているかという考察も興味深かったです。どうしては知りたい人は、この本を読むと分かるはずです。
たしかにこのエピソードを聞くと、自分もそのように意識をすることを増やそうと思いました。

 

rubygems のミラーサイトを作る方法

ふと、rubygems のミラーサイトを作る方法を調べてみた。rubygems のミラーサイトサイトを作るには、gem mirror というコマンドを使う。

gem mirror コマンドの使い方は、gem help mirror とすると、すぐに分かる。

まず、$HOME/.gemmirrorrc ファイルを作成して、次のように記述する。


---
- from: http://gems.rubyforge.org
to: /gemを保存するパス

.gemmirrorrc の最初は、ハイフン三つです。半角でないと、エラーが出るので注意。

あとは、gem mirror を実行するだけで、.gemmirrorrc で設定した場所に gem ファイルをダウンロードしてくれる。

今日現在、15,030 個の gem があるので、現在 fetching 中…。

次は、gem でミラーサイトを設定する方法を紹介する。

どうして、http://www.rubygems.org/read/chapter/10に説明がないのだろうか。と思ったら rubygems 0.8 系のドキュメントらしい。更新してほしい!

サーバ/インフラ Tech Meeting にいってきた

昨日、行われたサーバ/インフラ Tech Meeting にいってきた。

すでに動画がアップロードされているので、昨晩 ustream を見逃した人はチェックするといいと思います。

サーバ/インフラ Tech Meeting メモ

この本を書いたわけ by ひろせさん

  • Howto 本ではない
  • 自分が読みたい本だから書いた
  • 当日の悩みがあった、実現方法の見当がつかない
  • 何か情報を出すことで、何か反応がある
  • 情報交換
  • お互いの成長、向上や切磋琢磨
  • インフラに興味深ある人とつながる
  • アウトプットを出す
  • mod_cidr_lookup(Apache モジュール)を近々公開する予定(モバイルゲートウェイやボットの判定に便利そう)、次は lighttpd のモジュールか!?

 

Linuxカーネルの読み方 by 伊藤さん

  • そもそも負荷とは何か疑問だった(たしかにそのとおり、httpd を graceful して負荷が下がりましたとはなしです)
  • 根拠がなくて負荷を低減させることはできない
  • バイナリアンになりたくて、Linux のカーネルを読み始めた
  • 詳解 LINUX カーネルに、知りたいことが書かれていた
  • プロセス、スレッド、仮想メモリ、とは何かが分かった
  • Linux は、500M ステップくらい、grep したら以外に読めることは分かった
  • Emacs, Global, App:Ack を使ってソースコードを読んでいる
  • Etags は性能はよくないらしい(Emacs に Etag を設定していたけれど、Global を試し見てるか)
  • App::Ack は、性能のいい grep でおすすめ
  • 紙とペンで処理の流れをメモしながら進める(これでどんな割り込みも大丈夫!)
  • Linux Kernel Hack Japan というサイトにお世話にになっている
  • ソースコードを読む5つのコツ
  • 読む対象を絞る
  • 何を知りたいのか明確にする
  • いきなり読まない
  • ソースツリーの構造を把握する
  • 概観を知った上で読む
  • テストプログラムを活用
  • プログラムを strace する
  • カーネルモジュール開発が面白い
  • 役に立つどうかは知ってみないと分からない

DSASのこれから by 安井さん

  • DSAS の日常について
  • DSASは、「ダイナミック・サーバ・アサイン・システム」の略称
  • サーバの規模は、東京二カ所、福岡に一ヶ所で300台くらいのサーバがある
  • サーバ毎のサーバ台数を動的に変更できるという特徴がある
  • すべてのハードディスクを同じに保つ
  • ファイルの更新は、マルチキャストで一括転送している
  • 専用のツールを作っている、OSS で公開する予定
  • DSAS チームは、何をやるかは自由で人によってテーマや内容は様々です
  • 運用は楽しく
  • 夢を見るのは素敵なことです
  • 実現する方法を模索(妄想)するのは楽しいです
  • 日々の運用経験から、新しい仕組みが生まれる
  • インフラって楽しい!
  • はてなのインフラ、いまむかし by 田中さん
  • はてな7年のインフラの歴史
  • 物理的なサーバが350台、仮想化して500台くらい帯域はピーク時240Mbpsくらい
  • 2005年当時の問題
  • SPOF多数
  • 回線飽和
  • 電力不足
  • はてなインフラ2.0時代
  • 2006年後半から2007年
  • MySQL 手間に LVS を導入した
  • リバースプロキシの手間に LVS を導入したら、mod_proxy_balancer の不安定部分が解消した
  • 電力、場所、回線問題を根本的に解決策するために iDC へ移動した
  • インフラチームは、6名(2名はアルバイト)
  • 2007年半ば LVS 三層
  • データベースなどの大事なサーバに商用サーバを採用した
  • 64ビット化
  • 2008年のいま
  • Xen の導入、1台のハードウェアで複数の OS
  • idle 時間が多いサーバを集約している
  • Xen でディスクレスサーバ
  • 中央のファイルサーバから OS のイメージを取得してブートする
  • Hadoop の導入
  • ログ解析、データ分析に使っている
  • サーバ管理ツールを独自で開発している
  • ホスト情報はサーバから自動取得
  • 負荷状況調査
  • Nagios の設定ファイル、Capistrano のデプロイ先、社内 IRC サーバと連携している
  • OS の自動インストールシステム
すべての講演が面白かったけれど、特に後半の二つの講演はメッセージが「インフラは楽しい!」ということが伝わってくる講演でした。
 
帰りには、初めて本にサインというものをいただいてきました。
僕のまわりの環境をみてみると、僕のシステムのインフラは僕一人で担当なのでチームとかない。さらに、個人的にはいつも使っている FreeBSD を使ってみたいと思っているけれど、Linux じゃなくと他の人には引き継げないだろうだからかなり我慢している。けれど、僕個人的にはインフラは楽しいと思います。
たしかに、深夜作業しているというイメージや動いていて当り前のシステムを動かす仕事だと評価されかちだけど作業内容自体はとってもクリエイティブであるし、この先もずっとそうであり続けるように努力すると思う。
最近他の会社でも、サーバ/インフラ担当者を募集しているのをよく目にするようになった。業界全体として人が足りていないようだ、これにはいろいろな原因があると思うけれど何よりもサーバ/インフラという仕事の楽しさが他の人には伝わっていないんじゃないかと思う。一見地味できつい仕事だと思われがちなサーバ/インフラという仕事の楽しさをどうやって他の人に伝えればいいのか考えていたけれど、昨日のような Tech Meeting などを通じて伝わってほしいと思う。
今の僕にできることといえば、サーバ/インフラの仕事を続けている限りはいつも笑顔で「こんな楽しい仕事は他にはないよ!」と1人でも多くの人に伝わればいいと思う。

サーバ/インフラを支える技術を読んで

サーバ/インフラを支える技術を読んだ。僕も仕事では、かなりの時間をサーバ/インフラに費しているので、1つずつとても興味深く読んだ。
この本では、どういう状況でどんなトラブルにあってどう対策したのかについてよく書かれているので、現場志向の本で「体験」という貴重な財産が惜しげもなく公開されている本だ。
目次は、DSAS 開発者の部屋で公開されているので、僕が感じたことを目次と重ねあわせていきたい。

 

1.1 冗長化の基本
1.2 Web サーバを冗長化する – DNS ラウンドロビン

冗長化の基礎的な部分がかなり凝縮されて書かれている。冗長化については、オライリーの「サーバ負荷分散技術」という本の前半にかなり詳しく書かれているので、興味のある人はあわせて読むといいです。NAT と DSR の違いについてよく分かる解説がありました。
VIP を割り当てるシェルスクリプトには、とても興味深いものがあった。
DNS ラウンドロビンは、手軽なので他のところではけっこう使っているという話を聞いているので驚いています。

 

1.3. Web サーバを冗長化する – IPVS でロードバランサ
1.4. ルータやロードバランサの冗長化

IPVS と keepalived についてです。僕も最近になって、IPVS と keepalived を導入してみた。
IPVS と keepalibed は、試す前は難しそうだと敬遠していたけど、実際に試してみると思った以上に簡単です。とはいっても、DSR は Linux 内でのパケットの流れをちゃんと理解していないと設定できないのですこし難しいです。NAT は、楽勝ですが…。
ちなみに僕は 1 人で 2 日間頑張って DSR を設定することができなかったので(情けない…)、外部に依頼して解決してもらった。今は、試験環境で DSR を設定して試しているので、近いうちに本番環境に導入する予定。また、僕が DSR ではまったところも、後日このブログで公開していきたい。

あと、最近スケジューリングアルゴリズムが rr になっていることに気がついて、そっと wlc に変更したのは内緒だ。keepalived の設定はちゃんと見ないといけない。同一サブネットでの LVS は、まだやっていないので、これからの課題になる。
VRRP では、iptables で VRRP のパケットをフィルターしてしまっていて中途半端にマスターとバックアップが入れ替わってしまった大変な体験をしたことがあるので、本に書いてほしいと思ったがはまるのは僕だろう。

 

2.1 リバースプロキシの導入

リバースプロキシ Apache について。Keep-Alive のオンとオフの話が、とても勉強になった。気になって今のシステムの設定を見てみたところリアルサーバ側でも Keep-Alived がオンになっていたので改善の余地がある。
僕のシステムでは、リバースプロキシとして Apache mod_proxy_balancer を使っているけれどけっこうメモリを使っているので nginx に差し替えようかと検討している。
mod_proxy_balancer は、ずっとフェイルバックしないと思っていたのでこれから確認してみる。

ボットからのアクセスは、キャッシュサーバに飛ばすというのはすばらしい案だと思う。前にボットからのアクセスで DOS 攻撃ぽくなっていて急いで対策したことがあった。

 

2.2 キャッシュサーバの導入

キャシュサーバの導入について、これも僕のシステムでこれからやろうと思っている。Squid ではなく、Varnish を使う予定。

 

2.3 MySQL のレプリケーション
2.4 MySQL のスレーブ

MySQL 5.1 の行単位のレプリケーションはよさそうだと思った。あと、今は tar でバックアップしているけれど、tar によるバックアップは小学生までらしいので LVM によるスナップショットでバックアップをとるのもこれからやることの一つ。

MySQL スレーブへの LVS は、僕のシステムではウェブとスレーブが同じサーバにあるのでスレーブが別のサーバのときは LVS を導入したほうがいいと思った。

 

2.5 高速で軽量なストレージサーバの選択

軽量なストレージサーバにするために、HTTP を採用して軽量な HTTP サーバを選択するためのさまざまな試験の重要さが見にしみました。

 

3.1 DNS サーバの冗長化

これは新たな課題になりました。今のシステムでは、/etc/resolv.conf で nameserver を複数してありますが、たしかに問題がある。それに DNS 障害の影響は多い。前は、あまりにも内部ネットワークでの DNS 参照が多く nscd を導入したことがあった。
DNS サーバの障害にはあったことがないが、いざのときのためにとても参考になった。

 

3.2 ストレージサーバの冗長化

DRBD は前に担当していたシステムで使っていて、Active/Backup の構成で手動でフェイルオーバーしていた。DRBD はけっこう簡単で2台構成でシンプルにストレージサーバとして冗長化できるが、それ以上スケールしないのが問題だと思う。
今の僕のシステムは、一台のサーバに NFS をたててストレージサーバとして使っているが、このサーバは SPOF になっている。そのため SPOF をなくすため、今後のことも考えてmogilefs を検討しようかと思っている。

 

3.3 ネットワークの冗長化

Bonding ドライバで NIC を冗長化する方法。ちょうど、先月あたりにメインのスイッチが壊れた。スイッチの予備がなく、4時間ほどサービスが停止したことがあった。そのため、スイッチの冗長化は今すぐやらないといけないと思っている。

 

3.4 VLAN の導入

これは、最近僕のシステムで導入した。スイッチが1台という環境で外部と内部、それぞれのサブネットを別けたいときに設定した。はじめてでかつ時間もあまりなかったので、ポートVLANで設定した。
たしかにこの章を読んで、スイッチのフラットな構成で冗長化したい場合はタグつき VLAN にすることは理解できた。

 

4. 性能向上、チューニング

「推測するな、計測せよ」この言葉にすべて集約されていると感じた。

 

5. 省力運用

nagios, puppet, ganglia など、僕のシステムでも導入しているものばかり。さらに PXE ブートは、cobbler で簡単にセットアップして memtest86+ も実行できるようにしている。
nagios を使って、サービスの稼働率を出すというアイディアはすばらしいと思った。
ganglia のパッチの量には驚いた、僕もおかしいところをなおした。なんとか本家に還元したいところ。ganglia はウェブ画面の表示部分をテンプレートして分離できるところが気に入っている。
puppet は、最近がんがんモジュールを書いているので汎用的なところを github で公開する予定です。

後半も、実例ばかりなので、とても参考になったし、とても勉強になった。
サーバ/インフラをやっている人は、貴重な財産になるので、ぜひ読んで自分のシステムでも実践してほしい!
僕も負けずに頑張っていきたい。

 

ということで、今日はサーバ/インフラTech Meetingにいってきます! レポートは、このブログにエントリする予定。

 

[24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ) (WEB+DB PRESSプラスシリーズ)

 

サーバ負荷分散技術

 

cobbler から memtest86+ を実行する

管理している1台のサーバから、メモリの ECC Error が発生した。そこで、memtest86 を実行して再確認するため、cobbler から memtest86 を実行してみた。

まず、cobbler 0.9 以上から簡単に memtest86 を PXE メニューに追加できる。

cobbler 0.9 以上にしないといけないということで、思い切って cobbler 1.0.3 にバージョンアップしてみた。cobbler は SRPM はすでに用意されているので、通常ユーザの %_topdir に SRPM をインストールしてビルドした。ビルドは、問題なく成功した。
cobbler を 0.8.3 からバージョンアップすると、settings ファイルの場所が /var/lib/settings から /etc/cobbler/settings に変わったので、cobbler check を繰り返しながら /etc/cobbler/settings を変更した。ちなみに 0.8.3 の頃の settings ファイルはそのまま 1.0.3 で使えないので新たにインストールされた /etc/cobbler/settings を変更する必要があるので注意する。
cobbler 1.0.3 になって、変わったなと思ったことは、次のとおり。

– cobbler sync しても、どのプロファイルがあるのか表示しなくなった
– settings ファイルの位置と設定内容が変わった
– settings ファイルで、設定できる項目がいっきに増えた(例えば、デフォルトの kickstart ファイルを指定できるようになった)

次に、memtest86 は、すでにメンテナンスされていないということでかわりの memtest86+ という後継バージョンを使うのが普通みたい。今日時点の最新版は、2.0.1。

CentOS 5.1 64 ビット版の memtest86+ は 1.6 と古いバージョンということで 2.0.1 の最新版にしてみた。 memtest86+ 1.6 の SRPM をインストールして、SPEC ファイルのバージョンだけ書き換えた。stub32.h というインクルードファイルが見つからないというエラーがでるが、glibc-devel.i386 パッケージをインストールすることで解決できる。無事ビルドできたら、さっそく memtest86+ をインストールする。

$ sudo yum install memtest86+

あとは、cobbler sync すると自動的に memtest86+ が PXE メニューに追加される。

$ sudo cobbler sync
$ less /tftpboot/pxelinux.cfg/default

DEFAULT menu
PROMPT 0
MENU TITLE Cobbler | http://cobbler.et.redhat.com
TIMEOUT 200
TOTALTIMEOUT 6000
ONTIMEOUT local

LABEL local
MENU LABEL (local)
MENU DEFAULT
LOCALBOOT 0

LABEL centos51-x86_64
kernel /images/centos51-x86_64/vmlinuz
MENU LABEL centos51-x86_64
append ksdevice=eth0 lang= kssendmac syslog=10.0.0.1:25150 text initrd
=/images/centos51-x86_64/initrd.img ks=http://10.0.0.1/cblr/svc/op/ks/profile/ce
ntos51-x86_64

LABEL memtest86+-2.01
kernel /images/memtest86+-2.01
MENU LABEL memtest86+-2.01

MENU end

おおー、memtest86+ がメニューに追加されている。さっそく、メモリがおかしいサーバを PXE ブートしてみると、たしかに memtest86+ が追加されている。

これはかなり便利!!!