仮想化技術があると、あわてないでゆっくり修復できる。
仕事先から 80GB の HDD を借りてきて、動作を確認。
故障箇所が特定できていなかったのが、HDD 故障と特定。
今から HDD を買うなら SSD か、と考えていた。
でも、仮想サーバーの数世代のバックアップも考えると、128G ではちょっとつらい。
256G はさすがにまだ高い…
と言っていたら、仕事先の社長から次のような答え。
・128G じゃ、バックアップも考えると足りない。
→バックアップには安い HDD を使えばよい。
・２台つないだら電気も食うし、熱もこもるのでは？
→SSD は HDD より熱も出さないし電気も食わない。バックアップ HDD は、使わないときは止めればよい。
…なるほど。
なんか、妙に納得して 128G を購入。
次の悩みは、ext4 を導入するかどうかだった。
Linux のファイルシステムは、ここ数年で ext3 から ext4 に世代交代している。
ext3 は、古いシステムなので、いろいろと悪い面もわかってきている。
ext4 は悪い面が克服されているが、まだ新しいので信頼性も低いし、周辺ソフトも整っていない。
しかし、数年かけて移行してきたおかげで、そろそろ ext4 でも大丈夫、と言う状況。
なによりも、ext3 は SSD の機能をフルに生かせないが、ext4 なら対応できている。
CentOS は、6 から ext4 に対応している。
しかし、先に書いたように、6 からは仮想化方法が KVM に変更された。
KVM は CPU が VT 対応で無いと動作しない。
うちのサーバーは atom で、 VT 対応ではないので Xen でないといけない。
一応、5.8 でも「正式対応ではないが」 ext4を使える。
ただ、この場合インストール後に ext3 から ext4 に変更する、ややこしい操作が必要となる。
さてどうしよう…
と悩んでいたら、購入した安い SSD が TRIM コマンドに対応していないとわかった。
ext4 の SSD 対応最大の利点は、TRIM に対応したこと。
じゃぁ、特に意味無いじゃん、と、ext3 のまま行くことに決定。
でも、この際いい機会だから、しばらくアップデートを行っていなかった実験用サーバーの OS を、最新版にアップデートしてみる。
その後、fdisk してみたら、いろいろ壊れている。
HDD 故障で壊れたのではなく、仮想サーバーを動作させながら cp でディスクファイルをコピーしたのがよくなかったようだ。
50G もあるデータをコピーするので、30分以上かかる。
この間に、ディスクの内容が更新されるのだ。不整合も起こる。
fdisk で強制的に修復させてみたら、大量の「不正箇所」を修復して、結果としてディスクが完全に壊れた。
まぁ、少し前のバックアップはあるので、そこまで戻って起動は出来た。
さて、どうするか…
SSD をつけた新しいマシンに、CentOS 5.8 をインストール。
ディスクのパーテーションを自分でいじる。
LVM 領域から、32G を root に、32G を実験用サーバーに、32G を公開用サーバーに割り振る。
8G ほどを swap 領域にして、あとはあまらせておく。
インストール後、実験用サーバーに割り振った領域を、さらにパーティション分割。
ext3 の /boot と、同じく ext3 の root 、swap 領域にする。
古い実験用サーバーのディスクイメージを、ループバックデバイスとして認識。
パーテションを認識させ、/boot と root を dump する。
ディスクとして不整合になっていても、dump ならファイルを取り出せる。
そして、新しいマシンの LVM 領域に作った実験用サーバー用のパーティションで、restore 。
/boot/grub/grub.conf と /etc/fstab を書き換える。
さらに xen の設定ファイルを書き換え、このパーテションを phy で認識するようにさせて、起動してみる。
…ラベルが見つからない、と言われた。
ここまでディスク構造自分でいじったこと無かったから知らなかった。
ラベルを頼りにパーテション探したりしているのね。
tune2fs でラベルを付けられる、と調べて知ったので、正しくラベルをつける。
これで、無事起動。
いままで仮想サーバーはイメージファイルを使っていたが、パーテションを割り当てることにした。
これで、LVM のスナップショットを使い、安全にバックアップが取れる。
そして、今まではディスクイメージ丸ごとコピーでバックアップを取っていたが、これは時間がかかりすぎるので、dump の差分バックアップを使うことにする。
ひとまずは、これで完成。
２台の xenの土台（DOM-0）の設定が同じでないと、仮想サーバーの可搬性が落ちる。
公開サーバーをまず、SSD を搭載したサーバーに移行させてから、公開サーバー用の土台を再インストールしよう。
…と考えて、公開サーバーの全ファイルを、SSD の接続されたマシンに rsync した。
rsync にしたのは、一度 rsync 後、公開サーバーを停止して、もう一度 rsync するつもりだったから。
これなら停止が最小時間で整合性が保たれる。
が、うっかり間違えて、SSD の「公開サーバー用」パーティションにファイルを入れるつもりが、root に入れてしまった。
つまり、システムファイルグチャグチャ。
おかげで、SSD 搭載サーバーを再インストールすることに。
今度は面倒なので、パーティションを dd でイメージファイルにバックアップし、公開サーバの土台でイメージファイルから起動。
現在、SSD 搭載サーバーの土台を再インストール中…
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |