トップ > 興味のあること > コンピュータ > ハードウェア > パーソナルコンピュータ
モッピー!お金がたまるポイントサイト
日々の生活にhappyをプラスする|ハピタス

ProLiant ML115

http://h50146.www5.hp.com/products/servers/proliant/ml115/
http://h50146.www5.hp.com/products/old/servers/proliant/ml115/index.html

2008年1月9日

予定通り、本日納品。 付属品は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のメモリを使わないといけない。 つまり保証外で、 動いているとはいえメモリの読み書きがフルスピードで行えていないわけだ。 もっとも、メモリが足りなくてスワップを起こすよりはずっと早いはずだが。

2008年1月11日

NIC追加

Proxyに使う予定なので、もう1枚NICを追加する。 外向けに接続するので100Mbpsで十分だから、 適当に物色する。 コレガのCG-LAPCITXなんて1000円を切っている。 チップはRTL 8139だが、まあいいだろう。 FreeBSD 6.2ではrlとして認識した。

付属のCD-ROMからブートすると、 Linuxベースの診断プログラムが走り出す。 遅いメモリもきちんと遅いことを認識している。 完全テストを行ってパスすることを確認。 遅いメモリでもいいんだ。

FreeBSDインストール

とりあえずi386なFreeBSD 6.2をインストールしたので、 Kernelの再コンパイル。

  • SCSIデバイスを削除したら、USBのマスストレージも削除する。
  • キーボードとマウスは内部でUSBに接続されているらしい。USBを全部削除するとキー入力ができなくなる。

あたりが注意点か。 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の時間が大多数を占めているのでどうしようもない。

2008年1月14日

ハードディスク追加

手元に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ほどではないにせよ、 二つのハードディスクが同時に壊れる可能性は低い。

2008年1月15日

サーバー入れ替え

Cronで定期的に実行していたanalogやwebalizerを設定する。 namazuがどうもうまくいかない。 perlのMeCabモジュールのあたりでエラーが起きる。 Hyper Estraierのほうはどうにかなりそう。

それ以外はなんとか目処が付いたので、 今までメインのサーバーとして動いていた部品寄せ集め6号と入れ替える。 とりあえず物理的な位置は変えず、 ネットワーク的に入れ替えただけだが。 一応問題なく動いているような気がする。

2008年02月24日

ようやく物理的な位置も入れ替えた。 なんだか、ケースの見た目が半分くらいの大きさになったように感じる。 これなら、もう1台横に並べて置けそうな気がしてきた。

2008年10月19日

バックアップに使っていた160GBのハードディスクが一杯になったので、 250GBなSATAハードディスクと交換。 とりあえずpdumpfsで32GB消費。 インクリメンタルダンプでさらに1GB消費。 フルダンプしたら、合計で70GBになった。 ダンプ中、13121KBytes/secを記録。 過去の実績からすると、18ヶ月くらいは持つはず。

2009年2月15日

backup用の250GB SATA /dev/ad6s1dでwrite errorが発生。 umountしてfsckして再mount。 とりあえずerrorは止まった。

2009年8月19日

ふとその気になって、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からのケーブルをスイッチングハブでわけるだけ、 といった運用もできそうだけど。

2009年8月24日

6to4だと/48なネットワークを使える。 つまり、64ビットなアドレス空間を6万5536個、 サブネットとして使えるということだ。 さっそくgateway機能をオンにして、 RAでLANのマシンにアドレスを配ってみた。 直接IPv6アドレスを指定すると、 実にあっさりとLANからインターネットにつながる。 ただ、

  • IPv6/IPv4デュアルスタックでどちらを優先するのか。
  • IPv6でDNSを引くには。

といった課題が残っている。

2012年1月3日

このマシンはDDR-2なメモリを使っている。 そろそろ底値で、今買っておかないと無くなりそうな気がする。 そこで2GB×4=8GBに増設。 これで6000円なのだから、信じられないくらい安い。 ついでにOSもアップデートした。 ちょっとnapt回りで混乱。 snmpdも返事をしてくれない。

mysqlはmercuryからこちらに移動。 ただ、Webインターフェイスはphpで作ったので、 rubyかperlで書き換える予定。

2012年1月5日

DNS

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

snmpのほうは、なぜかsunとして呼び出すと返事をしてくれない。 だが、localhostとして呼ぶと返事をする。 さらに、別のマシンからsunとして呼び出すと、これまた返事をする。 なんだかよくわからないなあ。

2012年2月21日

バックアップに使っているzfsなハードディスクがチェックサムエラーを起こしている。 交換すべきなんだろうけれど、 今はハードディスクに割高感があるからなあ。

2012年2月24日

1回手動でフルダンプをとったら、 うまいことエラーの起きるブロックを回避してくれたらしい。 とりあえずこれでしのげるか?

2012年4月25日

OSを8.3-RELEASEにアップデート。 ZFSのdedupをonにしてみた。 効果のほどはいかに。

NAPTの仕様が変わったのか、うまく動いていない。 とりあえず、squid経由でwebは見られるのだが。

2012年5月9日

バックアップ用ハードディスクがまたチェックサムエラーを起こした。 scrubしたらさらにエラーが。 なのでProLiant Microserverに付属していた250GBのハードディスクと交換する。

2012年6月24日

またまたバックアップ用ハードディスクにチェックサムエラーが。 やはり使い古しのハードディスクだからだろうか。

2012年7月28日

チェックサムエラーを起こしたのは、 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

2012年9月25日

予想通り、エラーが出た。

 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

が、ミラーを組んでいたおかげで自動修復できたようである。

2012年9月26日

エラーの起きた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

一応問題なさそうだが、チェックサムエラーが増えている。 今まで気がつかなかったが、 ハードディスクは意外とエラーを起こすのかもしれない。

2013年1月25日

CrystalDiskMark 3.0.2で簡単なベンチマークをとってみた。

条件 compression on compression off
dedup ondedup offdedup ondedup off
連続読み出し32.70MB/s34.26MB/s34.23MB/s34.62MB/s
連続書き込み33.69MB/s31.57MB/s32.56MB/s35.68MB/s
ランダム読み出し
(512B)
33.42MB/s35.18MB/s33.53MB/s33.87MB/s
ランダム書き込み
(512B)
33.40MB/s32.95MB/s30.96MB/s28.39MB/s
ランダム読み出し
(4KB)
7.982MB/s8.398MB/s8.469MB/s7.756MB/s
ランダム書き込み
(4KB)
3.607MB/s6.339MB/s6.837MB/s3.806MB/s
ランダム読み出し
(4KB QD32)
11.72MB/s12.23MB/s11.28MB/s11.31MB/s
ランダム書き込み
(4KB QD32)
3.963MB/s4.038MB/s4.632MB/s3.738MB/s

これを見る限りでは明らかな差があるものの、 それほど大きな差でもない。 意外なことに、compression off、dedup onが一番よさそうである。