我が家には7台(のはず)ある。そのうち電源を入れる機会のあるものは3台。その3台のうち、最も稼働の少ない1台を親戚に譲る運びとなった。残りの2台はノート型とデスクトップ型。このデスクトップ型は少々古いものの、64bitCPUで、まだまだ現役で使いたいマシンである。このマシンにハードディスクを装着し、譲るパソコンのパックアップを確保することにした。

 

この64bitマシン、一度電源ユニットを交換したことがある。その際、原因を特定するまでにマザーボードのリセットとかして、その後電源を入れてからWindowsの画面が出るまでににえらく時間がかかるようになってしまったが、そのまま使っていた。

ATAはマスターもスレーブもないので、とタカをくくって500GBのものを購入したが、正常に使えるようになるまで3日かかってしまった。ハマッたポイントなどを紹介する。

 

<起動しなくなった>

HDDを接続して電源を入れると、Windowsが起動しなくなった。マザーボードの転送速度が1.5Gで、HDDが3.0Gなのが影響だろうと思い、ジャンパーピンを探し出して1.5Gに装着。これでWinddwsは起動するようになった。

しかし、Windows上では見れないし、BIOSでも認識していないようであった。

 

<SATAの設定?それ何?>

BIOSでSATAを有効にするらしい。が、BIOSのリセットとかした影響だろうか、そんな設定項目はない。BIOSを最新のものに載せ替えることに。BIOSのアップデートは危険と言われるが、最悪はまたリセットすればいいし、と軽いノリで実施。アップデート後のベリファイがえらく長いので電源を強制OFFし起動。チェック処理が実施されたがアップデートできた。BIOSの項目がガラっと変わるとは!

参考まで。以前のBIOSで設定していた値はきれいに消えていた。Windowsではどのデバイスも「新しいハードウェアを認識しました」で、USBマウスをつないで電源を入れたら起動しなかった・・。

これでSATAらしき項目が出てきた。

 

<RAID?そんなもの構築してませんが・・>

なんだかRAIDどうのこうのという項目がある。調べるとRAIDコントローラーもオンボードで用意されており、RAID 1 / 0 が構築可能だそうだ。そういうマザーボードだったんだ!先々はデータサーバーにしようと目論む。

BIOSでRAIDではなくATAにして起動。

しかしBIOSでも繋がっている様子はない・・。

 


<寄り道 LANカードのドライバ>

上記作業を終えると、インターネットにつながらなくなった。LANカードのドライバがない、とのこと。オンボードなのに・・。もう一台のマシンでダウンロードし、セットアップ。マシンが一台だったらこれで作業が止っていたな、と冷や汗。


 

<RAIDコントローラーとオンボードSATA>


マザーボード上のSATAは4口。ATA1、ATA2、SEL1、SEL2とある。前者2つと後者2つでコントロールしているチップセットが違うらしい。ATA1に接続していたが、これはRAIDコントローラーのチップセットが支配するもの。これもATAとできるのだが、ATA1からSEL1に変更。

これにより起動時のBIOS画面にHDDが容量と共に認識されていることが確認できた。が、Windows上からは相変わらず見られない。

 

<SATAのドライバが必要?>

インターネットを検索すると、SATAを認識させるにはOSインストール時にF6キーでドライバを入れないとダメだとか・・。ああ、面倒だなと思う反面、そういう面倒なものなはずはなかろう、と思いよくよく調べると、SATAを起動ドライブにする場合に必要だそうだ。今回はデータ用ドライブなので関係ない。

 

<八方塞がり?>

更に調べると、atapi.sysのバージョンが古いとダメとか、マザーボードが48ビットLBAに対応していないと147G以上は認識できないとか、色々あるが、BIOS自体が500Gを認識しているのだからその線は薄いだろう。

RAID構成にする訳ではないが、RAIDドライバを入れた方がよいらしいとの情報で入れてみる。が、やはりダメ。

 

<マニュアルから推測>

日本語マニュアルを読んでいて、何となく「やっぱりHDDはマザーボードのSATA1に接続してみるか」という気になった。

電源を入れると、先ほどまでは認識されていたドライブが「no device」となる。アカンかなと思いつつ、Windowsで認識されているか確認すると、なんと認識されていた!それも500Gフル。

なお、確認は[コントロールパネル]-[管理ツール]-[コンピュータの管理]の[記憶域]-[ディスクの管理]でチェック。ここで早速フォーマット開始。

 

このあたり、ネットでも断片的な情報しかなく苦労した。参考になれば。

 

 

 

 

 

 

 

 

例えばブログでアクセスカウンターも、どの検索エンジンからどんなキーワードでいつ到達したかの情報も、どうやっているかというと、とどのつまり「ログを確保しているから」表示できるのだ。

既存のシステムを見ると、ログはデバッグのためのものばかりであり、中堅のエンジニアの意識もデバッグ目的でしかなかった。内部のシステムのログは不要だと考えているエンジニアものもいた。

 

ブログなどのWebシステムではログが活用されているのに、内部処理のログには関心がないようなのだ。

 

昔、汎用機のバッチ処理を開発していた頃。バッチプログラムの処理順序をJCLに書いて実行させると、ジョブ*1 の開始終了もジョブステップ*2 の開始終了も記録されていた。プログラム側では処理した入出力件数を記録していた。

今になって思うのだが、正常系のログであっても

・処理能力の計測やボトルネックの発見

・処理件数の確認

・実際に動いた、という証拠

など、役立つ情報が結構記録されているのだ。例えば処理が遅い、と言う場合でも、単に遅いという定性的な情報ではなく、どこでどんなくらいの時間が掛かっているのかという定量的な情報を確保することができるのだ。こういう記録をしないで運用改善を行うのは困難ではないだろうか?

 

ただ、どういうログを確保すればいいのか、情報としてまとまっているものはない。システム監査においてもログから情報を取るのだが、どのような情報が有効で、こういうログは取りなさい、という指針や具体例は見つけられなかった。

ログについても何か指針を作ってみようかと思う。が、いつになるうやら・・。

 

<ざっくり解説>

*1 ジョブ: JCLで書いたファイル1つか1ジョブである。 

*2 ジョブステップ: JCL内で実行するプログラムの数。例えばプログラムを5つ動かすならジョブステップ数は5となる。

私の無知かも知れないが、Web アプリのサーバーサイドの処理であるが、.netは良い選択ではないのでは?と思っている。

そう考えるに至ったのは先日、Tomcatがリソースを管理していることを知ったのがきっかけだ。リソースを管理することで他の処理に悪影響を与えないとともに、自分の処理のリソースを確保する、ということをしているのなら、Javaは安定して稼働させることができる。

しかし、プログラムが取りたいときに取りたいだけのリソースを掴める可能性があるようでは、安定した運用という意味ではリスクがあると思うのだ。

 

汎用機でのJOB管理を知っている立場としては、UNIX系はあまり運用管理ソフトであまりいいものがないように思う。オープン系でも運用管理がしっかりできるソフトがあれば、汎用機が残っている牙城は完全に崩れるのではないか、とも思う。