他にも一週間分の停電スケジュールを見てcronでシャットダウンを仕掛けるという方法も考えられるが、その日の電力使用量によって直前にあっさり停電がスキップされたりするのでこれまた難しく停電の有無は直前まで分からない。で、調べてみると計画停電カレンダーなる有り難いサイトがあるのを発見。しかも計画停電中止などの情報もタイムリーに更新されているようだ。

というわけで、まずこのGoogle カレンダーからRSSで情報を取ってきて、停電情報を提供するWebサービスを作ってGoogle Application Engineで公開してみました。ポイントはこのカレンダーに「中止」か「CANCELED」と書かれてたらキャンセルとみなしリアルタイムで反映されること。で、使い方は以下。たとえばグループ5で今後30分以内に計画停電があるかどうかはhttp://nextteiden.appspot.com/tokyo/g5/nextteiden/inminutes/30で判定することができる。

Base URL: http://nextteiden.appspot.com

■nextteiden

指定電力会社の指定グループの現時刻から次回の計画停電の開始の時刻を返す

入力：

書式： /(電力会社)/(グループ)/nextteiden

電力会社：’tokyo’`もしくは’tohoku’（現状の対応はtokyoの東京電力のみ)

グループ：g1〜g5

例： /tokyo/g1/nextteiden

出力：

plain/textにて次回の停電の開始の時刻。存在しない場合は”None”

例：’2011/03/27 14:24:46′

エラー時には”ERROR: <理由>”を返す

■nextteiden/inseconds

指定電力会社の指定グループの現時刻から指定秒数以内に計画停電が予定されているかどうかを返す

入力：

書式： /(電力会社)/(グループ)/nextteiden/inseconds/(秒数)

電力会社：’tokyo’`もしくは’tohoku’（現状の対応はtokyoの東京電力のみ)

グループ：g1〜g5

例： /tokyo/g1/nextteiden/inseconds/3600

出力：

plain/textにて指定した現時刻から秒数以内に計画停電が予定の有無を’Yes’と’No’で返す

例：Yes

エラー時には”ERROR: <理由>”を返す

■nextteiden/inminutes

上記nextteiden_insecondsと同様。指定は分単位

■nextteiden/inhours

上記nextteiden_inhoursと同様。指定は時間単位

そんでもって、１０分おきに起動するシェル(teiden_shutdown.sh)を作ってみた。

#!/bin/sh

URL=’http://nextteiden.appspot.com/tokyo/g5/nextteiden/inminutes/20′
OUTFILE=/tmp/$$.teiden_shutdown.tmp
LOGFILE=/var/log/teiden_shutdown.log

wget -q -t 3 -O $OUTFILE $URL
RET=$?

if [ $RET -ne '0' ]
then
echo `date`’ FETCH ERROR’ >> $LOGFILE
exit 1
fi

echo `date`’ ‘`cat $OUTFILE` >> $LOGFILE

if [ `cat $OUTFILE` = 'Yes' ]
then
echo ‘date” SHUTDOWN NOW’ >> $LOGFILE
shutdown -h now
fi

rm $OUTFILE

今、このシェルを手持ちのVMのcronに設定して１０分おきにcron起動するようにしてみた。１０分おきに最大２０分先の停電の有無を答えるので停電の10～20分前に自動でシャットダウンされるはずである。

というわけで計画停電の範囲でUPSもないような方で「これは使える」と思った方は遠慮無く使ってくださいな。

• root権限を使える
• メモリ512MB、HDD20GB程度とロースペックでいいので安い
• 既存のVMをそのまま引越しできる

その結果、さくらのVPSに決定。上のスペックで月々980円という約牛丼２杯分という無理のないプライス。とはいえ、３番目の条件である既存VMの引越しはサポートされておらず通常はプリインストールのCentOSである。普通はこれをセットアップして使う。

既存VMの引越しはサポートされていないが、さくらVPSは完全仮想化なのでOSが起動してしまえばまあどうにでもなる。というわけで２段階でVMを移植した。方法としてはまず、上に書いた「カスタムOSインストール」でDebianをミニマムインストール(1GB)して起動し、そこからSWAPパーティションを除く残りの18Gにファイルシステムを作成し既存VMのルートファイルシステムをコピー。そのあと、/boot/grub/menu.lstを書き換えておもむろに再起動。図にするとこんな感じ。

この再起動後がこの移植作業の最大の難所である。だいたい最初の起動ではinitrdが無効とかrootファイルシステムがマウントできないとかで起動に失敗する。しかしこのさくらのVPSが秀逸なのがVGAコンソールが使えることだ。KVMには詳しくないが、Webの管理画面からJava Appletで管理画面であるVGAのコンソールが使えるので、Grubの画面操作や起動に失敗した画面でエラー内容を確認できる。これによりいくつか試行錯誤があったが無事に手持ちのVMを起動することができた。その他にも仮想のシリアルポートもサポートされておりこれもWebの管理画面から利用することができる。

