QNAP NAS+iscsi+zfsが固まる

iscsi initiator+gjournalが固まるからの続き。 カーネルデバッグは敷居が高すぎて早々に諦めつつ、iSCSI+ZFSは使いたいので調査継続。 どうやらiSCSI TargetであるQNAP NAS、中身はLinux LIOが怪しい気がする。 8/8追記: iSCSIのCmdSNとInitiator Task Tagに関して誤りがあったので訂正。

カーネルデバッグに手を染めてみる(2)

前回からの続き。 VMを使えばシリアルポートなんて簡単に接続できることに、いまさら気づいた。(始めてから2週間くらい) 機材そろえちゃったよ……。 気を取り直して、ハマっているbio(I/O)を探してみる。(そしてこれもうまくいかなかった。)

カーネルデバッグに手を染めてみる(1)

もたもたしてたらFreeBSD 11.0-BETA2が出てしまった。 この前から続けて、最後に試したFreeBSD 11.0-BETA1なシステムでiSCSI+zfsがハマる原因を調べる。 (一応書いておくと、9.3-RELEASE, 10.1-RELEASE, 10.3-RELEASEのいずれでも発生している。)

iscsi initiator+gjournalが固まる(2)

iscsi initiator+gjournalが固まるというのを前に書いた。 しかしどうやら、負荷のかけ方によっては、 複数のiscsi targetに接続したとき geom_gateを使ったzfsを作って書き込んだとき にも同じように固まることが分かった。 この状態ではまると、gstatで問題のデバイスがキュー長が非零のままで止まり、いつまでたっても解消しない。 そして 、こっちのほうが困るのだが、再起動ができなくなる。panicですら自動再起動できずに止まる。カーネルのコアも吐けない。 マシン固有の問題か、それともほかのなにかか。同じ型番のマシン複数で起きてるから、個体のバグではなさそう。 とりあえずは環境を別のマシンに移して起きるか確認して、あとはシリアル経由でカーネルデバッグかな……。

GlusterFSの構成ディスクを交換する

図らずも一台のデータを壊してしまったので嬉々として復旧実験。 ノード自体は生きているが、brickの中身を壊しちゃったという場合の話。 参考にするのはGlusterFSの公式資料。 http://www.gluster.org/community/documentation/index.php/Gluster_3.4:_Brick_Restoration_-_Replace_Crashed_Server とりあえずglusterfsを止める。 現状、FreeBSD版のservice stopだと子プロセスが残るのでkillallしてくださいな。 (そのうち直します。あとglusterfsdじゃなくてglusterdが正しいという話もね……。) # service glusterfsd stop # killall glusterfsd ディスクを入れ替えたりいろいろする。 newfsとかmountまで済ませる。 brickのディレクトリを手動で作る。 setextattrbinを持ってきてビルドしておく。(→おまけ) brickのディレクトリにvolume-idを設定する。ちょっと長いone-linerだけどこんな感じ。 # cat /var/db/glusterd/vols//info | perl -ne ‘m/volume-id=/ and s/^.*=// and s/-//g and print’ | setextattrbin user trusted.glusterfs.volume-id -stdin glusterfsを起動して、healを開始させる。 replicatedなら、 # service glusterfsd start # gluster vol heal full disperseならNFSでマウントしてから、 # find -exec stat {}\; […]

GlusterFSをESXiから使う(3) 書き込み速度測定

実運用を想定して、ESXiの仮想マシンを乗っけてddで計ってみた。 結果は大体20MB/sくらいは出ているのでセーフな範囲。もう少し速いとうれしい。 速度を気にするならstripeも測るべきだけど出てこないのは、またバグっぽいものを見つけたから。 こっちはまた追ってまとめる。

iscsi initiator+gjournalが固まる

glusterfs環境のパフォーマンステストのため、iscsi initiatorでNASに接続している/dev/da*に、gjournal labelでローカルなSSDをjournalとしてくっつけた。 newfsはうまくいってmount、gluster volume createしてgluster volume start、と思ったら固まってしまった。 いろいろ条件を変えて速度測定したかったのになぁ……。

GlusterFSをESXiから使う(2)

XtreemFSに見切りをつけてGlusterFSに戻ってきた。 前回はVMware ESXiからつなぐとデータストアを表示しても何も表示されないままとなってそのうち切断されていたので、ここを調査&修正。 修正版はGitHubにcommit/push済み。(4853f4d) 2016/06/11追記: Makefileがコミットされてなかったりpatchが動かないとかひどいコミットミスがあったから直したよ!! 0118d4d

XtreemFSをFreeBSDで動かす(6) 書き込み速度の改善

どうもFreeBSD+OpenJDKのバグで、Selector.select(int)がタイムアウト前に返ってくる模様。 このせいでMRCやOSDのあるスレッドが空回りしてCPUを食いつぶすことがある。(よくある) これを直してやって、7.4MB/sまで改善した。(前回は6MB/s) # dd if=/dev/zero of=/mnt/xtfstest/test bs=65536 count=4096 4096+0 records in 4096+0 records out 268435456 bytes transferred in 36.120514 secs (7431662 bytes/sec) 2016/05/31追記: 上記はiSCSI+ZFS+SSD ZILでの測定結果。 気になって夜も眠れないので、UFS on SSDにOSDを置いて計ってみたら、6.7MB/sになった。 遅くなってるけど、きっと測定誤差だと信じたい。(だとすると改善も誤差だけど……) # dd if=/dev/zero of=/mnt/xtfstest/test bs=65536 count=4096 4096+0 records in 4096+0 records out 268435456 bytes transferred in 39.965025 secs (6716759 bytes/sec) 正直なところ心が折れそうだけど、GlusterFSは(xattrが必要だから)zfsのzilで加速、とかができないし、微妙に柔軟性が足りない気がするのでもう少しがんばりたい。

XtreemFSをFreeBSDで動かす(5) 書き込み速度測定

またESXi用に使おうと思って、とりあえず書き込み速度を計ってみた。 結果、6.8MB/sという非常に悲しい数字をもらった。 ちなみに、rc.confの記述内容がxstreemfs_*_enableとかになってたので、xtreemfs_*_enableに修正している。