やっぱり Sun がスキ! : Weblog やっぱり Sun がスキ!

やっぱり Sun がスキ!

http://blogs.sun.com/yappri/date/20080423 2008年 4月 23日 水曜日

StarCalc を使ってみませんか。

Windows にはオフィスソフトとして、Microsoft Office があることを皆さんはご存じかと思います。
では Solaris にも同じようにオフィスソフトで、StarSuite というものがあることをご存じですか。

SOURCENEXT StarSuite 8
http://www.sourcenext.com/products/starsuite8/
サン・マイクロシステムズ StarSuite 8
http://jp.sun.com/products/software/starsuite/

この Blog を見られている方は基本的に Solaris を好まれている方だと思いますので、StarSuite の名前は
ご存じかと思いますが、Windows でも使用できるこの StarSuite を実際にどのくらいの方がお使いになられて
いますでしょうか。
StarSuite の特徴は、Microsoft Office との互換性があり、Microsoft Office で作った Excel や Word の
ドキュメントを StarSuite で読み込み修正することも可能ですし、逆に StarSuite で作成したドキュメントを
Excel や Word 形式に保存することも可能です。
このようなすばらしいオフィスソフトをもっと皆さんに使って頂きたいと思い、今回は StarSuite の中でもよく
使うだろうと思われる表計算ソフト StarCalc を使って Excel の機能を StarCalc でも使えることを確認したいと
思います。

列(行)をグループ化させて、その列(行)を簡単に表示/非表示させる。

よく、表を作っていると列(行)が 10 も 20 もなることがありますよね。
こんな感じです


そのようなとき、ほとんど変更しないような列に対して一時的に消したいというようなことありませんか。
特に列の左側がメニュー項目(名前等)になっていて、右端の列にあるデータに対して追加や修正をしないといけない
ときには途中にある列が邪魔になります。


こういった場合は、ほとんどの方は左側の列を固定させてから、右側にスクロールさせて対象列に行くと思います。
【ウィンドウ】メニューで固定を選択 スクロールバーで対象列までスクロールさせる


でも途中の列が無くメニュー項目のすぐ横に対象列がきていると作業が楽になると思います。
そんな時に役に立つのが 列(行)の表示/非表示機能です。

手作業で行う場合には、非表示にさせたい例を選択して右クリックをします。サブメニューが表示されるので、
"表示しない"を選択すれば不必要な列は一時的に非表示にすることができます。逆に表示させたいときはサブ
メニューから"表示する"を選択します。
不必要な列を選択して右クリックで
サブメニューを開いて"表示しない"
を選択する
不必要な列が一時的に消えます 再表示させたいときは表示していない
列を囲んでいる列を選択してサブメニ
ューより"表示する"を選択する

しかしこのやり方でも毎回不必要な列を選択する作業が発生します。

ではもっと簡単な方法はないのか...ということで列(行)をグループ化することによってこの作業が簡単になります。
設定方法は不必要な列を選択します。(これは上で書いた内容と同じです。)
次にメニューバーの【データ】→【アウトライン】→【グループ化】を選択します。
(または F12 キーでも設定されます。)


すると列の上部にラインが現れて、そのラインの左側に【-】ボタンが表示されます。これで設定は完了です。


これらの列はグループ化されました。では実際に列を非表示にしてみましょう。
左側の【-】ボタンを押すだけで、列が消えてしまい【-】ボタンが【+】に変わりました。


今度は列を元に戻してみます。【+】ボタンを押せば非表示されていた列が表示されました。
この設定は行に対しても有効ですので、皆さんもご活用ください。




絶対参照をすばやく設定するショートカットキー

次にセルに対して数式を作るときによくセル参照を使うことがあると思います。

【セル参照】
セル参照とは、よく数式を作るときにセルに直接値を埋め込まず、違うセルを参照させるようにすることがある
思います。 例えば A1 と B1 のセルの値を C1 セルで足し算する。
     この C1 セルで見ている A1、B1 セルのことをセル参照と言います。


通常このセル参照はコピーをすると参照先セルのアドレスが変わります。
このセル参照のことを相対参照と言います。
C1 の "=A1+B1" の数式を C2 にコピーしたことによって
"=A2+B2" に変更されました。

逆にコピーしても参照先セルのアドレスが変更しないセル参照のことを絶対参照と言います。
絶対参照にするためにはセル参照のアドレス部分(A や 1 のこと)の左に "$" をつけます。
C1 の "=$A$1+B1" の数式を C2 にコピーしても
"=$A$1+B2" のように A1 セルのアドレスは変更


上記の説明で相対参照と絶対参照を理解できたと思います。
ここからが本題ですが、この絶対参照ですが、上記にも記載しましたが設定するのにセルのアドレスの前に "$" を
つけなければいけません。
では皆さんはこの "$" をつけるのにどうされていますか?ほとんどの方は直接セルを修正して "$" を追加している
のではないでしょうか。
修正する数式が少なければ特に面倒なことではありませんが、数式が多い場合には手間がかかる作業だと思います。
そこでこの "$" を簡単につける方法がありますので紹介致します。

方法は以下のようになります。
対象セルを選択して【Shift-F4】を押せば絶対参照になります。
・押す回数によって絶対参照の対象が変更します。(通常は 4回押せば元に戻ります。)
  A1 → $A$1 → A$1 → $A1 → A1
・シート名が数式にある場合(シートを跨いだセル参照)はシート名も絶対参照の対象になります。
(元に戻すのに 8回必要になります。)
  シート名.A1 → $シート名.$A$1 → $シート名.A$1 → $シート名.$A1 → $シート名.A1 →
  シート名.$A$1 → シート名.A$1 → シート名.$A1 → シート名.A1
・対象をセル全体でなくあるセル("=A1+B1"の A1 だけ)だけ絶対参照にしたい場合は、絶対参照にしたいセルを
  選択することになります。



すばやく必要なセル範囲を指定する方法

よく StarCalc(Excel) を使っていて 1列100個(A1 ~ A100)のデータを集計する場合に SUM 関数を使ってデータ
範囲を指定すると思います。ではそのデータ範囲の指定方法ってどうされていますか?
通常は A1 に選択してからマウスを押したままカーソルを A100 まで持って行ったり、A1 を選択した後、スクロール
バーを下に引っ張って A100 セルを【Shift】キーを押しながら選択したりすると思います。
カーソルを A1 にあわせてマウスボタンを押したまま下に引っ張っていきます。 カーソルが A100 まできたらマウスボタンを離します。


この動作も簡単にする方法があります。
まず、A1 セルを選択するのは同じですが、その次の動作で Shift と Ctrlキーを押しながら下矢印キー
【Ctrl+Shift+↓】を押します。そうすれば一気に A100 までのデータを選択してくれます。
この処理は行に対しても有効ですし、100行x100列の範囲に関しても有効です。
はじめに 1列目を【Ctrl+Shift+↓】で全選択して、そのまま Ctrl と Shift キーを押したまま右矢印キー
【Ctrl+Shift+→】を押します。
見事 100列x100行のデータを選択することができました。


今回はこれだけです。
このような機能は Excel を使いこなせている人は当たり前のかもしれませんが、Solaris で StarSuite を使っている方
にとっては目新しいことではないでしょうか。
すべてを試したわけではありませんが、StarCalc でも Excel と同様の機能が使えることをご理解頂けたと思います。
皆様が今後 StarSuite を使うための足ががりにでもなれば幸いです。
今後もこのようなちょっとした活用術を記載していきたい思います。


http://blogs.sun.com/yappri/date/20080421 2008年 4月 21日 月曜日

CPU Caps 機能の動作を確認してみました

今回は、今月公開された Solaris 10 5/08 で新たに追加された Solaris コンテナの CPU Caps 機能に関して紹介します。

CPU Caps とは、コンテナに割り当てたれた CPU pool 内のリソースに対して使用制限を かける事ができる機能です。

では実際に動作を検証してみましょう。
検証環境は、8 CPU のサーバ上に作成したコンテナ (test-zone) に対して、4 CPU 分 のリソース使用制限を設定します。

[設定方法]
CPU Caps の設定は、ゾーン設定コマンド zonecfg 内で "set ncpus" にて制限を かけたい CPU 数を指定します。
# zonecfg -z test-zone
zonecfg:test-zone> create
zonecfg:test-zone> set zonepath=/export/zone/test2-zone
zonecfg:test-zone> add capped-cpu
zonecfg:test-zone:capped-cpu> set ncpus=4
zonecfg:test-zone:capped-cpu> end
zonecfg:test-zone> commit

CPU Caps を設定し、info で値を確認すると以下のように表示されます。
zonecfg:test-zone> info
zonename: test-zone
zonepath: /export/zone/test-zone
brand: native
autoboot: false
bootargs: 
pool: 
....
....
capped-cpu:
        [ncpus: 4.00]
rctl:
        name: zone.cpu-cap
        value: (priv=privileged,limit=400,action=deny)