ルートファイルシステムのコピーはパイプでsshに送ってssh経由で転送。コマンド例はVPSで新パーティションを/mnt/tmpにマウントしておき。以下を実行。

tar zcpf – . | ssh root@<VPSのサーバー> “(cd /mnt/tmp ; tar zxpvf -)”

注意点としてはお試し期間中は無料だけど外向けのSMTPポートが使えないこととネットワークの帯域宣言がされていることか。正式申し込みに１日ぐらい必要なので使うのを決めたら本申し込みをしましょう。

このVMのイメージは2002年くらいになんとなくインストールしたDebianをひたすらバージョンアップしたもので、今まで3.0→3.1→4.0→5.0→6.0とメジャーバージョンアップもapt-getコマンドでアップグレードしただけに感慨深い。また稼働VMもVMware Server→Xen→VMware ESX→KVM(さくらVPS)と渡り歩いてきた。今回の地震で自宅での運用は途切れたが、このDebianのメジャーバージョンアップは続けていきたいと決意を新たにする今日この頃です。

でもでも、VMwareで運用するに当たってはいろいろあって、

• やっぱストレージはRAID構成にしたいよねー
• でも、VMwareはソフトウェアRAIDサポートしないからRAIDカードいるよ
• 調べたら安いので４万くらいか。高いけどポチるとするか
• む、Raw Device MappingにしてLinux仮想マシンでSoftware RaidカードにすればRAIDカードいらないのでは！
• でもストレージをどうやって他の仮想マシンに見せるのよ？
• VMwareだとiSCSIのディスクサポートしてるからそれで仮想マシン達で共有できるよ
• おけ、ESXとSoftware RAID起動用の30G SSDとRAID用のWD 2T x 3発注したよ
• そういえば、今のバックアップ運用ってLVMのスナップショットで静止点とってrdiff-backupで逆差分バックアップとってたけどVMwareのiSCSIでもこの方法でとれるのか？
• う、VMwareにiSCSIデバイスを提供するとかなりまとめてVMwareに見せないとメリットがないなー
• まとめて見せると、その中にVMFSが作られて各VM毎のディレクトリにvmdkがあってあるのかー
• これでいくとしたら、夜間VMFSの論理ボリュームの静止点をとりマウント。そしてその中のvmdkをマウントしてrdiff-backupでバックアップか？
• VMFSとvmdkのマウントが出来れば（今調べたらできそう）出来ないこともないけど、VMwareにべったりだなー
• あ、そうだ。VMwareのハイパーバイザーすっとばしてVMが直接iSCSI喋ればいけるかも！

というわけで、構想としては仮想ディスクのない仮想マシンからディスクレスでアクセス。おまけにSAN Boot。カッコイイー。SANといっても通常のオレンジ色のファイバーのはFC-SANでiSCSIなどIPベースのはIP-SANというらしい。他にもFC-SANの内容をEtherでやり取りするFCoE(Fiber Channel over Ether)もあるらしい。ややこしいですな。図にするとこんな感じ。

次の課題が、IPでSAN Bootしようと思ったら、物理マシンだと専用のカードが必要なこと。しかし今回は仮想マシン。調べてみたらありましたよ、ピッタリのが。オープンソースのgPXEなるブートローダーでVMも仮想マシンのROMを置き換えたらネットブート可能です。

start – Etherboot/gPXE Wiki

最初はせっせとROMを書き換えていましたが、このブートローダーはISOイメージでも提供されてまして仮想マシンに仮想CDを付けるほうが手軽ということに途中で気づいてしまい仮想CD-ROM Boot→SANブートとなってます。長くなったので続きは次回に続きます。

197 Current_Pending_Sector  0×0012   100   100   000    Old_age   Always       -       1
198 Offline_Uncorrectable   0×0030   100   100   000    Old_age   Offline      -       1

このうち、”Current_Pending_Sector”は「アクセスに失敗したけど、代替セクタへの移動がまだのセクターの数」らしい。代替セクターへ割当させるためには、該当するセクタへの書き込みが必要とのこと。仕方ないので、エラーの出たディスクを一旦RAIDのアレイから外して、もう一度アレイに入れて同期を取り直してみた。

すると今度は別のディスクでまた読み込みに失敗して”Current_Pending_Sector”が１つ出てしまった。トホホです。２つ怪しいディスクを抱えてこれ以上作業するのも危険なので、もう一つディスクを発注する。ずっと予備のを買っておいておこうとは思っていたのが、結局問題が起こってから泥縄式に買うはめになってしまった。

さて問題のディスクを新しく買ったディスクと交換して、不良セクタの出たディスクを別のパソコンにつなげてKnoppixで起動する。まずは、不良セクタのアドレスを調べる。次のようなsmartctlコマンドでディスクにテストをさせる。

