AIXスレッド Technology Levels 06(Part6) (793ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
120(28): 115 2008/04/17(木)00:08 AAS
115だが....
>その結果そのTL当てたmksysbが全滅したけどね。
スマソ 言葉が足りなかった。smit.logは大した問題じゃない。
根本的な問題はLVをミラーしているときupdate_allすると途中でLVが拡張できなくなる。
rootvgをミラーするってのは一般的な使い方だと思うんよ。
不思議なのは奴らはrootvgをミラーしないでチェックしているってこと？
>これに関してはもちろん同意するけど、やっぱりテスト環境でチェックしてから
>TLをあげるってのは重要だなって思ったよ。
これもオリが悪かった。別環境でupdate_allしたとき大きなトラブルがないものだから
あまり考えずにおこなっちまったことだ。悲しかったのは金曜日の夜にupdateして
元に戻すのに日曜日までかかった。休日を返せ>IBMって。
>>118
>LANG=Cをしてない時点でお前の負け
東洋の黄色いサルは使うなってことか....
負けるのは今に始まったことじゃない。ファームを上げたりOSを上げたりするたびに
必ず何らかの問題を抱える。それもOS等の問題で....
そして元に戻すの連続さ。１つが修正されるとまた新たな不幸がやってくる。
これだけユーザーに迷惑をかけてもやっていける会社ってある意味凄い会社だと思う。
121(1): 2008/04/17(木)03:05 AAS
>>120
TLあげるのにmksysb取ってないの！？
あと「LVをミラーしているときupdate_allすると途中でLVが拡張できなくなる」の意味がわからない。
まあ、>>120はHP-UX使ってても同じこと言うんだろうな、と思った。
123: 120 2008/04/23(水)19:05 AAS
スマヌ。カットオーバー直前で忙しくて書き込めぬ。
>121
>TLあげるのにmksysb取っていないの！？
うん。サービス用ではないので取っていない。
地獄に行ったのは私だけだし...。
ま、復旧は時間がかかるだけで物を詰めて行くだけ。
>あと「LVをミラーしているときupdate_allすると途中でLVが拡張できなくなる」の意味がわからない。
update_allしている途中で/usrとかのFSを自動的に拡張していく。それが途中で
Failする。見るとLV領域をデカクしようとしてコケている。
LVM系にBugがあるみたいで....まだどのFilesetが原因なのか調べていないが....
HP-UXは大昔に使ったことがあるが今は知らない。でもOSが上がらないのは完全にOUT。
124: 120 2008/04/23(水)19:06 AAS
>うん、M$とかLiでサーバ組んでるよりは
遥かに安心できると思うけど。
驚いたのはrebootさせたら、OSが上がらなかった。:-(
あのM$でもUpdateをかけて再起動したらOSが上がらないってことはあまりないと
思うが.....
ま、JFS(2)が元気なら他のmksysbが入っているPVを持ってきてそいつでOS上げて
OSが上がらないrootvgをくっつけてmountしてやれば重要なfileは救える。
詳しくは調べていないが、ミラーしているとhd5(bootlv)を消去して新規hd5を
作っている（多分：未確認）その周囲に問題があるようだ。
あと古い5.3のBOSCD使ってメンテモードを上げようとすると変なメッセージを
吐きながら無限ループに陥るし。自分で新しいメンテ用CDを作れってことかよ。
TLをDLするとき
”何があっても文句を言うなボタン”
を押してからDLしているのでこれ以上は言えないが....
満足に確認されていない状態でTLを公開するからユーザがドツボにハマル。
そして馬鹿高いサポートに金を払う。原因はOSを作っている側にあるのに....
ソフトの品質が低い程、サポートが儲かる素晴らしいビジネスモデルです。
125: 120 2008/04/23(水)19:18 AAS
120だがたまたま変な現象を目撃。
networkが遅かったのでnetstatしてみた。
# netstat -v en0
-------------------------------------------------------------
ETHERNET STATISTICS (ent0) :
Device Type: IBM 10/100 Mbps Ethernet PCI Adapter (23100020)
Hardware Address: 00:60:94:xx:xx:xx
Elapsed Time: 0 days 2 hours 10 minutes 19 seconds
Transmit Statistics: Receive Statistics:
-------------------- -------------------
Packets: 1495909 Packets: 998618
Bytes: 2243467216 Bytes: 60146622
Interrupts: 11342 Interrupts: 373215
Transmit Errors: 76827 Receive Errors: 0
Packets Dropped: 0 Packets Dropped: 0
途中略
Bad Packets: 0Lost CTS Errors: 0 Alignment Errors: 0
Max Collision Errors: 0 No Resource Errors: 0
Late Collision Errors: 76701 Receive Collision Errors: 0
Deferred: 4753 Packet Too Short Errors: 0
SQE Test: 0 Packet Too Long Errors: 0
Timeout Errors: 0 Packets Discarded by Adapter: 0
Single Collision Count: 3471 Receiver Start Count: 0
Multiple Collision Count: 198
Current HW Transmit Queue Length: 1
つづく
126: 120 2008/04/23(水)19:20 AAS
Lost CTS Errors: 0 Alignment Errors: 0
Max Collision Errors: 0 No Resource Errors: 0
Late Collision Errors: 76701 Receive Collision Errors: 0
Deferred: 4753 Packet Too Short Errors: 0
SQE Test: 0 Packet Too Long Errors: 0
Timeout Errors: 0 Packets Discarded by Adapter: 0
Single Collision Count: 3471 Receiver Start Count: 0
Multiple Collision Count: 198
Current HW Transmit Queue Length: 1
途中略
IBM 10/100 Mbps Ethernet PCI Adapter (23100020) Specific Statistics:
------------------------------------------------
Chip Version: 25
RJ45 Port Link Status : up
Media Speed Selected: Auto negotiation
Media Speed Running: 100 Mbps Half Duplex
Receive Pool Buffer Size: 384
No Receive Pool Buffer Errors: 0
Inter Packet Gap: 96
Adapter Restarts due to IOCTL commands: 0
Packets with Transmit collisions:
1 collisions: 3471 6 collisions: 0 11 collisions: 0
2 collisions: 190 7 collisions: 0 12 collisions: 0
3 collisions: 8 8 collisions: 0 13 collisions: 0
4 collisions: 0 9 collisions: 0 14 collisions: 0
5 collisions: 0 10 collisions: 0 15 collisions: 0
Excessive Deferrals: 0
つづく
127: 120 2008/04/23(水)19:26 AAS
ん？なんじゃいcollisionってやつは？
# lsattr -El ent0
alt_addr 0x000000000000 代替イーサネット・アドレス 真
busintr 6 バスの割り込みレベル 偽
busio 0xbff800 バスの I/O アドレス 偽
fast_reset yes 高速リセットを使用可能にする 真
intr_priority 3 割り込み優先順位 偽
ip_gap 96 パケット間ギャップ 真
mcast_filter no マルチキャスト・フィルタリングを使用可能にする 真
media_speed 100_Full_Duplex メディア・スピード 真
poll_link no リンク・ポーリングを使用可能にする 真
poll_link_timer 500 リンク・ポーリングの時間間隔 真
rx_hog 1000 RX 割り込みごとに処理された RX バッファー 真
rx_que_size 256 受信キューのサイズ 真
rxbuf_pool_size 384 受信バッファー・プールのサイズ 真
slih_hog 10 割り込みごとに処理された割り込みイベント 真
tx_que_size 8192 送信キューのサイズ 真
use_alt_addr no 代替イーサネット・アドレスを使用可能にする 真
RS6000側は100_Full_Duplexに固定にしているし、
ネットワーク機器側も100 Fullの固定になっている。
訳解かんね〜（怒）
理由が解らないないからいつものreboot。それから幾らやっても再現なし。
見なかったことにしよう。-:)
これでカットオーバーが無事に行くのか？
128(3): 120 2008/04/23(水)19:33 AAS
不思議なのはlsattr -El ent0で見ると
media_speed 100_Full_Duplex
なのに
netstat -v en0すると
Media Speed Selected: Auto negotiation
Media Speed Running: 100 Mbps Half Duplex
なんでやねん？
こんなことが毎日続く。
130(1): 2008/04/24(木)00:48 AAS
イーサネット勉強しなおしてこい
話はそれからだ >120
131(1): 120 2008/04/24(木)01:52 AAS
>>129
確かにトラブルの連続で凄くスキルが不足していると思う。
何でこんなトラブルが発生するのか理解できん。
>>130
何で100M Full固定と100M Full固定で接続しているのに方側のRS6000側が
Media Speed Selected: Auto negotiation
Media Speed Running: 100 Mbps Half Duplex
になり、collision counterが上がるのか？
これを解決するにはイーサネットの何を勉強すればいいのか教えて欲しい。
ネットワークはシロートなんで....
135(1): 120 2008/04/24(木)04:21 AAS
>>132
>サポートに問い合わせしてくれ。
>とにかく無駄なことをここに書き込むな。
ここに書き込むとOSがBugだらけってのがバレだからか？:-)
尻尾を掴もうにも現象が再現しないんよ。こんなときのサポートって
役にたたない。
もっと訳わかんねーのは
”何でトラブルで徹夜しなければならないのか？”
ってことだ。
137(1): 120 2008/04/24(木)04:59 AAS
>>136
>お前がまともな設定も出来ないうえに問題解決能力も無いＳＥだからじゃないか？
確かに問題は解決できない。オイラにできることは次の修正が出るのを待つだけだ。
では聞くが”OSのBugに遭遇しないまともな設定”とやらを教えてくれ。
139(1): 120 2008/04/24(木)05:53 AAS
>どんなOS使ってもバグに遭遇するのは当たり前、
そんなことは理解している。問題なのは信じられないケースでBugに遭遇することだ。
たとえばrootvgをミラーしている状態でupdate_allすると問題が発生する。
オイラはrootvgをミラーして使うのは普通だと思っている。レアケースではの
Bugはしょうがない。しかしズバリは修正を出す前にメーカーサイドのチェックで
十分に防げると思うのだが....
完全なテスト不足だと思っている。
>そうなったときにこんな所で愚痴らずにベンダーと解決（回避策）に取り組めばいい。
>それが出来るようになってからいっぱしの口を聞く様にしてくれ。
”修正が出るまで使うな”って報告（回避策）に対していっぱしの口を聞く様になりたい。
138は関係者か？こんな時間まで火消しに付き合うのも大変だな。
149(1): 120 2008/04/24(木)22:37 AAS
>update_allがこける原因をミラーリングに求めた根拠がわからん。
TL7に上げるときrootvgをミラーしているのだけ死んだから。
詳しいことはＧＷが終わってから調べるつもり
153: 2008/04/24(木)22:54 AAS
>>120みたいなトラブルになってる人はほんのごく少数なんだと思うんだけどな〜、
大体そんなにバグだらけだったらこのスレで十分祭りになるだろうし。
>>120が変な設定ばかりしてるとしか思えんな。
154: 120 2008/04/24(木)23:27 AAS
>>150
マジレスサンクス
最初はlsattr -El ent0の表示がおかしいと思ってodmgetしたんよ
name = "ent0"
attribute = "media_speed"
value = "100_Full_Duplex"
type = "R"
generic = "DU"
rep = "sl"
nls_index = 70
ODM的には正しい動きだった。じゃあ何故Media Speed Selected: Auto negotiationなったのかが問題。
普通Netが稼動中の場合、 smitすると
メソッド・エラー (/usr/lib/methods/chgent):
0514-062 指定されたデバイスが使用中であるため、
要求された機能を実行できません。
って怒られるから稼動中に変更したとは思えない。
それに現象それ１回だけで、どうやっても再現しない。何故Autoになっちまったかだ？
>大体そんなにバグだらけだったらこのスレで十分祭りになるだろうし。
>>>120が変な設定ばかりしてるとしか思えんな。
自分では普通の使い方だと思っているが....多分:-)
このネットのトラブルも普通に動いていたので
多分、他のユーザーは気がつかないのではないかな？
156(1): 120 2008/04/25(金)00:29 AAS
>>155
当然L1 UP L2 UPを確認している。もちろん最初も確認したしトラブル時の今回もだ。
pingも投げたてOKを確認した。なので普通に動いていると判断した。
しかし速度があまりでない。なのでnetstat -v en0した。そこで100M Full duplexなのに
collisionが上がっているから へ？100M Fullなのに何collisionって？
で100 Mbps Half Duplexで何じゃこりゃ？？
>ネットワーク関連の勉強を一からし直してきてくれ。
100M Full duplexで固定設定しているのにもかかわらずAIX側がAutoになったのかがワカラネー
じゃあ聞くが１から勉強しなおすとこれの理由が解るようになるのか？
俺は解決能力がないから155が馬鹿な俺に教えてくれ。
158: 120 2008/04/25(金)01:13 AAS
>>157
AIXやめたい。でも台数と上に動くソフトがそれを許さない。
俺の意思と反して組織がAIXとLinuxになっていく。
時々IBMと心中するきかよ！って思うことが....
6.1を動かして確認しなきゃならないこともあるし、このクソ忙しい時に
”ちょっとこんな現象があるんだけど解析してくんない？”ってこの俺に....
185に6.1乗っけたまんまで放置状態。WPARの動作をもっと確認しなければならないのだが....
時間は幾らあっても足りない。
160: 120 2008/04/25(金)01:44 AAS
>>159
上で動くタコアプリが6.1のWPARでもまともに動作するかだよ。
>WPARはLPMあってこそだと思うけどな。p5ならおとなしく53使え。
俺も同じ意見だが、それを許しちゃくれない組織なんだよ。
162(1): 120 2008/04/25(金)02:03 AAS
>161
解析しようにも再現もしない。これの解決策をどうだせばいいのか？
俺はスキルが無さ杉だから、言ったからには手本となる解決策を教えてほしい。
167(1): 120 2008/04/25(金)12:25 AAS
>>165
Cat2950でsh int f0/20しちおるがそれが何か？
>なんでなんの得もしないのにお前に教えないとだめなんだよｗ
>そうやってすぐに「俺が馬鹿だから教えてくれよ」とか言うところがダメＳＥの証拠。
ま、俺の悪い頭でも、お前の頭レベルじゃあ十分に説明できないってことは十分に理解しているから安心しろ
169(1): 120 2008/04/25(金)12:39 AAS
>いや、だからSTSCに聞けよ。
聞くのだったら別のチャネルがある。
問題はこちらが現象を完全に掴んでいないことだ。
100%の証拠を掴んでいればいつものごとく”ホレ”で言うが
証拠がないし、こっちも再現しようにもあれ１回で解析不能。
4.2.1から数々の問題を報告してきたが狼は１回もない。
つまらんことで汚点は残したくない。
170: 120 2008/04/25(金)12:52 AAS
他が遭遇してないのにIは修正を出すがそれが何か？
171: 120 2008/04/25(金)12:59 AAS
>デバイスが勝手にautoになるはずねーよ
だよなぁ....ボソ まったく再現しない時点で疑いは持っている。
過去のODMの設定が反映されていないってトラブルがあったのだが....
183(3): 2008/04/28(月)13:01 AAS
なんか荒れてるのかな、書き込みづらいな。
あるｼｪﾙで、ﾊﾟｽの正規化がいるんだけど、
AIXにはrealpathｺﾏﾝﾄﾞが無いみたい。
`pwd`とかでｺﾁｮｺﾁｮやるしかないぽ？
libc.aにはあるみたいだから作ればいいんだろうけど、
コンパイラが無いのよねぇ・・。gcc禁止だからややこしいわ・・。
>120
似たような状況（遅い）になったときは、
hub側のポート設定がAutoのとこにケーブル刺したとか有ったけどね。
AIX側じゃなくN/W側でなんかやったとかかもねぇ。
192: らびっと 2008/04/29(火)10:53 AAS
>>120
>問題はこちらが現象を完全に掴んでいないことだ。
>100%の証拠を掴んでいればいつものごとく”ホレ”で言うが
>証拠がないし、こっちも再現しようにもあれ１回で解析不能。
遠隔でマジレスだが、再現性や資料が無くてもサポート(STSC)に、
類似の既存情報が無いかと、再現時の資料収集手順は確認すべきですよ。
AIXを含めSTSC Callは一時点で10〜20件は平行して聞いていて、
門前払いも多いが、解決やヒントになる場合も多い。
プロならできる限りの手を打ってから、それでもNGなら
「すみませんが再現待ちとさせてください」では？
完全で無いと抱えてしまうのでは、職人だがプロではない。
198(1): 2008/05/01(木)23:35 AAS
>>120
7年くらい前のSolarisと5年くらい前のLinuxで同じような事象に遭遇しました。
Linuxの場合は、Auto設定にして直りました。
Solarisの場合は、SW-HUB の交換で直りました。
技術の進化と新旧混在の実装仕様に問題があると思いますが、
完全主義を目指して最適な方法をとらなくても、ある程度妥協も必要かと思います。
確実性を目指して固定にするより、Auto設定のほうが良いような気が〜
参考になるかわかりませんが・・・
外部ﾘﾝｸ[php]:www.atmarkit.co.jp
外部ﾘﾝｸ[html]:oshiete1.goo.ne.jp
↓この意見に賛成
----
基幹部分はAuto Negoの失敗を警戒して、固定にしてしまうことが多いですが（変更も少ないし）、
末端のワークグループスイッチでは逆にAuto Negoで全部やってます。
つまり、必要な部分以外はAuto Negoでやってます。
Auto Negoに失敗する機器は古い機材が多いので、
最近では下手に速度固定するよりAuto Negoにしたほうがトラブルの発生率は下がるのではないかと考えています。
202: 120 2008/05/04(日)15:49 AAS
>>198
うちのルールでは幹線で固定設定できるところは固定することになっている。
例えばサーバーとネットワーク機器との間は固定to固定で接続して
パソコンショップで売っている安いSW-HUBとの間だとAuto-to-Autoで
接続することになっている。
今回の現象は別の問題でAIX ODMでは100M/Full設定なのが何故動作が
100M/Halfになっちまったか？
これが問題なのです。で問題はそれ１回でそれからはまったく発生しません。
現時点での対応は原因不明扱いとしてシステムを起動してからちゃんと
100M/Fullになっているか確認することでOKって指示をしておきました。
そして100M/Halfだったらオイラを呼べと....
今は判明していることはAutoの切り替えの後だった。オペレーションは
慣れている人がおこなっておりミスは無いと思われる。
つまり何かの手順でおこなうとODMの情報がデバイスに反映されないことが
あるらしい。でも電源OFFからの起動では問題が発生しない。
どういう手順でおこなうと発生するのか？これの解明なのです。
再現無しで問題が発生しなってのは余計にやっかいなのです。
今世間はGWなのにAIXでない別の問題を抱えちまって、これまた頭の痛い状態なのです。
でもこっちは再現性100%なので問題が解明できそうです。
203(1): 120 2008/05/04(日)15:54 AAS
AIXとは関係ないのでここには書きのはちょっとと思うが....すみません。
現象
あるサーバーとサーバーとの間でftpを使ったファイル転送が大量に(と言っても約60GB/day)
おこなわれている。ファイル転送は1個も失敗しないが転送している途中で一瞬止まる。
これは何故か？これを調べてくれ。と言われてしまった。
解析するとL4でACKが戻ってこないでTCPがTimeoutして再送していることが判明。
驚いたことに問題を報告してこない別の組織でも同じネットワーク機器とサーバー
の組み合わせを使っている所があり、同じ現象が発生していた。
（つまり問題に気がついていない。）
Timeoutを検地しているのはftpdがファイルを送信しているときに送信側で発生している。
次はL3でチェック。サーバー側で送信したハズのパケットが受信側に届いていないことが判明。
（これじゃL4でTimeoutする訳だ。）
パケットはネットワーク機器でdropしている。原因を調べるとネット機器のInputでCRCエラー
１つは140171833中2845CRC Error 0.002%。もう１つは276601434中61117CRC Error 0.022%
僅かなCRC Errorなので運用上は問題がないと思われるが何故かが気になるし、
報告書を書かなければならない。CRC Error 0が普通の環境なのに....
つまりL2での問題。救えるのは両者が同じ組み合わせで発生しているということ。
同じ型番のネットワーク機器で同じ型番のサーバーと同じOSの同じバージョンで
ノミ問題が発生していること。
この手のトラブルは原因を解析しやすい。アナライザーをつないでCRC Errorを
拾えばいいからだ。
さて原因はネットワーク機器なのか？デバイスなのか？OSのドライバーなのか？
これを探すのも１つの楽しみである。AIXとはまったく関係ないのでこれでオシマイ。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 1.358s*