今回は、右図のように、1TBのHDD(SATA2)を組み入れる。もともと、ボロボロの80GBのHDD(以下、sdc)がバックアップ用、OSを含むマスターファイルが120GBのボロボロのHDD(以下、sdb)に割り当てられていた。それぞれ、backup、storageというVGを割り当てて管理していたが、今回バックアップが溢れそうになったこと、サーバにデータを置いてnfsで管理する方法を採ることにしたことなどが原因で、新品の1TB(以下、sda)のHDDを購入した。既存の2つはIDEであるうえ、どちらもたいした容量がないため、二つ合わせてbackupとする※。また、アクセス速度と容量を兼ね備えた新品のHDDには、storageの役割をになわせるのが最適だ。つまり
- sdaをLVMでフォーマットし、
- sdbのデータをsdaに移行し、
- sdbをbackupに参加させる
※ pdumpfsで、一時ファイルや大きすぎるファイル(動画など)を除外してバックアップしているので、バックアップにはたいした容量は必要ない
1. sdaのフォーマット
このセクションは、新しいディスクをフォーマットしたりするだけなのでサービスを動かしたままで行えるが、運用中のディスクからコピーをとるので、CDブートが望ましい。
ただのフォーマットだが、これが案外ややこしい。sdbをバックアップに降格させるため、sdbのMBRと/bootパーティションをコピーすることが必要になる。
今回の場合は、sdbはsdb1(200MB,ext2)、sdb2(120GB,lvm)となっている。したがって、sda1とMBRだけあればいい。
ここで荒技なのだが、ddを使ってコピーをとる。
# dd if=/dev/sdb of=/dev/sdaこれの欠点は、sdbの大きさ分、つまり120GBをすべてコピーしてしまうということ。当然意味が無いので、数秒で止める。すると、コピー速度が出てくるので、sdb1の大きさから、必要な部分がコピーし終わるまでの時間を計算して、その時間待つ。これで、狙った部分のみコピーできる。ちゃんと大きさを指定することもできるが、どうせフォーマット前のディスク、こっちのほうがはるかに速い。
あとは、fdiskでsda2を作成してやればできあがり。sda2はゴミが入っているので、pvcreateに-ff(force)オプションをつける。
# pvcreate -ff /dev/sda2
# vgextend storage /dev/sda2
ここまで終われば、現在VGstorageは現在1.12TBの大所帯になっている。これから、0.12TBを追い出すわけだが、ここからはオンラインではできないので、CDブートで残りの作業を進める。
# reboot
2. sdbからデータを追い出す
現在、storageはsda2とsdb2が使われているが、sdbは一度空にしなければならないので、sdbからデータを追い出す。そのためのコマンドが用意されている:pvmoveだ。
# pvmove -v /dev/sdb2
これで、すべてのLVがコピーされるまで待つ。ddとちがってLVだけをコピーするのでまだ速いが、結構時間がかかるので、-vオプションで暇つぶしをするのは必須。
そして、これが終わったら/dev/sdb2をstorageから脱退させる。
# vgreduce -v server /dev/sdb2
実際には、pvmove終了後からはサービスの稼働は可能と思われるが、念のためこのまま最後まで作業を進めた。
3. sdbをbackupにする
これで、sdb2は宙に浮いてしまった。これを今度はbackupに参加させる。また、backupの唯一のLV「backup01」を200GBまで拡大する。backup01はxfsなので、xfs_growfsコマンドを使えばマウントしたままリサイズすることができる。ひとつ注意点は、xfs_growfsは、デバイスファイルではなくマウントポイントを指定するということ。
# vgextend backup /dev/sdb2
# xfs_growfs /backup
まとめ
以上の行程を踏めば、pvmoveの時間に依存するが1時間かからずにすべての作業が完了する。割とクリティカルな端末でもLVMが効力を発揮できることが実証できたと思う。
ただ、今回のpvmoveは今回初めて使ったので、もしかしたら運用中に実行できたのかもしれない。これが可能ならば、システムを一切止めること無くディスクを増設することができるようになるかもしれない。
0 件のコメント:
コメントを投稿