このブログをホスティングしているサーバーは2000年以降11年間いわゆる自宅サーバーで運用してきた。これも安定して電気が提供されていたからであって、この度の地震に伴う計画停電はどうしようもない。最近は頻度が減ってきたものの頻繁に発生する計画停電はどうしようもなくクラウドに避難。引越し先としてはいろいろ考えられるが、以下の条件で調べてみた。
その結果、さくらのVPSに決定。上のスペックで月々980円という約牛丼2杯分という無理のないプライス。とはいえ、3番目の条件である既存VMの引越しはサポートされておらず通常はプリインストールのCentOSである。普通はこれをセットアップして使う。
既存VMの引越しはサポートされていないが、さくらVPSは完全仮想化なのでOSが起動してしまえばまあどうにでもなる。というわけで2段階で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ポートが使えないこととネットワークの帯域宣言がされていることか。正式申し込みに1日ぐらい必要なので使うのを決めたら本申し込みをしましょう。
このVMのイメージは2002年くらいになんとなくインストールしたDebianをひたすらバージョンアップしたもので、今まで3.0→3.1→4.0→5.0→6.0とメジャーバージョンアップもapt-getコマンドでアップグレードしただけに感慨深い。また稼働VMもVMware Server→Xen→VMware ESX→KVM(さくらVPS)と渡り歩いてきた。今回の地震で自宅での運用は途切れたが、このDebianのメジャーバージョンアップは続けていきたいと決意を新たにする今日この頃です。
このドメインが動いている自宅サーバーは2007年にVMwareからXen移行した。その時に書いた大徳日記 » VMware ServerからXenに移植なるページは、「VMware Xen 移行」でググると2番目(最近まで1番だった)に来るぐらいの人気エントリーだったが、今度はXenからVMwareに戻した。理由は異なるディストリビューションの組み合わせの準仮想化(CentOSの上でDebian)ではたまたま動いているというのがあり気持ちが悪いことだ。カーネルのアップデートはリスクを考えるとかなり腰が重い。そういう訳で冬休みの宿題はXen→VMware移行で決定!
でもでも、VMwareで運用するに当たってはいろいろあって、
というわけで、構想としては仮想ディスクのない仮想マシンからディスクレスでアクセス。おまけに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ブートとなってます。長くなったので続きは次回に続きます。
前から気になっていたので試してみました。
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として動いています。もちろん、新規インストールで入れたのは最初の物理サーバーの時だけで後は全部移植です。
うーむ、いつまで引っ張れるのでしょうか?
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。かなり遊べますな。
サーバーが増えてきたので、といってもほとんどXenのサーバーなのだが、そろそろサーバー監視をせねばと思い統合監視ツールのNagiosを導入したのだが、いきなり「ルートパーティションの残り少ないよ!」と言われたので増設。
もともとVMwareでインストールしたディスクイメージはファイルで、ファイル=物理ディスクでルートパーティションとSWAPパーティションの2つがある。で、このルートパーティションを増やしたのでメモ。参考にしたのは次のサイト。
検閲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
ちなみにこの方法だと、変更できるのは後ろが空いているパーティション1つだけだ。本来ならpartedでやるのだが、なぜかDebianのetchだと”File system has an incompatible feature enabled”なるエラーが出来てresize出来なかった。
以前書いたように、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も再起動)すると、まったく問題なくバージョンアップしていた。
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を使って引っ越し時やプロバイダーの切り替え時のバックアップとして使えば、ダウンタイムを無くす事ができる。
ただこの私のサーバー、ダウンタイムがあってもあまり問題にはならないのが問題ではある…。
VMware Server上で動いている仮想マシンからXen on Debianへの移植作業に成功したので、手順を晒しておきます。
元環境:VMware Server on Vine3.1 (PentiumM)
新環境:Xen 3 on Debian etch(Athlon X2)
移行対象:Debian etch
ステップ1: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のサーバーにコピーして適当な場所に配置する。ネットワーク経由だとこれがまた時間がかかる。
ステップ2: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)
ステップ3:新しい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も可能だろう。
前回書いたように今このサーバーが動いているVMwareのDebianをXenに移植しようとしたものの、いろいろ試してみたが結局できなかった。経緯は以下のとおり
残念ながらdomain-0とdomain-uで別のディストリビューションをシームレスに動かすのはまだまだ厳しいようだ。とはいえ、domain-uがFedoraの場合は付属のツールで簡単にインストールできるし問題なく動く。
というわけで、domain-0もDebianにすればいいのだが、チップセットが最新すぎて動かず。今回の教訓としては以下のとおり。
2,3ヶ月したらまた挑戦してみます。