smartctl -t long -d ata /dev/sda

しばらくすると、次のようなエラーの行がsmartctlの結果に表示される。

SMART Self-test log structure revision number 0
Warning: ATA Specification requires self-test log structure revision number = 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed: read failure 90% 2021 1953520732

この結果から不良セクタのLBAのアドレスが、1953520732だということが分かる。ちなみにこのディスクのfdisk -luの結果は次の通りで、不良セクタの場所は実際に使っているパーチィションの外であることが分かる。

Disk /dev/sda: 1000.2 GB, 1000203804160 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953523055 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/dev/sda1 63 321299 160618+ fd Linux raid autodetect
/dev/sda2 321300 1953520064 976599382+ fd Linux raid autodetect

実際には使用しない領域なので実害はないが、ずっとエラーが出るのも気持ち悪いので以下のコマンドで不良セクタを上書きする。

dd if=/dev/zero of=/dev/sda bs=512 seek=193520732 count=1

すると、”Current_Pending_Sector”が0になった！。でもまだ”Offline_Uncorrectable”が1のままなので、もう一度セルフテストを実行する。

smartctl -t long -d ata /dev/sda

すると無事に、”Offline_Uncorrectable”も0に戻った。実にさわやかな気分である。このディスクはスペアとして置いておいて次にアレイのディスクで障害が起きたら交換することにしよう。本当はパソコンに入れておいてホットスペアとして自動で切り替わるようにしたいのだが、もうドライブベイがないのでホットスペアは断念する。

rsyncによるデジカメ写真の1世代バックアップだが、バックアップ対象のデータはRAID5のディスクにおいてあるので1台までのディスク障害には耐える。しかし、SAMBA経由で見せているWindowsからうっかりフォルダーを削除したりして、夜間のrsyncによるフォルダー同期まで気がつかないとデータが永久に失われてしまう。これが現行のrsyncのバックアップの一番の問題である。仮に日次のrsyncを週次にしたところで、タイミングによってはうっかり削除に対応出来ない点では同じである。

なので、業務データなどでは、週次のフルバックアップ（複数世代）＋日次の差分バックアップなどになるのだが、さすがにご自宅サーバーでここまでやるとやり過ぎ感は否めない。

なにかぴったりくるバックアップのソリューションがないかと思ってたどり着いたのが、定期購読しているWEB+DBのバックナンバーの特集「バックアップの研究」である。この特集、実にステキでP.107のバックアップツールの比較表では8項目、8種類が網羅されている。

WEB+DB PRESS Vol.47｜gihyo.jp … 技術評論社

最初はbaculaなど複数サーバーのバックアップ、暗号化、自動世代管理、ストレージのプーリングなど高機能なものに最初に目がいったが、さすがに大げさなことに気づいた。結局、この本で一番シンプルなrdiff-backupが非常に気に入った。ステキな点は、以下だ。

• バックアップされたイメージは常に最新状態で、履歴は逆差分で記録する。
• バックアップされたイメージは、アーカイブファイルではなく普通のファイルシステムなので、直接lsなどで日本語ファイル名のファイルがちゃんとバックアップされているかなどを確認することができ、安心できる。
• 古いバックアップの削除機能

とくに1点目は重要だ。一般的なフルバックアップ＋順方向の差分だと、ずーっと差分バックアップというのもリスクがどんどん高くなっていくので、一定のタイミングで起点となるフルバックアップを取り直す必要がある。そうすると取り直したフルバックアップ直後の障害に備えて、取り直したフルバックアップ以前にリストアするためには、さらにそのもう1世代前のフルバックアップも必要となるというジレンマがある。結局、本当は1世代のフルバックアップしか必要なくても2世代のフルバックをとらざるを得ない。しかし、逆方向の履歴を持つと起点となるフルバックアップが最新なので１つのフルバックアップだけで、逆差分により任意の時刻へのリカバリーが可能である。ああ、ステキすぎます。

とういわけで、以前のRAID5のトラブル時に唯一生き残ったSeagateの1.5Tをサーバーにつけてバックアップディスクとしてバックアップ運用を開始したところである。

次回は、LVMのスナップショット機能とこのrdiff-backupを使って、無停止でXenのディスクイメージのバックアップをとる方法について書く予定です。

久しぶりの更新です。

昨年末に、「素敵！」という理由だけで買ったIntelのAtomマザーに30GBのSSDをつけて、小型ケースのITX-100に組んでみた。サーバーマニアならかなり琴線に触れる構成かと思う。ちなみに、左の写真が家にあるデスクトップ達で左からサーバー、メインデスクトップ、そして今回組んだAtomデスクトップである。