[動作検証]
設定ができた所で、実際に zone を作成して負荷をかけてみます。 まずは、mpstat コマンドにて zone 内に CPU が 8 個存在している事を確認します。
test-zone# mpstat
CPU minf mjf xcal  intr ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
  0   12   0  212   285  182   54    0    1    2    0   149    0   1   0  99
  1    2   0   21    15    0   28    0    0    1    0   112    0   0   0 100
  2    1   0    4     9    0   15    0    0    0    0    87    0   0   0 100
  3    1   0    5     6    3    6    0    0    0    0    75    0   0   0 100
  4    9   0   57    24    0   66    0    1    1    0   195    0   0   0  99
  5    1   0   15     6    0   11    0    0    0    0    95    0   0   0 100
  6    1   0    2     2    0    2    0    0    0    0    74    0   0   0 100
  7    1   0    1     1    0    0    0    0    0    0    62    0   0   0 100
ここで、CPU リソースを大量消費するプロセスを dd コマンドで 9 個起動します。
test-zone# ps -ef | grep dd
    root  1723 28721   0 17:16:45 pts/2       0:00 grep dd
    root   587 28721   4 17:14:28 pts/2       1:00 dd if=/dev/zero of=/dev/null
    root   675 28721   4 17:14:29 pts/2       0:59 dd if=/dev/zero of=/dev/null
    root 22197 19493   4 17:13:29 pts/2       2:00 dd if=/dev/zero of=/dev/null
    root   763 28721   4 17:14:30 pts/2       0:59 dd if=/dev/zero of=/dev/null
    root   784 28721   4 17:14:30 pts/2       0:59 dd if=/dev/zero of=/dev/null
    root   384 28721   4 17:14:27 pts/2       1:01 dd if=/dev/zero of=/dev/null
    root   731 28721   4 17:14:29 pts/2       0:57 dd if=/dev/zero of=/dev/null
    root   797 28721   4 17:14:31 pts/2       0:58 dd if=/dev/zero of=/dev/null
    root   811 28721   4 17:14:31 pts/2       0:55 dd if=/dev/zero of=/dev/null

vmstat で CPU の idle 値を確認すると、8 CPU のうち 指定した 4 CPU 分 (50%) の リソース制限がかけれらている事が確認できました。(以下 vmstat のログ参照)
test-zone# vmstat 5
 kthr      memory            page            disk          faults      cpu
 r b w   swap  free  re  mf pi po fr de sr lf s0 s1 s2   in   sy   cs us sy id
 0 0 0 13665784 14289320 4 28 3 13 13 0  0 60  3 -0 -0  348  941  183  0  0 100
 0 0 0 13394712 14845816 0 2 0  0  0  0  0  0  2  0  0  687 381039 679 33 17 50
 0 0 0 13394584 14845688 0 1 0  0  0  0  0  0  0  0  0  675 380613 664 33 17 50
 0 0 0 13394584 14845688 0 1 0  0  0  0  0  0  0  0  0  680 378673 668 33 17 50
 0 0 0 13394784 14845888 0 1 0  0  0  0  0  0  0  0  0  677 378797 664 33 17 50

今度は、mpstat で各 CPU 毎のリソース消費状況を確認してみます。
test-zone# mpstat 5
....
CPU minf mjf xcal  intr ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
  0    0   0  362   291  190  102   19   34    0    0 41108   29  16   0  55
  1    0   0    1    60    0   93   21   26    1    0 48938   34  17   0  50
  2    0   0    1    60    3   84   24   21    1    0 51049   35  18   0  47
  3    0   0   12    61    2   97   21   26    3    0 43064   30  15   0  55
  4    0   0    1    55    0   84   21   28    2    0 55644   38  19   0  42
  5    0   0    1    48    0   69   19   22    1    0 50612   36  18   0  46
  6    0   0    2    51    4   68   20   21    1    0 45181   32  16   0  51
  7    0   0    0    50    0   77   18   21    1    0 41583   30  15   0  55
CPU minf mjf xcal  intr ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
  0    0   0  371   289  188   91   17   31    1    0 45559   31  17   0  52
  1    0   0    2    58    0   79   22   26    2    0 56062   38  19   0  43
  2    0   0    1    58    3   83   19   24    2    0 47050   33  17   0  51
  3    0   0    0    57    2   90   21   26    1    0 39873   28  14   0  57
  4    0   0    0    56    0   84   23   31    2    0 55867   38  19   0  43
  5    0   0    0    51    0   72   22   24    2    0 51719   36  18   0  46
  6    0   0    3    55    0   86   21   24    1    0 41062   29  15   0  56
  7    0   0   13    53    0   82   21   25    2    0 41240   29  15   0  56
....

CPU リソース制限を set ncpus=4 で設定したので、てっきり特定の 4 CPU が固定で 消費されるのかと思ったら、平均して 4 CPU になるよう制限されている事が 確認できました。(ncpus 値は 3.5 など整数でない値も指定可能です)
CPU Caps はあくまでも Fair Share Scheduler の制御下で動作しているのですね。

[まとめ]
今まで zone 間で CPU pool を共有する環境下で CPU リソース制限をかける時は、 いくら CPU リソースを zoneA:zoneB = 1:2 の割合で指定しても、Fair Share Scheduler の仕様で zoneA のコンテナが 100% pool 内の CPU リソースを使い切る事ができました。 今回追加された CPU Caps 機能は、zone 間で同じ CPU Pool を共有している時で も完全に CPU リソースに制限をかける事ができます。


http://blogs.sun.com/yappri/date/20080415 2008年 4月 15日 火曜日

128 スレッドサーバの発表

今月、サンの Coolthreads サーバに新たなラインナップ Sun SPARC Enterprise T5140 Sun SPARC Enterprise T5240 が追加されました。
T5140/T5240 は、UltraSPARC T2 Plus プロセッサを 2 個搭載した最新の CoolThreads サ ーバです。

Sun SPARC Enterprise T5140

T5140 の特徴は、高さ 1U の筐体に実行スレッド数がなんと最大 128 も実装され、 見た目の薄さからは想像できない程パワフルなサーバになっております。

Sun SPARC Enterprise T5240

一方、 T5240 も最大で 128 スレッドの実装もすごいですが、特徴的なのは、 高さ 2U の筐体に 146GB の内蔵ディスクが 16 本搭載可能で、最大 2.3TB の 内蔵ディスク容量をサポートします。(ZFS が活躍しそうです)

CoolThreads サーバに関するスレッド数進化の歴史といえば、2005 年の冬に発表した 8 コア 32 スレッド の UltraSPARC T1 プロセッサ搭載サーバに始まり、昨年発表した UltraSPARC T2 プロセッサ搭載サーバではスレッド 数が倍の 64 になった時も驚きましたが、今回はさらに UltraSPARC T2 Plus プロ セッサを 2 個搭載する事で最大 128 スレッドのサーバがラインナップに追加されま した。
( 128 スレッドだと、mpstat で CPU 利用率をモニタリングするのも一苦労ですね。;-p)

いやはや、Coolthreads サーバの進化には毎度驚かされます。

ではここでサンのサーバに関するクイズを出題してみましょう。

[問題]
過去を含め、サンのサーバラインナップの中でスレッド数が一番多いサーバは、 SPARC Enterprise M9000-64 の 256 スレッド( 64 CPU x 2 core x 2 Thread) ですが、CPU ソケットが一番多く 搭載可能なサーバは何でしょうか?
(これを即答できる方は相当サンに詳しい方です。)


[答え]
CPU ソケットが一番多く搭載可能なサーバは Sun Fire Enterprise 25K(通称 E25K) の 72 個というのは間違えで、正解は、Sun Fire 15K(通称 F15K)になります。
ここで、E25K も F15K もシステムボードの数は同じなので CPU 数は同じ 72 個と 思いがちですが、F15K には、MaxCPU ボードなるレアなコンポーネント が存在していたのをご存知でしょうか?
MaxCPU ボードとは、CPU を 2 個搭載するボードで、搭載場所は、本来 PCI スロット を拡張する為の hPCI I/O ボードの代わりにに挿入します。 この MaxCPU ボードが F15K には最大 17 枚入りますので、最大ソケット数は

       F15K 最大ソケット数 = 72 (System Board 分) + 17 x 2 = 106 CPU

が正解になります。

F15K には hPCI I/O ボード用のスロット数が 18 あるのですが、全て MaxCPU ボードで埋めてしまうと PCI スロットが無くなってしまう為、ディスクもネットワークも接続できなくなって しまいますので、少なくとも hPCI I/O ボードは最低 1 枚用意する必要があります。そんな理由でサーバの スペック上は 108 CPU 搭載する事は可能ですが、最大で 106 CPU になりました。


最後に...
この F15K の最大 106 CPU 構成は、F15K が発売されている当時、一台は売って みたかった構成ですが夢かなわず終わってしまいました....
(残念)


http://blogs.sun.com/yappri/date/20080328 2008年 3月 28日 金曜日

動作しているプロセスが、32 bit または 64 bit バイナリのどちらか?

「いま動作しているプロセスが、32 bit か 64 bit か確認する方法はあるか?」と聞かれたのですが、コマンド一発で確認する方法を考えてみました。
例えば、ある実行可能なコマンドが、32 bit バイナリか 64 bit バイナリかは、file コマンドにて確認することが可能ですね。
SPARC の場合

