Academic Archive

もう日がないのにいろいろと問題が。最初から他の人に窓口任せないで直接やってくれれば良かったのになー。今となってはしょうがないけどできる限りやろう。僕の気分は超デスマだ。

正直スマンカッタ・・・。自分の大学舐めてた、何この豪華なの。こないだちょこっと入った時は入口周辺しかいってなかったので判らなかったけど、中うろうろしたらありえない豪華さです。ここも日中はいっぱいなのかもしれんけど、ここと比べてうちの学部のスペースのなさは一体。。。

8末まで修行かな。

勉強会でXenの発表を学部2年の後輩がしてくれた。この時点で既にいつも以上に盛り上がった。さらに途中から内容補うために話始めたらさらに質疑応答・議論で盛り上がった。皆仮想化大好き、ライブマイグレーション大好き(´ー｀)。

最近毎週金曜の勉強会が21時超えてるけど楽しいのでOK。

一昨日適当に測ったのを掲載。会話の途中でいきなし測ってみるかってことになったので、適当に測ってみました。

• 他にも同一ネットワークの利用者がそれなりにいた状態
• ddだと1回目と2回以降で速度変わっちゃったりするらしいけどそこは気にしない
• bashのtimeで計測、結果は小数点第3位を四者五入
• 8GBの1ファイルに対する計測
  • 小さいファイルたくさんで計測したらまた違うかもね

構成とスペック

• SANストレージ1台: IBM System Storage DS4700
  • RAID-5 2TBのファイルシステムがGFSの同一論理領域をファイルサーバ3台で接続
    • ファイルサーバ3台でロック情報を共用
  • RAID-5 1.7TBのファイルシステムがext3の論理領域をファイルサーバ1台で接続
  • 2つあるコントローラに4 Gbps ファイバーチャネルでSANスイッチ経由でファイルサーバ3台に2本ずつ接続
    • それぞれ1本はスタンバイ
• ファイルサーバ3台: IBM System x 3550
  • OS: CentOS 4.4 64-bit (RDACがCentOS5にまだ対応していないため)
  • CPU: Intel Xeon 5160 3.0GHz
  • MEM: 4GB
  • HDD: SAS 160GB 15,000rpm (RAID-1)
• シェルサーバ (Xen上): IBM System x 3550
  • OS: CentOS 5.0 64-bit
  • Xen: xen-3.0.3-25.0.3.el5 (CentOS 5.0付属)
    • ゲストOS: 3台稼働中。シェルサーバはその内の1台。
  • CPU: Intel Xeon 5160 3.0GHz
  • MEM: 4GB
    • Xen上のゲストOSへの割り当て容量: 1GB
  • HDD: SAS 160GB 15,000rpm (RAID-1)
  • ファイルサーバのGFS領域をNFSマウント
• ネットワーク: 1000Mbps

テスト内容: 8GBのファイルの作成、コピー、削除の速度と適当に計測

1. シェルサーバ上のNFSマウント領域
2. ファイルサーバ上のGFSのSANストレージ領域
3. ファイルサーバ上のext3のSANストレージ領域
4. ファイルサーバ上のext3のローカルHDD領域

• 1. シェルサーバ上のNFSマウント領域
  • シェルサーバ(NFS) -> (Xenホスト) -> ファイルサーバ -> SANストレージ

$ time dd if=/dev/zero of=/home/users/*****/BigZero8G bs=1024 count=8000000
8000000+0 records in
8000000+0 records out
real    2m21.375s
user    0m3.600s
sys     0m23.869s
結果: 57.95 MB/s

$ time cp BigZero8G BigZero8G_2
real    5m4.968s
user    0m0.460s
sys     0m14.337s
結果: 26.69 MB/s

$ time rm BigZero8G -rf
real    0m0.541s
user    0m0.000s
sys     0m0.132s

• 2. ファイルサーバ上のGFSのSANストレージ領域
  • ファイルサーバ -> SANストレージ

$ time dd if=/dev/zero of=/home/users/*****/BigZero8G bs=1024 count=8000000
8000000+0 records in
8000000+0 records out
real    1m28.606s
user    0m1.291s
sys     1m2.863s
結果: 92.45 MB/s

$ time cp BigZero8G BigZero8G_2
real    2m13.240s
user    0m0.374s
sys     0m43.967s
結果: 61.48 MB/s

$ time rm BigZero8G_2 -rf
real    0m0.237s
user    0m0.000s
sys     0m0.212s

• 3. ファイルサーバ上のext3のSANストレージ領域
  • ファイルサーバ -> SANストレージ

$ time dd if=/dev/zero of=/home/backup/BigZero8G bs=1024 count=8000000
8000000+0 records in
8000000+0 records out
real    1m16.306s
user    0m0.946s
sys     0m16.891s
結果: 107.36 MB/s