前から気になっていたLinuxのUbuntuのインストールのために高価なスリムベイのDVD-ROM（ケースが小さいので普通のドライブは入らない）を買うのも惜しいので、ネットワーク経由でインストールしてみた。やり方は、DHCPを自前で立てていればとっても簡単だ。まずは/etc/dhcpd.confに次のように起動ファイルと起動サーバーのアドレスを設定しておく。

filename “pxelinux.0″;
next-server x.x.x.x;

そんでもって、起動サーバーにTFTPDを入れてTFTPDのルートディレクトリに、Ubuntu提供の”netboot.tar.gz“を解凍しておけば勝手にインストーラーが立ち上がる。

で、今そのUbuntu環境のFirefoxでこのブログのエントリーを書いている。Linuxのデスクトップもやっと普通に使えるようになって来ていると実感。日本語入力も十分快適だ。ただ若干動作が緩慢でもっさりしている。AtomはPentium4相当らしいので、それにしては少し遅いように思う。今後に期待したい。

先日のニューヨークのハドソン川で起きたＵＳエアウェイズ機の不時着の原因は、鳥がエンジンに吸い込まれるBird Strikeによる両方のエンジンの障害だった。双発の飛行機（エンジンが２基の飛行機）の場合、障害はどちらか１基までの想定で、両方のエンジンに同時に障害が起こることは想定していないし、そのための訓練もほとんど行われていないらしい。

またITの業界でも「二重障害は想定しない」と高らかに宣言するのが通例であり、二重障害が起きたらバックアップ等で対処するのが普通である。これを、さらに三重化するケースはあまりなく私もまだお目にかかったことがない。

同じことはRAID5のハードディスクアレイにも言えることで、RAIDアレイのうち１台のハードディスクの故障には耐えるが、２台異常故障した場合、データは完全に失われる。しかし、２台のハードディスクが同時に壊れる確率は低いため、めったに発生しないというのが通常の認識だ。

しかしである。前のエントリーであるように自宅サーバーにRAID5を組んでビルドが終わった翌朝、再起動をかけたタイミングで、RAIDアレイのうちのハードディスクの１つが突如として、本来1.5TBの容量がなぜか0.5TBになり、RAID5は縮退モードになってしまった。とここまでならよく話であるが、さらに残ったハードディスクのうち１つがさらに１つ「カコーン、カコーン」と断続的になるようになった。

経験上、「カコーン、カコーン」となるハードディスクはまともにシークが出来なくなりつつありリトライをしまくっているので、死期が近い。この状態で、もう１つ死んだら全滅である。なるべく速くもう一つハードディスクを追加してやる必要がある。というわけで、0.5TBに容量が減ってしまったのは、初期不良交換して、さらにカコーンのハードディスクの代わりにともう一つ注文。

長くなるのでここからはかいつまんで書くと、初期不良交換したハードディスクはもう一度500Gに容量になってしまい、追加で注文したHDDは最初から500Gしか認識せず、唯一健全だった残りの１つも「カコーン、カコーン」となった。あまりにもひどいので、500GになってしまったHDDを再度購入した店に持って行くと「先ほどSeagate社からこのハードディスクの不良について発表がありまして、交換してもいいがまた同じことになる可能性が高い」とのこと。Seagateの不良騒ぎで大騒ぎになる前日である。で、結局、サムソンの1Tのハードディスクの3台に差額交換してもらった。

しかしである。使い始めてすぐに、新しいサムソンのHDDも容量が1TBのところが32MBになってしまった。これはもう、ハードディスクが悪いのではなく、マザーボードかSATAケーブルが悪い可能性が高い。実に紛らわしい話である。幸いサムソンのハードディスクは、サムソン提供のES-Toolなるもので、復活できたがこれがなければ2週間分のデータ（といってもたいしてないが）をロストするところであった。

以下、今回の教訓

• RAID5を組むならスペアディスクも買っとけ
• 二重障害も起きるときはおきる
• どんなときも冷静に！

という訳で、近所のドスパラ川崎店に行くと運良く新年のセールで1.5Tが12,000円弱で売っていたのでゲット。ちなみに愛用しているこの店、今月一杯で閉店とのこと。せっかく歩いて（といってもちと遠いが）バルクのドライブが安く買える店だったのに…。

さっそくサーバーに取り付ける。とここで、BIOSとLinuxでドライブの認識が違うことを発見。私のも次のページにある情報と同じであった。

Debianクローン – eto.com/d

SATA0 /dev/sda
SATA1 /dev/sdc
SATA2 /dev/sdb
SATA3 /dev/sdd

ああ、破損ディスクが発生して交換するときにトラブルのもとになりそうではないですか！

現在、pvmoveコマンドでRAID1→RAID5にコピー中。電卓で計算すると13時間。とほほー。

64bit OS上での32bit OSの準仮想化とDebian on CentOS環境の構築完了 – u-ichiのにっき

