過去の苦労話 第13回：インフラ漂流記。〜RAIDの死、RHELの野望、そしてNICの罠〜

 私が作り上げた「イントラの城」は、決して盤石な石垣の上に立っていたわけではありません。その足元は、常にハードウェアの気まぐれと、OSの変遷という荒波にさらされていました。始まりは、あの伝説の**「赤帽（Red Hat Linux）7」。
　基幹系、情報系、そしてVPN系。なんと驚異の3セグメント**をひとつのサーバーで捌くという、今思えばなかなかに無茶な構成で「情報の交通整理」をしていました。

やがて、ハードも「本気」を出そうと、IBMの32ビットサーバーマシンを導入することになりました。
　私は開発者であってインフラ専門家ではありません。餅は餅屋、この巨大な移行作業自体は外注さんにお願いし、プロの手で安全に新天地へ進める道を選びました。ところが、落とし穴は意外なところにありました。

内蔵バッテリーの寿命です。

　「RAIDなら安心」と過信していた矢先、バックアップバッテリーが力尽き、あえなくRAID崩壊。……はい、レイド死です。
　「任せたはずなのに、そこかよ！」と心の中で叫びつつ、苦い涙とともに復旧を見守るしかありませんでした。

その後、気を取り直して自ら導入したのが富士通の「PRIMERGY（プライマジくん）」。
　当初はRHEL 4の予定でしたが、私は独断で最新のRHEL 5をダウンロードし、最新環境を構築。自作のRuby-CGIやPHPが、新しいエンジンで軽快に回る姿を見るのは、システム屋として至福の瞬間でした。しかし、そのRHEL君にも「物理の試練」が訪れます。
　ある日、マザーボードの交換修理を行いました。ハードウェアは新品、さあ再起動！……と思いきや、なぜかネットワークに一切繋がらない。
　「設定ファイルは1ミリもいじっていないのに、なぜだ！」調査の末に判明したのは、RHELが誇る（？）MACアドレスの紐付け設定でした。
　新しいマザーボード＝新しいNIC。OS側は「前のMACアドレスじゃないから、お前はeth0（一番目のLANポート）とは認めん！」と頑なに通信を拒否していたのです。
　
　「設定じゃなくて、お前の『記憶』が邪魔なんだよ！」NICの「個体識別」という目に見えない鎖を、設定ファイルをほじくり返して力技で書き換える……。

あの孤独な格闘こそ、物理サーバー時代のシステム屋の真髄でした。最後はベンダー依存のIISへと主役の座を譲りましたが、OSの進化に一喜一憂し、ハードの故障に右往左往した20数年。

　今、クラウド全盛になり、ファンの騒音を懐かしく思い出しながら、私は静かに次のコードを書き始めています。

（つづく）