$ time cp BigZero8G BigZero8G_2
real    2m25.014s
user    0m0.376s
sys     0m17.820s
結果: 56.49 MB/s

$ time rm BigZero8G -rf
real    0m2.017s
user    0m0.000s
sys     0m0.535s

• 4. ファイルサーバ上のext3のローカルHDD領域
  • ファイルサーバ -> ローカルHDD

$ time dd if=/dev/zero of=/tmp/BigZero8G bs=1024 count=8000000
8000000+0 records in
8000000+0 records out
real    1m32.946s
user    0m0.981s
sys     0m16.132s
結果: 88.13 MB/s

$ time cp BigZero8G BigZero8G_2
real    3m22.509s
user    0m0.354s
sys     0m17.396s
結果: 40.45 MB/s

$ time rm BigZero8G -rf
real    0m2.612s
user    0m0.001s
sys     0m0.567s

表

テスト実施環境 / テスト項目	書き込み速度(MB/s)	コピー速度(Read+Write)(MB/s)	削除(秒)
1. シェルサーバ上のNFSマウント領域	57.95 MB/s	26.69 MB/s	0m0.541s
2. ファイルサーバ上のGFSのSANストレージ領域	92.45 MB/s	61.48 MB/s	0m0.237s
3. ファイルサーバ上のext3のSANストレージ領域	107.36 MB/s	56.49 MB/s	0m2.017s
4. ファイルサーバ上のext3のローカルHDD領域	88.13 MB/s	40.45 MB/s	0m2.612s

まとめ

• 1: シェルサーバ上での作成とコピーの値がほぼ2倍になっているので、これはNFSの処理速度とネットワークの限界で、SANストレージは足を引っ張ってなさそう。
• 2,3: SANストレージのGFSはSANストレージのext3の86.11%のファイル書き込みパフォーマンスだった。
• 2,3: ファイルのコピーはSANストレージのext3よりSANストレージのGFSの方が早かった。
• 2,4: GFS経由でもローカルHDDより早い -> たぶんファイバチャネルが早いから。
• 2,3,4: ファイバチャネルはやっぱし早い
• 1,2,3,4: 削除は早い順でGFS(SAN) > NFS-GFS(SAN) >>>> ext3(SAN) > ローカルHDD。GFSとNFSはたぶん実際に削除する前にレスポンス返してるので早いっぽい。

という結果でした。GFSはext3と比べて大きな差もなくかなり早いという印象です。GFSに似たとある商用分散ファイルシステムはなぜかファイルの削除に2分以上かかるらしい。たぶんロック情報の共有の仕方がおかしいんだと思う。

ただし、GFSなのかSANストレージなのか判ってないけど、このGFS環境には罠が1個あって、dfした時の現容量の表示が2秒ぐらい掛かる。ファイバーチャネルの接続構成変えても治らなかった。

関連: Sambaで共有フォルダ内のファイル表示が遅い

64bit版のSamba 3.0.25で発生するこのバグにハマってた人 ノ。テストしたらこの症状が出たので、時間無かったのもあり、LDAPのエントリのパスワード期限周りのとこ書き換えてら、警告は出なくなったけどネットワークドライブが全滅したので、3.0.24にすぐに下げてた。

• メールサーバでSSL通信(POPS,SMTPS,IMAPS)を行うと、利用者のユーザ名とパスワードは確実に暗号化通信されることが保障できるけど、違うメールサーバに所属するメールアドレスにメールを出した場合、MTA間で暗号化通信がされるとは限らないためメール本文の盗聴、漏洩、改竄が確実に起きないことを保障できない。というより多くのMTAはSMTPサーバ間は暗号化通信しない。MTA間を暗号化通信してくれる例としてはqmail-ldap同士なんかがある。逆に言えば、同一メールサーバ内のメールアドレス宛なら、そのメールサーバがクラックされてない限りメール本文の盗聴、漏洩、改竄されていないことを保障できる。
• ただし、上記に限らず接続先メールサーバを誤って設定していたり、もしくは、ウィルスなどでDNS情報が書き換えられてたりしてダミーメールサーバに接続されていたりすると、SSL通信したとしても利用者のユーザ名とパスワードが保護されるとは限らない。後者の場合、その時点でたぶん既に漏れてるだろうけど。。
• 非SSLポートであってもSTARTTLSを使えば暗号化通信できる。ただし、こっちだと間違ってメールクライアントで暗号化通信しない設定で通信しちゃうとメールクライアントによっては認証情報自体は送っちゃうのでよろしくない。あと、一部プロバイダでは、自分とこのメールサーバ以外の外部のメールサーバには非SSLの標準ポート(25,110,143)は接続できないようになってるらしい。

原因はディスクの空き容量の計算にありました。smb.confに下記を追加してとりあえず誤魔かした。