試してみたところ、さっくり動きました。おかげで、Debian系とCentos系で2台動かしていたXenのサーバーを1.5TのHDDに換装したサーバーの1台にマージ出来そうです。これもサーバー統合というのでしょうか？

というわけで、このブログをホスティングしているDebianサーバーは、最初は物理サーバーで動いていたのですが、次に仮想化してVMware上で動き、そしてVMwareイメージをコンバートして32bit DebianのXen上でDomain-Uとして動き、今では64bit CentosのXen上でDomain-Uとして動いています。もちろん、新規インストールで入れたのは最初の物理サーバーの時だけで後は全部移植です。

うーむ、いつまで引っ張れるのでしょうか？

というわけで移行の開始である。移行元のCentos 5.2はSATAの１ドライブに入っておりパーティションの状況は次の通り。１つめが/bootで残りはすべてLVMという典型的なインストールである。

デバイス Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 60801 488279610 8e Linux LVM

これを新しく買ったドライブに置き換えてRAID1で2重化する。既存のドライブにもう1台追加してRAID1化する方法は次のページにあるので参考にする。

非RAIDシステムのRAID化 – CentOSで自宅サーバー構築

今回は追加ではなく置き換えなので、上の手順とは少し手順が異なるがほとんど同じである。しかし、上のページを参考にしてやってみたが、最初はなかなかうまくいかなかった。どうしても起動時にルート・ファイルシステムを認識するときにkernel panicになってしまう。一時は自分でinitrdを自作して、起動するところまで行ってしまったが、この解決法に激しく違和感を憶えもう一度調べ直す。最終的には、次のページを見て解決。

mydrive.jp／OSインストール後のRAID追加方法

このページによると、ブート時にRAIDパーティションを認識させるためには、次の3点を守らないといけないらしい。

• カーネルにRAIDドライバがモジュールではなく組み込まれている
• RAIDを構成するデバイスのパーティションIDが0xfd (RAID 自動検出) である
• persistent-superblockが有効になっている。

で、私はパーティションIDをLinux(0×83)やLinux LVM(0x8e)にしていたので、自動認識されなかった。気づいてしまえばなんと言うことはない。まあ、ここで作ったパーティションはRAIDパーティションであり、Linux LVMのパーティションでもあるのでどちらにするか迷うところだが、よくよく考えてみると、このパーティションの目的はあくまでRAIDなのでRAID(0xfd)を設定すべきである。RAIDのパーティション構成した上で、出来たRAIDパーティションをLVMにするのかあるいは素でext3で使うかというのは、あくまでRAIDを構成した後の話なのでここで持ち出すべきではない。ということに気づいた。

というわけで無事に1.5Tx2(RAID1)で起動するLinuxサーバーが1つ出来ました。次は引き続きこのサーバーにDebianのDomain-Uを乗せて、saitoudaitoku.comサーバーに仕上げます。

Nagios -> check_disk(ファイルシステムの空き容量）

で、NRPE(Nagios Remote Plugin Executer)なる拡張によって、リモートのシステム内の情報もリモートで取得出来るようになる。

Nagios -> nagios_plugin(check_nrpe) -> ネットワーク -> nrpe_server -> check_disk

というわけでDebian(etch)の場合、監視対象のサーバーには次のパッケージが必要

nagios-nrpe-server
nagios-plugins

でNagiosサーバーにはリモート監視するためにNagios本体の他に次のパッケージが必要

nagios-nrpe-plugin

プラグインの設定は、/etc/nagios-plugins/configあたりに書くのだがローカルとリモートで引数の渡し方が結構違っててややこしい。以上、あまりネットを検索しても見つからなかったのでメモでした（私の検索能力が低いだけかもしれないが）。

CentOS5 64ビットモードにXen導入（32ビット準仮想はNG) — lights on zope

で、今日間違えて64 bit OSの上なのにi386プラットフォームのOSを間違えてインストールしたら何事も無かったかのようにブートした。いつの間にか出来るようになったのね。ぐぐったら次のようなページも発見。

64bit OS上での32bit OSの準仮想化とDebian on CentOS環境の構築完了 – u-ichiのにっき

せっかく64bit環境のためにもう一台サーバーPCを組んだのに1台にマージできそうです。これで、4Gのメモリーが普通に流通したら5,000円くらいのマザーでも16G搭載だし、Phenom入れたら4 CPU。かなり遊べますな。

もともとVMwareでインストールしたディスクイメージはファイルで、ファイル=物理ディスクでルートパーティションとSWAPパーティションの２つがある。で、このルートパーティションを増やしたのでメモ。参考にしたのは次のサイト。

検閲Tech: Dom0からDomUのイメージファイルをディスクデバイスとして扱う

まずは、DomainUを停止して古いイメージをバックアップ

# cp reborn.img reborn.img.org

