カテゴリー: ITめいたこと (23ページ目 (31ページ中))

この前、会社でThinkPadを買ったのでLenovoからDMが届くようになっていて、普段はぼんやりと読み飛ばしているんだけど、ふと、今日、読んでみたら、なぜか周辺機器をかなり安売りしてた。

5月22日までの週末限定クーポンってことだけども。

PC周辺機器（保守サービス、モニター、モニター用アクセサリー、バッテリー/電源を除く）が、キャンペーン価格より35%OFF！

…とのこと。

おぉ、35%って結構大きいじゃないか、ということで「ThinkPad USB トラックポイントキーボード」(55Y9024)を買ってみた！(実は、これの前モデルを持っているんだけど、しばらく使い倒していたら、エンターキーとかの跳ね返りが悪いというか、希に沈んだままになる始末…)

もともと、Lenovoのサイトで売っている価格は\6,300。それがキャンペーン(?)で\5,796になっていて、さらに週末限定クーポンを適用すると、\3,767。しかも、送料込み。確か、価格.com的な最安値はAmazon.co.jpで、\5,200くらいだったような気がする。

ついでだったので、ノートPCを持ち運べるバックパック(43R2482)も買ってみた。このバックパックはLenovoブランドだけど、ターガス製だったりするので、ま、いっかということで。これも、もともとの値段が「ThinkPad USB トラックポイントキーボード」(55Y9024)と同じ\6,300だったので\3,767。クーポンとキャンペーンがなければ、\12,600の買い物だけど、クーポンのおかげで、結局、\7,534。む、かなり安い買い物だったような。

…てか、大丈夫なのかな、Lenovo(汗)

レノボ・ジャパン ThinkPad USB トラックポイントキーボード(日本語) 55Y9024

posted with amazlet at 11.05.23

Lenovo (2009-08-25)
売り上げランキング: 1620

Amazon.co.jp で詳細を見る

postfixやBINDなんかの各種デーモンや、MySQLやApacheなど死んでもらったらとっても困る各種プロセスなどをどうやって監視しようかなんてことを最近ぼんやりと考えている。

システム監視と称してやりたいこととしては、だいたい以下の3つか。管理とは言いつつも、見張ってくれるだけでよくて、自動的にリカバリーしてくれってところまでは贅沢しない(涙)ということで。

• 死活管理
  • 気持ち的には「各種プロセスよ、死んでくれるな」と言いたいところだけど…、ま、もし死んだら通知して欲しい。
• リソース管理
  • いきなりDiskFullとかになっちゃうとイヤだけど、毎日、ディスクの空き容量を眺めるのもだるい。他にも空きメモリ量(…正確な数字を追い始めると深みにはまりそうなので、ざっくりと)とか気になる数字はいくつかあって、ある種の閾値を設定しておいて、もし、超えたら教えて欲しい。
• 流量(?)管理
  • Webサーバとかルータにどれくらいのパケットが流れているのか…というところも取っておきたいような気がする。何に使うかは微妙だけど、例えば、サーバの負荷が高くなっているときにソフトウェア/ハードウェアがおかしくて負荷が高くなっているのか、流入するリクエストが増えているのかくらいはさくっと切り分けられたらいいのかな…とか。

リソース管理や流量(?)管理に関しては、ヒストリーというか、数字の変化をグラフで見られるとうれしいかなぁとか思ってしまう。

結局、いろいろとWebを探してみたら、NagiosとMuninを両方入れた方がいいのかなぁという気がしてきた。Nagiosは「現時点」の状況を管理するのはできそうだけど、ヒストリー管理はあんまり協力じゃない気がするが(…って、使い込んでないだけなのかも…)Muninはほぼデフォルトに近い設定でも、いい感じのグラフを書いてくれそう(ただ、MuninはPerlモジュールをいろいろと入れないといけないのが面倒そうなのが辛い…)ただ、2本のアプリで監視するとなると、監視される側もちょっと面倒なのかもなぁと思ったりすると遠い目にならざるを得ず、ちょっとどうなんだろう。