32 bit バイナリ
$ file /usr/bin/truss
/usr/bin/truss: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped
sunfish(SUNW,Ultra-60):/usr/bin/sparcv9

64 bit バイナリ
$ file /usr/bin/sparcv9/truss
/usr/bin/sparcv9/truss: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, stripped

x86 の場合

32 bit バイナリ
$ file /usr/bin/truss
/usr/bin/truss: ELF 32-bit LSB executable 80386 Version 1, dynamically linked, stripped

64 bit バイナリ
$ file /usr/bin/amd64/truss
/usr/bin/amd64/truss: ELF 64-bit LSB executable AMD64 Version 1, dynamically linked, stripped

では、動作しているプロセスが 32 bit か 64 bit か判別するにはどのようにすればよいでしょうか?

Solaris は、64 bit OS であるため、いくつかのコマンドやライブラリは、64 bit バイナリとして提供されてはいますが、いまだ、32 bit バイナリも多く含まれています。
また、アプリケーションによっては、32/64 bit バイナリを同梱している場合もあります。
64 bit 環境を生かすべく、64 bit バイナリが動作しているかと思っていたら、実は 32 bit バイナリがサービスを提供していた・・・なんてことになっているかも・・・
そのような環境の中で、目的のバイナリが適切に動作しているかを確認する必要がでてくる場合があるかもしれません。

というわけで、より環境を把握しておくためにも、現在、動作しているプロセス(コマンド)が 32 bit または 64 bit バイナリなのかを簡単に確認する方法をご紹介したいかと思います。
debugger を使いプロセスに attach して解析とか、truss でシステムコールを追いかけたりする必要もありません。

・Proc Tools を使ってみる


Solaris には、process filesystem (procfs) と呼ばれるプロセスの状態を記録する特別なファイルシステムが提供されています。

man -s 4 proc

この procfs を利用し、プロセスの動作をより視覚化するために proc tools なるものがが提供されています。
今回は、Proc Tools に含まれる pldd とコマンドを利用します。

man -s 1 proc

pldd は、動作中のプロセスが dlopen(3C) 関数を使用して呼び出している共有ライブラリを確認するために利用しますが、この共有ライブラリを確認することで、そのプロセスが 32 bit または 64 bit アプリケーションかを確認することができます。
※1 pldd は、出力を得るために、実行中のプロセスを内部的に一次停止させます。ご利用は計画的に。

その前に、Solaris における 64 bit サポートについては、次のようなお約束があります。

・32 bit オブジェクトと 64 bit オブジェクトを混在できない

このことから、32 bit アプリケーションは、32 bit ライブラリを呼び出し、64 bit アプリケーションは、64 bit ライブラリを呼び出しているはずです! というわけで、実際に見てみましょう。
例えば、稼働中の apache (http) のプロセスに pldd を実行してみます。

# ps コマンドで、http のプロセス ID を確認
# pldd 2861
2861: /usr/apache2/bin/httpd -k start
/usr/lib/libz.so.1
/usr/sfw/lib/libssl.so.0.9.7
/usr/sfw/lib/libcrypto.so.0.9.7
/lib/libdl.so.1
/usr/apache2/lib/libaprutil-0.so.0.9.16
/usr/apache2/lib/libexpat.so.0.1.0
/usr/apache2/lib/libapr-0.so.0.9.16
/lib/libsendfile.so.1
/lib/librt.so.1
/lib/libm.so.2
/lib/libsocket.so.1
/lib/libnsl.so.1
/lib/libresolv.so.2
/lib/libpthread.so.1
/lib/libc.so.1
:
このように、呼び出しているライブラリを確認することができます。
Solaris では、ライブラリやコマンド類が配置されるディレクトリには、通常 32 bit オブジェクトが配置(※2)さ­れますが、そこを更に堀下がって sparcv9 (SPARC版) または、amd64 (x86版) という、特別な名前がつけられたディレクトリに 64 bit オブジェクトが格納されます。
このようにディレクトリを分けることで 32 bit と 64 bit オブジェクトが混在することを防いでいます。
この例では、amd64 や sparcv9 の文字が見えないので、このプロセスは 32 bit アプリケーションであることがわかります。

※2 最近は、32 bit オブジェクトも i86 (x86 版) または sparcv7 (SPARC 版) という特別なディレクトリに配置されているものも増えており、��位のディレクトリにも同様のコマンドが配置されている場合があります。
例えば、dtrace コマンドなどがそうです。
$ find / -name dtrace -print
/usr/sbin/amd64/dtrace
/usr/sbin/i86/dtrace
/usr/sbin/dtrace
このように 3 つの dtrace コマンドが存在します。 それぞれのファイルサイズを見ると、/usr/sbin/dtrace だけが小さなファイルであることに気づきます。
$ ls -l ./usr/sbin/dtrace
-r-xr-xr-x 66 root bin 5816 Jan 9 2007 ./usr/sbin/dtrace*
$ ls -l ./usr/sbin/i86/dtrace
-r-xr-xr-x 1 root bin 41264 Aug 15 2007 ./usr/sbin/i86/dtrace*
$ ls -l ./usr/sbin/amd64/dtrace
-r-xr-xr-x 1 root bin 48520 Aug 15 2007 ./usr/sbin/amd64/dtrace*
これは、/usr/sbin/dtrace は、コマンドの実態ではなく、i86 また amd64 に配置される dtrace コマンドの実態を呼び出すための wrapper コマンドとなるためです。

wrapper となる /usr/sbin/dtrace が行うことは、sysinfo(2) システムコールを利用して、システムが 32 bit または 64 bit kernel のどちらかで動作しているかを確認し、適切なバイナリを実行させるようにしています。
truss コマンドを使って、注意深く見てみるのもおもしろいかと思います。

では、試しに、64 bit アプリケーションのプロセスを見みてみましょう。
#例では、iSCSI target daemon を利用しています。これも dtrace 同様 wrapper が提供されています。­
# pldd 15531
15531: /usr/sbin/iscsitgtd
/lib/sparcv9/libumem.so.1
/lib/sparcv9/libuuid.so.1
/usr/lib/sparcv9/libxml2.so.2
/lib/sparcv9/libsocket.so.1
/lib/sparcv9/libnsl.so.1
/lib/sparcv9/libdoor.so.1
/lib/sparcv9/libavl.so.1
/lib/sparcv9/libmd5.so.1
/lib/sparcv9/libadm.so.1
/lib/sparcv9/libefi.so.1
/lib/sparcv9/libiscsitgt.so.1
/lib/sparcv9/libzfs.so.2
/lib/sparcv9/libaio.so.1
/lib/sparcv9/libc.so.1
/lib/sparcv9/libpthread.so.1
/usr/lib/sparcv9/libz.so.1
/lib/sparcv9/libm.so.2
/lib/sparcv9/libscf.so.1
/lib/sparcv9/libdevinfo.so.1
/lib/sparcv9/libdevid.so.1
/lib/sparcv9/libgen.so.1
/lib/sparcv9/libnvpair.so.1
/lib/sparcv9/libuutil.so.1
/lib/sparcv9/libsec.so.1
/platform/sun4u/lib/sparcv9/libc_psr.so.1  

sparcv9 ディレクトリに配置される共有ライブラリが呼び出されていることがわかり、このプロセスは、64 bit アプリケーションであることがわかります。
このように、呼び出されているライブラリから、動作中のプロセスが 32 bit か 64 bit アプリケーションかを判断することができますが、これでどうでしょうか?!

また、proc tools には、pldd 以外にも使えるツールがそろっていますので、ぜひ、利用してみてください。  
 

Sunグッズ紹介(16)

Sun のロゴ入りグッズ紹介の第十六弾です。


・Sun ロゴ入り ワインツールセット
 高級感溢れる Sun ロゴ入りの木箱に丁寧に納められているのはワインツールセット。
 中に納められているのはシンプルなデザインのワインツール 4 点。
 ソムリエナイフ、ボトルストッパー、液だれストッパー、ワイン温度計が揃っているので
 家でワインを楽しむ際に重宝しそうです。(^o^)




・Sun ロゴ入りキャップ
 Sun のロゴ入りキャップは原色系ながらにシンプルなデザイン。
 Sun のロゴも綺麗に刺繍されていてとても良い感じ (^o^)
 日差しが厳しくなるこれからの季節の行楽先や外での作業時にピッタリですね!



・Ruby T シャツ
 Java のマスコットである Duke がルビーを掲げるポップなデザインの
 Ruby T シャツ。これはもう着るだけで楽しくなること間違いなし!
 背中に書かれた "include Java" という文字もとても Cool! です(^o^)




・Sun ロゴ入りムニュボール
 「コレはいったい何?」っと思わず手に取ってしまう不思議な物体ムニュボール。
 低反発のポリウレタンフォームでできているのでふんわり柔らかく良い感じ。
 握った時の心地よさでストレス解消になりそうです (^o^)



http://blogs.sun.com/yappri/date/20080327 2008年 3月 27日 木曜日

Sun Blade 6000 を触ってみました。(インストール編)

前回は Sun Blade 6000(以下 Blade 6000) の特徴(概要、管理ポート)を記載しました。


