Linux Archive

マザーが新しすぎて、内蔵のSATA HDDが認識しないー。Intel P35 + ICH9Rのマザー使うかな。

すごい組み合わせです。10Gb以上のNICかInfinibandかMyrinetが揃えられれば現時点(といってもまだものはないけど)で最強のストレージクラスタな気がします。

Cargo Maven 2 Pluginによるリリース良いな、今度ためしてみよう。

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

• 他にも同一ネットワークの利用者がそれなりにいた状態
• 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で共有フォルダ内のファイル表示が遅い

物理ポートに設定するVLANなんてTagVLANで全部流しときゃ良いよねっと思う今日この頃。ただし、絶対に違うVLANにアクセスさせたくない場合を除いて。

そんなわけでTagVLANなんだけど、TagVLANに対応させるとなるとサーバ側の選択肢は次の2つ。それぞれのメリット、デメリットも記載。

1. NICの機能を使う (対応しているNICのBIOS画面などで設定)
   • Good: OS上で意識しなくて良い
   • Good: 標準のネットワークインストーラで問題ない
   • Bad: TagVLANの設定してることを忘れる、他の環境に持って行ってアレレ!?…
   • Bad: 対応しているNICが少ない(?)
2. Linuxのvconfigを使う
   • Good: OS上で意識できる
   • Bad: 標準のネットワークインストーラだと接続できない
   • Good: まずTagVLAN使ってることを忘れない

速度の違いは測ってないので不明。ネットワークインストーラをごにょごにょして面倒じゃなくなればLinuxのvconfigでやる方が忘れなくて良いかな。

ちょっと気になったので試した。

sshd_config内でMatchディレクティブを使うことでsshd_config内で定義可能な設定オプションのいくつかを、ユーザ、グループ、ホスト名、アドレスごとに再定義することが出来ます。ブロックの開始記号と終端記号がないので設定ファイルの最後に書くのが無難です。

• Matchの構文
  • Match User ユーザ名
  • Match Group グループ名
  • Match Host FQDN
    • FQDNは対象サーバ内での名前解決結果に依存、/etc/hostsファイルで静的定義したものも有効
  • Match Address xxx.xxx.xxx.xxx
    • 「*」利用可、それもかなり大胆に。
    • 例1: 192.168.0.*
    • 例2: 192.*.0.* (途中穴抜けててもOK)
    • 例3: *.1* (末尾のIPの頭が1であればOK)

• 再定義可能な設定オプション
  • AllowTcpForwarding
  • Banner
  • ForceCommand
  • GatewayPorts
  • GSSApiAuthentication
  • KbdInteractiveAuthentication
  • KerberosAuthentication
  • PasswordAuthentication
  • PermitOpen
  • RhostsRSAAuthentication
  • RSAAuthentication
  • X11DisplayOffset
  • X11Forwarding
  • X11UseLocalHost

フォワーディング系が多い。PasswordAuthenticationが設定できるのは美味しい。

• 例1: 192.168.0.0/16からの接続時のみパス認証を許可する設定例

... 省略 ...
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
... 省略 ...
Match Address 192.168.*
    PasswordAuthentication yes

要望として良くありそうで出来ないこととしては、Matchディレクティブでは、PermitRootLoginを再定義出来ません。なので、PermitRootLoginを許可するにはグローバル設定でPermitRootLoginをon(デフォルト未設定時on)にしておく必要があります。

• 例2: 192.168.0.0/16からの接続時のみパス認証を許可する設定例 + rootログイン許可

... 省略 ...
#PermitRootLogin yes
PasswordAuthentication no
ChallengeResponseAuthentication no
... 省略 ...
Match Address 192.168.*
    PasswordAuthentication yes

この場合、192.168.0.0/16以外からの接続は公開鍵認証必須になるので、root用の公開鍵をあえて設定しない運用をするとか。まぁでもそれだったら、一般ユーザでログインしてsu -かsudoしろって話でもある。

PuTTY 0.59がなんかおかしいかもで書いた「OpenSSL 0.9.8e + OpenSSH 4.5p1なサーバが相手だと次のエラーが出て繋がらない。」はOpenSSH 4.6p1に上げたら出なくなった。

ってのが出来たらしい。メンバー見ると日本Sambaユーザー会がベースになってる感じなのかな。オープンソースカンファレンス2007 Tokyo/Springで設立セミナーってのをやるらしいので見に行くかも。

一応LDAP関係のプロジェクトとしてS2Directory?とSMBLDAP Addonsやってるしね。

2つおかしなことがある。

• CentOS 4.4のRPMのOpenSSHなサーバが相手だと次のエラーが出て繋がらない。
  • 現時点の回避方法: PuTTY 0.58を使う

Disconnected: No supported authentication methods available

自前でOpenSSH 4.5p1を入れてる場合は出ない。

• OpenSSL 0.9.8e + OpenSSH 4.5p1なサーバが相手だと次のエラーが出て繋がらない。
  • 現時点の回避方法: PuTTY 0.58を使う or PuTTY 0.59の設定で[接続] -> [SSH]の暗号化選択のポリシーでデフォルトAESが一番上にあるのを、3DESかBlowfishのどちらかを一番上にする。

Incoming packet was garbled on decryption

Xen 3.0.4_1の64bit環境で3ware 9650SE-2LPが使いたかったのでコンパイルしてみたら動いた。

• xen-3.0.4_1-install-x86_64
• 3w-9xxx-linux-src-2.6-supp_distros-suse10-fc5-9.4.0.1.tgz
  • 試したカード: 3ware 9650SE-2LP

XenはSAN環境と複数物理台数構成にすると激しい威力を発揮するんだなと思い始めてきた。今後メモリが馬鹿安＆大容量化して潤沢になるともっと使われるんだろうね。