前回の続き。
結局FreeBSD 9.3-RELEASEにしたら直った。
FreeBSD 10.0以降のiSCSI Initiatorがおかしいか、相性が悪いかのどちらか。
パケットキャプチャの結果があるから後者もあるとは思うが、余計なバグを踏まされたので前者も疑わしい。
前回の続き。
結局FreeBSD 9.3-RELEASEにしたら直った。
FreeBSD 10.0以降のiSCSI Initiatorがおかしいか、相性が悪いかのどちらか。
パケットキャプチャの結果があるから後者もあるとは思うが、余計なバグを踏まされたので前者も疑わしい。
iscsi initiator+gjournalが固まるからの続き。
カーネルデバッグは敷居が高すぎて早々に諦めつつ、iSCSI+ZFSは使いたいので調査継続。
どうやらiSCSI TargetであるQNAP NAS、中身はLinux LIOが怪しい気がする。
8/8追記: iSCSIのCmdSNとInitiator Task Tagに関して誤りがあったので訂正。
前回からの続き。
VMを使えばシリアルポートなんて簡単に接続できることに、いまさら気づいた。(始めてから2週間くらい)
機材そろえちゃったよ……。
気を取り直して、ハマっているbio(I/O)を探してみる。(そしてこれもうまくいかなかった。)
もたもたしてたらFreeBSD 11.0-BETA2が出てしまった。
この前から続けて、最後に試したFreeBSD 11.0-BETA1なシステムでiSCSI+zfsがハマる原因を調べる。
(一応書いておくと、9.3-RELEASE, 10.1-RELEASE, 10.3-RELEASEのいずれでも発生している。)
iscsi initiator+gjournalが固まるというのを前に書いた。
しかしどうやら、負荷のかけ方によっては、
にも同じように固まることが分かった。
この状態ではまると、gstatで問題のデバイスがキュー長が非零のままで止まり、いつまでたっても解消しない。
そして 、こっちのほうが困るのだが、再起動ができなくなる。panicですら自動再起動できずに止まる。カーネルのコアも吐けない。
マシン固有の問題か、それともほかのなにかか。同じ型番のマシン複数で起きてるから、個体のバグではなさそう。
とりあえずは環境を別のマシンに移して起きるか確認して、あとはシリアル経由でカーネルデバッグかな……。
図らずも一台のデータを壊してしまったので嬉々として復旧実験。
ノード自体は生きているが、brickの中身を壊しちゃったという場合の話。
参考にするのはGlusterFSの公式資料。
service stop
だと子プロセスが残るのでkillallしてくださいな。# service glusterfsd stop # killall glusterfsd
newfs
とかmount
まで済ませる。# 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
# service glusterfsd start # gluster vol heal <ボリューム名> full
disperseならNFSでマウントしてから、
# find <マウント先> -exec stat {}\;
などで復旧を開始。
おわり。
標準のsetextattr
だと文字列しか設定できない。
一応バイナリ(表示不可文字)も引き数に設定できるものの、万が一”00″が入ったらダメ。
たとえば、こんな風に消えてしまう。(これだけだとperlの責任が否定できないけどね)
# echo -n "110022" | perl -e 'print pack("H*",);' > a # hexdump -C a 00000000 11 00 22 |.."| 00000003 # perl -e 'print $ARGV[0]' `cat a` | hexdump -C 00000000 11 |.| 00000001
そんなわけでsetextattrbinを作ったのです。
実運用を想定して、ESXiの仮想マシンを乗っけてdd
で計ってみた。
結果は大体20MB/sくらいは出ているのでセーフな範囲。もう少し速いとうれしい。
速度を気にするならstripeも測るべきだけど出てこないのは、またバグっぽいものを見つけたから。
こっちはまた追ってまとめる。
glusterfs環境のパフォーマンステストのため、iscsi initiatorでNASに接続している/dev/da*
に、gjournal label
でローカルなSSDをjournalとしてくっつけた。
newfs
はうまくいってmount
、gluster volume create
してgluster volume start
、と思ったら固まってしまった。
いろいろ条件を変えて速度測定したかったのになぁ……。
どうも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で加速、とかができないし、微妙に柔軟性が足りない気がするのでもう少しがんばりたい。