今回は実際にそれぞれのブレードに OS をインストールをしてみたいと思います。
Blade 6000 の各ブレードには内臓ディスクを搭載していますが、DVD ドライブが付いていません。
従って、OS インストールをするためには、PC等をつないで RKVMS 経由でインストールするか、インストールサーバ経由で
ネットワークインストールすることになります。
今回はセットアップするブレードも多かったのでインストールサーバ経由でネットワークインストールをすることにしました。
普通にインストールサーバを構築するのも良いのですが、せっかくなので Sun が出しているプロビジョニングツール
(provisioning)である Sun N1 System Manager(以下 N1SM) を使ってインストールサーバを構築してみようと思います。


N1SM は以前の記事がございますので、そちらをご参照ください。

 

まずは、N1SM のインストールです。
インストールはパッケージのインストールと設定(n1smconfig コマンド)が必要です。


N1SM の設定は環境によって差異がありますので今回は割愛します。


では N1SM の設定が完了しましたので実際にそれぞれのブレードにプロビジョニング(OS インストール)したいと
思います。
今回の構成は以下のようにシンプルにしました。(本来は管理用ネットワークとサービス用ネットワークは分けたほうが良い
のですが、今回は OS セットアップだけなのでこのようにしました。)




N1SM を起動します。定番の Web コンソールからのアクセスとなります。
Web ブラウザーを起動して「https://localhost(N1SM サーバ):6789/」と入力します。
そうするとログイン画面が表示されますので、N1SM サーバのアカウントを使用してログインします。
ログインに成功すると以下のようなメニュー画面が表示されますが、初めてログインしたときはプロファイルやサーバは登録されていませんので、OS プロファイル等の設定が必要になります。
(設定方法に関してはマニュアルをご参照ください。)




前置きが長くなりましたが、実際に N1SM でそれぞれのブレードに OS をインストールしようと思いましたが、リリースノートを確認したところ Intel チップの X6250 ブレードがサポートされていませんでした。

従いまして今回は T6300 と X6220 ブレードに OS をインストールすることにしました。

インストール時の注意事項としては OS プロファイルをインストールするサーバに対してアサイン(OS プロファイルを選択してドラック&ドロップすることができます)してから、実際にインストールが開始するまでに、ネットワークの構成やディスクパーティション、監視項目設定がありますので、それぞれの環境にあった構成を選択/入力する必要があります。
あるいは今回、私が試したように Flash を作って、それをプロファイルに登録しておくという方法もございます。Flash でのプロビジョニングは簡単なのでお勧めです。

実際に Flash でインストールするための設定を以下に掲載しておきます。


写真の左側にある設定項目を順番に選択/入力して最後に確認画面を開くと、このような画面が表示されます。
確認画面でもわかると思いますが、コマンドが記載されていますが、コマンドラインモードでも直接入力することができます。
(詳細はマニュアルをご参照ください。)


Flash でのインストールは通常の時間の 2/3 程度で終わりました。
以下は T6220 ブレードにプロビジョニングした後、RemoteConsole 経由でアクセスした画面です。


インストールログも LOM 経由で見ることができます。 もちろん T6300 ブレードも問題なくインストールできました。
その他、通常の N1SM 監視機能も使えます。


もし、Blade 6000 を使うことがありましたら、N1SM も一緒に使ってみてはいかがでしょうか。
使いこなせればセットアップや管理が楽になると思います。


【参考情報】 今回ご紹介した Sun N1 System Manager をより詳しく知りたい方は以下のページを是非ご覧ください。

http://blogs.sun.com/yappri/date/20080326 2008年 3月 26日 水曜日

Solaris 10 から、NTFS ファイルシステムをマウントする方法

 最近の Solaris 10 (x86/x64版) ユーザは、開発業務を Solaris 10 で実施する等の目的の為、ノート・パソコンに Solaris 10 と Windows XP デュアルブート環境を構築し利用 している方もいらっしゃるのではないでしょうか。 (デュアルブート環境の構築は他稿 に譲るとして・・・。)

 Solaris 10 は、正式に PCFS ファイルシステム( FAT や FAT32 )の マウント及び読み書きをサポートしています。ところが、Windows XP / Vista ではデフォルトのファイルシステムがNTFS を採用しているため、従前は Solaris / Windows の両 OS からファイルシステムを共有することができませんでした。

 今回は、 OpenSolaris の Distribution の ひとつである Belinix のサイトから、NTFS ファイル システム(ext2 ext3 もサポート)を read-only にてマウント可能にするためのパッケージと利用方法をご紹介し ます。

 (以下の作業は Solaris から行います。)


Belenix トップページ

Belenix のトップ ページから、Download を選択して以下の Misxallaneous Downloads の二つのパッケージ をダウンロードします。

 

後は、適当なディレクトリに解凍して、pkgadd するだけです。


# /usr/sfw/bin/gtar zxvf FSWfmisc.tar.gz
# pkgadd -d . FSWfmisc
# /usr/sfw/bin/gtar zxvf FSWpart.tar.gz
# pkgadd -d . FSWpart

利用方法

(1)まずは、fdisk パーティションを以下の手順で確認します。


# /usr/bin/prtpart
Fdisk information for device /dev/rdsk/c1d0p0
Block Size : 512 bytes
Controller : ide
Disk       : cmdk
Capacity   : 37 GB 

#  start block  # nblocks    startCylSecHd endCylSecHd   OSType
 1: 0000000068   0057303787     0/ 6/ 1    ff/ff/fe      IFS: NTFS
 2: 0057303855   0020820240    ff/ff/fe    ff/ff/fe      Solaris x86

# prtpart /dev/dsk/c1d0p0 -ldevs
Fdisk information for device /dev/dsk/c1d0p0
** NOTE **
/dev/dsk/c1d0p0      - Physical device referring to entire physical disk
/dev/dsk/c1d0p1 - p4 - Physical devices referring to the 4 primary partitions
/dev/dsk/c1d0p5 ...  - Virtual devices referring to logical partitions
Virtual device names can be used to access EXT2 and NTFS on logical partitions
/dev/dsk/c1d0p1 IFS: NTFS
/dev/dsk/c1d0p2 Solaris x86


(2) ファイルシステムに NTFS を指定して、マウントします。


# mount -F ntfs /dev/dsk/c1d0p1 /mnt

マウントポイントを確認すると NTFS がマウントされていることが確認できます。 


# ls /mnt
ADIST5J.PPD*                System Volume Information/
AUTOEXEC.BAT*               Update/
BOOTWIZ/                    WINDOWS/
CONFIG.SYS*                 _rpcs/
CanonMP/                    boot.ini*
Documents and Settings/     bootfont.bin*
Downloads/                  bootwiz.sys*
Drivers/                    gs/
IO.SYS*                     gsview/
Infineon/                   hiberfil.sys*
MSDOS.SYS*                  ntdetect.com*
MSOCache/                   ntldr*
Program Files/              pagefile.sys*
Python25/                   spoolerlogs/
RECYCLER/                   temp/
SunIT/


マウント状況を確認すると read-only でマウントされていることがわかります。


# mount
 ・
 ・
 ・
/mnt on 127.0.0.1:/ remote/read only/setuid/devices/port=43289/public/vers=2/proto=udp/xattr/dev=4d80001 on (水)  3月 26 11:35:56 2008

以上が簡単な利用方法になります。

こちらのパッケージは、ext2 / ext3 ファイルシステムも読むことが可能ですので、マルチブート環境でファイルのやりとりを実施する方は参考になさってください。正式な Solaris 10 のアップデートにて取り込まれることを期待したいところです。

<Reference URL>

<注意事項>

本稿で紹介した内容は、 Solaris 10 の正式サポート範囲外の手順になりますのでご了承下さい。また、環境の構築に際しては、バックアップ等を適切に実施し、利用は自己責任で行ってください。



 

 
 

http://blogs.sun.com/yappri/date/20080325 2008年 3月 25日 火曜日

DTrace の profile プロバイダを使おう


今回は、DTrace のスクリプトを時間指定で終了させたい時や、一定間隔で 情報を取得したい時に便利な profile プロバイダを紹介します。

DTrace のスクリプトを終了する際、[Cntl + C] で強制終了させる場合が多い と思いますが、この場合、cron を使って決まった時間に DTrace を実行したい 時や、Shell スクリプトの中から DTrace を呼び出す時に [Cntl + C] を入力し ないと DTrace スクリプトが終了しない為不便です。

そんな時、 profile プロバイダが活躍します。

例えば、 10 秒間に write システムコールを発行したプロセスを調査したい時は、 下記 profile プロバイダを使用した sample-1.d のコーティングで対応可能です。

(sample-1.d)
#pragma D option quiet

dtrace:::BEGIN
{
    i=10 ;
}

profile:::tick-1sec
/ i > 0 /
{
    i = i - 1 ;
}

profile:::tick-1sec
/ i == 0 /
{
    exit(0) ;
}

syscall::write:entry
{
    @counts[execname] = count();
}

実行するには、下記コマンドを実行します。
# dtrace -s sample-1.d

[sample-1.d 解説]
まず、前処理(BEGIN)で変数 i に初期値 10(秒)を代入します。
メインのアクションでは、変数 i が 0 より大きい時 (i > 0) は、 i から 1 を引き、 i が 0 になった時点(i == 0)でスクリプトが終了します。

