サーバー設定 2012夏【日記 2012/09/06】

前: サーバー修復

次: iMacros

サーバー設定 2012夏　　2012-09-06 12:11:16　　コンピュータ

先日壊れてからいろいろといじっていたサーバーの設定が終わった。

他の方への参考と、自分が忘れないためのメモをかねて記録しておく。

前提：

すでに、２台の atom マシンでサーバーを組んであった。

それぞれの上に、Xen で仮想サーバーを１つ載せてある。KVM でないのは、Atom が VT 対応で無いから。

本体に問題がでた場合、仮想サーバーは問題が無い側に寄せて実行される。

これによって、停止時間を減らすようにしていた。

仮想サーバーを使うようにしてから、ハードディスクが壊れたのは初めて。

つまり「片側に寄せる」作業すら支障が出たわけで、実際に「停止時間が減ったか」といえば、そうでもなかった。

もっとも、仮想マシンのディスクイメージをバックアップしてあったので、再構築の手間はかなり省けた。

実際に環境再構築を試みて、反省点が１つ。

仮想マシンを CentOS のデフォルト状態で入れていた。

こうするとストレージ上に LVM で論理ボリュームを構築し、その上にパーテションを作成して、インストールを行う。

つまり、ファイルとして準備された仮想ディスクに、パーテションを設定して boot と LVM が作成される。

そして、LVM の論理ボリューム上に root パーテションが作成され、インストールが行われる。

この仮想ディスクファイルの「中身を見たい」と思ったとき、以下の操作が必要となった。

・仮想ディスクファイルをループバックデバイスとして認識

・LVM のボリュームグループとして、ループバック接続されたデバイスを認識。

・LVM のボリュームグループ内の論理ボリュームを認識。

・論理ボリューム内のパーテションを認識。

・パーテションをマウント

…非常に面倒くさい。使い終わったら逆の手順で開放が必要になる。

LVM はメリットのある技術だ。LVM を使うと、物理的なデバイス（HDDなど）を、論理的なボリューム（記録領域）と切り離せる。

…話がややこしいので丁寧に解説しよう。

デバイスには、固有の記憶領域がある。これを「物理ボリューム」と呼ぶ。

ディスクの場合、パーテションが区切られていると、それぞれが物理ボリュームになる。

Windows などでは、物理ボリュームに直接データを書き込む。

システム領域を小さめのパーテションに…などと分割していると、データ領域は十分空いているのにシステム領域が足りなくなる、などの厄介ごとにも繋がる。

かといって、パーテションを分けていないと、システムが壊れて再インストールしたらデータも消える、と言うことになる。

LVM では、物理ボリュームを集めて合算し、「ボリュームグループ」を作る。

そして、ここから「論理ボリューム」を取り出して使う。

論理ボリュームは、ボリュームグループに余裕があれば、後から拡張することも可能。

ボリュームグループ自体、後から物理ボリュームを追加して容量を増加できるので、いろいろと便利。

また、論理ボリュームを取り出す際に、別の論理ボリュームの「スナップショット」にすることが出来る。

簡単に言えば、特定の論理ボリュームのコピーを作ると言うことだ。

ただし、実際にはコピーは行わず、同じものを参照するので、作成は一瞬。

ここで、もとのボリュームに変更が行われると、その時点でスナップショット側にデータがコピーされる。

これにより、スナップショット側からは「データは変化していない」ことになる。

後でもう一度説明するが、データのバックアップには便利な機能。

もっとも、CentOS のデフォルト状態では空き容量無しにディスク容量を使い切ってしまうので、この機能は使えない。

使いたければ、インストール時に詳細に指定を行う必要がある。

さて、CentOS のデフォルトで、物理サーバー（以下、土台と呼ぶ）も仮想サーバーもインストールしていると、どちらもディスクを LVM でフォーマットしている。

LVM では論理ボリュームに名前をつけて管理するが、デフォルトの名称も一緒だ。

ここで、仮想サーバーのディスクイメージを、上に書いた手順で読み書き可能にしようとすると、エラーとなってしまい、中身を見ることが出来ない。

このエラーは、土台サーバーで使っている LVM ボリューム名と、仮想サーバーの LVM ボリューム名が同じため、混乱して生じるものだ。

よって、先の面倒くさい手順に、さらにもう１手順、「ボリューム名の変更」を加えなくてはならない。

さらに面倒になった。

さて、土台マシンが不調になっても、仮想マシンのバックアップがあるから大丈夫…

と思っていたら、ことはそう単純でなかった。

仮想マシンをバックアップから起動してみたら、ディスクが不整合を起こしていた。

仮想マシンは、実験などでそれなりにデータを使用しているので、50GByte のディスクを割り振っていた。

…これは、ちょっと多すぎたと思う。でも、最初に容量を決めてしまうと、後から変更しづらいのだ。

この 50GByte を、仮想マシンを動作させたまま、コピーすることでバックアップを行っていた。

週に１度バックアップを行い、４世代前、およそ１ヶ月前のデータまで保存してあった。

50GByte のコピーには、ローカルで30分ほどかかった。

つまり、稼動しているディスクの、頭とお尻の部分で 30分のずれがある、ということだ。

さらに、コピー済みのデータは「もう一台」の土台マシンに送られ、安全に保存されていた。

土台が不調になったとき、「もう一台」のデータから仮想マシンを再起動したことになる。

結果は、先に書いたとおり、ディスク内の不整合が起きていた。

このバックアップ方法はあまりよくなかった、と言うことになる。

ディスク全体としては壊れているが、先の方法でマウントを行い、中身はファイル単位で可能な限り取り出した。

以上の状況を踏まえ、新しい環境構築を行う。

・土台マシンは LVM を使用し、仮想マシンのディスクには、各々論理ボリュームを割り振る。

　また、LVM の領域は余らせておき、スナップショットを撮れるようにしておき、バックアップ時に使用する。

　土台マシンが使用するLVM のボリュームグループ名は、念のため２台のマシンで変えてある。

・仮想マシンは、LVM を使用せず、素直に基本パーテションのみを使う。

　こうすると、土台マシンからディスク内容を見たいときは、「パーテションの認識」だけ行えばマウントできる。

・バックアップは基本的に dump で行う。土台同士のコピー速度を高速化するためと、世代バックアップ容量を最小化するため。

旧仮想ディスクは、ファイル単位で dump して、新しく作ったパーテションに restore した。

ディスクの構造が LVM では無くなり、ただのパーテションになったので、grub.conf と fstab を書き換えた。

また、tune2fs でパーテションにラベルを付けておかないと起動できない。

（fstab 内で LABEL=/boot を参照している）

土台マシンでのバックアップに、こちらの記事の dumpHanoiByDate をいただいた。

その上で、仮想マシンを一瞬停止してスナップショットを撮り、そのスナップショットを dumpHanoiByDate でバックアップするスクリプトを組む。

こんな感じ。


#! /bin/sh


if [ "$1" = "" ] ; then
echo backup [master] or [public]
exit;
fi


xm pause $1
lvcreate --snapshot --size=3G --name $1_snap /dev/VGatom/$1
xm unpause $1


kpartx -a /dev/VGatom/$1_snap


d=`date +%m%d`
./dumpHanoiByDate /dev/mapper/$1_snap1 > /backup/$1/boot.${d}.bz2
./dumpHanoiByDate /dev/mapper/$1_snap2 > /backup/$1/root.${d}.bz2


kpartx -d /dev/VGatom/$1_snap
lvremove -f /dev/VGatom/$1_snap