HrsTのあれこれ

某大手ウイルス対策ソフトのサーバ対策製品の費用を一覧にしてみた。 このサーバ対策製品は、サーバにアクセスするクライアント数によって費用が決定するため、小規模は小規模なりのコストで良心的な価格設定となっている。 管理者側の立場からして扱いやすく、世間のイメージとは違い私は好きな製品だということを宣言しておく。 今は知らないが、コンシューマ向けは一番嫌いな製品かも・・・ この製品はクライアント数5～24, 25～49,50～99 と増えるごとにレベル分けされ、個々の単価が設定されている。 何も知らないユーザーと気の利かない営業担当の場合、正直にクライアント数でライセンスを購入することでしょう。 たとえば、クライアント数が450台だった場合、まじめに買えば110万円支払うことになる。 でも表を見るとわかると思うが、500台分購入すると69万円で済む。 さて、貴方が購入するときどうするのか？50台分多く見積もるだけで安くなる。 厳密にいえばNGかもしれないが、近々購入予定があるとか適当な理由を付けて買ってしまえばよいと思いませんか？

  ネットワークって正直通信ができれば問題ない。そう思ってます。 でも、ネットワーク管理者としてはそれだけじゃ勤まらないと思います。 医者がカルテを作成するように、ネットワークも経過観察が重要です。 ネットワークの状況を見るというのは瞬間のパケットを見るではなく、トラフィックの推移や各機器のCPU利用率などを長期的に観察し、「いつもと違う」を発見することです。 そこでおすすめなのが「MRTG」Perl上で動作するので、Windowsでも利用可能です。私はWindows2008R2上で要所ルータ、サーバを監視しています。（会社方針でPC UnixがNGなんです） さらにメールサーバや各機器からのLogをSyslogで集め、特定メッセージをカウントすることで、メールの流量やエラーの数なども監視し、トラブルが発生したときの状況把握に役立てています。 メールのエラー量を監視していると、ユーザアカウントが乗っ取られて迷惑メールを送信しだしても、あれ？いつもと比べて送信数が多いし、User Unknownが多ければ無差別に送信していることが目に見えてわかるのです。 これを数値ではなくグラフという形で表現してくれるのが、MRTGなのです。 ただ、MRTGは1つのグラフに2種類の整数しか表示できない点が、グラフ化において問題になることがあります。 そんな時はRRDTOOLを利用すると複数の値を表示できるのでお勧めです。 でも、その分いろいろ設定する必要はありますけど・・・ 最後に、いくつかの専門書などではMRTGで設備増強のタイミングを予測するなんてありますが、一般企業で問題なく使えているネットワークではこの目的で役立った経験はまだありません。（サーバのメモリやCPU、ハードディスク監視では大活躍ですけどね）

  Pingを打つと応答時間がわかる。 これは素人でもしっている人が多く、ホームページの表示が遅かったりしたときに、「Pingで応答時間が数百ミリ秒かかっている。ネットワークが遅いんだ！！」って文句を言ってくる人がごく稀にいる。 まぁ、間違っているとは言わないけど、Pingの応答時間だけで判断するのは安易すぎます。 PingってLANだと<1msなんて結果が返ってくるので、時間がかかる＝ネットワークが遅い。って思いがちですが、Pingの応答時間はその機器の処理能力によって変化することを知るべきです。 たとえばCPU使用率が100％の機器にPingを打つと応答がないとか、非常に時間がかかることがあります。 だから、 応答時間が長い＝　ネットワークが遅い または Ping先に問題がある と思った方が正しいと思う。 技術者としてはユーザ意見として受け止め、輻輳なのか障害なのか、サーバ側、ネットワーク側などと切り分けを行い、原因を特定し、解決および解答すべきですね。 なぜPing応答が遅かったのか？その答えを探ることが出来るのは技術者であるあなたです。   あとNW導入工事の完了試験項目で　Ping応答数ミリ秒以下なんて基準を決めたら、これで不合格になって困ってしまうこともあります。　あくまでPingは 応答があること 。にしておいた方が安全です。あくまで疎通確認のコマンドだということです。 上司や取引先などから応答時間を条件に求められた場合は、慎重にPing先と応答時間を検討すべきですね。 出来れば、サーバやルーターを避け、負荷の非常に低い専用端末を用意することをお勧めします。 また、試験中は他のトラフィックが流れない状態で実施するべきです。 あと、Ping回数も最低限にすること。「50回でタイムアウトが発生しないこと」なんて条件を付けると、試験だけで50秒は必要ですし、たまたま1回タイムアウトが出ると、もう一度やり直し。試験時間が無駄に増えるだけです。   ネットワークが開通した直後って、興味のある人はどのくらい早いのだろうか？とか調べて通常より負荷が高い状態になっていることが多いのです。そんな条件の悪いタイミングに試験を行って、万が一不合格となった場合どうしますか？

  どこかでトラブルが発生したとき、その原因となる機器を見つけたり、回復（疎通）確認に便利なのが、Pingコマンド。 Pingがなぜ便利なのか？　多くのOSに標準で実装されているので他人のパソコンでも利用できる点だと思ってます。 Pingの使い方 １．目的の機器の疎通確認 これはよく使うのですが、「○○サーバにつながらない」なんて連絡があったらとりあえず、そのサーバに対してPingを打つことで、サーバの死活確認を行う。応答があればアプリ側の問題。そうでなければNW側と思って良い。 ２．応答時間によるNW状況の把握 Pingの応答時間は応答する機器のCPUの状況によって大きく変化するので、参考程度にしかならないが、遅延が大きい時や輻輳が発生しているときは、その機器はほかに比べて時間がかかることが多い。 ３．故障機器を探す NW構成図を参考に、手前または遠くからPing応答可能な機器に疎通確認を行い、どの機器と機器の間に問題があるかを探すことができる。手前から調べれば、応答がなくなった機器とその前の機器が怪しいことになる。 ４．DNSの確認（nslookupコマンドの代わり） nslookupやdigコマンドを使うのが本当だけど、名前解決がちゃんとできているかを確認したり、このサーバのIPアドレスなんだっけ？と思った時に使える。 Ping \\Server 　や　Ping server.local など打てば、IPアドレスを教えてくれる。