さらなる応用として、 DTrace の実行時間を固定でなく、実行時に引数として指定するには、 前処理の部分で初期値 10 の代わりに DTrace 実行時の引数 $1 として記述します。
#pragma D option quiet

dtrace:::BEGIN
{
    i= $1 ;
}

.....
.....

(実行例) 3 秒でスクリプトを終了する
# dtrace -s sample-2.d 3

ちなみに、 "i = i - 1 ;" が記述されているアクション節の中にデータを取得する 文や中間結果を出力するプリント文を入れると一定間隔で意図した アクアションを実行できます。

[補足情報]
 profile プロバイダの NAME tick-1sec の秒数は、任意に指定が可能で、5秒間隔 であれば tick-5sec と指定すればOKです。ちなみに、sec を忘れて tick-5 と 指定してしまうと、1 秒間に 5 回アクションを実行してしまうので気をつけて下さいね。

http://blogs.sun.com/yappri/date/20080228 2008年 2月 28日 木曜日

VirtualBoxのご紹介

2008年2月に米国SunはドイツのInnotekを買収することを発表致しました。
今回はInnotekが手がけるオープンソースの仮想化ソフトウェアVirtualBoxをご紹介します。


VirtualBoxのホームページには各プラットフォーム(Windows/Linux等)に対応した バイナリが公開されています。
【参照URL】
http://www.virtualbox.org/Downloads/

このバイナリを使用することでVirtualBoxを簡単にインストールすることができます。
2008年2月時点では、OpenSolaris,Mac OSに対するベータ版のバイナリも公開されていますが、
残念ながらSolaris10に対するバイナリは未だ公開されていません。
そこで、今回はSolaris10の環境でVirtualBoxを動かしてみました。


[ 環境の確認 ]

検証マシンとしてSun Fire V20z Serverを使用しました。
CPU:AMD Opteron 1.6GHz(64bit CPU)
Mem:1GB
OS: Solaris10 8/07

# uname -a
SunOS v20z 5.10 Generic_120012-14 i86pc i386 i86pc

# more /etc/release
                        Solaris 10 8/07 s10x_u4wos_12b X86
           Copyright 2007 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                            Assembled 16 August 2007
#

# isainfo -v
64-bit amd64 applications
        sse2 sse fxsr amd_3dnowx amd_3dnow amd_mmx mmx cmov amd_sysc cx8 tsc
        fpu
32-bit i386 applications
        sse2 sse fxsr amd_3dnowx amd_3dnow amd_mmx mmx cmov amd_sysc cx8 tsc
        fpu


[ VirtualBoxのインストール ]
VirtualBoxのサイトにOpenSolaris用のバイナリが公開されているため、 このバイナリを利用します。
入手先
http://www.virtualbox.org/wiki/Downloads/
* 今回は/export/work以下に保存しました。
# cd /export/work
# ls
VirtualBox-opensolaris-amd64-1.5.51-r28040-beta1

インストール自体はpkgaddコマンドを実行するのみです。
# pkgadd -d VirtualBox-opensolaris-amd64-1.5.51-r28040-beta1

The following packages are available:
  1  INNOvbox     innotek VirtualBox
                  (i386) 1.5.51

Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]:
...
...
(以下略)

インストールが完了すると/opt/VirtualBox以下にコマンドやライブラリがコピーされます。

[ 環境変数の設定 ]
インストール直後に/opt/VirtualBox/VirtualBoxを実行すると、 以下のようなエラーメッセージが出て起動できません。
ld.so.1: VirtualBox: 重大なエラー: VBoxKeyboard.so: open に失敗しました: ファイ ルもディレクトリもありません。
強制終了

そこで、VirtualBoxが必要とするライブラリを確認してみます。
#ldd /opt/VirtualBox/VirtualBox
        VBoxKeyboard.so =>       (ファイルが見つかりません)
        libqt-mt.so.3 =>         (ファイルが見つかりません)
        VBoxRT.so =>     (ファイルが見つかりません)
        VBoxREM.so =>    (ファイルが見つかりません)
        VBoxVMM.so =>    (ファイルが見つかりません)
        libX11.so.4 =>   /usr/lib/64/libX11.so.4
        libX11.so.4 (SUNW_1.1) =>        (バージョンが見つかりません)
        libXrender.so.1 =>       /usr/sfw/lib/amd64/libXrender.so.1
        libXfixes.so.1 =>        /usr/sfw/lib/amd64/libXfixes.so.1
        libXext.so.0 =>  /usr/lib/64/libXext.so.0
        libpthread.so.1 =>       /lib/64/libpthread.so.1
        librt.so.1 =>    /lib/64/librt.so.1
        libsocket.so.1 =>        /lib/64/libsocket.so.1
        libnsl.so.1 =>   /lib/64/libnsl.so.1
        VBoxXPCOM.so =>  (ファイルが見つかりません)
        libstdc++.so.6 =>        /usr/sfw/lib/amd64/libstdc++.so.6
        libm.so.2 =>     /lib/64/libm.so.2
        libgcc_s.so.1 =>         /usr/sfw/lib/amd64/libgcc_s.so.1
        libc.so.1 =>     /lib/64/libc.so.1
        libdl.so.1 =>    /lib/64/libdl.so.1
        libaio.so.1 =>   /lib/64/libaio.so.1
        libmd.so.1 =>    /lib/64/libmd.so.1
        libmp.so.2 =>    /lib/64/libmp.so.2
        libscf.so.1 =>   /lib/64/libscf.so.1
        libdoor.so.1 =>  /lib/64/libdoor.so.1
        libuutil.so.1 =>         /lib/64/libuutil.so.1
        libgen.so.1 =>   /lib/64/libgen.so.1
#

* 環境変数LD_LIBRARY_PATHに、インストールした/opt/VirtualBox以下を追加します。
#LD_LIBRARY_PATH=/opt/VirtualBox:/opt/VirtualBox/qtgcc/lib:/lib:/usr/sfw/lib
#export LD_LIBRARY_PATH

また、以下のようなエラーが出る場合は、/usr/X11/lib/amd64をLD_LIBRAY_PATHに追加 します。
v20z@root%VirtualBox
ld.so.1: VirtualBox: 重大なエラー: libGL.so: open に失敗しました: ファイルもディレクトリもありません。
強制終了

環境変数の設定
#LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/X11/lib/amd64
#export LD_LIBRARY_PATH

上記環境変数を設定後、/opt/VirtualBox/VirtualBoxコマンドを実行し、 GUI画面が立ち上がるか確認します。

VB_windows

ところが、この状態のままですと、仮想OSの設定をすることはできるのですが、 いざ起動しようとすると、以下のようなエラーメッセージが出て先に進むことができません。

VB_windows


上記原因ですが、 VirtualBox Beta1 for OpenSolaris Hosts for AMD64 パッケージにはlibdlpi.so.1の64bit版ライブラリが必要となります。
これはOpenSolarisには含まれていますが、現行のSolaris10にはバンドルされていません。
よって、OpenSolarisから上記ライブラリを入手する必要があります。
Solaris10付属のlibdlpi.so.1の確認
v20z@root%file /lib/libdlpi.so.1
/lib/libdlpi.so.1:      ELF 32-ビット LSB 動的ライブラリ 80386 バージョン 1

[動的にリンクされています][取り除かれていません]、利用できるデバッグ情報はありません

64bit版libdlpi.so.1の入手先:
http://archive.nexenta.org/elatte-unstable/base/sunwcslr
パッケージの展開
v20z@root%/usr/xpg4/bin/ar x sunwcslr_5.11.82-1_solaris-i386.deb
v20z@root%
v20z@root%ls
control.tar.gz
data.tar.gz
debian-binary
sunwcslr_5.11.82-1_solaris-i386.deb

v20z@root%gunzip data.tar.gz v20z@root%tar -tf data.tar | grep libdlpi.so ./lib/amd64/libdlpi.so.1 ./lib/libdlpi.so.1 ./lib/amd64/libdlpi.so libdlpi.so.1 へのシンボリックリンク ./lib/libdlpi.so libdlpi.so.1 へのシンボリックリンク v20z@root%tar xvf data.tar

上記libdlpi.soライブラリを任意の場所にコピーします。
以下では/usr/local/sunwcslr_5.11というフォルダを作成し、その中にライブラリをコピ-しています。
v20z@root%cp  /export/work/lib/amd64/libdlpi* /usr/local/sunwcslr_5.11/lib/amd64

ライブラリが64bitであるかの確認
v20z@root%file /usr/local/sunwcslr_5.11/lib/amd64/libdlpi.so.1
./lib/amd64/libdlpi.so.1:       ELF 64-ビット LSB 動的ライブラリ AMD64 バージョ ン 1

[CMOV][動的にリンクされています][取り除かれていません]、利用できるデバッグ情報はありません

上記libdlpi.so.1を環境変数の中に組み込みます。
#LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/local/sunwcslr_5.11/lib/amd64
#export LD_LIBRARY_PATH
#

最後に/opt/VirtualBox/VirtualBoxコマンドを実行し、正常にゲストOSが起動できるかを確認します。
Solaris上に仮想OSとしてWindows Server 2003を起動した画面