一応、NTTデータのHinemosも運用管理できそうだけど、導入事例をちらっと見てみると、なんかちょっとジョブマネージャとして使われている事例が多いような感じ。「うち、ややこしいバッチをパズルのように組んだりしてないから、ジョブマネージャはとりあえずいらないんだけどなぁ」という状況なので、あんましフィット感はないのかも。Hinemosは、日立のJP1をオープンソースでリプレースするような用途にはいいのかもなぁ…という印象を受けた。まぁ、ある意味、NTTデータ出身のOSSらしいのかもしれず(汗)

あと、死活管理は、モノによってはロードバランサが担っている部分もあるわけで、その辺との棲み分けも考慮する必要がありそう。

私はmuninのことをどこでどう間違ったか【mumin】と覚えていて(汗)Google先生の検索結果に、例のムーミン谷の生き物がごろごろ出てきて、かなり途方に暮れていたとかいないとか(涙)いやはや、かなり痛い午後だった。…って、何の告白なんだよ。orz

昨日、会社のルーター(RT57i)がパフォーマンス不足になって、ちょっとややこしいことになったので、勢いよくRTX-1100に交換してみたら、きれいにはまった(涙)

まぁ、もともと使っていたRT57iの設定を流用しつつ、無駄なNAT設定や意味不明な設定を見直そうとしたときに、コンフィグに余計な設定を追加しちゃったのが原因だったことが後からわかる…のだが、ま、その時は気がつかないわけで(汗)

RTX-1100に交換して何が起こったのかというと、RTX-1100に交換してパフォーマンスの向上を期待したにも関わらず、すさまじいパフォーマンスのダウン。

とりあえず、つながっているんだけども、SFTPでファイルをダウンロードし始めたら、スループットがRT57iを使っていた時の10%くらいになってた(涙)

さらに、イントラネットのマシンからイントラネット側のIPアドレスにPingを打ったらRTTがすんごいことになった。ファストイーサネットなLAN(間に入ってるスイッチングハブが2つくらい)なのに、RTX-1100にPingを打つと600msとかかってる(汗)てか、太平洋超えても200msくらいじゃないのか…と。

まず、RTX-1100に余計なフィルター設定をしたんじゃないかと思って見直してみたが、その辺はRT57iの時と変わらず。RTX-1100にすることでハードウェア性能は向上しているはずなので、同じ設定であれば、こんなことは起きるはずもない。

イントラネット側のIPアドレス宛のPingのRTTがすんごいことになっているにも関わらず、RTX-1100のCPU使用率は10%以下のまま。RTX-1100自体が輻輳している訳じゃないことがわかった。

…で、設定を見ながら、ふと目にとまったのがこの1行。RT57iの頃にはなかった設定で、なんとなく追加した1行。

lan type lan1 100-fdx

この設定は、RTX-1100に搭載されてるイーサネットポートの通信速度を100BASE-TXのFull Duplexに固定する設定と。

そういえば、RTX-1100が刺さってるのは、非管理型のギガビットイーサ対応のスイッチングハブ…(汗)あ、やばいかも。

というわけで、この設定を

lan type lan1 auto

に、変えた瞬間にSFTPのスループットもPingのRTTも大幅に改善するわ…と。とりあえず、問題は解消。

なんか、最近、データセンター用のL3スイッチいじってたから、通信方式は固定すべきなんて無意識に思ってたのが仇になった。確かに、データセンタに置かれてるような(高い)スイッチは、スイッチ側で通信方式を固定させられるから、接続するマシンの通信方式を固定しても、うまく接続できるわけで…。一方、オートネゴシエーションにするとややこしいことになるから、わざわざ、スイッチとマシンに設定を施して固定するという背景があることも確かだしなぁ(遠い目)

ただ、ポートの通信方式を設定できないスイッチにマシン(とか、NW機器)を接続するときは、とりあえず、オートネゴシエーション設定にするしか選択肢がないんだろうなぁ…って、そんなことは当たり前ですか、そうですか(涙)

…やっぱり、ネットワークは難しいなぁと…。