2007年 9月 26日 水曜日
やっぱり Sun がスキ！
2007年 9月 26日 水曜日
ILOM の syslog 転送に挑戦！〜へっぽこ SE 奮闘記〜
前回は ZFS を USB メモリーでフル活用する方法をお伝えいたしましたが
へっぽこ SE たるもの独自路線で強行突破するべし！・・・・
ということで今回もキワモノ系のネタですみません！m(_ _)m
皆さんは Sun x64 Server に搭載されている ILOM というモジュールを ご存じでしょうか？小さなハガキサイズほどの基盤に独立した CPU・メモリを 搭載したモジュールでシステムの監視・管理をネットワーク経由で行うことが できます。 他社のサーバと違い標準で本体に搭載され、なんら追加のコストも必要 ございません！ 簡単設定でフル活用できるかなりお得な機能です。
【Integrated Lights Out Manager (ILOM) のマニュアルはこちら】
特に ILOM がシステムとは独立したコンポーネントで構成されている事の 恩恵は大きくシステム側で H/W 等の障害が発生してシステムが昇天して しまっても ILOM は生きているので ILOM から障害の状況把握が可能という メリットがあります。
今回はこの便利な ILOM の機能の中でもひっそりとマニュアルに記述が 掲載されているだけなので、思わず見過ごしてしまいそうな超マイナーな機能、 「 ILOM で拾ったイベント情報を syslog 情報として転送する機能」 を試してみたいと思います。
まずは syslog 転送先の IP アドレスを ILOM に設定するところからスタートです。
【1】 ILOM 側の syslog 転送設定
(1)ILOMにログインして /SP/clients/syslog/ ディレクトリに移動します。-> cd /SP/clients/syslog/
/SP/clients/syslog(2) show コマンドにて現在の設定を確認。
※(none)表示は未設定を示しています。-> show
/SP/clients/syslog
Targets:Properties:
destination_ip1 = (none)
destination_ip2 = (none)Commands:
cd
set
show(3) set コマンドにて転送先 IP アドレスを設定します。
※転送先 IP アドレスは二つまで設定できます。-> set destination_ip1=xxx.xxx.xxx.xxx
Set 'destination_ip1' to 'xxx.xxx.xxx.xxx'(4) show コマンドで設定内容を確認する。
-> show
/SP/clients/syslog
Targets:Properties:
destination_ip1 = xxx.xxx.xxx.xxx
destination_ip2 = (none)Commands:
cd
set
show
これで ILOM 側の設定は完了です。ILOM 内で発生したイベント情報は ILOM 内部に
ログ保存されると同時に syslog 形式で転送先のログサーバに転送されているはず
です・・・・(^o^)/
【2】送信される syslog 情報のファシリティとレベルを探る
まずは受け取りサーバー側で snoop コマンドを活用してパケット
送信の状況を読み取り、確認してみようと思います。(^o^)
# と言うのもへっぽこ SE は過去に転送先の IP アドレスの記入をミスって違う
# IP アドレスに転送してしまい・・かなりの時間を浪費した経験が有るため (汗
以下は snoop コマンドを張った状態で ILOM 側へのログインを行った際の
パケット情報です。
--- snoop コマンドによりパケット送受信を確認 -- # snoop -d nge0 xxx.xxx.xxx.xxx between yyy.yyy.yyy.yyy Using device /dev/nge0 (promiscuous mode) xxx.xxx.xxx.xxx -> yyy.yyy.yyy.yyy SYSLOG R port=514 local0.warn: <132>logmgr: ID = 15
☆ snoop コマンドの結果から正しくパケットが流れていることを確認できた
だけでなく、以下のことも分かりました。(^o^)
・ILOM はファシリティ「 local0 」を使用するらしい！
※ ILOM 側での設定で割り当てた値は「送信先の IP」情報のみであったので
このファシリティ「local0」は変更できない固定の値と推測されます。
【3】受け取り syslog サーバ側の設定
では【2】で得られた情報を元に受け取り側の syslog 設定を行いましょう。
(1) 設定ファイルである /etc/syslog.conf に以下の行を付け加えます。
※レベル設定でログ情報の取りこぼしが無いようにレベルを「info」以上としています。
local0.info /var/log/ilomlog
# 「ファシリティ.レベル記述」と「ログ出力先記述」の間は”タブ”で空白を記入します♪
# スペースで記入してしまうと・・・へっぽこ SE と同じく時間を浪費する羽目に(^_^;;
(2) 空のログファイルを作成しておきます。
# touch /var/log/ilomlog
(3) syslogd も Solaris 10 では SMF の管理下に取り込まれていますので
svcadm コマンドにてサービスインスタンスのリスタートを行います。
（※乱暴に行うなら「 # pkill -HUP syslogd 」でも OK かも？(笑)）
# svcadm restart svc:/system/system-log
これで受け取り側のサーバ設定も完了です！
テストがてらに Web ブラウザ経由でのログイン、SSH 経由でのログインを行った際のログ記録です。
# cat /var/log/ilomlog Sep 21 16:34:18 [xxx.xxx.xxx.xxx.x.x] logmgr: ID = 1537 : Fri Sep 21 16:34:16 2007 : Audit : Log : minor : root : Open Session : object = /session/type : value = www : success Sep 21 16:35:36 [xxx.xxx.xxx.xxx.x.x] logmgr: ID = 1538 : Fri Sep 21 16:35:34 2007 : Audit : Log : minor : root : Open Session : object = /session/type : value = shell : success
同じ情報は ILOM 内部には以下のように保存されていました。
-> show /SP/logs/event/list
ID Date/Time Class Type Severity
----- ------------------------ -------- -------- --------
1567 Fri Sep 21 17:20:11 2007 Audit Log minor
root : Open Session : object = /session/type : value = shell : success
1566 Fri Sep 21 17:18:15 2007 Audit Log minor
root : Open Session : object = /session/type : value = shell : success
さてシステムの H/W に障害が発生した場合はどのような情報が飛ぶのでしょうか？
思い切ってフロントファンと電源ケーブルを外してみました♪ (^o^)
(1) ILOM 内のイベントログには以下のようにイベント情報が保存されます。
-> show /SP/logs/event/list
ID Date/Time Class Type Severity
----- ------------------------ -------- -------- --------
1590 Fri Sep 21 17:52:54 2007 IPMI Log critical
ID = 2f2 : 09/21/2007 : 17:52:54 : Power Supply : ps1.pwrok : State Deasserted
1589 Fri Sep 21 17:52:50 2007 IPMI Log critical
ID = 2f1 : 09/21/2007 : 17:52:50 : Power Supply : ps1.vinok : State Deasserted
1588 Fri Sep 21 17:52:33 2007 IPMI Log critical
ID = 2f0 : 09/21/2007 : 17:52:33 : Fan : ft0.fm0.f1.speed : Lower
Non-recoverable going low : reading 2600 < threshold 3000 RPM
1587 Fri Sep 21 17:52:31 2007 IPMI Log critical
ID = 2ef : 09/21/2007 : 17:52:31 : Fan : ft0.fm0.fail : Predictive Failure Asserted
1586 Fri Sep 21 17:52:28 2007 IPMI Log critical
ID = 2ee : 09/21/2007 : 17:52:28 : Fan : ft0.fm0.f0.speed : Lower
Non-recoverable going low : reading 2600 < threshold 3000 RPM
(2) syslog 転送先のシスログサーバには以下のような情報が保存されました。
# cat /var/log/ilomlog Sep 21 17:52:28 [xxx.xxx.xxx.xxx.2.2] logmgr: ID = 1586 : Fri Sep 21 17:52:28 2007 : IPMI : Log : critical : ID = 2ee : 09/21/2007 : 17:52:28 : Fan : ft0.fm0.f0.speed : Lower Non-recoverable going low : reading 2600 < threshold 3000 RPM Sep 21 17:52:31 [xxx.xxx.xxx.xxx.2.2] logmgr: ID = 1587 : Fri Sep 21 17:52:31 2007 : IPMI : Log : critical : ID = 2ef : 09/21/2007 : 17:52:31 : Fan : ft0.fm0.fail : Predictive Failure Asserted Sep 21 17:52:32 [xxx.xxx.xxx.xxx.2.2] logmgr: ID = 1588 : Fri Sep 21 17:52:33 2007 : IPMI : Log : critical : ID = 2f0 : 09/21/2007 : 17:52:33 : Fan : ft0.fm0.f1.speed : Lower Non-recoverable going low : reading 2600 < threshold 3000 RPM Sep 21 17:52:50 [xxx.xxx.xxx.xxx.2.2] logmgr: ID = 1589 : Fri Sep 21 17:52:50 2007 : IPMI : Log : critical : ID = 2f1 : 09/21/2007 : 17:52:50 : Power Supply : ps1.vinok : State Deasserted Sep 21 17:52:54 [xxx.xxx.xxx.xxx.2.2] logmgr: ID = 1590 : Fri Sep 21 17:52:54 2007 : IPMI : Log : critical : ID = 2f2 : 09/21/2007 : 17:52:54 : Power Supply : ps1.pwrok : State Deasserted
電源ケーブルの異常も、ファンの異常も「critical」表示であることから
どうやら H/W 障害系のイベント情報は「crit」のレベルで送信されるようです。
ILOM 内に保存されるイベント情報とほぼ同じ内容のメッセージに発信元の
IP アドレスが加えられて記録されます。 複数の ILOM からメッセージを
受け取ったとしても、この IP アドレスでソートすれば問題なさそうです！
ILOM には NTP クライアントとしての機能もあるのでシスログサーバの参照先と
同じ NTP サーバを指定すればログに記録された時刻のズレを心配する必要もなく
なるかと思います。
これで簡易 H/W 監視システムの出来上がりですね♪(^o^)
Posted at 11:15午前 9 26, 2007 by moridenki in Sun | 投稿されたコメント[1]
2007年 9月 25日 火曜日
Solaris コンテナに対するメモリ制限方法
今月リリースした Solaris 10 8/07 (Update4) では、Solaris コンテナの
メモリ管理が強化されましたのでその機能を紹介致します。
今までの Solaris コンテナでは、非大域ゾーン全体に対する CPU
リソースは制限可能でしたが、メモリリソースに対しては制限をかけることができませんでした。
今回リリースした Solaris 10 8/07 では、Solaris コンテナの非大域ゾーンに対してメモリの制限を
かける capped-memory のリソースが追加されており、この capped-memory に対し
て、physical, swap, locked プロパティが指定可能となりました。
では、実際に確認してみましょう。
今回は、zone01 に対して、200M の物理メモリ(RSS) と swap 300M の制限
をかける非大域ゾーンを作成しました。
# zonecfg -z zone01 zone01: そのような構成済みゾーンはありません 'create' を使用して、新しいゾーンの構成を開始してください。 zonecfg:zone01> create zonecfg:zone01> set zonepath=/export/zone/zone01 zonecfg:zone01> add capped-memory zonecfg:zone01:capped-memory> set physical=200m zonecfg:zone01:capped-memory> set swap=300m zonecfg:zone01:capped-memory> end zonecfg:zone01> verify zonecfg:zone01> commit
設定の確認
# zonecfg -z zone01 info
zonename: zone01
zonepath: /export/zone/zone01
brand: native
autoboot: false
bootargs:
pool:
limitpriv:
scheduling-class:
ip-type: shared
...
...
capped-memory:
physical: 200M
[swap: 300M]
rctl:
name: zone.max-swap
value: (priv=privileged,limit=314572800,action=deny)
今回制限をかけた物理メモリとスワップの値は、具体的に "prstat -Z" で表示される RSS と SWAP の値になります。(下記 prstat -Z の出力結果参照)
実際、物理メモリを50M 消費するプログラム malloc50m を動作させて 検証してみた所、 zone01 の RSS が一瞬 200M を超えますが、 rcapd の働きにより物理メモリ(RSS)が 200M を超えた分はスワップに退避されました。
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
1464 noaccess 159M 50M run 59 0 0:00:30 9.3% java/23
142 daemon 7504K 2256K sleep 59 0 0:00:00 1.1% rcapd/1
1141 root 4848K 2856K cpu0 59 0 0:00:00 0.8% prstat/1
1478 root 51M 51M sleep 59 0 0:00:00 0.7% malloc50m/1
621 root 19M 16M sleep 59 0 0:00:04 0.6% Xorg/1
756 noaccess 157M 74M sleep 59 0 0:00:30 0.5% java/24
934 root 10M 8976K sleep 59 0 0:00:10 0.5% svc.configd/16
872 root 9144K 5472K sleep 59 0 0:00:00 0.2% dtterm/1
715 root 22M 17M sleep 59 0 0:00:02 0.1% iiimd/6
870 root 10M 6852K sleep 59 0 0:00:01 0.1% dtwm/5
932 root 9988K 8452K sleep 59 0 0:00:02 0.1% svc.startd/14
760 root 7720K 4084K sleep 59 0 0:00:00 0.0% iiim-xbe/3
762 root 6728K 2724K sleep 59 0 0:00:00 0.0% atokx2auxd/1
1072 root 4672K 3108K sleep 59 0 0:00:00 0.0% inetd/4
873 root 8092K 4328K sleep 59 0 0:00:00 0.0% sdtperfmeter/1
ZONEID NPROC SWAP RSS MEMORY TIME CPU ZONE
1 33 161M 200M 20% 0:00:42 11% zone01
0 67 171M 292M 29% 0:00:55 3.7% global
(まとめ)
今回追加された Solaris コンテナに対するメモリリソース制限の機能追加は、BrandZ の ように派手ではありませんが、着実に Solaris 10 仮想化技術をまた一歩進化させております。
Posted at 05:53午後 9 25, 2007 by Naoyuki Yamada in Sun | 投稿されたコメント[0]
2007年 9月 21日 金曜日
システムサイジングにまつわる話～アムダールの法則～
ある処理を 4CPU で処理した時の時間が 1CPU で処理した時の 1/4 に必ずしもならないことは
皆さんご存知の事実でしょう。
アプリケーションの処理は常にパラレル処理が可能とは限らないからです。つまり、4CPU あっても1CPUしか使えない処理が
アプリケーションに存在するということです。
この影響を簡単なモデル化したものにアムダールの法則というものがありますので少しご紹介
してみましょう。
アプリケーションの処理というのは大きく分けると次の２つのフェーズに分かれます。
1. シリアル実行フェーズ
・ひとつの CPU のみが使用されるフェーズです。例えば、テープからデータをロードするといったような処理になります。
2. パラレル実行フェーズ
・複数の CPU で処理が実行されるフェーズです。CPU 数に比例して性能が向上するような処理です。
このアプリケーションを 1CPU で実行した場合のトータル実行時間は以下の数式で表されます。
T = Ts + Tp (1)
Ts : シリアル実行フェーズの実行時間
Tp : パラレル実行フェーズの実行時間
同じアプリケーションを複数 CPU で実行した場合の実行時間のトータルは以下の数式となります。
ここで、アムダールの法則では、パラレル実行フェーズの実行時間は、CPU数と反比例するという仮定をおいています。
T(N) = Ts + Tp/N (2)
Ts : シリアル実行フェーズの実行時間
Tp : パラレル実行フェーズの実行時間
N : CPU 数
Ts と Tp については通常は不明の値ですが、異なる CPU 数での実行時間は実際にアプリケーションを動かすことで求めることができます。
その実行時間を元に上記 (1),(2) の 2 つの連立方程式を解くことで、Ts、及びTpを求めることができます。
ここでもう一つ前提ですが、CPU 数が変わることでのオーバーヘッドについてはアムダールの法則では考慮しないこととなっています。
それでは、実行時間の仮定をおいた上で、上記連立方程式を解いてみましょう。アプリケーションを 1CPU と 16CPU で実行した時の
処理時間をそれぞれ以下のように仮定します。
T(1) = 100.0
T(16) = 7.1
これを元に上記(1)、(2)の連立方程式を解くと、
Ts = 0.91
Tp = 99.09
となります。これは言い換えると、99 ％以上の処理がパラレルに実行されることを意味しており、かなり良い状況であることが分かります。
アムダールの法則による分析は通常、全体の処理時間に占めるパラレル処理される部分の比率を対象とします。その比率は次の数式、
Fp = Tp/(Ts + Tp) (3)
で表され、上記の例の場合は、0.9909 という値となります。
このようにパラレル実行部分の比率が 99 ％という比較的良好なものであっても、16CPUにした時の性能向上率は、CPU 数 16 倍
に対して、約 14 倍ということになります。
例えば、ベンチマークなどで CPU 数 2 パターンのデータが得られれば、上記方程式を解くことによって、CPU 数に応じた処理性能を予測する
ことが可能と考えられます。但し、この場合、測定した構成以上の CPU 数での処理性能をこの方式で予測するのは危険です。それは、既知の
構成でのシステム挙動を未知の領域まで適用するということになるからです。上記の例でいうと、1CPU から 16CPU までの性能向上率を元に、
24CPU での性能を予測するということはリスクが高いということです。
最後に、N 個の CPU での性能向上率を S とすると、S = T(1)/T(N) と表すことができます。これを上記 (1), (2), (3) の式を用いて Fp を使う形
に変換すると次のようになります。
S = 1/((1-Fp) + Fp/N)
となります。
これをグラフ化すると以下のようになり、CPU 数が多くなればなるほど、Fp の少しの違いがスケーラビリティに大きく影響してくることが
分かります。
Posted at 04:02午後 9 21, 2007 by Tez in Sun | 投稿されたコメント[0]
Subscribe!