2024年11月18日 | EOS R7ファームウエアアップデート |
2024年11月17日 | PX-M730Fのシアンインク交換 |
2024年11月4日 | 360度モニタ不調 |
2024年11月2日 | ノート給油 |
2024年10月19日 | 腕時計のファームウエア |
2024年10月5日 | RF-S 10-18mm F4.5-6.3 IS STM購入 |
2024年10月3日 | 三菱UFJニコスカード到着 |
2024年9月28日 | 三菱UFJニコスカード申込 |
2024年9月23日 | 第10世代iPad購入 |
2024年9月17日 | iPadOS 18 |
http://h50146.www5.hp.com/products/servers/proliant/ml115/
http://h50146.www5.hp.com/products/old/servers/proliant/ml115/index.html
予定通り、本日納品。 付属品はPS/2接続のキーボードとスクロールマウス、 それに`HP ProLiant ML115 Server Support and Documentation CD bootable Diagnostic Utility' というCD-ROM。 さっそく仮セットアップして起動する。 起動直後は冷却ファンがすごい勢いで回転する。 BIOSに制御が移ると温度を検出できるのか、 途端に静かになった。
とりあえず、Solaris 10のハードウェアテストはすんなり通過。 FreeBSD 6.2もあっさりとインストールできた。 ハードディスクやらCD-ROM、イーサネットは問題なさそう。 例によってX Window Systemは使わないので、 グラフィック関係はどうだかわからないが。
たまたまDDR2 PC4300 512MBのメモリが4枚あったので、 最初から入っていた512MBメモリと入れ替えてみた。 あっさりと、2GBを認識する。 ただし、本来であればDDR2 PC5300のメモリを使わないといけない。 つまり保証外で、 動いているとはいえメモリの読み書きがフルスピードで行えていないわけだ。 もっとも、メモリが足りなくてスワップを起こすよりはずっと早いはずだが。
Proxyに使う予定なので、もう1枚NICを追加する。 外向けに接続するので100Mbpsで十分だから、 適当に物色する。 コレガのCG-LAPCITXなんて1000円を切っている。 チップはRTL 8139だが、まあいいだろう。 FreeBSD 6.2ではrlとして認識した。
付属のCD-ROMからブートすると、 Linuxベースの診断プログラムが走り出す。 遅いメモリもきちんと遅いことを認識している。 完全テストを行ってパスすることを確認。 遅いメモリでもいいんだ。
とりあえずi386なFreeBSD 6.2をインストールしたので、 Kernelの再コンパイル。
あたりが注意点か。 genericなkernelは7050706バイトだが、 これでコンパイルしたkernelだと2855313。 6割減である。 いくらメモリが安くなったとはいえ、 やるだけの甲斐はありそうだ。
そういえば、FreeBSDはamd64アーキテクチャもサポートしているはず。 さっそくCD-ROMイメージをダウンロードしてCD-Rに焼き、 再インストール。 同じような設定でkernelを再コンパイルした。 generic kernelが8407792バイトで、 再構築したkernelは3837459バイト。 54%減だが、i386に比べると2~3割増えている。 まあ単純に考えると、 オペランドのアドレス長が2倍になっているからなあ。
ML115 FreeBSDでGoogle検索すると、 Cool'n'Quietをオンにする方法があった。 /boot/loader.confにcpufreq_load="YES"、 /etc/rc.confにpowerd_enable="YES"をそれぞれ追加する。 アイドル状態の時には、クロックが1GHzまで落ちるようだ。 portsでインストールすると、 ftpでファイルを取得しているときは1GHzのままだったが、 コンパイルが始まると2.2GHzに戻った。 普段はあまり仕事をしていないサーバーだと効果は高そう。 seti@homeとか、folding@homeをやっていると意味がなさそうだけれど。
コンソールでいろいろコンパイルしている分には、 あまりPentium III 850MHz×2のマシンと速度が違うようには思えない。 が、portupgradeなんかのデータベースを更新すると、 見た目でも速度が違うのがわかる。 さすがにクロック2.2GHzは伊達ではないようだ。 analogによるレポート作成だと、 バージョンも違えば設定ファイルも違うのだが、 2分かかっていたのが40秒になっている。 5~6MB/sだったdumpの実行速度も、 12~13MB/sに向上した。 この辺はCPUだけではなく、 ハードディスクなんかのI/O回りも含めた総合的な問題だが。 webalizerの実行時間はほとんど変わらないが、 まあこれは逆引きDNSの時間が大多数を占めているのでどうしようもない。
手元に160GBのATAハードディスクがあったので、 バックアップ用に組み込んだ。 ML115のCD-ROMはATA接続で、ケーブルにはもう一つコネクタがある。 ハードディスクのジャンパをCable Selectにしておいたらちゃんと認識した。 ただ3.5インチベイの一番上に設置しても、 ATAのケーブルはぎりぎりの長さである。 欲を言えばスペーサーを使ってCD-ROMドライブ直下の5インチベイに入れたいところだ。
追加したハードディスクは/backupにマウントした。 で、リブートしたらブートローダーが見つからない。 デフォルトではCD-ROM、ATA、 SATAの順でブートデバイスを探すようになっているためだ。 ATAハードディスクへのコネクタを外してブートすると、 /backupがマウントできないと表示して止まる。 セーフモードで起動してもキーボード入力を受け付けない。 最悪再インストールかと思ったが、 念のためにBIOSでブート順を変えてみた。 あっさりとブートしてくれたので、一安心。
肝心のバックアップはRAIDではなく、 cronを使ってdump、pdumpfsを行うというもの。 まあもともとRAIDはバックアップじゃないんだけどね。 テープやNASほどではないにせよ、 二つのハードディスクが同時に壊れる可能性は低い。
Cronで定期的に実行していたanalogやwebalizerを設定する。 namazuがどうもうまくいかない。 perlのMeCabモジュールのあたりでエラーが起きる。 Hyper Estraierのほうはどうにかなりそう。
それ以外はなんとか目処が付いたので、 今までメインのサーバーとして動いていた部品寄せ集め6号と入れ替える。 とりあえず物理的な位置は変えず、 ネットワーク的に入れ替えただけだが。 一応問題なく動いているような気がする。
ようやく物理的な位置も入れ替えた。 なんだか、ケースの見た目が半分くらいの大きさになったように感じる。 これなら、もう1台横に並べて置けそうな気がしてきた。
バックアップに使っていた160GBのハードディスクが一杯になったので、 250GBなSATAハードディスクと交換。 とりあえずpdumpfsで32GB消費。 インクリメンタルダンプでさらに1GB消費。 フルダンプしたら、合計で70GBになった。 ダンプ中、13121KBytes/secを記録。 過去の実績からすると、18ヶ月くらいは持つはず。
backup用の250GB SATA /dev/ad6s1dでwrite errorが発生。 umountしてfsckして再mount。 とりあえずerrorは止まった。
ふとその気になって、6to4を試してみることにした。 /etc/rc.conf に
ipv6_defaultrouter="2002:c058:6301::"
ipv6_enable="YES"
stf_interface_ipv4addr="割り当てられたグローバルIPv4アドレス"
stf_interface_ipv6_ifid="0:0:0:1"
stf_interface_ipv6_slaid="0000"
と書いてリブートするだけだった。 any castを使っているので、 デフォルトルータは決め打ちでいいらしい。
$ traceroute6 www.kame.net traceroute6 to www.kame.net (2001:200:0:8002:203:47ff:fea5:3085) from 2002:dd74:58ba::1, 64 hops max, 12 byte packets 1 2001:200:0:b001:192:88:99:1 1.432 ms 1.350 ms 1.383 ms 2 2001:200:0:b001::1 1.896 ms 1.862 ms 1.834 ms 3 ve44.foundry6.otemachi.wide.ad.jp 1.593 ms 1.665 ms 1.692 ms 4 ve42.foundry4.nezu.wide.ad.jp 1.851 ms 1.910 ms 1.736 ms 5 ve45.foundry2.yagami.wide.ad.jp 7.895 ms 2.556 ms 2.344 ms 6 2001:200:0:4803:212:e2ff:fe28:1ca2 3.123 ms * 3.091 ms 7 orange.kame.net 3.357 ms 3.279 ms 3.150 ms
といった感じ。 もっとも、NATなりproxyなりを介さないと LAN側からインターネットにアクセスできないのは、 IPv4と同じ。 IPv6だけの世界なら、 ISPからのケーブルをスイッチングハブでわけるだけ、 といった運用もできそうだけど。
6to4だと/48なネットワークを使える。 つまり、64ビットなアドレス空間を6万5536個、 サブネットとして使えるということだ。 さっそくgateway機能をオンにして、 RAでLANのマシンにアドレスを配ってみた。 直接IPv6アドレスを指定すると、 実にあっさりとLANからインターネットにつながる。 ただ、
といった課題が残っている。
このマシンはDDR-2なメモリを使っている。 そろそろ底値で、今買っておかないと無くなりそうな気がする。 そこで2GB×4=8GBに増設。 これで6000円なのだから、信じられないくらい安い。 ついでにOSもアップデートした。 ちょっとnapt回りで混乱。 snmpdも返事をしてくれない。
mysqlはmercuryからこちらに移動。 ただ、Webインターフェイスはphpで作ったので、 rubyかperlで書き換える予定。
DNSサーバーとしてはずっとdjbdnsを使っていたのだが、 最近のdnssecとかIPv6とかを考えるとこのまま使い続けるのは不安。 なので、nsdとunboundに乗り換えることにした。 どちらもportsにあるので、インストールは簡単である。
unboundのほうは、/usr/local/etc/unbound/unbound.conf を
server:
interface: 192.168.x.x
interface: 2002:dd74:58ba:1::x
access-control: 192.168.x.x/24 allow
access-control: 2002:dd74:58ba:1::/64 allow
local-data: "sun.akiyama.nu A 192.168.x.x"
local-data: "sun.akiyama.nu AAAA 2002:dd74:58ba:1::x"
として、待受IPアドレスを明示的に指定して、 問い合わせを許可するネットワークを設定する。 デフォルトではすべてのIPアドレスで待ち受けるのだが、 外向けにはnsdを使うのでそれ以外を明示的に指定する必要がある。 djbdnsの時は、外向けのIPアドレスで外向けのtinydnsを、 127.0.0.1でLAN向けのtinydnsを動かし、 プライベートIPアドレスで動かしたdnscacheでLANの時だけ127.0.0.1に聞きに行く、 という設定にしていた。 ひとつ動いているプロセスが減ったことになる。
nsdは、/usr/local/etc/nsd/nsd.conf を
server:
ip-address: 221.116.88.186
ip-address: 2002:dd74:58ba::1
zone:
name: "akiyama.nu"
zonefile: "akiyama.nu.zone"
とした。 で、/usr/local/etc/nsd/akiyama.nu.zone を用意して、
# nsdc rebuild
# nsdc start
で動き出す。 もちろん、/etc/rc.conf にはnsd_enable="YES" を追記しておく。 ゾーンファイルの書き方は省略するが、 rebuildで/var/db/nsd/nsd.db ができあがって、 こちらを参照する。 なので、 ゾーンファイルを書きなおしたらrebuildとrestartが必須のようだ。
snmpのほうは、なぜかsunとして呼び出すと返事をしてくれない。 だが、localhostとして呼ぶと返事をする。 さらに、別のマシンからsunとして呼び出すと、これまた返事をする。 なんだかよくわからないなあ。
バックアップに使っているzfsなハードディスクがチェックサムエラーを起こしている。 交換すべきなんだろうけれど、 今はハードディスクに割高感があるからなあ。
1回手動でフルダンプをとったら、 うまいことエラーの起きるブロックを回避してくれたらしい。 とりあえずこれでしのげるか?
OSを8.3-RELEASEにアップデート。 ZFSのdedupをonにしてみた。 効果のほどはいかに。
NAPTの仕様が変わったのか、うまく動いていない。 とりあえず、squid経由でwebは見られるのだが。
バックアップ用ハードディスクがまたチェックサムエラーを起こした。 scrubしたらさらにエラーが。 なのでProLiant Microserverに付属していた250GBのハードディスクと交換する。
またまたバックアップ用ハードディスクにチェックサムエラーが。 やはり使い古しのハードディスクだからだろうか。
チェックサムエラーを起こしたのは、 Microserverに付いてきた比較的新しいものだった。 なので、zfsでmirrorを組んでみた。 さて、どうだろうか。
tom-a@sun$ zpool status
pool: backup
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
backup ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ad6 ONLINE 0 0 0
ad8 ONLINE 0 0 0
errors: No known data errors
予想通り、エラーが出た。
tom-a@sun$ zpool status pool: backup state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scan: none requested config: NAME STATE READ WRITE CKSUM backup ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 ad6 ONLINE 0 0 0 ad8 ONLINE 0 0 1 errors: No known data errors
が、ミラーを組んでいたおかげで自動修復できたようである。
エラーの起きたZFSのプールにscrubをかけてみた。
tom-a@sun$ zpool status pool: backup state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scan: scrub repaired 85.5K in 0h47m with 0 errors on Tue Sep 25 01:46:45 2012 config: NAME STATE READ WRITE CKSUM backup ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 ad6 ONLINE 0 0 1 ad8 ONLINE 0 0 1
一応問題なさそうだが、チェックサムエラーが増えている。 今まで気がつかなかったが、 ハードディスクは意外とエラーを起こすのかもしれない。
CrystalDiskMark 3.0.2で簡単なベンチマークをとってみた。
条件 | compression on | compression off | ||
---|---|---|---|---|
dedup on | dedup off | dedup on | dedup off | |
連続読み出し | 32.70MB/s | 34.26MB/s | 34.23MB/s | 34.62MB/s |
連続書き込み | 33.69MB/s | 31.57MB/s | 32.56MB/s | 35.68MB/s |
ランダム読み出し (512B) | 33.42MB/s | 35.18MB/s | 33.53MB/s | 33.87MB/s |
ランダム書き込み (512B) | 33.40MB/s | 32.95MB/s | 30.96MB/s | 28.39MB/s |
ランダム読み出し (4KB) | 7.982MB/s | 8.398MB/s | 8.469MB/s | 7.756MB/s |
ランダム書き込み (4KB) | 3.607MB/s | 6.339MB/s | 6.837MB/s | 3.806MB/s |
ランダム読み出し (4KB QD32) | 11.72MB/s | 12.23MB/s | 11.28MB/s | 11.31MB/s |
ランダム書き込み (4KB QD32) | 3.963MB/s | 4.038MB/s | 4.632MB/s | 3.738MB/s |
これを見る限りでは明らかな差があるものの、 それほど大きな差でもない。 意外なことに、compression off、dedup onが一番よさそうである。