VB_windows

VirtualBoxは日本語対応しており、様々な仮想OSを構築することができます。 是非一度試してみて下さい!

【参考情報紹介】
今回ご紹介した方法は以下のページを参考にしています

□ Virtualbox-on-solaris-virtualization

http://unixsadm.blogspot.com/2008/02/virtualbox-on-solaris-virtualization.html

http://blogs.sun.com/yappri/date/20080227 2008年 2月 27日 水曜日

頑張る姿が結構カワイイ! SL24 Tape Autoloader 〜へっぽこ SE 奮闘記〜

先日発表されたエントリ・レベル テープストレージ装置 " Sun StorageTek SL24 Tape Autoloader " を
実際に使用する機会に恵まれましたので、その実機の内容を写真付きでご紹介したいと思います。 (^o^)

まず初めに Sun StorageTek SL24 Tape Autoloader 製品の特長を簡単にご紹介。

SL24 の名称にある " テープオートローダー " とはテープドライブにロボットを組み合わせたもので、
テープカートリッジの管理をロボットによって行うテープストレージ装置です。

SL24 は LTO ドライブを搭載したラックマウントが可能なテープオートローダーです。
筐体サイズは " 2U " という非常にコンパクトでありながらメディアカートリッジを格納する
スロットは " 24 スロット " もあり、最大 19.2TB のデータ容量を保管することが可能です。


□ 搭載ドライブ種別、ドライブ転送速度(非圧縮時)

  ・LTO Ultrium Generation 2 (half height):Ultra160 SCSI(LVD) [24MB/秒 86.4GB/時]
  ・LTO Ultrium Generation 3 (half height):Ultra320 SCSI(LVD) [60MB/秒 216GB/時]
  ・LTO Ultrium Generation 3 (full height):Ultra320 SCSI(LVD)、4Gb FC [80MB/秒 288GB/時]
  ・LTO Ultrium Generation 4 (full height):Ultra320 SCSI(LVD)、4Gb FC [120MB/秒 432GB/時]


□ 単体容量(非圧縮時)&ライブラリ最大容量(非圧縮時)[スロット数:最大24]

  ・LTO Ultrium Generation 2 (half height): 200GB 4.8TB
  ・LTO Ultrium Generation 3 (half height): 400GB 9.6TB
  ・LTO Ultrium Generation 3 (full height): 400GB 9.6TB
  ・LTO Ultrium Generation 4 (full height): 800GB 19.2TB


なんと 2U というコンパクトな筐体でありながら LTO4 の場合は最大 19.2TB もの容量を
まかなえるストレージ装置となるのです。まさに”高密度でコンパクト!”ですよね! (^o^)

さて、そんな高密度なテープストレージ装置 SL24 を実機の写真とともに詳細を見ていきましょう。

【SL24 筐体前面、背面】

SL24_01  SL24_02

筐体はサーバ群と同じく前面がシルバーの基調でまとめられおり、ラックにならべて搭載した際にも
サーバとの統一感を生み出す様になっています♪ 背面にはドライブのインタフェース(SCSI or FC)と
筐体管理の為のインタフェース (NIC) があります。ロボット用の専用外部インタフェースは無く
ロボットは内部でドライブとバイパス接続されていて、外部からのコマンドを受け付ける仕組みに
なっています。


SL24_04  SL24_03

筐体前面には操作パネルがあり、筐体情報の確認・設定やテープメディアの移動など SL24 が持つ一通りの
操作はボタン操作でこちらから行えます。


【メールスロット】

SL24_05  SL24_06

テープライブラリから指定のテープカートリッジを取り出す際に役に立つのがメールスロットです。
左右それぞれのマガジンを一本丸ごと取り外すことも可能なのですが、マガジン取り付け後に
マガジン内の全てのスロット(x12)にロボットによる走査スキャンが走りメディアを使用できる
状態になるまで時間が必要となります。メールスロットを使用すれば単体のテープカートリッジを
外部にスムーズに出し入れ出来るため効率的に作業が行えるという利点を生み出します。
このメールスロットへのアクセスはコントロールパネルから行えます。
(バネ式になっていてスロットがマガジンより自動的に飛び出す仕組みになっています。)


【マガジン】

SL24_07  SL24_08

メールスロットと同じく左右に装備されたマガジンも通常はロックがかかっていて取り出せません
メールスロットやマガジンのロックを外す操作はパスワードで保護されていますので、管理パスワード
をボタンで入力した後にアンロック指示を出す必要があります。
(マガジンはバネ飛び出し式ではありません。)


【ロボット】

SL24_09

ロボットは筐体内に実装されていて普段では見えない状態で筐体内部で稼働しています。
ロボットはテープカートリッジの移動だけでなくバーコードリーダー機能も有していて
各スロットに納められたメディアの検知を行うことができます。


【LTO テープカートリッジ】

SL24_11  SL24_12

SL24 では LTO メディアを使用します。CD を二回りくらい小さくした大きさの四角いカセットで
内部に磁気テープが巻かれています。 LTO4 であれば 800GB のデータを一本のメディア内に納める
事ができ、ドライブ転送速度も 120MB/sec と非常に高速です。写真の右側はクリーニングテープです。
LTO 規格のドライブであれば世代によらず同じクリーニングテープを使用できます。


【片面 12 スロットのマガジン】

SL24_10  SL24_13

左右のマガジンにはそれぞれ 12 スロットのテープカートリッジのスペースがあり、縦横「3x4」で
ならんでいます。またスロットが「空」であることを認識させる為のバーコードシールが各スロットの
奥に張られています。


【ドライブとドライブベイ】

SL24_14

SL24_16  SL24_15

トライブは手回しねじによってドライブスロットに固定されます。これは万が一、ドライブが故障し
交換が必要になった際にも素早くドライブ交換を行える仕組みです。ドライブはハーフハイトと
フルハイトの 2種類あります。ハーフハイトであれば最大2台まで SL24 に
搭載できます。(LTO3 では転送速度に違いがあるので構成選択の際、注意が必要です。)



□ Web 管理インタフェースのご紹介(各画面はクリックすると別ウィンドウで大きく表示されます。)

SL24 では背面の NIC port からネットワークに接続することによってリモートより管理を行う
ことができます。リモート管理インタフェース (RMI) は Web ベースの GUI となっていて
ブラウザ経由で SL24 の筐体情報を得たりメディアカートリッジの管理を行う流れとなります。
(筐体前面のパネルとボタンで行える事と同等の操作を遠隔地から行う機能です。)


【ログイン画面】

Sl24_ss_01

ログイン画面では「Account Type」を選択し、必要な場合はパスワードを入力します。
Administrator 用のパスワードは前面パネルで使用する管理用のパスワードと同じものになります。

【筐体情報画面、ドライブ情報画面】

Sl24_ss_02  Sl24_ss_03

SL24 の筐体と実装されたドライブの健全性は画面左側に常時表示されます。
「identity」タグでは筐体とドライブの詳細情報を確認することが出来ます。

【カートリッジ格納情報画面、 Move 操作指定画面】

Sl24_ss_04  Sl24_ss_05

RMI では内部スロットのテープカートリッジの格納状態を図として表示することもできます。
スロット→ドライブ、スロット→メールスロット等へのテープカートリッジの移動指示も
GUI メニューで分かりやすく指示を出すことが出来ます。

□ まとめ

以上で Sun StorageTek SL24 Tape Autoloader のご紹介を終わります。
非常にコンパクトでシンプルな構成ながら、エントリークラスのテープ装置では類を見ない
ほどの高密度な仕上がりになっているのがご理解いただけたものと思います!(^o^)

【参考情報】

今回ご紹介した Sun StorageTek SL24 Tape Autoloader をより詳しく知りたい方は下記の
製品情報のページを是非ご覧下さい。

□ Sun StorageTek SL24 Tape Autoloader 製品情報

http://jp.sun.com/products/storage/tape/sl24/

□ Sun StorageTek SL24 Tape Autoloader 日本語マニュアル

http://docs.sun.com/app/docs/coll/sl24-ja


http://blogs.sun.com/yappri/date/20080226 2008年 2月 26日 火曜日

はじめてみよう! PostgreSQL for Solaris 10

Solaris 10 6/06 (update 2) から、PostgreSQL がバンドルされました。
具体的にはSolaris 10 6/06,11/06 には PostgreSQL 8.1.x が、Solaris 10 8/07 には
PostgreSQL 8.1.x,8.2.x が Solaris に最適化された形でコンパイルしたものが入っています。
ソースコードは PostgreSQL と同じものです。

これらのバイナリはSolaris にバンドルされておりますのでもちろん使用権無償でご利用いただけます。
バンドルされた PostgreSQL の保守サポートを受ける場合は Solaris の
サポートとは別オプションで提供しています。

ちなみに、PostgreSQL は 8.2 からソースコードに DTrace プローブポイントが埋め込まれており、
コンパイル時に "--enable-dtrace" オプションをつけることにより、利用することができます。
もちろん、バンドルされている PostgreSQL 8.2 にはこのオプションがついた形でコンパイルされております。

ディレクトリ構造は以下のようになっています。