次にこのイメージファイルに追加書き込みしてサイズを増やす。オリジナルのサイズは20Gバイトで、これに10Gバイト追加する。ちなみに下の例のようにddコマンドで30Gバイト-1Mバイトまでスキップして1Mバイトだけ書くと瞬時に完了する。こうするとCopy On Writeになるので実際に利用するときまでディスクへの書き込みは遅延される。ゆえに最初はディスクもほとんど消費しないので省エネなのだが、これだけのサイズを確保しているわけではないのでディスクフルになると大変なことになるので気をつけよう＞私。

# ls -l
合計 20086696
-rw-r–r– 1 root root 21474836480 2008-06-26 08:00 reborn.img

# dd if=/dev/zero of=reborn.img seek=30719 bs=1M count=1
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.035053 seconds, 29.9 MB/s

次にfdiskを使っていったんパーティションを削除して（ドキドキ）、次のように変更する。守るべき点は、ファイルスステムの開始セクターは同じこと、かならずサイズは増やすことの2点である。SWAPパーティションは作り直すので開始セクターがずれてもいい。

（編集前）
Disk /dev/loop1: 32.2 GB, 32212254720 bytes
255 heads, 63 sectors/track, 3916 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/loop1p1 * 1 2550 20482843+ 83 Linux
/dev/loop1p2 2551 2610 481950 82 Linux swap / Solaris

（編集後）
Disk /dev/loop1: 32.2 GB, 32212254720 bytes
255 heads, 63 sectors/track, 3916 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/loop1p1 1 3850 30925093+ 83 Linux
/dev/loop1p2 3851 3916 530145 82 Linux swap / Solaris

このままだと30Gバイトの器に20Gバイトのファイルシステムの状態なので直す必要がある。まずはパーティションを変更するために空いているループバックデバイスをゲット。

# losetup -f
/dev/loop1

このループバックデバイスにイメージファイルをマッピングする。

# losetup /dev/loop1 reborn.img

そんでもってこのloop1のパーティションを読み込ます。これで/dev/mapper以下にループバックデバイスのパーティションが現れる。コマンドはkpartxなのだがDebianの場合、testingでないと提供されていない(2008/06/26現在)。

# kpartx -a /dev/loop1

で、fsckでチェック。

