第2案への切り替え

ども。
ようやく腕林檎が届き、「それってもしかして・・・」と声をかけられることが多くなってきた担当ちゅんです。

本日は久しぶりにPCの保守案件。「PCの起動にものすごく時間がかかるようになり、ついにはログオン画面を表示することもできなくなった」とのことでした。
利用していた職員からは「特に何もしてません」と繰り返し説明されました。昨今大きなニュースとなっているあの事案をうけ、PCが少しでも変な動きをすると「もしかしてウィルスでは」と心配している職員は、想像した以上に多いようです。

本案件では「急ぎの仕事があるので何とか早くあげてほしい」という要望もあったので、自分の仕事をほったらかして、とりあえず診察を始めました。
症状から察するに、これはまず間違いなくディスク障害だと予想しました。いきなりではなく「ついには」というのがポイントで、ディスクの障害が発生すると、徐々に症状が悪化していく印象を持っています。

まず通常に起動してみると、やはりログオン画面まで行き着かず、画面には「LogonUI.exe – 正しくないイメージ」というタイトルのダイアログボックスが表示され、「システム管理者に問い合わせてください」と。それ、私なんですが・・・。
その後、ディスクのクローンを作ってみると、何とかログオンはできましたが、相変わらずエラーメッセージは出続けました。とりあえずディスク障害で間違いなかったことがわかりましたので、ここからは「下手な鉄砲も数撃てば当たるモード」に突入し、セーフモードで起動を試みたり、スキャンディスクしてみたり、コマンドからsfcを流してみたり、挙句はインストールメディアからブートしてスタートアップ修復までしてみたのですが、一向に改善せず。ただ時間だけが過ぎ去っていく中で解決策を見出せないまま、試合終了間際で急遽方針転換。別なPCを用意して、データの引越し作業を敢行。予定より少し遅くなりましたが、無事にPCをお返しできました。

この業界、何かとあきらめが重要です。個人的なプライドやこだわりで事に取り組むのは決して悪いわけではないのですが、その結果、ユーザー側に不便をかけるというのはタブーですよね。いかに「第2案、第3案」を持っているか、そしてそこに大胆に方針転換できるかが、まさに「現場力」なのだと思います(と、自分に言い聞かせます・・・)。正直、解決できなかったことは悔しいですけどね。

エラー
結局、このエラーは謎のまま、リカバリーしてしまいました。

(投稿者:ちゅん)

カテゴリー: つぶやき | コメントする

せっかく修理するも爆音!

昨日は、落部つつじ祭り出没しておりました。残念ながら、つつじの花は見ごろを過ぎており、花より団子となってしまいました。まあ、それはそれで・・・楽しかったです。

さて「経年劣化、あっぶねー!」で書いた、P社の24ポートGiga-HUBの続報を。皆さんのご想像どおり、半田ごての出番となりました。それらしい?コンデンサを持ってきて交換です。それらしい?耐電圧は同じですが、同容量が無かったので、多少大きいので代用することに。物理的サイズとしては少し縦長な程度で作業は簡単。まあ、問題ないでしょう。勿論、チップの放熱器を留めるバネの基盤側フックもガッチリはんだ付けし直し完了です。

すんなり、電源は入ります。当たり前?LANケーブルを挿してTESTもOKです。Gigaでリンクしています。治ったぞ~!!です。わざわざ直した目的は、自席の足元にある同社の100Base-TXの24Pとの交換です。これで、また一つ100のHUBを撤去できるはずでした・・・。ところが、付けてビックリ!爆音です。サーバ室では気になりませんでしたが、静かな事務室では問題です。このHUB、40mm角のFANが2個付いているのですが、かなりうるさいです。特に片方は、ベアリングが参っているのか明らかな異音です。結局、FANレスの100Base-TXの24Pで暫く我慢し、サーバのジャンクからでも、FANを流用したいと思います。諦めが悪いです。でも、40mm角のFANに静音型ってないですよね?

コンデンサの交換は、上手くいったのですが・・・。
電解コンデンサ4個の交換は上手くいきました。今度はFAN・・・ですか。

(投稿者:92)

カテゴリー: つぶやき | コメントする

バックアップが終わらない原因は○○の不具合(下)

ども。
本日は前回の記事の続きです。よろしければお付き合いを。担当ちゅんです。

ディスク容量が大きすぎてバックアップに失敗していると思っていたのですが、どうやら原因は通信速度不足ではないか?と推測をたてました。
早速、実験開始です。まずは、転送速度が落ちている原因がファイルの送り側(ファイルサーバ)なのか受け側(バックアップサーバ)なのかを突き止めなければなりません。別なローカルサーバから大きめなデータをダウンロードしてみて、速度を確認します。

最初にバックアップサーバから。SMBでファイルをコピーしてみると、速度は300Mbpsを越えました。そもそも、リソースモニタのグラフのスケールが1Gbpsに変更されていました。これは正真正銘のギガビット・イーサネットですね。
では、次にファイルサーバ。同じファイルを同じ方法でダウンロードしてみたのですが、いくら頑張っても100Mbpsを越えません。スケールも100Mbpsになってます。ようやく、問題の核心に近づいたようです。どうやらファイルサーバのネットワーク周辺で何らかの不具合が発生しているのは間違いなさそうです。