< PostgreSQL 8.1.x >
実行形式                /usr/bin
ライブラリ              /usr/lib
ドキュメント            /usr/share/doc/pgsql/8.1.x
                        /usr/share/doc/pgsql/8.1.x/contrib
Contrib                 /usr/share/pgsql/contrib
Data                    /var/lib/pgsql/data        --> 空
バックアップ領域	/var/lib/pgsql/backups     --> 空
テンプレート            /usr/share/pgsql
開発用ヘッダ            /usr/include/pgsql
その他の共有データ      /usr/share/pgsql
< PostgreSQL 8.2.x >
実行形式                /usr/postgres/8.2/bin
ライブラリ              /usr/postgres/8.2/lib
ドキュメント            /usr/postgres/8.2/doc
Contrib                 /usr/postgres/8.2/share/contrib
Data                    /var/postgres/8.2/data     --> 空
バックアップ領域	/var/postgres/8.2/backups  --> 空
テンプレート            /usr/postgres/8.2/share
開発用ヘッダ            /usr/postgres/8.2/include
その他の共有データ      /usr/postgres/8.2/share

ご覧いただくとお分かりの通り、PostgreSQL 8.1.x では /usr/bin にバイナリがあるため、
例えば postgres や pg_ctl のようなコマンドは既にパスが通っています。
ただし、PostgreSQL 8.2 を使用する場合には /usr/postgres/8.2/bin にあるため、
/usr/bin の前にパスを通しておくことが必要となりますのでご注意ください。

ここでは Solaris 10 8/07 を前提とし、実際にサービスを起動するまでの手順を紹介します。
( "#" は root のプロンプト、"$" は postgres ユーザーのプロンプトを示します。)

Solaris 10 8/07 では postgres ユーザーおよび postgres グループがデフォルトで
入っておりますので、今回はそれを使用します。

< PostgreSQL 8.1.x >
1.root ユーザーで PostgreSQL のデータ領域の権限を postgres ユーザー・グループに変更し、
  postgres ユーザーでログインする

 # chown postgres:postgres /var/lib/pgsql/data
 # su - postgres

2.PostgreSQL のデータベースクラスタを作成する

 $ /usr/bin/initdb -D /var/lib/pgsql/data

3.svcadm で PostgreSQL を起動する

 # /usr/sbin/svcadm enable postgresql:version_81
< PostgreSQL 8.2.x >
1.root から、postgres ユーザーにログインする

 # su - postgres

2.PostgreSQL のデータベースクラスタを作成する

 $ /usr/postgres/8.2/bin/initdb -D /var/postgres/8.2/data

3.svcadm で PostgreSQL を起動する

 # /usr/sbin/svcadm enable postgresql:version_82

起動までの手順は以上です。
これだけですぐに PostgreSQL を利用できます。

Solaris 10 8/07 からは PostgreSQL のサービスも SMF で定義されているので、
PostgreSQL で使用する pg_ctl コマンドを利用しなくても簡単に起動できます。
もちろん、PostgreSQL で使用する pg_ctl コマンドなどで起動・停止していただくことも可能です。

 # svcs postgresql
 STATE          STIME    FMRI
 disabled       16:09:02 svc:/application/database/postgresql:version_81
 disabled       19:29:25 svc:/application/database/postgresql:version_82

以下のサイトに PostgreSQL for Solaris に関する有用な情報が満載ですのでご参照下さい!

o PostgreSQL for Solaris

http://www.sun.com/software/products/postgresql/index.jsp

o PostgreSQL Tuning Tips for Sun Fire T2000 Systems Running Solaris

http://www.sun.com/servers/coolthreads/tnb/applications_postgresql.jsp

http://blogs.sun.com/yappri/date/20080225 2008年 2月 25日 月曜日

IP アドレスを削減! Link-Base の IPMP 設定方法

今回は、Solaris 10 から追加されたリンクベースの障害検出 IP network multipathing (IPMP)の設定方法を紹介します。

IPMP は、Solaris8 10/00 からサポートされた機能ですが、当初は検査信号ベースの 障害検出のみサポートされておりました。その為、IPMP の設定にはサービス用 IP アドレスの他に検査用 IP アドレスが2つ必要であったり、検査に使用される ICMP Ping のトラフィックが発生したりと煩わしい部分がありました。

今回紹介するリンクベースの障害検出 IPMP は、検査 用 IP が不要で、サービス用の IP アドレス1つあれば設定可能ですし、ICMP Ping の トラフィックも発生しないメリットがあります。
さらに設定も簡単で、検査信号ベースの設定と比べて非常にシンプルです。


それでは、実際に リンクベースの障害検出 IPMP の Active-Standby と Active-Active の 設定を行ってみます。

[ IPMP Active-Active 構成設定方法]

今回は、e1000g の 0 と 1 のインターフェースを使用し、 サービスする IP アドレスは 192.168.0.1、 group 名を ipmp-g としました。
編集するファイルは、 /etc/hostname.e1000g0/etc/hostname.e1000g1 になります。

/etc/hostname.e1000g0 の設定内容
# cat hostname.e1000g0
192.168.0.1 netmask + broadcast + group ipmp-g up
/etc/hostname.e1000g1 の設定内容
# cat hostname.e1000g1
group ipmp-g up

上記ファイルを編集後、システムを再起動すれば終了です。
検査信号ベースの IPMP と比べて設定内容が非常にシンプルです!

(補足情報)
本設定をすると、システム起動時に in.mpathd が エラーを出しますが、検査信号 ベースを使用しない事を意味しており問題ございません。
Feb 21 20:58:52 server01 in.mpathd[149]: [ID 975029 daemon.error] No test
address configured on interface e1000g1; disabling probe-based failure 
detection on it
Feb 21 20:58:52 server01 in.mpathd[149]: [ID 975029 daemon.error] No test 
address configured on interface e1000g0; disabling probe-based failure 
detection on it

リンクベースの障害検出 IPMP を設定後の ifconfig コマンド出力結果は下記の通りです。

(設定後の ifconfig コマンド出力結果)
# ifconfig -a
lo0: flags=2001000849 mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
e1000g0: flags=1000843 mtu 1500 index 2
        inet 192.168.0.1 netmask ffff0000 broadcast 192.168.255.255
        groupname ipmp-g
        ether 0:14:4f:f:a1:80
e1000g1: flags=1000843 mtu 1500 index 3
        inet 0.0.0.0 netmask ff000000 broadcast 0.0.255.255
        groupname ipmp-g
        ether 0:14:4f:f:a1:81


[Active-Active 構成障害検知テスト]

それでは、障害検知テストをしてみましょう。
サービスしている e1000g0 インターフェス側のケーブルを抜くと障害を検知し、サービス するインターフェースが切り替わります。

(障害検知後の状態)
lo0: flags=2001000849 mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
e1000g0: flags=19000802 mtu 0 index 2
        inet 0.0.0.0 netmask 0
        groupname ipmp-g
        ether 0:14:4f:f:a1:80
e1000g1: flags=1000843 mtu 1500 index 3
        inet 0.0.0.0 netmask ff000000 broadcast 0.0.255.255
        groupname ipmp-g
        ether 0:14:4f:f:a1:81
e1000g1:1: flags=1000843 mtu 1500 index 3
        inet 192.168.0.1 netmask ffff0000 broadcast 192.168.255.255

(障害検知時の syslog メッセージ)
Feb 21 21:04:40 server01 e1000g: [ID 801725 kern.info] NOTICE: pci8086,1011 - e
1000g[0] : Adapter copper link is down.
Feb 21 21:04:40 server01 in.mpathd[149]: [ID 215189 daemon.error] The link has
gone down on e1000g0
Feb 21 21:04:40 server01 in.mpathd[149]: [ID 594170 daemon.error] NIC failure d
etected on e1000g0 of group ipmp-g
Feb 21 21:04:40 server01 in.mpathd[149]: [ID 832587 daemon.error] Successfully
failed over from NIC e1000g0 to NIC e1000g1

ちなみに、抜いたケーブルを差して元の状態に戻すと、リンクアップを検知し、すぐに フェイルバックします。


[ IPMP Active-Standby 構成設定方法]

Active-Standby 構成も、/etc/hostname.e1000g0、/etc/hostname.e1000g1 ファイルを 編集するだけで終了です。
Active-Active 構成と比較して、hostname.e1000g1 ファイルに standby のキーワードが 入ります。

/etc/hostname.e1000g0 の設定内容
# cat hostname.e1000g0
192.168.0.1 netmask + broadcast + group ipmp-g up
/etc/hostname.e1000g1 の設定内容
# cat hostname.e1000g1
group ipmp-g standby up

(設定後の ifconfig 出力結果)
# ifconfig -a
lo0: flags=2001000849 mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
e1000g0: flags=1000843 mtu 1500 index 2
        inet 192.168.0.1 netmask ffff0000 broadcast 192.168.255.255
        groupname ipmp-g
        ether 0:14:4f:f:a1:80
e1000g0:1: flags=1000843 mtu 1500 index 2
        inet 0.0.0.0 netmask ff000000 broadcast 0.0.255.255
