この状態での消費電力は、データシート上の数値で行くと
毎日飛んでくるDaily reportを見ていると、結構な数の記事がRejectされている。
最も多いのが「Posted in the future」（未来に投稿された記事）というやつ。
どうやら、投稿者のPCか、投稿を受け付けたサーバの時計がずれているらしい。
受け付けてしまうサーバもどうかと思うが、INNの判定基準が厳しすぎるのかもしれない。
こいつの許容範囲を広げるためには、INNをコンパイルする前にヘッダをいじらなければならないようだ。
具体的には「include/acconfig.h」の「DATE_FUZZ」という許容範囲を秒数で定義している定数を変更する。
デフォルトは「24L*60L*60L」、つまり1日のようだ。
24時間のずれを許しててもあんなにエラーが出るのか･･･。
というわけで、エラーになった記事の大半は2日以内らしいので、2日まで許す設定に変えてみる。
変更したら、再コンパイルして入れなおし。
INNに標準で付属するMail to Newsコンバータ「mailopost」。
メーリングリストとかcronから飛んでくる定期ログなんかをニュース記事に変換するのに使える。
こいつで、延々たまり続けるsuckのログを、変換して送り込んでしまおうと考えた。
先に「local.sucklog」というグループを作った上で
/etc/aliasesにmailpost用のエントリ
sucklog: "| /usr/local/news/bin/mailpost local.sucklog"
# echo test | mail -s "suck log" sucklog
inews failed: /usr/local/news/bin/inews: Permission denied
というエラーメールが届いた。googleで調べてみると、最近のINNでは、inewsのパーミッションが異なるとのこと。
inews failed: inews: warning: What server? inews: article will be spooled inews: cannot create spool file: Permission denied
server: localhost
2003/07/15 新品HDDに不良セクタ
だいぶ間が空いたがようやくストレージ関係が落ち着いてきたところで、まとめておくとしよう。
現在は、各RAID装置の共有をやめて、単体で使用している。
dsは、データ用ストレージとして120GB x 7のRAIDを占有。これをSambaで共有した。
以前、nsとdsで共有していた80GB x 3のRAIDは、160GB x 3のケースとして使用し、余ったIFT-3102UAでRAID5とした。
こいつはメインマシンのデータディスクとして使用。
さて、色々なデータが日々ため込まれていく現状では、RAIDですべてまかなうにも限界がある。
もともと購入した160GBは4本で、そのうち3本はRAIDとして使用しているため、1本余っていた。
（というか、ホントは4本でRAIDを組む予定だったのだが、PCIタイプのカードは全部駄目だったので、3102になった関係上、ベイ数が足りなくなったから。）
とりあえず、この160GBをメインマシンに単体で内蔵し、消えてもいいデータをまとめていたのだが、毎度のごとくこいつもいっぱいになってきた。
しかも、ほぼ同時期に160GB x 3の方も、逼迫しつつある・・・。
そんな折、オークションでIFT-2101U2を発見。こいつが有れば、外付けコントローラが要らなくなるではないか。
そして気がついたら落札していた。
んで、早速IFT-3102UAを取り外して、IFT-2101U2を接続。
ファームウェアのバージョンがIFT-3102UAの2.23から2.12にグレードダウンするので、既存のRAID構成を認識できるかどうか不安であったが、問題もなく正常に認識した。
（ここで正常に認識できないと、データをどこかに待避してRAIDを再度構成し直す必要がある）
ついでに、内蔵ディスクの容量アップも目論んで、200GBのHDD「6Y200P0」を買ってきた。
こいつに160GBのデータを移してやって、空いた160GBをRAIDにExpansionで追加しようと言う計画だ。
しかし。
このディスクはハズレだった。
新品のくせに、当初から不良セクタがあるわあるわ。しかも、ECCエラーやらCRCエラーやらを大量に吐き出し、とうとう認識しなくなってしまった。
こんなもん出荷しているようで、大丈夫なのか？Maxtorよ。
とりあえず、ディスクを交換してこなくてはならないので、それが終わってからまた追記することにしよう。
ACARDからまったく返事がないので、仕方なくExpress 200 + 7720UWの作戦はあきらめる。
とりあえずブートディスクを入れ替えて、消費電力を低減させるほうのアプローチで進めることにして、オークションを徘徊･･･。
3wareの6200が比較的安かったので、これをゲット。
予定通りDJSA-210を2台使用して、ミラーリングする。
前と同じ方法で入れ替えて作業は完了。
あとは来月あたりの予算で少し大きめのディスクを買って、ミラーリングをもう1セット作って内蔵すれば完了といったところか。
そのときはnsとdsの電源ユニットとRAIDカードを交換しなくては。
いくら低消費電力とはいえ、Micro ATXの電源ではそれだけのディスクを回すのはやや不安が残る。
nsに入っている電源はたしか300W位のやつが入っていたので、dsのと入れ替えればちょうどよいはず。
RAIDカードも、nsの方を先に組んだので、6410を使ってしまっている。dsのほうの6200と入れ替えれば、無駄がない。
ns.artin.nuのほうは、ブートディスクの入れ替えを完了。
入れ替え方は簡単。
１．新しいディスクの領域を切る
sysinstall実施前
Filesystem Mounted on /dev/da0s1a / /dev/da00s1f /database /dev/da0s1d /data /dev/da0s1e /data/www /dev/da0s1g /tmp /dev/da0s1h /var「/stand/sysinstall」で、ディスクを切ってnewfs。fdiskで領域を切るときは、最初に実際のマウントポイントとサイズを決めて、割当を終えてからマウントポイントを変更するのが吉。
twed0s1a / 1536MB twed0s1e /database 512MB twed0s1f /data/www 512MB twed0s1b swap 512MB SWAP twed0s1g /tmp 64MB twed0s1h /var 1024MB twed0s1d /data 33986MBかといって、このまま「w」でnewfsしないこと。newfsが完了した段階で、sysinstallが自動的にマウントしてしまい、sysinstallを抜けるとすっからかんの「/」になってしまう。（元の「/」データが消えたわけではないのでリブートすれば直るが）
twed0s1a /raid/ 1536MB twed0s1e /raid/database 512MB twed0s1f /raid/data/www 512MB twed0s1b swap 512MB SWAP twed0s1g /raid/tmp 64MB twed0s1h /raid/var 1024MB twed0s1d /raid/data 33986MBこれで「w」すれば、newfsが始まって、終わったあとで自動的にマウントされる。
Filesystem Mounted on /dev/da0s1a / /dev/da0s1f /database /dev/da0s1d /data /dev/da0s1e /data/www /dev/da0s1g /tmp /dev/da0s1h /var /dev/twed0s1a /raid/ /dev/twed0s1f /raid/database /dev/twed0s1d /raid/data /dev/twed0s1e /raid/data/www /dev/twed0s1g /raid/tmp /dev/twed0s1h /raid/var
とりあえずns.artin.nuのブートディスクを入れ替える。
購入してきたのはIBMの2.5inch HDD「IC25N040ATCS04」（40GB）x2。
それからM/Bを１枚。AOPEN製のMicroATX M/B「MX36LE-UN」。VIAチップセットな上にOnboard LANがカニなので、本来なら買わないところなのだが、
使いたいCPUが低消費電力の雄「VIA C3」なので、とりあえずVIAのを買っておかねばなるまい。同じくAOPENのMX3S-Tも有るんだが、こいつはC3に対応しているとか言いながら起動すらしなかったので、使用不可。
で、購入してきたMBを早速ケースに取り付け、Escaladeを組み込む・・・。が、EscaladeのBIOSが起動しない。MX3S-Tを引っぱり出してきて載っけてみると、正常に動くことからどうやらチップセットかM/Bと相性が悪いらしい。
購入してきたM/BのBIOSは最新だったので、とりあえず起動できるMX3S-Tにさして、EscaladeのファームとBIOSをあげてみる。
無事、ファームをあげ終わって、MX36LE-UNに戻してみると、あっさり起動。こういうときやはりIntelチップセットって業界標準なんだと実感。業界標準以外を使うと、こういうリスクを負うわけで。
とりあえずRAID 1に設定、イニシャライズを仕掛けていったん終了。
ファイルサーバにキャプチャした動画がたまり始めたせいか、ディスク容量が足りなくなってきた。
とりあえずニューススプールの保存期間を短くすることで対処するも、いま部屋にあるビデオをすべてキャプチャしたらこんなもんじゃ足りない。
スプール期間も、alt.binaries.*は短くできるが、alt.freedom.*はneverになっている関係上、増えることはあっても減ることがない。最近活気がないので、以前ほどの勢いはないものの、それなりの容量。
そこで、ディスクの増設を目論む。
かといって、単純にディスクを増やすのは難しい。
まず、設置スペースの問題。
メインマシンと共有している外付けRAIDは8ベイのSCSIケースだが、RAIDコントローラと7台のディスクですでにいっぱい。
新規にケースを増設するにも、置くスペースがない。
RAIDコントローラも、外付けをまた買うには時間がかかるし、内蔵のPCIタイプはスロットの空きがないので刺せない。
次に消費電力の問題。
親に電気代を払わせているという政治的・経済的（？）都合と、接続UPSの容量という技術的都合の観点から、消費電力は極力抑えたい。
となると、現在有るディスクのリプレースになるわけだが、これがまた面倒くさい。
既存のデータを移行する作業が必要になるから、その時点では両方が同時に使えなくてはならない。
結局、接続の問題があるので、これも難しい。
さて、どうしたものか。
まずは現在の構成図。
この状態での消費電力は、データシート上の数値で行くと
| コントローラ | 構成ディスク | 合計消費電力 | |
|---|---|---|---|
| 左側のRAID 各サーバのブートディスク | IFT-3102UA 31VA | Seagate ST380020A x 3 7.5VA x 3 = 22.5VA | 53.5VA |
| 右側のRAID データディスク | IFT-3102UA 31VA | Maxtor 4G120J6 x 7 5.17VA x 7 = 36.19VA | 67.19VA |
まずは、設置スペースの確保の観点から行くと、左側のRAIDを廃止して、各サーバのディスクをそれぞれ内蔵のものに切り替えるのが良さそうだ。
内蔵のディスクのミラーリングは、SCSIにでもしたいところだが、SCSIにすると消費電力が跳ね上がるので却下。RAIDカードが余っているので使いたいんだが、残念。
次に、各サーバに内蔵するディスクの新しい構成。
消費電力の観点から、ノートPC用のディスクがよいのではないかと考える。
IBMあたりの40GBなら1発あたりの消費電力は2.3VAと、3台使ってもSeagate１発分でお釣りが来る計算だ。
MRTGでここ数日のディスクの使用量を監視してみたが、ns.artin.nuのニュースフィード時のデータ量は、ピークで全容量の5%。つまり140GBのうち7GBほどしか使用されていない。
ブートディスク分や、dsトラブル時の予備スプールを含めても40GBなら十分まかなえそうだ。
ds.artin.nuのほうは、データディスクには別のRAIDが有り、ブートディスク分しか必要ない。
これなら10GBもあれば足りるだろうと言うことで、以前購入したDJSA-210 x 2を流用することにする。
このディスク、オークションで購入したミラーリングユニットで使用するつもりで購入したのだが、このユニット自体の使い勝手が悪く、実稼働経験がほとんどない。
今頃になって使い道が出てくるとは思わなかったが・・・。
各サーバのミラーリングについては、3wareのEscaladeが2枚ばかし余っているので、久々に登板を願うことにする。
監視機能が充実しているし、なによりまともなエラー処理がされているハードウェアRAIDだ。
秋葉原で格安の値が付いているPromiseやらHighpointやらのカードは、ディスクが完全に故障しないとエラーにならなかったり、不良セクタに当たってフリーズしたりと、まったく使い物にならない。
さて、この段階での構成図がこれ。
消費電力は
| コントローラ | 構成ディスク | 合計消費電力 | |
|---|---|---|---|
| ns.artin.nuの内蔵RAID | 3ware 3W-6410 7.5VA | IBM 40GN 40GB 2.3VA x 2 = 4.6VA | 12.1VA |
| ds.artin.nuの内蔵RAID | 3ware 3W-6400 7.5VA | IBM 20GN 10GB 2.3VA x 2 = 4.6VA | 12.1VA |
さて、肝心のデータ領域の増設だが、今までブートディスクになっていたSCSI RAIDのケースが空いたので、コントローラをはずして160GBのディスクを3つ入れてRAID5にするのがよいかもしれない。
現在は、右側のRAIDのうち、240GBを割り当てているから、160GB x 3でRAID 5を組めば320GBになって、80GBの増設になる。本来なら200GBでも組み込んでやりたいところだが、価格が圧倒的に高いので、断念。
ここで問題が発覚。
現在出回っている160GBのモデルは、現在使用している120GBに比べて、消費電力が倍であることが判明。（4G120J6が5.17VAなのに対し、4R160L0が10.18VA。7200回転モデルの6Y160L0に至っては12.23VA）。
これだと、まえのブートディスクの80GBx3をそのまま流用して、データディスクにした方が消費電力的によいと言うことになる。
できれば１つのボリュームとして使用したかったので、あえて160GBの使用を検討したのだが、この状況では無理っぽい。予算にも限りがあるし、今回は妥協するか・・・。
PostgreSQL 7.3がリリースされた。
7.1以来あげてなかったので、アップデートすることにする。
pg_dumpallですべてのデータベースのデータを取りだしたあと、既存verのディレクトリをリネームしてからインストールする。
インストール自体は非常に簡単。
最近のバージョンは、gmakeを指定しなくても、makeで勝手にgmakeを探してくるようになったらしい。
しかしgmakeを入れておく必要があることには変わりない。
データのリストアでハマる。
どうやらPHPから書いていたデータベースのデータが、SJISとEUC混在になってしまっていたらしい。
initdbの際、EUC_JPを指定していたので、SJISのデータを見つけると、不正なコードとしてはじいてしまう。
結局、ダンプデータのなかに、
SET CLIENT_ENCODING to 'SJIS';と記述することで、PostgreSQLにEUC変換してもらうことにした。
忘れないうちに、今後はデータをEUCで確実に保存するようPHPコードを直しておく。
というか、同じくCLIENT_ENCODINGをEUCにするようSQLを追加しただけなんだが。