こういうときに疑うのは、NICの不具合よりもむしろスイッチとかケーブルです。ギガハブの手前に100BASEのハブが挟まっていないか、ケーブルの施工不良で速度が落ちていないか。もっと初歩的なミスで、ギガに対応しているケーブルを使っているか、などなど。ボトルネックを探していきます。

L3スイッチのランプを見てみると、やはりファイルサーバのリンク速度は100BASEになっていました。原因がはっきりと判明した瞬間です。で、ケーブルを抜き挿ししてみるとランプの表示上はギガに。しかし、サーバ本体のイーサネットポートを見てみると、通常は左右のランプが点灯するはずが、右側のランプのみ消灯している状態でした。
このサーバはNICを2つ搭載していたので、試しにセカンダリのNICにケーブルを挿すと左右のランプが点灯しました。

原因はわかりませんが、どうも怪しいのはプライマリのNICのような気がします。とりあえず、そのポートを使うのはやめて、セカンダリに設定を移し、念のため「カテゴリー6」のケーブルで接続。
この構成でいつもどおりにバックアップを走らせると、速度はようやく300Mbpsを越えてくれました!
結局のところ、これってプライマリのNICが壊れたということなんでしょうかね。後から説明書を読んでみると、右側のランプは「1000/100/10ランプ」とされ、消灯の場合は「未接続、または10BASE-Tで接続中」と書いてありました。う~ん、残念ですがハードウェア障害として処理するしかなさそうです。

というわけで、バックアップが終わらない原因は「NIC」の不具合だったのでした。

不具合のNIC
極めつけは取扱説明書のミス?左側が緑で右側が橙に見えるのですが・・・。

(投稿者:ちゅん)

カテゴリー: つぶやき | コメントする

窓10は7月29日

年○機構のウィルス感染は、我々にとって他人事ではありません。システム的な問題よりも「無用なメールは開封しない。」と言う、基本的な・・・。でも、あそこまで「件名」や「発信者」を詐称されてしまうと、職員としては・・・。やはり、システムになりますか。早速にわかも、全職員に向け一層の注意喚起をGWで促しましたが、由々しきことです。

さて、次期窓系OSである「Windows 10」の公開(発売)日が、7月29日と正式にアナウンスされました。これにより、なんと窓八(8.1)のサポート期間も確定してしました。メインストリームが2018年1月9日、延長サポートはここから5年後の2023年1月10日までです。ちなみに、窓OSのサポート期間をまとめると次のようになります。今一度、ご確認ください。
Windows 最新・最終 メインストリームサポート終了 延長サポート終了
XP SP3 2009/ 4/14 2014/ 4/ 8
Vista SP2 2012/ 4/10 2017/ 4/11
7 SP1 2015/ 1/13 2020/ 1/14
8 8.1 2018/ 1/ 9 2023/ 1/10
過去の経験則から、我が社のメインOSである窓七から、窓八飛ばしで窓10への移行を画策中です。約700台の端末を、2020年1月までに何とかする大計画です。この窓の呪縛から逃れる術は、本当に無いのでしょうか?
 
ダウンロード予約
7月29日のアップグレードを予約出来る KB3035583 が配布され始めました。
 
(投稿者:92)

カテゴリー: つぶやき | コメントする

バックアップが終わらない原因は○○の不具合(上)

ども。
職場のクールビズ開始の号令にあわせて上着を脱いだ担当ちゅんです。

今回の記事は長くなるので、計2回に分けて投稿します(今日は上下巻の上ですね)。

先日から頭を悩ませていたのが、町内小中学校の集中管理ファイルサーバのバックアップ問題です。基本的に全学校の校務用データを16TBのWindows Storage Server に集約して管理しているのですが、このサーバのバックアップに時間がかかり、丸一日近くバックアップし続けても終わらないという状況になってしまいました。

でも、状況としては十分ありえる話です。仮に1Gbpsの速度をフルに使って転送したとして、

1024Mbps ÷ 8 = 128MB/s

ということで、1秒間に128MBしか転送できないということになります。1分だと60倍して7.7GB、1時間だとさらに60倍して460GB。2時間かかっても1TBの転送すらできないのです。無圧縮で16TBを転送しようとすると35時間かかってしまう計算です。しかもこれはあくまでNICの通信速度から計算した「理論値」で、実際にはディスク速度なども影響して1Gbpsなど出ませんから、もっと時間がかかるということになります。

さて、どうしたものでしょう。とりあえず、日々のバックアップは「差分バックアップ」とし、専用のソフトウェアを使って圧縮転送していますが、夜の10時から翌朝7時までの9時間でなんとか終わらせたいところ。それを前述のように計算してみると、

9時間 × 460GB = 4TB

・・・って、あれ?4TBものデータを転送できる計算になります。何かおかしい。差分ファイルが4TBになるなど考えられませんし、まして丸一日たっても終わらないなどありえません。
ふと、バックアップ稼働中のサーバのタスクマネージャからパフォーマンスを確認してみました。すると、理由はわかりませんが、リミッターがかかったかの如く、通信速度が99.6Mbpsでビタッと天井に張り付いています。1GbpsのNICなので、少なくとも100Mbps以上、理想では200~300Mbps程度で通信していなければならないのに、これは明らかに異常。何かがボトルネックになって100Mbpsに速度が落ちているのでは!?

こうした推測のもと、いよいよ原因究明に乗り出したのでした・・・次回に続く。

原因調査
速度が遅いときは、冷静に計算してみると色々わかってきます。

(投稿者:ちゅん)

カテゴリー: つぶやき | コメントする