dfree cache time = 60

この設定で空き容量の計算を60秒に1回しかしないようになります。デフォルトだと毎アクセスごとに2回計算されます。

このオプションに辿り着いたのは、Sambaの共有フォルダへアクセスするごとに何か遅くて我慢できなくなったのでソース追ってみたら下記のとこで1アクセスに2秒*2回も掛かってて、そっから辿ってったらこのオプションがありました。

[2007/05/10 23:58:44.130953, 3] smbd/trans2.c:call_trans2qfsinfo(2167)
  call_trans2qfsinfo: level = 1007
[2007/05/10 23:58:46.007478, 10] lib/sysquotas.c:sys_get_quota(426)
  sys_get_quota() uid(XXXX, XXXX)

本当の原因は別のとこにあって、ファイルサーバ上でdfした時のSANストレージの結果表示が遅いことにあります。つまりほんとに空き容量計算が遅い。この原因についても現在後輩が対応中で、来週にはたぶん直りそう。

いろいろ変わったことは変わったけど、ほとんど裏方ばっかで表から見たら違い判んない罠。深く使わない人以外面白くなさそう。スペックももう十分だし、単純スペックを上げるリプレースは今回で終わりで、次回からはコンテンツやサービスの向上を目指す形に移り変わっていきそうです。

といいつつ、次回あたりだと世の中的にHDDレスが進んで、全メモリ化とかやっちゃいそうだけど。。少なくともサーバサイドはSANストレージ以外はそうなるだろうなー。

裏方はかなり大きな変化がありました。具体的にはSANストレージの導入、ファイルシステムのGFS化、全サーバの64bit化、ネットワークのセグメント分割などなど。OSはファイルサーバ3台はCentOS 4.4、それ以外の6台がCentOS 5.0、1台だけWSUSのためにWindows Server 2003。また、CentOS 5.0の入ったうちの2台はXenが動いており、その上でゲストOSが5台分動いてます。認証系のLDAP、ドメインコントローラのSamba環境は動かすマシン自体を変えて今までとおり継続。GFSのフェンシングにはIPMIを使っています。

ネットワークはVLANで6つに分け、内訳はグローバル用VLANが1つとローカル用VLANが5つ、グローバルとローカルの両方を1物理ポートで利用するのに一部スイッチではTagVLANにしました。Xen環境ではVLANを組んだイーサネットデバイス2つをそれぞれブリッジし、ゲストOS環境でも両方へアクセスできるようになっています。

ローカルのVLAN分けはちょっと失敗っぽいことがあります。スイッチ(Catalyst 4503)の機能でローカルVLAN間の静的ルーティングとマルチキャスト、bootp(DHCP)をルーティングをしていて透過的に繋げるようにしていたものの、どうやらGhostのタスクでのファイル転送とDeployCenterのPXEブートイメージの配信はまた別の手段を使っているようで、セグメントを越えての配信が出来ませんでした。Ghostのメイン機能であるマスタイメージ配信はマルチキャストなので問題なく出来たので、セグメントを越えられない処理は、1セグメント=1部屋ずつ処理することでとりあえず良いやってことにしています。

表側のクライアントLinuxはとうとう物理パーティションからVMwareの中に押しやられました。ただここでも問題があり、ゲストOS用のMacアドレスの生成アルゴリズムが公開されている仕様と違っていて(たぶん古い)DHCPによるIP配布が上手くいきませんでした。この問題に対しては、ホスト側のWindowsで実MacアドレスからDHCPで取得したIPから静的なMacアドレスを決めて、vmxファイルを書き換えて固定するWSHスクリプトを書いて対処しました。VMwareの中にLinuxがインストールされたことで、Ghostブートパーティションも使えるようになりました。

他にも様々な問題やその対処がありましたが今回は省略。

今回のリプレースは、僕らとは関係ないとこで数多くのミスやトラブル、無茶な要望が大量にあり、ものが納品される時点でもう作る時間がほとんどない日程だったため非常に大変でした。

何より、実はサーバ・クライアント環境の構築などの作業ほぼすべてを後輩の現学部2年と3年(春休みの時点だと1年と2年)が中心にやったため、彼らの春休み後半、GW休みがほぼすべて無くなってしまったのは非常に申し訳なかった。

ただリプレースを通して、その分後輩達の知識が飛躍的にあがったことは嬉しい限りです。学部2年、3年の人がXenとかLDAPとかGFSだとか議論するんだから、それは自分がその歳の時のことを考えると末恐ろしい限りです(;´ー`)。

というわけで、まだ細かいことでやり残してることがあるけど、ほんとにお疲れ様でしたー。

WEB向けのサーバならどんな構成でも1日でだいたい全部作れるのになー。ラッキングとか終わってからの状態で。