e1000g1: flags=69000842 mtu 0 index 3
        inet 0.0.0.0 netmask 0
        groupname ipmp-g
        ether 0:14:4f:f:a1:81

[Active-Standby 構成障害検知テスト]

それでは、障害検知テストをしてみましょう。 サービスしている e1000g0 インターフェス側のケーブルを抜くと、Active-Active 構成 と同様に障害を検知し、サービスするインターフェースが切り替わります。 (障害検知後の状態)
# ifconfig -a
lo0: flags=2001000849 mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
e1000g0: flags=19000802 mtu 0 index 2
        inet 0.0.0.0 netmask 0
        groupname ipmp-g
        ether 0:14:4f:f:a1:80
e1000g1: flags=21000843 mtu 1500 index 3
        inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
        groupname ipmp-g
        ether 0:14:4f:f:a1:81
e1000g1:1: flags=21000843 mtu 1500 index 3
        inet 192.168.0.1 netmask ffff0000 broadcast 192.168.255.255

(障害検知時の syslog メッセージ)
Feb 21 21:13:57 server01 e1000g: [ID 801725 kern.info] NOTICE: pci8086,1011 - e
1000g[0] : Adapter copper link is down.
Feb 21 21:13:57 server01 in.mpathd[149]: [ID 215189 daemon.error] The link has 
gone down on e1000g0
Feb 21 21:13:57 server01 in.mpathd[149]: [ID 594170 daemon.error] NIC failure d
etected on e1000g0 of group ipmp-g
Feb 21 21:13:57 server01 in.mpathd[149]: [ID 832587 daemon.error] Successfully 
failed over from NIC e1000g0 to NIC e1000g1
Feb 21 21:13:57 server01 in.routed[337]: [ID 970160 daemon.notice] unable to ge
t interface flags for e1000g0:1: そのようなデバイ スもアドレスもありません。
抜いたケーブルを差して元の状態に戻すと、Active-Standby 構成も同様、リンクアップ を検知し、すぐにフェイルバックします。

(最後に)
リンクベースの障害検出 IPMP は、ネットワークスイッチの口が2つあれば 簡単にネットワークの冗長構成を組む事ができますのでとても便利です。


http://blogs.sun.com/yappri/date/20080222 2008年 2月 22日 金曜日

yappri blog の過去記事リンク集を作成しました!!

↓ 過去記事リンク集 ↓
http://wikis.sun.com/display/yappri/Home

(右のメニューにも過去記事へのリンクを追加しています→→→→)

blogs.sun.com/yappri を初めて約 2 年、記事が沢山になってきて、 古い記事にどんな内容があったか確認しづらい状況です。 なので wiki.sun.com に過去記事を見やすいようにまとめました。

古い記事(といっても技術的には古くないものも多いです)に ご興味のある方は是非是非アクセスしてみて下さい。

カテゴリ一覧(クリックすると wikis.sun.com に飛びます)
Solaris 全般
Solaris ZFS
Solaris コンテナ
Solaris Dtrace
SunRay
Open Source
UltraSPARC T1/T2
ハードウェア
Java Enterprise System
へっぽこ SE 奮戦記
その他技術
Sun 豆知識

http://blogs.sun.com/yappri/date/20080204 2008年 2月 04日 月曜日

zvol と iSCSI と NTFS と zfs snapshot (その 3)

前回は、Solaris iSCSI target が提供するボリュームを Windows 側にてローカルドライブとして利用できるところまでご紹介しました。 (その 2 は、こちらから

今度は、Solaris  側でのオペレーションに戻り zfs snapshot や zfs clone などを駆使して、作成したボリュームをいろいろと操作してみましょう。

・zvol の snapshot 作成

本 blog コンテンツでもご紹介しているように、zfs snapshot は、とても便利な機能です。
zfs snapshot の詳細については、本 blog の下記 URL を参照してください。

ZFS スナップショット
http://blogs.sun.com/yappri/entry/zfs_snapshot

本稿で作成した領域は、ZFS の一部領域を block device として作成し、その中のファイルシステムは、Windows 側にて NTFS としてフォーマットしています。
zvol は、block device なので、Solaris が理解できる filesystem が構築されている場合は、mount コマンドにてアクセスすることが可能だったりします。
しかし、Solaris は、NTFS を理解できません。
取得した snapshot をどのように利用するかがポイントになりますね。
まぁ、とりあえずやってみてから考えましょう♪

まずは、zfs snapshot で snapshot を取得してみます。
zvol は、block device となることは、その 1 でもご説明しましたが、具体的には、以下の device node となります。

block device としてのファイル名
/dev/zvol/dev/ntfspool/windowsxp

raw device としてのファイル名
/dev/zvol/rdsk/ntfspool/windowsxp 

filesystem として構成されている領域の snapshot は、zfs snapshot 実行時に指定された filesystem 上の .zfs 隠しディレクトリに作成されますが、zvol の snapshot はどこに作成されるのでしょうか?

それでは、実際に zvol の snapshot を作成してみましょう。
(iSCSI Initiator から接続している状況で問題ありません)

snapshot 取得時に名前をつけますが、@ 以降に適当な名前を設定できます。本稿では、採取した時間がわかるように date コマンドを使って日時を割り当てます。これは、筆者のオススメだったりします。

ntfspool/windowsxp 領域の snapshot を取得するには、次のように実行します。

# zfs snapshot ntfspool/windowsxp@`date +%Y%m%d%H%M%S`

簡単ですね。

zfs list コマンドで、確認してみましょう。
# zfs list
NAME                                             USED  AVAIL  REFER  MOUNTPOINT
ntfspool                                           30.0G   104G  24.5K     /ntfspool
ntfspool/windowsxp                           74.3M   134G  74.3M      -
ntfspool/windowsxp@20080203171813      0        -     74.3M      -         ←これ
できてますね。(時間が最近であることについては気にしないでください。。。)

では、肝心の snapshot はどこに作成されたのでしょうか・・・
答えは、device node が作成されているディレクトリに snapshot が作成されます。

snapshot 作成前
# ls
./          ../         windowsxp@

snapshot 作成
# zfs snapshot ntfspool/windowsxp@`date +%Y%m%d%H%M%S`

snapshot 作成後
# ls
./                         windowsxp@
../                        windowsxp@20080203171813@
/dev/zvol/dsk と /dev/zvol/rdsk どちらにも作成されるのもポイントです。

zfs get all で、取得した snapshot のプロパティ���確認すると、下記のようになっていることがわかります。

# zfs get all

ntfspool/windowsxp@20080203171813  type           snapshot               -
ntfspool/windowsxp@20080203171813  creation       Sun Feb  3 17:18 2008  -
ntfspool/windowsxp@20080203171813  used           0                      -
ntfspool/windowsxp@20080203171813  referenced     74.3M                  -
ntfspool/windowsxp@20080203171813  compressratio  1.00x                  -
ntfspool/windowsxp@20080203171813  devices        on                     default
ntfspool/windowsxp@20080203171813  exec           on                     default
ntfspool/windowsxp@20080203171813  setuid         on                     default
ntfspool/windowsxp@20080203171813  shareiscsi     off                    default
ntfspool/windowsxp@20080203171813  xattr          on                     default  

こちらも、対象が filesystem の時と同様、容量(used) が 0 となっています。
定期的に snapshot を作成しておけば、いつでも rollback できる状態をつくることができました。

これで、NTFS でありながらも zvol の snapshot が取得できるようになり、いつでも rollback できるようになりました!

・zfs clone による dataset 化

でも、たとえば、誤って必要なファイルを一つだけ削除してしまい、それを snapshot から取り出す事態が発生するとします。
filesystem であれば、.zfs 隠しディレクトリに移動し、目的のファイルを見つけ出し、コピーすれば復活させることが簡単にできますが、zvol ではそうはいきません。
Solaris からも Windows からも、zvol から取得された snapshot を参照することができません・・・
ある時点の snapshot に、わざわざ rollback しなければ取り出せないことになります・・・
それって、がっかりですよね?

すでに、お気づきの方もいると思いますが・・・
zvol の snapshot が rollback でしか使えないなら、作成した snapshot を iSCSI target と紐づけて、Winodws 側の Initiator で新たにドライブとして割り当てたらいいんじゃないか?って思ったりしましたよね!
するどい!するどすぎる!

し かし、snapshot は、元となる filesystem や volume と親子関係を持っており、親がすでに iSCSI target と紐づけられているいないに関わらず、子となる snapshot には、iSCSI target を割り当てることができない仕様です。

そこで・・・ snapshot といえば、clone ですよね!
clone 機能についての詳細は、下記の記事を参考にしてください。

ZFS クローン、プロモーション機能
http://blogs.sun.com/yappri/entry/zfs_clone

clone は、指定された zfs snapshot から、read/write 可能な  data set  を作成する機能です。
snapshot から dataset が作れるというところがポイントです。

早速、snapshot から clone を作成してみましょう。
利用する snapshot は、ntfspool/windowsxp@20080203171813 です。
clone を作成するには、別途、名前を割り当てる必要があるので、本稿では、ntfspool/windowsxp_clone20080203171813 とします。

# zfs clone ntfspool/windowsxp@20080203171813 ntfspool/windowsxp_clone20080203171813