月曜日 10 06, 2008
- All
- Java
- OpenSolaris
- Solaris
- その他
- 趣味
月曜日 10 06, 2008
ファイルシステムの複写をZFSでおこなう - その２
前回は 全部メインメモリに入ってしまう結果でしたが、追加で入りきらないものを計測しました。 一つの結果に対して３回計測しており、全部終わるまでに74時間以上かかりました。 もちろん一発できれいに行かない（私のスクリプトがへくったのも含めて）ために、 今日までかかってしまいました。 マシンの構成は変わっていないのですが、読み込み側のZFSファイルシステムは StorageTek 3510FCというディスクアレイで、RAID5になっています。 計測方法は前回若干変えています。 まずread onlyですが、gtarの結果があまりにもはやいので不思議に思い、 /dev/nullを直接の出力に指定するのではなく、パイプでcatに繋いでから/dev/nullにおくりました。
gtarはもしかすると出力先によっては処理が違うのかな？と思える結果です。 直接/dev/nullで、パラレルgtarの結果は４分台でした。もう一つは10台のディスクで組んであるRAID5からの読み込みの速度を少しでも上げるために、 tar/gtar/cpioを複数同時に起動するものもやってみました。 これは試験対象ファイルシステムのルートにあるファイルおよびディレクトリに対し一対の スクリプトを同時に実行するという形にしました。 各ディレクトリに含まれるファイルの数や大きさが必ずしも一致しないのですが、 かなり当初の目的は達成できたかなと思います。 今回の対象のファイルシステムは以下の通り158GBでメインメモリのほぼ２倍の容量です。
ファイルシステム サイズ 使用済み 使用可能 容量 マウント先 p1/tst 331G 158G 172G 48% /p1/tst
結果は:
| read only | copy | |||||
|---|---|---|---|---|---|---|
| Real time | User time | Sys time | Real time | User time | Sys time | |
| tar | 2:14:03 | 0:19:55 | 0:38:21 | 5:12:43 | 0:38:47 | 5:10:17 |
| gtar | 2:01:10 | 0:03:38 | 0:41:32 | 2:05:08 | 0:06:32 | 1:27:11 |
| cpio | 2:18:22 | 0:02:45 | 0:41:55 | 3:11:58 | 0:04:13 | 1:02:37 |
| multi tar | 0:56:44 | 0:23:41 | 0:47:22 | 1:50:09 | 0:45:43 | 8:45:35 |
| multi gtar | 0:53:32 | 0:05:03 | 0:55:18 | 0:54:49 | 0:07:14 | 1:40:36 |
| multi cpio | 0:57:46 | 0:04:22 | 0:57:37 | 2:02:38 | 0:08:02 | 2:02:38 |
| zfs send/recv | 1:39:01 | 0:00:02 | 0:31:49 | 1:51:50 | 0:00:04 | 1:14:57 |
なかなか興味深い結果だと思います。 手間をのぞくとzfs send/recvは必ずしも最も早い方法ではないことになります。 zfsはファイルシステムとしてかなり優秀だと思いますが、 zfs send/recvまではマルチスレッドホットになっていないと言うことでしょうね。
「マルチスレッドホット」という言葉最近聞きませんね。 Solaris 2.0開発時によく使っていた言葉で、"multi-thread unsafe", "multi-thread safe"と"multi-thread hot" と確か３種類あって、それぞれ、マルチスレッド環境下で使えない、マルチスレッド環境下で使える、 そして、マルチスレッド環境下でマルチスレッドであることを活かして早くなるということで、 システムの各コンポーネントをどれだけホットにできるかという課題に取り組んでいました。 man pageにMTの属性の説明がありますが、ホットは無いんですね。但しこれは今回のようにCPUの個数に余裕がある場合ということになります。 実際multi tarの結果は実時間の４倍以上のCPU時間を使っている （４つ以上平行に走っていた）ことになり、 CPUもしくはCPUの個数に余裕が無ければ違う結果になっていたでしょう。 また、gtarとmulti gtarのread onlyとcopyの結果を見ると、実時間であまり差がありません （むしろcopyの方がはやいですが、計測誤差の範囲内でしょう）。 詳しく調べないとわかりませんが、zfsのwrite cache/bufferと、 6140Arrayのwrite cacheと、さらに全体の平行動作との組み合わせがうまく働き合い、 書き込みのオーバーヘッドが無いような結果になったのでしょうか？ さらに、multiがこれほど効果的、特にgtarでの結果出たと言うことは、 zfsは複数のプロセスからの同時アクセスに対して効率よく処理できていると思われます。
ここまでくるとディレクトリを作るのがごとくばんばんファイルシステムを作れるzfsで、 ルートディレクトリ単位にファイルシステムを作って複数のzfs send/recvを走らせてみたくなりました。 が、さすがにそこまでは時間がとれないかなー.... ま、この方法が早かったとしても運用方法が変わってしまうのでそのまま比べられませんね。
金曜日 9 26, 2008
ファイルシステムの複写をZFSでおこなう
またしてもZFSを使ったちょっとした試験をしました。
私がこういう試験をするのは社内で利用しているシステムの更新をする時の、 実際の更新までの空いた時間でやっているので毎回違う構成になってしまいます。 今回のマシンも決して新しいマシンとは言えないのですが、もうすぐ実際の運用に回します。今回はすでにZFSを使っていて、 マシン間や新しいディスクアレイに移行する時に どうやって行うが早いのかいろいろ試してみました。 ZFSどうしなら当然zfs send/zfs recvの組み合わせが思い浮かびますが、 果たしてどのくらい他の方法に比べて早いのか？ また、zfs send/recv はリリース間の互換性を今のところ保証していないので、 将来的にマシン間ではできなくなる可能性もあります。 他の方法はtar/gtar/cpioをそれぞれ試してみました。
まずはハードウエアの構成ですが、
となり、サーバは少し古いですが、メモリはたっぷりです。 OSはSolaris 10 + patch です。 ディスクアレーは私のブログに登場する中では珍しく現在販売している最新機種です (^ ^)。 試験は36GBをZFSで3way mirrorにしたファイルシステムにおいてあるものを、 6140のRAID-5に複写するという形で行いました。 結果を見るとわかりますが、この構成の詳細はあまり重要ではありませんでした。 複写したファイルシステムはある製品のソースコードが入っているもので、 およそ 16GB の容量に32万個のファイル（ディレクトリをのぞく）が入っているものです。 16GBということで、このシステムのメインメモリーにキャッシュされると思われるので、 ディスクのI/Oはこのベンチマークにはほとんど影響されない予定です。System : Sun Fire V1280 CPU Type : SUNW,UltraSPARC-III+ * 12 CPU MHz : 900MHz CPU 2nd Cache : 8MB Memory : 86GB Disk : 36GB * 3 Disk Array : StorageTek 6140
各方法の実行の仕方は、
の様になっております。 また、念のために読み込みだけの時間も計りました （上の例では書き込みのプロセスだけを計っていますが、 読み込み時は書き込み先を/dev/nullにして、読み込みのプロセスを計測しています）。tar EcfbB - 1024 . | (cd /${T} ; timex tar xfb - 1024) gtar cfbB - 1024 . | (cd /${T} ; timex gtar xfb - 1024) find . -print | cpio -ocC 524288 | (cd /${T} ; timex cpio -idmlC 524288 zfs send ${SP}@bench | timex zfs recv ${T}
結果は:
| read only | copy | |||||
|---|---|---|---|---|---|---|
| Real time | User time | Sys time | Real time | User time | Sys time | |
| tar | 05:34 | 04:16 | 01:17 | 32:22 | 06:17 | 32:13 |
| gtar | 01:06 | 00:18 | 00:45 | 06:18 | 00:41 | 08:08 |
| cpio | 02:21 | 00:20 | 02:23 | 09:47 | 00:44 | 10:12 |
| zfs send/recv | 00:56 | 00:00 | 00:56 | 04:50 | 00:00 | 06:30 |
ある意味想定通りCPUで頭打ちになっています。 しかし、これほどtarが遅いとは思いませんでした。 というか、gtarって早いんですね。 zfs send/recvが勝ってはいますが、思いの外gtarと近かったです。 ディスクアレイへの書き込みに関しては、StorageTek 3510FCへの書き込み （しかも、RAID-5に使っているディスクの本数も違う）と比べて誤差ぐらいの差しかありませんでしたので、 関係なさそうです。 この中で実時間よりもCPU時間の長い物がありますが、 Solarisのカーネルがマルチスレッドで複数のCPUを効率よく使って結果だと 思っているのですが、確認していません。 とここまで書いて思ったのですが、このマシン、運用に回すまでまだ1,2週間あるので、 もっと大きな（メインメモリを超えるような）ものもやってみようと思います。
水曜日 4 16, 2008
順次アクセスファイルにおけるZFSの性能について その２
およそ一年前にZFSの性能に関して 順次アクセスファイルにおけるZFSの性能について - 日本語 として書いていますが、 今回さらにもう少し性能の良いマシンで試験できましたので報告します。 とはいっても、他部署から譲ってもらった使い古しのマシンで、最新というわけではないです。 前回はx86でしたが、今回はSPARCです。
System : Sun Fire 280R (2 X UltraSPARC-III+) CPU Type : SUNW,UltraSPARC-III+ * 2 CPU MHz : 1200MHz CPU 2nd Cache : 8MB Memory : 8GB OS : SunOS 5.10 Generic_127111-11 Device Size Vendor Model Revision c0t0d0 36.4GB SEAGATE ST336704FSUN36G [1526] 内蔵1 c0t1d0 18.1GB SEAGATE ST318304FSUN18G [0726] 内蔵2 c3t5002 253.5GB SUN T300 [0302] T3B c3t5002 253.5GB SUN T300 [0302] T3B c4t1d0 18.1GB SEAGATE ST318304FSUN18G [1126] A5200前側 c4t2d0 18.1GB SEAGATE ST318304FSUN18G [1126] A5200前側 c4t3d0 18.1GB SEAGATE ST318304FSUN18G [1126] A5200前側 c4t4d0 18.1GB SEAGATE ST318304FSUN18G [1126] A5200前側 c5t17d0 18.1GB SEAGATE ST318304FSUN18G [0726] A5200後側 c5t18d0 18.1GB SEAGATE ST318304FSUN18G [042D] A5200後側 c5t19d0 18.1GB SEAGATE ST318304FSUN18G [042D] A5200後側 c5t20d0 18.1GB SEAGATE ST318304FSUN18G [042D] A5200後側
c0に繋がっているディスクにシステム(OS)がはいっています （運用する時には3way mirrorにする予定）。 c3はFCAL switch経由で2台のT3Bストレージアレイに繋がっていて、 今回はtarの試験の時の元データを此処に入れました。 c4/c5が今回の試験の対象となるJBOD(Just a Bunch Of Disks)です。 A5200という古いJBODですが、FCAL接続なのでまあまあです。 ただし、残念ながらc3/c4/c5すべて1GbpsのFCAL HBAで構成しています (A5200はもともと1Gbpsしかサポートしないですけど）。 システムはSolaris 10 8/07 (U4)で、比較的最近のパッチレベルまで当ててあります (Solaris 10 5/08 (U5)がすでに発表されています）。
前回は特に書きませんでしたが、今回ZFS/UFSを作ったコマンドは以下のようになります。
最近はZFSを使うことが多いので、 SVM (Solaris Volume Manager)でミラーとかRAID 5を組んだ時のめんどくささが際だちました。 SVMで組むとどちらも事実上すぐには使えません。 ミラーはmetattachしたあと同期完了を待たないと、ベンチマークになりません。 RAID 5も初期化完了をまたないとつかえませんが、どちらも結構時間がかかります。 この点ZFSは数秒（それもほとんどの時間は指定されたディスクが他の用途に使われていないか 調べている時間です）で終わるので、これになれるとSVMはつらいです。 しかも、この後newfsをしないと使えませんが、ZFSはすぐ使えます。# ZFS ストライプ (RAID 0) zpool create bench c4t2d0 c5t18d0 c4t3d0 c5t19d0 c4t4d0 c5t20d0 # ZFS ミラー(RAID 0+1) zpool create bench mirror c4t2d0 c5t18d0 mirror c4t3d0 c5t19d0 mirror c4t4d0 c5t20d0 # ZFS RAIDZ zpool create bench raidz c4t2d0 c5t18d0 c4t3d0 c5t19d0 c4t4d0 c5t20d0 # ZFS RAIDZ2 zpool create bench raidz2 c4t2d0 c5t18d0 c4t3d0 c5t19d0 c4t4d0 c5t20d0 # SVM ストライプ (RAID 0) metainit d900 1 8 c4t1d0s6 c5t17d0s6 c4t2d0s6 c5t18d0s6 c4t3d0s6 c5t19d0s6 c4t4d0s6 c5t20d0s6 # SVM ミラー (RAID 0+1) metainit d901 1 4 c4t1d0s6 c4t2d0s6 c4t3d0s6 c4t4d0s6 metainit d902 1 4 c5t17d0s6 c5t18d0s6 c5t19d0s6 c5t20d0s6 metainit d900 -m d901 metattach d900 d902 # SVM RAID 5 metainit d900 -r c4t1d0s6 c5t17d0s6 c4t2d0s6 c5t18d0s6 c4t3d0s6 c5t19d0s6 c4t4d0s6 c5t20d0s6
注意してほしいのは上記の作成方法が二つのコントローラを使った場合の速度的に最適か どうかは私にはわかりません。 過去の経験からなんとなくそうしているだけです。 ミラーなどの場合は安全性からはこれが良いと思ってはいますが。
今回の試験で予想はできたのですが、やっぱりというのが扱うファイルの大きさです。 前回は3.6GBのファイルを使っていたのですが、 今回はメモリが8GBあるマシンだったのでディスクに書き込む時間の計測にはなりませんでした (とくにZFSの場合全部キャッシュされてしまう）。 そこで、同じファイルを三つ足して11GBにして、これをT3B側のZFSにおいて、 複写する時間を計ることにしました。 しかし、やってみてわかったのですが、T3Bからの読み込みがボトルネックになりました。 つまり1Gbps以上の速度で書き込みができるようなのです。 開き直ってファイルを複写するのではなく
で単にゼロの内容のファイルを作ることにしました(mkfileでも良かったかもしれません）。 大きさは前記のファイルと同じにしただけで、意味はありません (メインメモリの容量をはっきり超えればよいはず）。 さらに今回はそれぞれ単独のドライブでの試験もやってみました。dd if=/dev/zero of=file_name bs=1024k count=11037
- ddコマンドでファイルを作成。 都度消しながら３回やった最も短い結果。
- 同様にddコマンドでファイル作成。 消さないで別名にしながら３回やった最も長い結果。
- およそ23GBのtarでアーカイブされたファイルシステムの内容をtarで T3Bから読み込みながら展開。
結果は:
| cp/rm | cp | tar x | |||||||
|---|---|---|---|---|---|---|---|---|---|
| Real time | User time | Sys time | Real time | User time | Sys time | Real time | User time | Sys time | |
| UFS Single drive | 06:22 | 00:00 | 00:57 | ||||||
| SVM/UFS Stripe | 01:34 | 00:00 | 01:14 | 01:42 | 00:00 | 01:22 | 30:44 | 01:53 | 12:51 |
| SVM/UFS Mirror | 02:47 | 00:00 | 01:23 | 03:01 | 00:00 | 01:22 | 41:00 | 02:00 | 13:22 |
| SVM/UFS RAID5 | 45:59 | 00:00 | 01:38 | ||||||
| ZFS single drive | 05:06 | 00:00 | 00:22 | ||||||
| ZFS stripe | 00:59 | 00:00 | 00:22 | 01:19 | 00:00 | 00:22 | 29:40 | 01:48 | 26:47 |
| ZFS Mirror | 02:01 | 00:00 | 00:30 | 02:39 | 00:00 | 00:23 | 30:02 | 01:50 | 27:03 |
| ZFS RAIDZ | 01:24 | 00:00 | 00:22 | 01:49 | 00:00 | 00:23 | 30:48 | 01:50 | 27:02 |
| ZFS RAIDZ2 | 01:57 | 00:00 | 00:22 | 02:44 | 00:00 | 00:22 | 31:22 | 01:51 | 27:15 |
再びStarSuite8でグラフを ちょっと作ってみました：
わかると思いますが、UFS RAID 5の結果はいれてません
（確認の意味でやりましたが、やっぱり桁違いに遅いのでこれしか測定していません）。
今回もほぼ前回と同様の傾向が見て取れますが、 さらに差がはっきりしたように思います。 また、細かく見るとZFSのRAIDZ/RAIDZ2ともにMirrorよりはやいというのは意外に思えます。 しかし、これはミラーでも同じ数のディスクしか使っていない、 つまりストライプの幅が半分くらいになっているのでこれが影響しているだけかもしれません。 ミラーが単純ストライプ(RAID 0)の倍くらいの時間という結果も、 ストライブの幅の影響と思えなくはないです。 今回も前回と同じ反省点があります（進歩していない (X X)）。 表を見てもCPUの時間に差がありません。 つまり、SVM/UFS/ZFS/ZPOOLに費やされているCPUの時間が計測されていません (%ですけどtimexコマンドの"-s"で計れそうです）。 tarコマンドの結果に関しては残念です。 ほぼ間違いなくデータの送り側であるT3Bの1GbpsのFCALがボトルネックで、 書き込み側の時間に測定になっていないと思われます。 もし、経過時間に使用したトータルなCPU時間が計測できていれば少しは意味のある データがとれたかもしれませんが、このままでは意味がありません。 UltraSPARCIII+@1.2GHzのシステムで1Gbps FCALの限界をファイルシステムの書き込みで こんなに簡単に超えるとは思っても見ませんでした。
今回の結果をだけを見るとZFSのRAIDZ2をJBODの場合には多用したいと私は思いますね。 速度的にはUFSやZFSのミラーよりも早く、容量的な制限が少なく、 可用性に関しても充分 （もちろんHBA丸まるとかの場合を考えるとミラーしかないですけど） といったところでしょうか。 もちろん用途によりますけど、かなり多くの用途で通用しそうです。
水曜日 3 26, 2008
ZFSを使ったNASの製品が出荷されています！
びっくりしました。 なんとZFSを使ったNASの製品というのがすでに出荷開始されています。 サンからではなくコア・マイクロ・システムズさんというところなのです。 いろいろNAS関連の製品を出されているようなのですが、 その中で最新の製品が NetFiler ZFS シリーズということです。 システムはSolaris 10を使い、CPUはx64とまで書かれていますがどのx64かまでは書かれていません。 これ以外のNASの製品はWindows Storage Serverを使っておられるようですが、 これからは？Solarisということなのでしょうか（だとなおうれしいです）。 うーん、すばらしい！
ZFS NAS product has been shipping in Japan!
ZFS NAS product has been shipping in Japan!
Breaking news !? ZFS based NAS product has start shipping in Japan. But not from Sun, from Japanese company called Core Micro Systems Incorporated. I can not find any English translated materials yet, but at least you could see the some of the table and chart here. System is based on Solaris 10, and CPU are appear to be x64 based (but does not say exactly which). They must to know something good in this industry :-) (this company has line of NAS products, and other product line are based Windows OS).
火曜日 3 18, 2008
第5回Solaris夜間講習会
先日 Solaris Night Seminar 5th 〜 〜 ユーザ管理・認証編 〜 〜 を 当社の神宮前のオフィース で開催しました。 昨年からはじめまして( 第一回は昨年４月 でした)まだ５回目と思われるかもしれませんが、 毎回申し込みがいっぱいになり追加開催の要望が多く、 同じ内容でリピートも開催されているのでその倍はやっていることになります （もちろん内容はまだ５種類目ですが :-)。 毎回申し込みがいっぱいになるという問題点と用賀という場所がやはり遠いという方のために、 最近は神宮前のオフィースも使うようにしています。 神宮前は山手線内にあるという地の利と、 講習会会場が広く100人以上の方に一度に入って頂くことができます （用賀は60人はいるとかなりきつい感じになります）。
主催者としては全員用賀のオフィースにいるのでちょっと不便なのですが。今回も90人近くの方において頂き盛況でした。
当日の資料はまもなく講師である舟崎さんの Funasaki's Weblogで公開されるはずです。 また、初級編だけではなく最新の情報も提供できるようにと Solaris/OpenSolaris Hot Topics セミナー（これはすでに終わっている講習会の案内ですが）も最近はじめました。 どちらの内容も当日のアンケートや質疑応答の内容を参考に先の予定を決めていますが、 今後は OpenSolarisユーザ会のメイリングリスト などでもぜひ意見を出して頂いて決めていきたいと思います。 単にこれが知りたいとか、今こういう事で困っているとか、 あるいは自分はこういう事を知っているので是非しゃべりたいとか。 様々な意見が出ることを期待しています。
水曜日 12 19, 2007
Linux ゼロ、Solaris ヒーロー！
おもしろい記事がありました。 Linux defector says RHEL zero, Sun Solaris hero。 このサイトは今まで見たことはなく、社内で回っていたメイルで初めて知りましたので、 どのようなサイトなのか、どのくらい読まれているのか（あるいは日本語訳があるのか） 全然わからないのですが、興味深く読ませて頂きました。 UnixからLinuxへの転向が多いと言われる昨今、 我々の所ではこの記事のように逆の話もきかれます。 Solarisエバンジェリストだから書くともいえますが、 Linuxはどちらかというとブームであって、 確かに取っつきがよく、それなりによくできています。 しかし、長年厳しい現場で鍛えられてきているSolarisはLinuxとは違う面で評価されるところが多いのも事実だと思います。 今回の記事のようにLinuxを長年使っていたけれども、 Solarisを使ってみるとLinuxでの問題点が解決されるという話は考えられる話です。 Solarisは取っつきにくさを無料かつオープンソースにすることによって取り払ってきましたが、 実際のInstallや最初に使った時の感じなどまだ残された問題も少なくありません。 しかし、プロジェクトIndianaはこれすらも取り除くプロジェクトですのでさらに期待が持てます。
月曜日 10 22, 2007
ネットワークなしでSunRayサーバソフトウエアのインストール
ひょんな事からSunRayのサーバソフトウエアをネットワークのない環境を前提に インストールすることになりました。 まあ、デモためにインターネットやイントラネットに繋がっていなくても SunRayが使える環境が必要になったのです。 もっとも、NotePCでイーサネットが一つしかなく、 他の環境に影響を及ぼさないようにする必要があったともいえます。 あまり参考になる人は多くないかもしれませんし、 私が見つけた方法よりも良い方法があるとは思いますが、 せっかくの経験なので書かせてもらいました。
SunRayはネットワーク端末とも言われていますから、 ぜんぜんネットワークがないわけではなく、 SunRay端末を使うためのネットワークは当然あるわけですけど。
-
当初軽く考えていました。
やったことは
- NotePC にネットインストールでSolaris 10 8/07 (update 4)をインストール (SunRay用に十分パーティションに余裕があるように、特にスワップ）。
- update managerを使って、システムを最新のパッチレベルに更新。
- 最新のsrss4.0(SunRay Server Software4.0)のイメージををNotePCの/var/tmpに複写。
- sys-unconfig(1M)を使ってシステムを落とす。
- ネットワークからはずし、システムを再起動。
- ネットワークに繋がっていない状態にシステムを設定。
- ルートで（というかルートしかない）ログインをして、 複写しておいたsrssをutinstallを使ってインストール。
-
utconfigをやって、utadmでネットワークを追加....しようと思ったところで
エラーです。
srssは良くできていて、utinstall/utconfig/utadmを実行すれば、 今回のような特殊な環境でなければ設定終わりです。 実に簡単にSunRayが使える環境が構築できます。
- そこで、適当なアドレスを書いておいてあとで消すとか、 いろいろ小細工をしたのですが、 dhcpのマクロでこのホストアドレスがしっかり書かれてしまい、 到達できるアドレスでないとうまくいきません。 一つ一つ手で書き直せば何とかなるのはわかったのですが、 何台どのアドレスにSunRayが繋がるかわからず、 全部直すのは面倒だったので、別の方法考えました。
- この場合のSunRayの設定はSunRayのホストとしてのアドレス （インターネット/イントラネットなどに繋がっている前提）と、 SunRayファブリック（SunRay端末専用ネットワーク）が必要となります。 SunRayファブリック側はutadmがローカルアドレスを適当につけますので、 そのまま使えますし、実際設定をしてくれます。 これに使われるSunRayサーバのアドレスをそのままホストのアドレスとして 使えればよいのですが、どうもそれはutadmが許してくれません。 そこで、念のために同じサブネットアドレスだけど違う番号をもったIPアドレスに ホストをしてしまいました。 これでutadmは通るのですが、実際にSunRayをつなぐと動きません。 どうも、dhcpサーバの動きが変です。
-
dhcpサーバはホストのアドレスが実際に動いていないとだめなようです。
そこで、SunRayファブリックにも使うNotePC唯一のインターフェイスに
２番目のアドレスとしてホストのアドレスを設定するように/etc/hostname.*
を書いてリブートしました。
# echo "srss40plus" > /etc/hostname.iprb0:1
木曜日 7 19, 2007
docs.sun.comの検索が直りました
サンの特にソフトウエアの製品を使っている人は docs.sun.com をよく利用して頂いていると思いますが、 最近まで日本語で検索ができないと言う情けない状態でした。 一般のインターネット検索エンジンで検索した方が良い位言われてしまったのですが、 やっと直りました(^O^)/ また、日本語のフォントがSolaris上では適切ではない状態だったのですが、 これもスタイルシートの修正が入って直っております。 今まで不便だと思っていた方は是非この機会に再度試してみてください。
別に私がなおしたわけではなく、別の部署のひとと当部が協力してなおしたのですが、 アナウンス見たいのはまだ見ていないので、とりあえずお知らせです。
木曜日 4 26, 2007
追追々記：第1回Solaris夜間講習会
学習できていないみたいで申し訳ないのですが、 追加で同じ内容をもう一度やらさせてもらうと言うことで、 書きました が、 すでに満員御礼になってしまいました。 スタッフ一同うれしい悲鳴をあげております。 さて、今晩はその本当の意味での第一回です。
水曜日 4 25, 2007
追々記：第1回Solaris夜間講習会
第1回Solaris夜間講習会が満員御礼になりましたと 書きました が、 その後の問い合わせも続いてきておりましたので、 急遽同じ内容の物をもう一度行うことにしました。 来月である５月８日（連休明けすぐ）で、 初歩の初歩！そもそも Solaris ってどういうもの？ となっています。 もし、前回検討したけど満員だったという方が周りにいらっしゃいましたら、 教えてあげてください。
昨日予行演習を舟崎さんがやりましたが、歴史のところでやたらと盛り上がりました。 どうも創世記のUnixを知っている人間同士で勝手に盛り上がってしまってそのままやると、 深すぎるのでとりあえずそこそこに押さえてもらうようにしましたが、 もっと知りたい方は当日つっこんでもらえればいろいろお話はできると思います。 最初に書いた 様に、 通り一遍の講習会ではなく、きて頂いた皆さんの質問や、意見を取り入れながら、 わいわいとやれればと思います。 質問の多い方、今後こういう内容をやってほしいと思っている方、歓迎です。
金曜日 4 20, 2007
用賀だより - 6 八重桜2
やっぱり八重桜1でしたから、今回は八重桜2です (^ ^;)。
今朝自転車で走っていると砧公園で八重桜満開（もしくは８分咲き？）だったので、
期待をして馬事公苑にいってみると。
なんと乗馬をしている人がいるではないですか。
あわててカメラをだすと、１枚目は失敗しましたが、
２枚目はまあまあでしょう。
前回よりも色の濃い花がありましたので、
あと今週気になったのは藤です。
今日通った時にどこだか忘れてしまったのですが、
木は小振りなのですが、とてもきれいに咲いているのがありました。
また、今朝激坂の下にある日産の教習所の中でもきれいに咲いていました。
八重桜の結構後に咲くと思ったのですが....砧の藤はまだでしたけど（咲き始め）。
それと、つつじも結構咲き始めていますね。
月曜日 4 16, 2007
追記：第1回Solaris夜間講習会
びっくりしました。 先週の金曜日に案内 させて頂いた 初歩の初歩！そもそも Solaris ってどういうもの？ ですが、もう満員御礼です。 うれしい限りです、申し込んで頂いた方、また、私のブログを読んで紹介してくれた方、 ありがとうございます。 Solarisの夜間講習会は初めてなので、不安だったのですが、あたりだったのでしょうか？ 問題はなにがあたりだったのか？企画の内容、今だからSolarisをはじめたい人が多いのか？ 舟崎さんにあいたいのか (^ ^;)？ 当然当日きて頂ける方からはいろいろ意見を聞かせてほしいのですが、 今回は行かないけど基本的には興味がある、申し込もうと思っていたのに締め切られたから、 もう一回やってほしいとか、いろいろ意見を頂ければと思います。 このブログにコメントを残して頂いても良いですし、 もともとの案内のページ の問い合わせ先にメイルをして頂いても良いですので、 ぜひ声をお聞かせください。
金曜日 4 13, 2007
第1回Solaris夜間講習会
準備の様子を見ていた方としてはいろいろあってやっとという感じなのですが、 いよいよJavaに続いてSolarisエバンジェリストグループも夜間講習会を開きます。 NSUGさんが最新の情報などに関しては がんばってくれているのでこちらは初心者コースとして、 初歩の初歩！そもそも Solaris ってどういうもの？です。 しかも講師は若手のホープ舟崎さんです。 新人の頃にわからなくて苦労した経験がまだ新鮮な人のほうが、 これから学ぶ人が気持ちがわかるのではないかと言うことです （わたしなんかだとうん十年前の記憶でまったく役に立ちませんから）。 当日は私も後ろからつっこみ^h^h^h^h応援しにいきます。
おそらく私のブログを読んで頂いている方はSolaris初心者という場合は少ないと思うのですが、 これから学んでほしいという方に是非紹介してあげてください。 また初回にきて頂いた方々の意見によって２回目以降の開催内容を調整していく予定ですので、 こういう内容をやってほしいという方もぜひいらしてください。 最後のQ&Aもしくはその後でもざっくばらんに意見交換ができたらと思います。
月曜日 4 02, 2007
順次アクセスファイルにおけるZFSの性能について - 日本語
ZFSの評判は未だに衰えないようですが、 私の方でも少しまた性能に関して計ることができたので報告します。 以前 ソフトウエア開発環境におけるZFSの性能について - 日本語 として一度書いていますが、 マシンの性能とか、今となっては古いビルドになっているとか、 ありますので、再度、でも、違う内容で計りました。 これは此処で報告するために計ったと言うよりも、実際に使うためにどうしようかと いう事ではかっているので、にたような環境で使う人がいましたら参考にしてください という感じでしょうか。
さて今回は引っ越しをした時に、 立ち上げを少し時間かけても仕事に大きく影響しないマシンを使って、 より良い環境になるはずだと言うことでやってみた件です。 それは社内にCD/DVDを焼くために用意しているマシンで以前からx86のSolarisマシンで おこなっています (古くはSS2->SS10でした）。 これを以前はSVM(Solaris Volume Manager, metaなんとかコマンドで使うやつ）とufsで 運用していたisoイメージを一時的におくためのファイルシステムをZFSに移行するのに、 どういう構成にしようかな？ということです。 ですから、順次アクセスファイルを早く書き込めることがポイントになります （読みは現状でも十分早く、DVD2台、CD3台同時書き込みでも問題なることはまずありません）。
またしてもだれも使いたがらないような古いマシンから組んでいるので 今回も今の標準では非力なマシンです （といってもこの仕事をさせるのには十分な速度は持っています）。
5.10 Generic_125101-02 i86pc Intel(r) Pentium(r) III : 750MHz : L2 256KB Memory size: 768 Megabytes Device Size Vendor Model Revision c0t0d0 0.0GB HL-DT-ST DVDRAM GSA-4082B [A204] c1t0d0 0.0GB HL-DT-ST DVDRAM GSA-4082B [A204] c2t1d0 18.1GB SEAGATE ST318203LSUN18G [034A] c2t2d0 18.1GB SEAGATE ST318404LSUN18G [4207] c2t3d0 18.1GB SEAGATE ST318404LSUN18G [4207] c2t4d0 18.1GB SEAGATE ST318203LSUN18G [034A] c3t1d0 18.1GB SEAGATE ST318404LSUN18G [4203] c3t2d0 18.1GB SEAGATE ST318404LSUN18G [4207] c3t3d0 18.1GB SEAGATE ST318203LSUN18G [034A] c3t4d0 18.1GB SEAGATE ST318203LSUN18G [034A] c4t1d0 0.0GB GENERIC CRD-BP4 [4.31] c4t2d0 0.0GB GENERIC CRD-BP4 [4.31] c4t3d0 0.0GB GENERIC CRD-BP4 [4.31]
ディスクは2940UW２枚にそれぞれMultiPackに入ったつないだもので、 本体同様結構古い物です。 Solarisは10で、FCSの物からずっとパッチを当て続けて運用しています （3/12/2007の時点で最新）。 もともと以下のようにSVMとufsでファイルシステムは組んでありました。
d9 m 50GB d10 d11 d10 s 50GB c2t2d0s2 c2t3d0s2 c2t4d0s2 d11 s 50GB c3t2d0s2 c3t3d0s2 c3t4d0s2
今回の試験で主に対象としたのは実際に使うDVDのイメージです。
そして試験の内容は：% ls -l nv_iso_nvx_dvd_55b_solarisdvd.iso -rw-r--r-- 1 root 3857448960 Mar 14 16:05 nv_iso_nvx_dvd_55b_solarisdvd.iso %
- 対象のファイルをNFS越しに（結果が安定しませんが、実際にこうやるので）複写。 消しながら３回やった最も短い結果。
- 同様に対象のファイルをNFS越しに（結果が安定しませんが、実際にこうやるので）複写。 消さないで別名にしながら３回やった最も短い結果。
- およそ20GBのufsdumpされたファイルシステムの内容をやはりNFS越しにufsrestore (ufsrestoreという名前ですが、ファイルを戻す時は通常のAPIで書き込むので 書き出されるファイルシステムはZFSでもよい）。
結果は:
| cp/rm | cp | ufsrestore | |||||||
|---|---|---|---|---|---|---|---|---|---|
| Real time | User time | Sys time | Real time | User time | Sys time | Real time | User time | Sys time | |
| UFS Mirror (new) | 09:52 | 00:00 | 01:38 | 09:52 | 00:00 | 01:41 | 01:01:26 | 02:13 | 18:24 |
| UFS Mirror (half full) | 09:50 | 00:00 | 01:41 | 09:51 | 00:00 | 01:42 | |||
| ZFS stripe (new) | 06:36 | 00:00 | 01:05 | 06:36 | 00:00 | 01:02 | 00:40:15 | 02:34 | 13:23 |
| ZFS Stripe (half full) | 06:35 | 00:00 | 01:03 | 06:36 | 00:00 | 01:03 | |||
| ZFS Mirror (new) | 06:33 | 00:01 | 01:09 | 06:32 | 00:01 | 01:08 | 00:41:47 | 02:36 | 13:54 |
| ZFS Mirror (half full) | 06:32 | 00:01 | 01:08 | 06:32 | 00:01 | 01:08 | |||
| ZFS RaidZ2 (new) | 07:57 | 00:00 | 01:00 | 07:57 | 00:00 | 01:00 | 00:49:09 | 02:35 | 12:59 |
| ZFS RaidZ2 (half full) | 08:08 | 00:00 | 01:00 | 08:03 | 00:01 | 01:00 | |||
前回同様データをこのままみるのは見づらいのでStarSuite8でグラフを ちょこっと作ってみました：
細かいことを抜きにすればだいたい予想通りですが、 Raidz2でもufs mirror(raid1)よりはやいというのは良い結果です。 (new)と(half full)はファイルシステムがいっぱいになってくると 遅くなるというファイルシステムでは無いことの確認です。 ZFSの結果ではストライブとミラーの結果があまり大差はないので、 ミラーのプロテクションが容量を除けばただ同然であることが確認され、 当初の目的としてはZFSのミラーで行くという結論になりました。
今回も気になるのはCPUの時間です。 前回はZFSの性能がかなりCPUの速度に制限されていたように思いますが、 データを見る限り今回はそうは見えません。 しかし、此処では書かれていないデータとしてこの実験をしている間 ずっとiostatでディスクの動きとCPUに動きを見ていましたが、 ZFSの場合は70%位常にCPUが忙しかったのに、 此処出ている(timex コマンドでみています）結果には反映されていません。 なんとなくtimexコマンドではかれるシステムタイムがZFSの場合、 計りたい内容をはかっていないように思われます (ZFSがこのcpコマンドの実行に使っているCPUタイムが全部計測されていない？）。 このことからもしかするとまだCPUの制限を受けている可能性がありますが、 実は今回はネットワークに主に制限を受けています。 単純な計算ですが、3.8GBのデータを100Mbpsのネットワークで移動すると だいたい６分かかることになります。 そうするとNFS/ZFS/ディスクによるオーバヘッドは今回ほとんどない ことになり、かなり良い結果といえます （NFSサーバは8GB積んでおりGigabitEthernetですが、 このクライアントはFast Ethernet/100Mbpsです）。
もう一点、上の表では現れていないのですが、 ZFSの結果はUFSのものよりもふれが大きいです。 何に影響されるのかまではつかめていないのですが、 UFSに比べても結果のふれ具合が大きくなる点が気になります。 最悪の結果を持ってしてもUFSに楽に勝てるのですが、 なぜふれるのか知りたいところです。 もっとも、ZFSは特にパフォーマンスに関しては発展途上でどんどん変わっていく 予定なので、 今わかってもあまり意味をなさないかもしれませんが。
今回も簡単な試験しかできませんでしたが、 ZFSの優位性が証明できたと思います。 此処には書いていませんが、速度以外の利点はそのままに、 速度のメリットも発揮されると言うことで、 機会を見つけるたびにZFSに移行していこうと思います。