ネットワーク技術者として必要なパソコン。何でもいいです。 現場で作業することがあるのでラップトップであれば・・・ あとはシリアルポート。 いわゆるRS232C。 これ、本当に必要です。 LANポートより重要です。 多くの企業向けのネットワーク機器は初期IPアドレスは設定なし。 DHCPクライアントの設定も入っていません。 ファイアウォールならDHCPが動いていたり、初期IPアドレスが設定されていたりしますけど、 ルータやスイッチ製品は全く設定が入っていない状態が多い。 だから、シリアルポートで設定を始めます。 最近のラップトップパソコンにはシリアルポートはついていません。 だから、USB接続のRS232Cポートは必須です。   これってめんどくさくない？って思われると思いますが、 どんなIPアドレスが設定されているかわからない機器をするときに楽なんですよ。 ドキュメント見ても初期設定しかわからないよ 現在のIPアドレスがわからないってことは、どうやって同じセグメントにパソコンを設定するの？ WireSharkでパケットキャプチャして調べますか？ 自発的にパケットを出さない機器だったらどうします？ シリアルなら通信速度を9600bpsにすればほとんどの機器は応答があります。 応答なくても、いくつかの速度に切り替えればよい。 あとはコネクタを見ればケーブルがストレートかクロス、RJ45が分かるので３種類持ってればよい。 ね。楽でしょ？ まぁ、複雑な設定を行うときはブラウザのほうが楽ですけど、 設定が分からない時はまず、シリアルでコンソールポートにつなげてみる。 いち早く自分の制御下に置くってことが重要なんですね。

今はMovable Typeを使って本文以外は自動生成していますが、その前は手書きだったり、フリーのCGIを使った日記だったりと、結構な手書き部分がありました。ブログ中心になる前はそうだったと思います。 まずはHTMLを手書きするのですが、店頭に並ぶ書籍はIE4/6専用とかNNのみとかタグに情報が付加されて、このブラウザだったらこういう書き方をするとか、特定ブラウザに向けた内容が多いので、ページの下のほうに「このホームページはIE4で確認しています。」とか書いていました。 今ではそういうブラウザ指定をすることが減ってきいると思うのですが、ソースを見ると、ブラウザ個別のスクリプトがあったりして苦労しているなぁ～と思います。特に高機能化しているので、その辺の努力は感心しますね。   私も以前はそういった本を見ながら作成していた時期があったのですが、途中からそういう本は一切見なくなりました。で、そのきっかけとなったのが「正しいHTML4.0リファレンス&作法」って本。 この本を読んで、W3Cを参照するようになりました。 で、その時に使っていたのが、「 Another HTML-lint 」というサイト。 文法チェッカーを使うことで、可能な限り正しい文法で手書きする。 正直、コンテンツより、この文法チェッカーで高得点を取ることが目的になって更新するという状態。   「このサイトは Another HTML-lintによるチェックを行い正しいHTMLで記述しています 」なんて書いてしまって・・・ 今思えば、○○ブラウザに最適化していますってのと一緒ですね。 知人に「なんかレイアウトがおかしいところがあるよ」って指摘されても、「ブラウザが悪い」って解答してたあたりは最悪ですね。 俺は正しい文法で記述しているんだから、きれいに表示できないのは、正しい表現のできないブラウザの責任 まさに、宗教。 お恥ずかしい・・・ しばらくすると、ブログが流行りだして、日記をネットに公開するようになりました。でも、はじめのころは手書き、そのうち日記CGIを使って、携帯で更新できたらいいなぁ～ってyaplogを使い始めて・・・。このころから正しいHTMLを記述することが事実上不可能になり、Movable Typeに移行してからはすべてのページについて「気にしても何もできない」状態になりまし