# e2fsck -f /dev/mapper/loop1p1
e2fsck 1.40-WIP (14-Nov-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/: 390908/2557216 files (0.8% non-contiguous), 4413250/5120710 blocks

いよいよファイルサイズを増やす。

# resize2fs /dev/mapper/loop1p1
resize2fs 1.40-WIP (14-Nov-2006)
Resizing the filesystem on /dev/mapper/loop1p1 to 7731273 (4k) blocks.
The filesystem on /dev/mapper/loop1p1 is now 7731273 blocks long.

最後に新しく作ったSWAPパーティションを再作成。

# mkswap /dev/mapper/loop1p2
Setting up swapspace version 1, size = 542863 kB
no label, UUID=b4e99967-5f4c-45ef-acab-25bd89ff8d5d

後始末としてループバックを解除して、VMを起動する。

# kpartx -d /dev/loop1
# losetup -d /dev/loop1

ちなみにこの方法だと、変更できるのは後ろが空いているパーティション１つだけだ。本来ならpartedでやるのだが、なぜかDebianのetchだと”File system has an incompatible feature enabled”なるエラーが出来てresize出来なかった。

で、下のリンクのようにクローズする前ならサルベージする方法もあるのだが、loopbackデバイスのためかオープンしているプロセスを見つけることができない。

Open Tech Press | 削除したファイルをlsofで復元する

losetupコマンドでループバックデバイスにひも付いているイメージファイルのi-node番号も分かっているんだけど、復活させる方法はありそうでなかなかありそうでない。i-node番号をもとにハードリンクを作るとうまくいきそうなのだがlinkシステムコールの引数はファイルのパスのみだし…。

すでにバックアップからのイメージで動いているのでサルベージする必要もないわけだが、なんか気になる今日この頃です。

ブログのエントリーなど半年分全部ロストか？と思いながら、死んだはずのVMにアクセスしてみたらディスクイメージを消されたにもかかわらずいまだに動き続きている。「しめた！」と思い、まずはそのディスクイメージが入っていたファイルシステムにこれ以上書き込みが起こらないように、Sambaサーバーなどを停止。そして半年前のイメージの別のDomain-UのVMを作り起動し、aptitudeでソフトを自動更新したあと、rsyncでなぜか動いているサーバーとWebのコンテンツや設定ファイルなどを同期させた。で、動いているのを確認してルーターの設定を新しいVMに振り替えた。←いまここ

不思議なことに一晩たったあとも、死んだはずのVMはまだ普通に動いている。Domain-0のカーネルからのloopbackデバイス経由のアクセスはファイルが消えても検知されない仕組みになっているのだろうか？

もちろんシャットダウンしたら二度と起動しないことは確実である。まさにDead Man WalkingならぬDead OS Runningである。このOS動かせ続けてもいいのだが、ファイルシステム的には解放されている領域を読み書きしてるからなるべく早くとめたほうがいい。なので、しばらくして新VMへの同期を確認したらシャットダウンする予定である。これはOSの安楽死なのだろうか？

大徳日記 » Xenに移行しました。

方法は簡単でまずはXenのカーネルを探してみると

$ apt-cache search xen-linux-system
xen-linux-system-2.6.18-4-xen-686 – XEN system with Linux 2.6.18 image on i686
xen-linux-system-2.6.18-4-xen-vserver-686 – XEN system with Linux 2.6.18 image on i686
xen-linux-system-2.6.18-5-xen-686 – XEN system with Linux 2.6.18 image on i686
xen-linux-system-2.6.18-5-xen-vserver-686 – XEN system with Linux 2.6.18 image on i686
xen-linux-system-2.6.18-6-xen-686 – XEN system with Linux 2.6.18 image on i686
xen-linux-system-2.6.18-6-xen-vserver-686 – XEN system with Linux 2.6.18 image on i686

とリストされるので最新版のxen-linux-system-2.6.18-5-xen-686をDomain-0とすべてのDomain-Uインストール。
（追記）下のコマンド間違っていたので修正しました。

$ sudo aptitude install xen-linux-system-2.6.18-6-xen-686

そして/etc/xen/サーバー名.cfgを編集して新しいカーネルに変更

kernel = ‘/boot/vmlinuz-2.6.18-6-xen-686′
ramdisk = ‘/boot/initrd.img-2.6.18-6-xen-686′

これでDomain-0を再起動（当然Domain-Uも再起動）すると、まったく問題なくバージョンアップしていた。

さっそくsshでリモートログインしてみたがやはり海外にあるサーバーということでコマンドラインからの操作もちょっと遅延がある。が、通常の管理作業をするぐらいならまあ問題ないレベル。Webのホスティングなどでも許容範囲内かと思う。

さて、この実験でこのブログをホスティングしているwww.saitoudaitoku.comのXenイメージを自宅サーバーからEC2に移動させても動かせることが確認できた。また以前は、IPアドレスが動的という問題があったが、その問題も最近固定アドレスも使えるようになった。

問題は、0.1 x 24 x 30 = 72ドル/月という値段だ。常時動かすサーバーを無くせるのは魅力だが、それでもやっぱりローカルのファイルサーバーは欲しいし、自宅のブロードバンドを解約するわけにもいかないし、考えてみるとあまりお金は浮かない。趣味でやっている自宅サーバーを完全に移行する金銭的にはあまりメリットはないように思う。

ただOSのイメージを送るといつでも時間課金でホスティングしてくれる環境があるのは非常にうれしい。たとえば引越しのときなど必ずダウンタイムが生じていたが、これからはEC2を使って引っ越し時やプロバイダーの切り替え時のバックアップとして使えば、ダウンタイムを無くす事ができる。

ただこの私のサーバー、ダウンタイムがあってもあまり問題にはならないのが問題ではある…。

ファイルシステムが吹っ飛んだ理由は不明。Domain-Uのが飛ぶのはloopbackデバイスがsyncされてなかったのなどなど想像もつくが（それにしてもfsckも動かないぐらいは飛ばないか）、Domain-0のはなぁ。怖いのでしばらくは様子見。

それにしても感慨深いのはこのサーバーイメージでもともとはPentium 4のWindows機のVMwareでインストールしたDebianイメージを別のLinuxのPentium Mサーバーにコピーしてしばらく（1年位かな）動かしたあと、Xenに移植してAthlonマシンでこうやって動いている。以前に VMWareによるシステム構築っていいかもというエントリーを書いたがまさにinstall once run anywareだ。

ただ、前に書いたように電力がアイドル時でも72Wとやや高めなのが気に入らない。Kernel2.6なので電源管理もやろうと思ってセットアップ。ネットで見つけたサーバの消費電力削減に対するメモを参考にして、サーバーの使用率に応じて自動的にクロックを下げる設定をしてみた。

sudo aptitude install powernowd
sudo modprobe powernow-k8
sudo modprobe cpufreq_userspace
sudo echo ‘userspace’ > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

通常の2.1GHzから１GHｚぐらまで下がってくれたかと思いきや2.1GHzのままである。

$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 107
model name : AMD Athlon(tm) X2 Dual Core Processor BE-2350
stepping : 1
cpu MHz : 2100.000
cache size : 512 KB

（略）

で、Xenカーネルが悪いのかと思い普通のカーネルで起動して同じようにpowernowdの設定を行うとすぐに1GHzに下がった。すかさずワットチェッカーで確認すると50Wまで下がっている。グレート！

ふたたびpowernowdを切って2.1GHzに戻して消費電力を見ると56Wだ。あれ？

つまりアイドル時の消費電力は次の通り。とほほな結果である。

• 普通のカーネル 2.1GHz: 56W
• 普通のカーネル 1.0GHz: 50W
• Xenカーネル 2.1GHz: 72W
• Xenカーネル 1.0GHz: 設定不可

まだ確認は出来ていないがXenのハイパーバイザーが動いている場合はCPUがフルに回っている状況になっている可能性が高い。このあたりの挙動はCore 2 Duoだと変わってくるのかもしれない。

ちなみに、差分の22Wの一年間の電気代は 22W x 24hour x 365day / 1000 * 22.31yen/KWh　≒ 4,300円なりであるので追加でCore 2 Duoを買う理由にはならない。

元環境：VMware Server on Vine3.1 (PentiumM)

新環境：Xen 3 on Debian etch(Athlon X2)

移行対象：Debian etch

ステップ１：VMware Serverから仮想サーバーのディスクイメージを取り出す

まずは、必要なパッケージのインストール。カーネルは不要だが、/lib/modules/2.6.18-5-xen-686以下は必要。またlibc6-xenがないと、”4gb seg fixup”なるメッセージがこれでもかっ！というくらい出てくるので入れておく。

$ sudo aptitude install xen-linux-system-2.6.18-5-xen-686 libc6-xen

ターゲットのサーバーを停止します。

$ sudo shutdown -h now

シャットダウンしたらVMwareコンソールからsnapshotを取っている場合はsnapshotを削除しておく。

次は、イメージの変換でVMware独自のvmdkファイルをrawフォーマットに変換する。Linux上で作業したい場合は、QEMUのホームページからダウンロードしてビルドする。ただ欲しいのは、eqmu-imgコマンドだけなので次で十分である。

./configure –disable-gfx-check
make qemu-img

Windowsで変換するのであれば、QEMU on Windows
からバイナリーを落とせばよい。

で、次のとおり変換する。出力されるサイズが大きいので要注意。

qemu-img convert -f vmdk hoge.vmdk -O raw hoge.img

そんでもってそれをXenのサーバーにコピーして適当な場所に配置する。ネットワーク経由だとこれがまた時間がかかる。

ステップ２：Xen Serverの構成

これは、Xen on etchのページを参考にした。

まずは必要なパッケージをインストール

$ sudo aptitude xen-linux-system-2.6.18-5-xen-686 libc6-xen

Domain0のメモリーを制限する。/boot/grub/menu.datを次のようにする

kernel /xen-3.0.3-1-i386-pae.gz dom0_mem=524288

xend-config.sxpの次の行のコメントをはずしてブリッジを使えるようにする。

(network-script network-dummy)

ステップ３：新しいDomainUサーバーの構成

そして次のような設定ファイルを/etc/xen/hoge.cfgとして作成

#
# Configuration file for the Xen instance hoge, created on
# Sun Dec 9 18:46:42 2007.
#

#
# Kernel + memory size
#
kernel = ‘/boot/vmlinuz-2.6.18-5-xen-686′
ramdisk = ‘/boot/initrd.img-2.6.18-5-xen-686′

memory = ’128′

#
# Disk device(s).
#
root = ‘/dev/sda1 ro’
#root = ‘/dev/sda1 rw’

disk = [ 'file:/home/xen/domains/hoge/hoge.img,sda,w' ]

#
# Hostname
#
name = ‘hoge’

#
# Networking
#
vif = [ '' ]

#
# Behaviour
#
on_poweroff = ‘destroy’
on_reboot = ‘restart’
on_crash = ‘restart’

最後に起動する。そのままコンソールが使えるのでrootでログインする。

$ sudo xm create -c /etc/xen/hoge.cfg

起動すると、新しいインターフェースが eth1になったりしているのでもうVMware Serverに戻るつもりがないのなら、新しい仮想イーサカードをeth0にする。/etc/udev/rules.d/z25_persistent-net.rulesを開いて新しいMACアドレスをeth0にして古いエントリーはコメントアウトしておく。

# This file was automatically generated by the /lib/udev/write_net_rules
# program, probably run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.
# MAC addresses must be written in lowercase.

# PCI device 0x10ec:0×8167 (r8169)
SUBSYSTEM==”net”, DRIVERS==”?*”, ATTRS{address}==“xx:xx:xx:xx:xx:xx”, NAME=”eth0“

上の、xx…の部分が新しいMACアドレスなので次回以降も同じMACアドレスになるように、Domain0上の/etc/xen/hoge.cfgに書いておく。

vif = [ 'mac=xx:xx:xx:xx:xx:xx, bridge=xenbr0' ]

最後に、 keymap.shが起動時にエラーが出るので無効にしておく。

$ sudo update-rc.d -f keymap.sh remove

これでDomainUを再起動すると移植完了である。試していないが、逆の手順でやればXen→VMware Serverも可能だろう。