目次
03日 サーバー修復
06日 サーバー設定 2012夏
25日 iMacros
仮想化技術があると、あわてないでゆっくり修復できる。
仕事先から 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 搭載サーバーの土台を再インストール中…
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
先日壊れてからいろいろといじっていたサーバーの設定が終わった。
他の方への参考と、自分が忘れないためのメモをかねて記録しておく。
前提：
すでに、２台の 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
スナップショットの名前の一部に、サーバー名を入れるようにしてある。
これは、dump が差分バックアップを行う際に、デバイス名をヒントに使用するため。
別のディスクだったら、スナップショットも別名にしないと混乱するってことだ。
最後に、cron.daily でバックアップを取る設定を行う。
取ったバックアップは、もう一台の土台サーバーに転送する設定も行った。
これで、一応安定運用に戻ったと思う。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今までに iMacros の話って書いたこと無かったな。
仕事などで、大量のデータが必要になることがある。
データサンプルが欲しかったり、複数部に分割されたリファレンスを手元においておきたかったり。
大抵は、wget でダウンロードする。
これは、WEB ページを丸ごとダウンロードするためのツール。
とあるページを起点に、そこから４回のクリックで到達できる範囲は全部取得する、とか、jpg ファイルに限って取得する、とか、URL のディレクトリ階層が下位の部分のみ取得する、とか、いろいろな条件をつけてダウンロードできる。
これで大抵の作業は完了する。
でも、時々 wget では取得できないことがあるのだ。
こういうツールで引っこ抜かれることを嫌がるのか、ブラウザ判別や cookie による一時キーの発行などを使って、ダウンロードできないようにしてあるページは、結構存在する。
たとえば、w3m を使う、という方法もある。
これは「変なブラウザ」ではあるが、ちゃんとしたブラウザだ。cookie だって使える。
その一方で、w3m は「ツール」でもある。
ダウンロードしたデータの保存も指定できるし、バッチ実行が可能だ。
しかし、近年 Javascript が活用されるようになり、w3m は力不足になった。
w3m では javascript がまともに動かないのだ。
というわけで登場するのが、iMacros。
これはかなり強力なツールだ。
といっても、使うことは１年に１度あるかないか。普通は wget で十分だから。
なので、使うときだけ導入して、使い終わったらアンインストールしてしまうことが多い。
iMacros は、IE、Firefox、Chrome など、いくつかのブラウザで使用できるプラグインだ。
もっとも、chrome 版はまだ開発途上で機能が少ない。
全機能が欲しいなら IE 版がよいのだろうけど、僕は Firefox 版を使うことが多い。
で、iMacros で何ができるかと言うと、名前のとおりマクロを組める。
言い換えれば、ブラウザの操作を自動化できる。
マクロを作るのは簡単だ。
「RECORD」ボタンを押して記録状態にしたら、自分でマウスなどを使ってブラウザ操作するだけ。
これで、大抵の動作は覚えてくれる。
複雑なことをしたい場合でも、自動記録で雛形を作っておいて、修正することで簡単に目的を達成できる。
しかし、これだけだとただの「自動化ソフト」に過ぎない。
iMacros の本領は、HTML の操作機能にある。
HTML を正規表現で検索し、見つけ出した対象に対してアクションを実行できる。
たとえば、特定の URL パターンを持つ画像を見つけ出し、保存したりできる。
このとき、「保存」は、ブラウザの保存機能を呼び出すわけではない、というのがミソだ。
iMacros はブラウザの動作を自動化するソフトだが、独自の動作も持っているのだ。
「保存」を行うと、あらかじめ指定してあるディレクトリに対し、あらかじめ指定した名称で（もしくは、ダウンロード URL に含まれた名称で）、すでにダウンロードしたキャッシュデータを保存する。
再ダウンロードは必要ないので、目の前にあるデータを確実に保存できる。
（状況によっては、リロードできないページと言うのも存在するのだ）
HTML を直接操作しているので、「右クリックで保存」を CSS や Javascript を駆使して禁止しているような場合でも保存が可能だ。
…禁止しているものを可能にするのだから、著作者の意向とは違うことをしているかもしれないことは胸に留めておこう。
ここから少し、iMacros の話ではなく、法的な話になる。
iMacros を使えば、「技術的には」データのダウンロード保存が可能となるかもしれない。
しかし、技術的に可能だから保存してよいかと言えば、そうではない。
データの利用条件をよく読み、ダウンロード禁止と明示されていない場合にのみ、保存が許されると考えてよいだろう。
厳密なことを言えば、「ダウンロード禁止」と謳っている WEB サイトがあったとして、その禁止条項自体の有効性には疑問がある。
WEB の仕組みと言うのは、データをダウンロードして閲覧させるものだからだ。
つまり、WEB に掲示している時点でダウンロードを許可していることになり、「禁止」と明示することに意味が無い。
しかし、規約と言うのは明文化されたものではあるが、杓子定規に解釈するものではない。
ダウンロードが前提である WEB で「ダウンロード禁止」と書いてあるのだとしたら、WEB で閲覧する以上のダウンロード行為…明示的、かつ永続的に再利用するためのファイル保存を禁じていると考えるべきだろう。
この場合、ブラウザが「メモリ上に」ダウンロードして閲覧させることや、「一次的に」キャッシュファイルを残すことは除外される。
つまり、一般的な感覚における「ダウンロード」こそが、規約として明示された「ダウンロード」に該当するわけだ。
逆に言えば、ダウンロードを禁じてはおらず、別の条項…２次利用の禁止や再配布の禁止が定められている場合は、自分自身があとで再度参照するために手元にデータを残すことは禁じられていない、と考えてよいだろう。
（ダウンロード可能であることを前提としなくては、２次利用や再配布の禁止に意味が無い）
ともかく、データ著作者の意向は守ること。
強力なツールを手に入れたとき、これは最低限のモラルとなる。
iMacros のもう一つ便利な点は、「繰り返し実行」という実行方法があることだ。
１つのデータをダウンロードして、次のページに進み、再びダウンロードを繰り返す、ということは、よくある。
普通、プログラムを作るのであれば、ループを組むようにしなくてはならない。
しかし、iMacros ではループプログラムは不要だ。繰り返したい回数を入れて、「繰り返し実行」すればよい。
かくして、100ページにも渡るデータであっても、丸ごとダウンロードして保存しておくことが出来るようになる。
初めて iMacros を使ったのは、知り合いに頼まれて、政府系機関が公開しているデータを大量に取得したときだ。
その機関では多くのデータを公開していたが、古いデータは順次公開終了となる仕組みだった。
消える前にデータを保存しておきたかったそうなのだが、政府系機関なので（？）なぜかセキュリティが厳しく、公開されたデータであるにもかかわらず、wget などでは自由に取得できなかったのだ。
最近久しぶりに iMacros にお世話になっているのは、自分の趣味のデータを保存したかったからだ。
そのサイトでは、データの２次利用、再配布を禁じており、簡単にはダウンロードできないようにしてあった。
しかし、利用許諾を見る限り、ダウンロードが禁止、と言うわけではないようだった。
再配布を警戒してダウンロードしにくいようにしてあるだけだったのだろう。
また、サイトに行けばいつでもデータを見られるので、普通に考えればダウンロードする意味も無い。
しかし、僕としては携帯端末でデータを見たかったのだ。
残念ながら、その端末では WEB 接続してサイトに行くことが難しかったので、iMacros を駆使してファイル保存する方法を選んだ。
こういうときに、小回りが利くツールがあると、ちょっと便利である。
注：もう一つのサイト側の意向としては、ダウンロードされてしまうと広告表示できない、と言うこともあると思う。
これに関しては、サイトの意向を尊重して、サイトを訪れる際には気になる広告は内容を見てみる、ということで対処させていただいている。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |