Category
自宅サーバー
-
2011/3/29 火曜日計画停電にあわせて自動シャットダウンするためのWebサービス「nextteiden」
前のエントリーに書いたように、東京電力の計画停電に組み込まれた自宅は頻繁に停電するようになってしまったのでWebサーバーはさくらVPSに移動した。ただ、他にもファイルサーバーなど自宅サーバーはあるわけで、問題は自宅サーバーのシャットダウンである。いくら気を付けていても、仕事でミーティングに出てたりするとあっさり停電の直前のシャットダウンを忘れてしまう。その結果次に起動したときにRAIDのResyncなどが走り、精神衛生上よろしくないことこの上ない。UPSを検討したが2,3時間も給電するとすると結構な金額になる。しかもフレッツ・マンションタイプなので停電になったら自分だけ給電してもマンション内の電気系統は動かなくなるので自分の家だけ電源があってもダメだろう。
他にも一週間分の停電スケジュールを見て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.logwget -q -t 3 -O $OUTFILE $URL
RET=$?if [ $RET -ne '0' ]
then
echo `date`’ FETCH ERROR’ >> $LOGFILE
exit 1
fiecho `date`’ ‘`cat $OUTFILE` >> $LOGFILE
if [ `cat $OUTFILE` = 'Yes' ]
then
echo ‘date” SHUTDOWN NOW’ >> $LOGFILE
shutdown -h now
firm $OUTFILE
今、このシェルを手持ちのVMのcronに設定して１０分おきにcron起動するようにしてみた。１０分おきに最大２０分先の停電の有無を答えるので停電の10～20分前に自動でシャットダウンされるはずである。
というわけで計画停電の範囲でUPSもないような方で「これは使える」と思った方は遠慮無く使ってくださいな。
-
2011/3/28 月曜日自宅サーバーのさくらVPSへの引越し
このブログをホスティングしているサーバーは2000年以降１１年間いわゆる自宅サーバーで運用してきた。これも安定して電気が提供されていたからであって、この度の地震に伴う計画停電はどうしようもない。最近は頻度が減ってきたものの頻繁に発生する計画停電はどうしようもなくクラウドに避難。引越し先としてはいろいろ考えられるが、以下の条件で調べてみた。
- 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のメジャーバージョンアップは続けていきたいと決意を新たにする今日この頃です。
-
2011/1/23 日曜日VMware仮想マシンをSAN Boot その１
このドメインが動いている自宅サーバーは2007年にVMwareからXen移行した。その時に書いた大徳日記 » VMware ServerからXenに移植なるページは、「VMware Xen 移行」でググると２番目（最近まで１番だった）に来るぐらいの人気エントリーだったが、今度はXenからVMwareに戻した。理由は異なるディストリビューションの組み合わせの準仮想化(CentOSの上でDebian)ではたまたま動いているというのがあり気持ちが悪いことだ。カーネルのアップデートはリスクを考えるとかなり腰が重い。そういう訳で冬休みの宿題はXen→VMware移行で決定！
でもでも、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を置き換えたらネットブート可能です。
最初はせっせとROMを書き換えていましたが、このブートローダーはISOイメージでも提供されてまして仮想マシンに仮想CDを付けるほうが手軽ということに途中で気づいてしまい仮想CD-ROM Boot→SANブートとなってます。長くなったので続きは次回に続きます。
-
2009/4/18 土曜日不良セクタの直し方
直前のエントリーに書いたように、rdiff-backupを使ってバックアップ運用を始めたのだが、普段アクセスしないところをアクセスし始めたためか、不良セクタが出てしまった。 smartctlの結果は次のような感じである。
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 bytesDevice 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に戻った。実にさわやかな気分である。このディスクはスペアとして置いておいて次にアレイのディスクで障害が起きたら交換することにしよう。本当はパソコンに入れておいてホットスペアとして自動で切り替わるようにしたいのだが、もうドライブベイがないのでホットスペアは断念する。
-
2009/4/15 水曜日ご自宅サーバーのバックアップはrdiff-backupがオススメですよ
ご自宅サーバーのバックアップは、夜間のデジカメで撮った写真や動画のrsyncによるフォルダー同期、ブログの内容のMySQLのダンプといった最低限のものだった。が、最近仕事でサーバーインフラの構築についていろいろと勉強したので、もうちょっと真剣にバックアップについて考えてみた。
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のディスクイメージのバックアップをとる方法について書く予定です。
-
2009/4/5 日曜日Atomマザー+SSDのデスクトップにUbuntu
久しぶりの更新です。
昨年末に、「素敵！」という理由だけで買った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相当らしいので、それにしては少し遅いように思う。今後に期待したい。
-
2009/1/23 金曜日ハードディスク受難
先日のニューヨークのハドソン川で起きたＵＳエアウェイズ機の不時着の原因は、鳥がエンジンに吸い込まれる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を組むならスペアディスクも買っとけ
- 二重障害も起きるときはおきる
- どんなときも冷静に！
-
2009/1/12 月曜日やっぱりRAID5に
Linux Software RAID1がうまくいったのでウキウキしながら（死語？）、散らばっているデーターを新しいドライブに１日かけてコピーして集めてみた。すると1.5Tという量は思ったよりも、少なかったことを発見。また、Software RAIDに慣れてきたせいか、段々と自信がついてきてRAID5も意外に行けそうな気がしてきた。あと１つドライブを買ってRAID1にすると1.5T→3Tと容量が倍増するではないか！
という訳で、近所のドスパラ川崎店に行くと運良く新年のセールで1.5Tが12,000円弱で売っていたのでゲット。ちなみに愛用しているこの店、今月一杯で閉店とのこと。せっかく歩いて（といってもちと遠いが）バルクのドライブが安く買える店だったのに…。
さっそくサーバーに取り付ける。とここで、BIOSとLinuxでドライブの認識が違うことを発見。私のも次のページにある情報と同じであった。
SATA0 /dev/sda
SATA1 /dev/sdc
SATA2 /dev/sdb
SATA3 /dev/sddああ、破損ディスクが発生して交換するときにトラブルのもとになりそうではないですか！
現在、pvmoveコマンドでRAID1→RAID5にコピー中。電卓で計算すると13時間。とほほー。
-
2009/1/11 日曜日Debian(32bit) on Centos(64bit)
前から気になっていたので試してみました。
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として動いています。もちろん、新規インストールで入れたのは最初の物理サーバーの時だけで後は全部移植です。
うーむ、いつまで引っ張れるのでしょうか？
-
インストール済みのCentos5.2のSoftware Raidへの移植
年末に町田のドスパラを覗いてみたら、特価で1.5TのHDDが11,980円で売られていた。私の自宅サーバーには４台のHDDを積んでいるのだが、うまくしてこの1.5TのHDDをミラーリングしてHDDを４台から２台に減らしたいという欲望に駆られ、気がついたらこの1.5TのHDDを２台購入していた。
というわけで移行の開始である。移行元の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を自作して、起動するところまで行ってしまったが、この解決法に激しく違和感を憶えもう一度調べ直す。最終的には、次のページを見て解決。
このページによると、ブート時に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サーバーに仕上げます。
-
2008/7/27 日曜日Nagios
Nagiosはオープンソースの監視ツールでリモートのHTTPやSSHなどのサービスのネットワーク監視してWebでレポートしたり閾値を超えるとメールで通知したり出来る。ネットワーク以外にもファイルシステムの空き容量やロードアベレージの監視も出来るのだが、これらOSの内部情報が取得できるのは基本的にはNagiosが動いているローカルだけだ。呼び出しはこんな感じ。
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あたりに書くのだがローカルとリモートで引数の渡し方が結構違っててややこしい。以上、あまりネットを検索しても見つからなかったのでメモでした（私の検索能力が低いだけかもしれないが）。
-
2008/7/3 木曜日32bit OS on 64bit OSの準仮想化いけるみたいですよ
Xenの話なのだが、以前読んだ次のブログで64bit OSの上で32 bit OSの準仮想化は動かないと思っていた。
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。かなり遊べますな。
-
2008/6/26 木曜日VMwareやXenのディスクイメージのサイズを増やす
サーバーが増えてきたので、といってもほとんどXenのサーバーなのだが、そろそろサーバー監視をせねばと思い統合監視ツールのNagiosを導入したのだが、いきなり「ルートパーティションの残り少ないよ！」と言われたので増設。
もともと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 bytesDevice 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 bytesDevice 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出来なかった。
-
2008/6/5 木曜日My OS is still alive!!
前のエントリーで間違ってイメージを消してしまった私のXenのサーバーイメージだが、なんとまだ動いている。腑に落ちないのでちょっと調べてみたところUNIXでは誰かがオープンしているファイルを削除した場合、削除のシステムコールは成功するものの実際にファイルシステム上で削除されるのはオープンしているすべてのファイルがクローズしたときとのこと。これに対してWindowsではオープンしたプロセスがロックをとるので、オープン中のファイルを削除しようとすると「削除できません」というメッセージが表示される。
で、下のリンクのようにクローズする前ならサルベージする方法もあるのだが、loopbackデバイスのためかオープンしているプロセスを見つけることができない。
Open Tech Press | 削除したファイルをlsofで復元する
losetupコマンドでループバックデバイスにひも付いているイメージファイルのi-node番号も分かっているんだけど、復活させる方法はありそうでなかなかありそうでない。i-node番号をもとにハードリンクを作るとうまくいきそうなのだがlinkシステムコールの引数はファイルのパスのみだし…。
すでにバックアップからのイメージで動いているのでサルベージする必要もないわけだが、なんか気になる今日この頃です。
-
2008/5/31 土曜日Dead OS Running
あり得ないミスなのだがこのサーバーをホスティングしているXenのディスクイメージ(Domain-0上のフラットファイル）をうっかり削除してしまった。ちなみにこういう人為的なミスに対してはRAIDは何の役にもたたない。こんな致命的なミスは学生時代に自分のホームディレクトリーを”rm -rf”で消した時以来である。その時は、管理者に泣きついてテープの日次バックアップから戻してもらったが、今回はサーバーのイメージはVMwareから移行した際の昨年末のイメージしかない。
ブログのエントリーなど半年分全部ロストか？と思いながら、死んだはずのVMにアクセスしてみたらディスクイメージを消されたにもかかわらずいまだに動き続きている。「しめた！」と思い、まずはそのディスクイメージが入っていたファイルシステムにこれ以上書き込みが起こらないように、Sambaサーバーなどを停止。そして半年前のイメージの別のDomain-UのVMを作り起動し、aptitudeでソフトを自動更新したあと、rsyncでなぜか動いているサーバーとWebのコンテンツや設定ファイルなどを同期させた。で、動いているのを確認してルーターの設定を新しいVMに振り替えた。←いまここ
不思議なことに一晩たったあとも、死んだはずのVMはまだ普通に動いている。Domain-0のカーネルからのloopbackデバイス経由のアクセスはファイルが消えても検知されない仕組みになっているのだろうか？
もちろんシャットダウンしたら二度と起動しないことは確実である。まさにDead Man WalkingならぬDead OS Runningである。このOS動かせ続けてもいいのだが、ファイルシステム的には解放されている領域を読み書きしてるからなるべく早くとめたほうがいい。なので、しばらくして新VMへの同期を確認したらシャットダウンする予定である。これはOSの安楽死なのだろうか？
-
2008/5/25 日曜日DebianのXenカーネルのアップデート
以前書いたように、DebianのXen環境でこのサーバーを運用しているわけだが、aptitude dist-upgradeでは更新されないようなので、カーネルのアップデートは手動で行う必要があるようだ。
方法は簡単でまずは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も再起動）すると、まったく問題なくバージョンアップしていた。
-
2008/4/21 月曜日Amazon EC2試してみました
Amazonがやっている仮想レンタルサーバーEC2(Amazon Elastic Compute Cloud)を試してみた。普通のレンタルサーバーが月いくらの課金なのに対して、EC2は1時間あたり10セントの時間課金だ。サーバーで動かすOSはFedoraなど出来合いのものもあるが、信用ならんという人は自分のイメージを送ることもできる。私はDebianを動かしたいのでこのページを参考にしてDebianのミニマム・インストールイメージを転送して動かしてみた。マイ・イメージを動かすまでの手順は認証の鍵などの使用がやや煩雑だが大したトラブルもなく稼働に成功。ちなみにEC2についてはWEB+DB Vol43が詳しい。さっそくsshでリモートログインしてみたがやはり海外にあるサーバーということでコマンドラインからの操作もちょっと遅延がある。が、通常の管理作業をするぐらいならまあ問題ないレベル。Webのホスティングなどでも許容範囲内かと思う。
さて、この実験でこのブログをホスティングしているwww.saitoudaitoku.comのXenイメージを自宅サーバーからEC2に移動させても動かせることが確認できた。また以前は、IPアドレスが動的という問題があったが、その問題も最近固定アドレスも使えるようになった。
問題は、0.1 x 24 x 30 = 72ドル/月という値段だ。常時動かすサーバーを無くせるのは魅力だが、それでもやっぱりローカルのファイルサーバーは欲しいし、自宅のブロードバンドを解約するわけにもいかないし、考えてみるとあまりお金は浮かない。趣味でやっている自宅サーバーを完全に移行する金銭的にはあまりメリットはないように思う。
ただOSのイメージを送るといつでも時間課金でホスティングしてくれる環境があるのは非常にうれしい。たとえば引越しのときなど必ずダウンタイムが生じていたが、これからはEC2を使って引っ越し時やプロバイダーの切り替え時のバックアップとして使えば、ダウンタイムを無くす事ができる。
ただこの私のサーバー、ダウンタイムがあってもあまり問題にはならないのが問題ではある…。
-
2007/12/26 水曜日Xenに移行しました。
手順の確認が終わったので、週末にsaitoudaitoku.comサーバーをVMwareからXenに移植した。テストを終えて完全に旧サーバーをばらばらにして新サーバーをくみ上げたところで、Domain-0とDomain-Uのrootのファイルシステムが全部吹っ飛んで、泣きながら修復して写真のようにまだばらばらの状態で動いている。ファイルシステムが吹っ飛んだ理由は不明。Domain-Uのが飛ぶのはloopbackデバイスがsyncされてなかったのなどなど想像もつくが（それにしてもfsckも動かないぐらいは飛ばないか）、Domain-0のはなぁ。怖いのでしばらくは様子見。
それにしても感慨深いのはこのサーバーイメージでもともとはPentium 4のWindows機のVMwareでインストールしたDebianイメージを別のLinuxのPentium Mサーバーにコピーしてしばらく（1年位かな）動かしたあと、Xenに移植してAthlonマシンでこうやって動いている。以前に VMWareによるシステム構築っていいかもというエントリーを書いたがまさにinstall once run anywareだ。
-
2007/12/15 土曜日XenとAthlon X2と消費電力
さて前に書いたVMware ServerからXenに移植に沿ってsaitoudaitoku.comサーバーの移行を計画しており、新しく買ったAthlon X2サーバーも様子見のために1週間電源を入れておいたが問題なく動いている。
ただ、前に書いたように電力がアイドル時でも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を買う理由にはならない。
-
2007/12/11 火曜日VMware ServerからXenに移植
VMware Server上で動いている仮想マシンからXen on Debianへの移植作業に成功したので、手順を晒しておきます。
元環境：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-imgWindowsで変換するのであれば、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も可能だろう。
