drobo proとVMWareでの実機試験中。都合によりSC430しか空きがなかったので、VMWare ESXi 3(3.5.0, 207095)とDELL Poweredge SC430(Intel Celeron 2.53GHz * 1)にて構築。

間に１つGbEのHUBが挟まっている環境で、iSCSI経由でdrobo proのボリューム(2TB)をマウント、そこに512GB(1MB block)のdatastoreを作成して、その中に32GBのVMを作成した。OSはとりあえずCentOS5.5(i386)。メモリは実装2GB中512MBを割り当てる設定。

OSをインストールして、bonnie++ 1.96をこの辺から拾ってきてインストール、実行してみると、これくらいの結果となった。

正直、このままだと相当遅い。ランダムが遅いのはともかくとして、シーケンシャルでこれはありえない。

で、調べてみるとこの辺に情報が。曰く、Block sizeは8MBにしないとパフォーマンスが出ないよとのこと。それではとボリュームストアをもう１つ作って(こちらは2048GB(8MB block))、そこに同じ物を同じようにインストールしてみた。結果はこちら。

うーん。。ある程度の改善は見られるが、write 27MB/sec rewrite 16MB/sec、Readが48MB/secと、about 85-100Mb/secなどという速度には遙か遠い。読み出しが速い分まだ救いがあるが、ストレージ用途には却って使いづらい。ダブルパリティのRAIDにしているからといって、それってどうなのさ、といいたい感じ。

以前書いたように、drobo proは１台のコンピュータからしかiscsi接続を受け付けない(試しにVMWareで接続中にWindowsから接続してみると認証エラーとなった)。iscsi接続をしていないとdrobo dashboardは動かない(接続準備完了、の画面から進まない)ので、アラートを受け取ることが難しいし、ボリュームの管理もできない。これもちょっとではなく使いづらい。

当初の目論見と違う使い方のほうが都合がよさそうで、もう少し使用法は検討してみる必要がある。場合によっては適当なNASアダプタにUSBでぶら下げてNAS化してしまうのもアリかもしれぬ。だいぶ筐体が大きい割にかっこわるい話ではあるが。もしくはWindowsServer+HyperVというのも手か。

追って調査。

drobo proをVMWareのストレージ用に購入した。早速いじってみたのだが、時間がないのでざくっとレポート。

・proはeliteと違ってiSCSIの設定項目は無い
作成したボリュームがそのまま認証不要で使用可能になる。よってセキュリティが確実でないネットワークで使うわけにはいかなそう。iSCSI用セグメントをつくるべし。ちなみにこのせいかどうかはさておき、proにはVMWare ready certificateはない。

・ボリューム変更は再起動
これは割と落とし穴。ボリュームを削除したり追加するたびに再起動が必要なので、VMWareから使うときは色々気をつかう必要がある。

・BeyondRAIDは結構強固
思い切り簡単なトーチャテストしかしていないが、ダブルパリティに設定後ボリュームを作ってそこに数GBのファイルをiSCSI経由でコピー、コピー中にディスクを１本抜いて少々待ってからもう１本抜いて、その２本を入れ替えて差し込んでリビルドが再開されることを確認したのと、正常状態からディスクを１本抜いて、リビルド中に再度突っ込んでみるということを試してみた。いずれも問題なく認識、データの破損はない。まだ試したいことはあるけれどそれなりに信用していいのではないかと思う。

・転送レートはぼちぼち
NTFS、FAT32いずれでフォーマットしたところで転送レートはさほど変わらず下記のとおり。Windows7よりMS純正iSCSIイニシエータで接続したボリュームにCrystalDiskMark3.0 x64を使って測定。ネットワークはクライアント、droboともにGbE接続、間にはcoregaの安いHUBが挟まっている。Jumbo frameは使っていない。droboはWD20EARS(2TB)が5本、ダブルパリティ。

■NTFS
           Sequential Read :    81.386 MB/s
          Sequential Write :    46.765 MB/s
         Random Read 512KB :    26.711 MB/s
        Random Write 512KB :    22.536 MB/s
    Random Read 4KB (QD=1) :     0.542 MB/s [   132.4 IOPS]
   Random Write 4KB (QD=1) :     0.821 MB/s [   200.3 IOPS]
   Random Read 4KB (QD=32) :     1.397 MB/s [   341.0 IOPS]
  Random Write 4KB (QD=32) :     0.799 MB/s [   195.1 IOPS]

