期限までに完成しないことを前提として途中までのレポートを提出することを、許されないとしても理解した上でお読みいただければ何よりです。
初めに構築を行う上で大いに参考にしたリンクを貼っておきます。
自作サーバカンファレンス http://bb.watch.impress.co.jp/docs/news/20091126_331459.html
Centosで自作サーバー構築 http://centossrv.com/
図1、届いた直後の状態
今回この5枚のD510MOを預かり、これを用いてクラスタ構成によるハイパフォーマンスサーバを作成せよ、とのお題を受けた私は『webサーバを作ろう』と思い立ちました。
クラスタリングという言葉を今回のレビューで初めて知り、そして当然ながらその実現方法も分からない。
そんな私がどうして選ばれたのか。
ということを考えながら今回の実験を行いました。
できるだけ簡易に、そして安価に作ろうという方針で作ろうかと思います。
使用パーツ構成は以下の通りです。
◆OS:
Linux(Fedora 14) →のちに Centos 5.5(Final)に変更
◆メモリ:
1GB(ノーブランド)
◆ブートドライブ:
◆電源:
※もともとFedoraでの検証を予定していましたが、想像以上にネット上に転がっているドキュメントやインストール用のパッケージの量にも差があったことから、より平易なCentosに移行することにしました。
恐らくFedoraでもパッケージさえ適切なものを使えば同様の動作をすると思います。
メモリはデスクトップ用DDR2に、電源はATXの24ピンに対応し、映像出力はD-subのみと余り物を有効活用くれと言わんばかりですが、残念ながら全く余りがなかったのですべて購入しました。
電源は自作サーバカンファレンスの構成を参考にし、個別の電源を用意しております。
その他サプライを含めると1機につき15000円ほど(D510MOを除く)です。
□ まずハードウェア面の構成を考えます。
簡易に、なのでこんな感じにしました。
図2、穴あけ後の箱
一度電源が付きさえすればあとはLANコネクタさえ見えていればそれでいい、という感覚です。
そして資源の再利用。
これはマジックテープなどでお互いを固定することでいかなる構造の組み立ても可能になる柔軟さを秘めていますが、密閉されているだけに難点は多いです。
エアフローや電源の配線は今のところ考慮していません。
フィンに触ると火傷するほどの熱が出るので今後の対策は必須かと思われます。
また、電源のつけ方ですが、非常にシンプル。
図3、ボールペンショート
これです。赤の2ピンを引っかけると電源が付き、青の2ピンを引っかけるとリセットされます。
電源はタコ足を用意します。
LANにも専用のHUBを用意しますが、家に8portのHUBがなかったので5portの物を使っています。
各機のリモートメンテに対応していないため、メンテナンスを行う場合サブネットを合わせてwww1の接続を外してからクライアント機に繋がないといけません。
そして全体を構築するとこうなります。
構築後
手間を惜しんだ結果こうなりました。
お許しください。
□ そしてソフトウェア面の構成を考えます。
これも自作サーバカンファレンスを大いに参考にさせてもらいました。
webサーバのクラスタリングということで、1台をwebサーバ兼ロードバランサとして動かし作業の割り振りを行い、残りをバックエンドで処理行い結果を返却するサーバとして動かすように考えます。
大まかですが、
ロードバランサ:nginx (0.8.54)
web:nginx,Starman(CGI)
を使うことにします。
Starmanを使う理由はnginxには単独でCGIを処理する能力がないからです。
fcgiの機能はあるのでそれを用いても構いませんが、今回はPlack/PSGIを使ってCGIを動かすことにしました。
負荷確認にApache Benchmarkを、そしてCMSとしてMovable Typeを採用しようかと思いましたが時間の都合上個人的に使用しているフリーのcgi日記ツール、nickyを使うこととします。
□ ネットワーク面の構成を考えます。
ネットワーク
こんな具合です。
また、ロードバランスを行うためにはLANが2つ必要であるため、個別にCG-LAPCIGTR(http://corega.jp/prod/lapcigtr/
)を用意しました。
RTL8169チップというD510MOの若干上位互換?なチップを積んだ安価なNICです。
□ セットアップを行います。
図5、セットアップ時の環境
詳細はこの
作業工程に記述されています。
補足。
Centosの公式ページからDVDイメージをダウンロード、そしてDVD-RWに焼きインストールを行います。
なお、今回はi386版を使いましたが、x86_64版を使いたい場合、そのままのDVDイメージがあまり転がっていないため、ハッシュを拾ってshareでダウンロードするなりftpで公開されてるところを根気強く探してみてください。
このときだけUSBにDVSM-P58U2/B(http://buffalo.jp/products/catalog/storage/dvsm-p58u2_b/
)を挿入してブートを行います。
手順は起動直後にF10を押してブートドライブにDVDドライブを選び、あとは上記のページを参考にしてインストールを行うだけです。
エラーは起きず、一切問題なくインストールが完了しました。
D510MOのLANチップはr8168というドライバを使うのに対して今回用意したNICはr8169を使います。
相性的な問題を懸念しましたが、ネットからr8159をダウンロードしてインストールし、lsmod | grep r81で検索したときにr8159とr8169が両方とも確認できる状態のときに挿し込み、正常なLANケーブルを接続したさいに両方とも認識させることができました。
□ 検証を行います。
上記の設定によって、
http://192.168.11.1/diary/nicky.cgiにアクセスするとそれぞれのサーバに作業が割り振られるようになります。
今回は1台で動作した時から1台ずつサーバとして稼働させる台数を増やしていき、どれだけパフォーマンスが変わるかどうかを検証したいと思います。
まずは私が普段使ってるパソコンにVMwareを入れて同様の設定で動かした場合の検証を行います。
少々不公平に見えるかもしれませんが、この場合に限りStarmanに直でアクセスすることにします。
同時に100リクエストを処理させるベンチマークを行います。
使用するベンチマーク用アプリケーションはApacheのBenchmarkです。
原則として2回ベンチマークを行い、もっともパフォーマンスのよかった方を優先します。
環境は
CPU:
system:
save:
memory: 8GB
OS:
VM設定:
core: 2
memory: 4GB
OS: Centos5.5 x86_64
IP: 192.168.224.128
■メインPC
ab -n 100 -c 100 http://192.168.224.128:5000/nicky.cgi
Document Path: /nicky.cgi
Document Length: 35682 bytes
Concurrency Level: 100
Time taken for tests: 5.489 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 3584200 bytes
HTML transferred: 3568200 bytes
Requests per second: 18.22 [#/sec] (mean)
Time per request: 5489.197 [ms] (mean)
Time per request: 54.892 [ms] (mean, across all concurrent requests)
Transfer rate: 637.65 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 5 9.6 2 44
Processing: 513 2654 1413.4 2653 4958
Waiting: 511 2607 1408.9 2499 4957
Total: 514 2659 1413.4 2655 4961
Percentage of the requests served within a certain time (ms)
50% 2655
66% 3434
75% 3951
80% 4185
90% 4706
95% 4873
98% 4928
99% 4961
100% 4961 (longest request)
■次に1台のときのベンチマークを行います。
ab -n 100 -c 100 http://192.168.1.1/diary/nicky.cgi
Document Path: /diary/nicky.cgi
Document Length: 34525 bytes
Concurrency Level: 100
Time taken for tests: 12.915 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 3467000 bytes
HTML transferred: 3452500 bytes
Requests per second: 7.74 [#/sec] (mean)
Time per request: 12915.140 [ms] (mean)
Time per request: 129.151 [ms] (mean, across all concurrent requests)
Transfer rate: 262.15 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.8 1 7
Processing: 494 6709 3705.8 6802 12862
Waiting: 492 6707 3705.9 6801 12860
Total: 498 6710 3705.6 6803 12862
WARNING: The median and mean for the initial connection time are not within a no
rmal deviation
These results are probably not that reliable.
Percentage of the requests served within a certain time (ms)
50% 6803
66% 8800
75% 10056
80% 10614
90% 11845
95% 12459
98% 12796
99% 12862
100% 12862 (longest request)
■次に2台動作させたときのベンチマークを行います。
ab -n 100 -c 100 http://192.168.1.1/diary/nicky.cgi
Document Path: /diary/nicky.cgi
Document Length: 34532 bytes
Concurrency Level: 100
Time taken for tests: 6.512 seconds
Complete requests: 100
Failed requests: 50
(Connect: 0, Receive: 0, Length: 50, Exceptions: 0)
Write errors: 0
Total transferred: 3467350 bytes
HTML transferred: 3452850 bytes
Requests per second: 15.36 [#/sec] (mean)
Time per request: 6511.826 [ms] (mean)
Time per request: 65.118 [ms] (mean, across all concurrent requests)
Transfer rate: 519.99 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 0.9 1 6
Processing: 494 3451 1815.7 3431 6446
Waiting: 491 3448 1815.7 3428 6444
Total: 495 3451 1815.4 3432 6446
Percentage of the requests served within a certain time (ms)
50% 3432
66% 4482
75% 5094
80% 5323
90% 5994
95% 6275
98% 6361
99% 6446
100% 6446 (longest request)
一気に倍近くパフォーマンスが上がりました。
なお、この際requests failedのlengthが溜まっているのは微妙に各マシンで返す値が異なっているためだと思います。
100のリクエスト中50が落ちていることから、ほぼ処理の割り振りは半々で行われていることが予想できます。
■次に3台動作させたときのベンチマークを行います。
ab -n 100 -c 100 http://192.168.1.1/diary/nicky.cgi
Document Path: /diary/nicky.cgi
Document Length: 34532 bytes
Concurrency Level: 100
Time taken for tests: 4.400 seconds
Complete requests: 100
Failed requests: 66
(Connect: 0, Receive: 0, Length: 66, Exceptions: 0)
Write errors: 0
Total transferred: 3467502 bytes
HTML transferred: 3453002 bytes
Requests per second: 22.73 [#/sec] (mean)
Time per request: 4399.559 [ms] (mean)
Time per request: 43.996 [ms] (mean, across all concurrent requests)
Transfer rate: 769.68 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.6 1 4
Processing: 495 2400 1205.8 2429 4350
Waiting: 490 2395 1206.2 2426 4349
Total: 496 2400 1205.6 2429 4350
WARNING: The median and mean for the initial connection time are not within a no
rmal deviation
These results are probably not that reliable.
Percentage of the requests served within a certain time (ms)
50% 2429
66% 3023
75% 3494
80% 3800
90% 4051
95% 4257
98% 4293
99% 4350
100% 4350 (longest request)
1台目のときの1/3程度の処理時間になりました。
lengthが66になっていることから、それぞれ1/3ずつ等分して処理を行っていることが予想できます。
■次に4台動作させたときのベンチマークを行います。
ab -n 100 -c 100 http://192.168.1.1/diary/nicky.cgi
Document Path: /diary/nicky.cgi
Document Length: 34532 bytes
Concurrency Level: 100
Time taken for tests: 3.378 seconds
Complete requests: 100
Failed requests: 75
(Connect: 0, Receive: 0, Length: 75, Exceptions: 0)
Write errors: 0
Total transferred: 3467375 bytes
HTML transferred: 3452875 bytes
Requests per second: 29.60 [#/sec] (mean)
Time per request: 3378.429 [ms] (mean)
Time per request: 33.784 [ms] (mean, across all concurrent requests)
Transfer rate: 1002.27 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.8 1 7
Processing: 467 1863 895.0 1932 3325
Waiting: 464 1859 894.7 1929 3324
Total: 468 1863 894.8 1932 3325
WARNING: The median and mean for the initial connection time are not within a no
rmal deviation
These results are probably not that reliable.
Percentage of the requests served within a certain time (ms)
50% 1932
66% 2416
75% 2636
80% 2921
90% 3065
95% 3189
98% 3211
99% 3325
100% 3325 (longest request)
1台目のときの1/4程度の処理時間になりました。
lengthが75になっているため、またもや1/4で等分して処理をしていることが予想できます。
■最後に5台動作させたときのベンチマークを行います。
ab -n 100 -c 100 http://192.168.1.1/diary/nicky.cgi
Document Path: /diary/nicky.cgi
Document Length: 34525 bytes
Concurrency Level: 100
Time taken for tests: 2.777 seconds
Complete requests: 100
Failed requests: 40
(Connect: 0, Receive: 0, Length: 40, Exceptions: 0)
Write errors: 0
Total transferred: 3467300 bytes
HTML transferred: 3452800 bytes
Requests per second: 36.01 [#/sec] (mean)
Time per request: 2777.353 [ms] (mean)
Time per request: 27.774 [ms] (mean, across all concurrent requests)
Transfer rate: 1219.16 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.6 1 4
Processing: 487 1530 696.0 1586 2723
Waiting: 484 1526 695.6 1583 2721
Total: 489 1530 695.8 1586 2723
WARNING: The median and mean for the initial connection time are not within a no
rmal deviation
These results are probably not that reliable.
Percentage of the requests served within a certain time (ms)
50% 1586
66% 1892
75% 2203
80% 2341
90% 2457
95% 2544
98% 2651
99% 2723
100% 2723 (longest request)
最終的に5倍程度にまでパフォーマンスが上がりました。
この場合に限りlengthが40になっています。
また、ロードバランサとしてnginxを使っているマシンにも処理を投げているのですが、nginxのロードバランス機能は重み付きラウンドロビンで作られているため、重みが付けられてこんな結果が出ている可能性が推測されます。
設定ではそんなことやってなかったはずですが……。
nginxによるロードバランシングを行うとおおよそその台数分パフォーマンスは上がるようです。
処理時間にだけフォーカスを移して表にまとめると以下のようになります。
graph
3台目の時点で私のメインPCよりもパフォーマンスで勝っているのが分かりますね。
ちなみに私のこのPCは30分のtsをlancozを用いたリサイズ+ロゴ抜きをかけてx264でエンコして2時間くらいかかったり、プレアデスをHD画質で再生するとパンで若干カクつきが確認できるくらいのスペックです(グラボの性能が低いため)。
それでは、ランニングコスト的にはいかがなものか？
私のメインPCはグラボなど色々載せている都合上、消費電力はおよそ120Wくらいです。
シバいて150Wくらいです。
それに対して、D510MOは1台およそ30Wほどで動きます。電源を繋いで通電させてるだけだとおよそ3W程度使うようです。
実際に5台まとめて繋ぐと152Wくらいで動作します。これはシバいてもほとんど変化がありません。
3台動かしたときの消費電力を考えると90W程度に落ち着きます。
この時点でメインPCのパフォーマンスに加え、ランニングコスト的にも上回っています。
家で燻らせていたものを流用してこのマシンを構築し、サーバとして運用するのであればかなり全体的なパフォーマンスは高いのではないでしょうか。
無論、今回のベンチマークの比較においてはVMによるパフォーマンスの低下や、グラボなどの今回のベンチマークには必要のないオプションを付加していることによる消費電力の増加があることは配慮頂けると幸いです。
また、今回の動作においてはwebで実際に公開することに主眼を置いて設定をしておりません。
そのためすぐに運用することはできませんが、設定次第では可能だと思います。
後日更新していく予定ですのでどうかよろしくお願いします。
一応記載しておきますと、恐らく、
・iptablesによるセキュリティ強化
・www1をルータ化するか、別にメンテ用にゲートウェイ的なサーバを用意してリモートメンテの実装
・データサーバを用意して各アプリケーションサーバとのファイルの共有
・PSGIファイルのコードの見直し
・DNSの実装
などが実際に運用する上では必要になるかと思います。
もちろん、ApacheにLVS+keepalivedで運用した場合その限りではありません。
最後に、このようなスキルアップの機会を与えてくださいましたintel様、zigsow様に深く感謝を申し上げます。
※11/16 r8168のところをr8159(ハイゴッグ)と間違えて表記してしまっていたので修正しました。
DOZENさん
2010/11/18
レビュー頑張ってください。
誇りたまえさん
2010/11/18
まだその肝心の内容はできてないのでもう少し待っていただけると嬉しいです。
最終的には『何も知らない人でもとりあえず見よう見まねでwebサーバのクラスタリングができる』くらいに平易な内容にしたいと思うのでどうかご期待ください。
初めてのことだらけで非常に苦労しておりますが……。