■FAT32
           Sequential Read :    52.293 MB/s
          Sequential Write :    45.468 MB/s
         Random Read 512KB :    28.503 MB/s
        Random Write 512KB :    22.409 MB/s
    Random Read 4KB (QD=1) :     0.596 MB/s [   145.5 IOPS]
   Random Write 4KB (QD=1) :     0.752 MB/s [   183.5 IOPS]
   Random Read 4KB (QD=32) :     1.661 MB/s [   405.5 IOPS]
  Random Write 4KB (QD=32) :     0.745 MB/s [   182.0 IOPS] 

・総評として

割と良い買い物だったように思う。追ってVMWare ESXiにて試験してレポートしたい。

・追記2010/11/27:

複数のホストから同時につなげない様子。正直ZFSを期待したら負け。

結論からいうと、下記許可ルールを追加すると解決する。

ローカル側：UDP 67-68ポート
リモート側：UDP 67-68ポート 信頼ゾーン

非常に気持ち悪いのだが、ひとまず解決策。

追記：
VMWareのIP幅を信頼ゾーンに加えてないと、失敗するかもしれない。未検証。

追追記：
サポートに推奨設定を問い合わせていたが、その返答がきた。曰く、

プロトコル：UDP
方向：内向き
アクション：許可
ローカルポート：68
リモートポート：67

を追加するようにとのこと。これで変なところで引っかからずきちんとファイアウォールを使うことができる。ありがたい。

Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.
The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.
[Fri Sep 26 03:51:51 2008] [notice] child pid 335 exit signal Trace/BPT trap (5)
[Fri Sep 26 03:51:54 2008] [notice] child pid 136 exit signal Trace/BPT trap (5)

あちこち調べた結果、どうもMacPortsの問題としてちょうど俎板の上に乗っている問題で、gdのimagettftext()関数がApacheを巻き込んで死んでしまうということらしい。解決方法はfreetypeのPortfileを持ってきて、コンパイルオプションを変えて手で突っ込めということらしい。

この時点でかなり嫌気が差すが、あきらめてまずfreetypeのPortfileを開く。Portfileはえらく深い階層(/opt/local/var/macports/sources/ rsync.macports.org/release/ports/print/freetype/Portfile)にあったので見つけるのに苦労したが、これの50行目–with-old-mac-fontsをコメントアウトする。

# --with-old-mac-fonts

そしてfreetypeを強制再インストール。

$ sudo port -nf upgrade freetype

次にphp5をもう一度ビルドし直す。

$ sudo port -nf upgrade php5

これでひとまず問題は解決した。portの中身をsyncするたびに元に戻ってしまうので根治療法にはならないが、Macports側の対応がなされるまでの間の手当としては妥当なところだろう。手数も最小限だ。

参考になれば幸い。

dekiwiki8.05.2がリリースされた。フィクスされたバグはChangelogを見てもらうとして、割と困っていたのが「#4292    Templates cannot be added to unsaved pages」。テンプレートを使えば、事務仕事のかなりの部分をwikiへ移管できると目論んだのに、このバグのせいでテンポが悪いことこの上なかったのだ。それと、SWFUploaderもうまく動いていなかったのだが、Changelogにあがっているので直っていればうれしい。

8.05.1から8.05.2への置き換えは簡単。dekiwikiのサービスを停止し、ドキュメントルート以下全てのファイルをバックアップ。ドキュメントルートに8.05.2のweb/*をコピーして、バックアップからLocalSettings.phpとattachments/をドキュメントルートへ移す。全てのファイルのグループとオーナーをapache:apacheへ変更すれば完了。思った以上に簡単に終わって安心した。

アップデートの結果、テンプレートは思った通りにきちんと動くようになった。残念なことに、SWFUploaderがIOエラーで動かない問題は解決せず。もしかするとこれはこちらの手元環境に問題があるのかもしれない。追って調べる必要がある。

追記：ごく一部のボタン類に文字化けがある。UTF8をEUC-JPにしようとして失敗してるんじゃないかなぁと思うような化け方。文字化け判定表はこんなのがある。

• http://nonn-et-twk.net/twk/nondrupal/mojibakeMatrix.html
• http://blog.livedoor.jp/dankogai/archives/50809008.html

たまに便利だ。

追記：バグレポートが上がっていた。こちら。