知らないことがあってもへっちゃらさ

.htaccess を使ってWebページをリダイレクトしよう

　うちで使っている Apache HTTP Server において HTTP301リダイレクトの必要が出てきたので、.htaccess を使ったリダイレクトの設定をメモメモです。

　記述する際のフォーマットは

Redirect permanent [転送元のディレクトリorファイル名] [転送先のディレクトリorファイルのURL]

　実際の記述例は

Redirect permanent /sample/indexhtml http://www.hoge.jp/redirected/newindex.html
Redirect permanent /sample/ http://www.hoge.jp/redirected/

　上がファイルを指定しての、下がディレクトリを指定しての、リダイレクトの設定の記述です。

　注意点としては、転送元を記述する際にはサーバーの DocumentRoot からのパスを記述すること（先頭の / を忘れない）と、行末の改行を忘れないことかな。

参照リンク
　・HTTP301リダイレクト .htaccess によるサイト移転・ファイル移動 - アフィリエイトで稼ぐためのサーバ構築スキル

Amazon EC2 のインスタンスの引っ越しをしました

　先日、Amazon EC2 Notification なる方からメールが来まして、「あぁ、Amazon Web Services の中の人ね」と思ったんですが、件名に「Notice:」（予告？警告？）ってあるし、こんなメールをもらったのも初めてなので気になります。

　メール内の単語を拾い読みすると、どうやら障害が発生していたようすです。超訳するとこんな感じ？

　あなたの使っているインスタンスの１つ以上が、ハードウェア障害の発生したホスト上で実行されています。

　インスタンス名

　該当ホストはメンテナンスの必要があり、 12:00 GMT on 2009-08-19.に停止されます。
　あなたのインスタンスもこの時点で終了されます。

　そうした場合、あなたのインスタンス上で実行されているアプリケーションがどうなるかは予測ができません。
　新たなインスタンスを立ち上げて、現在のインスタンスと置き換えることをオススメします。

　へ～、そういうこともあるんだ。まぁ、そういう話なら仕方がないので、サクッとインスタンスの引っ越しをしました。

行った作業は以下のとおり。

1. 現在実行中のインスタンス（旧インスタンス）をイメージ化する。
2. １のイメージを使って、新たなインスタンスを立ち上げる。
3. 旧インスタンスの /mnt 内をtarボールにまとめる。
4. ３のtarボールを、新インスタンスに転送する。
5. 新インスタンスの /mnt 内を４のtarボールから構築する。
6. シンボリックリンクのチェックやら、サービスの再起動等を行う。
7. 旧インスタンスで外部に提供していたサービスを止める。
8. 旧インスタンスに割り当てていたグローバルIPアドレスを新インスタンスに割り当て直す。
9. 外部からアクセスし、期待するサービスが提供されていることを確認する。
10. 旧インスタンスを終了する。

　最大の問題は、tarボールをいかにして転送するかなんですが、僕の場合Ｗｅｂサーバーを動かしていたので、旧インスタンスにグローバルからアクセスできないURL（？）を作って、新インスタンスからwgetしました。

　なおＤＢを動かしている場合は、「旧インスタンスでＤＢ停止->データ移行->新インスタンスでサービス開始」の手順をきっちりしないと、「旧インスタンスに新インスタンスにないデータがある」ってコトになりかねないので注意が必要です。

　また、今回は僕がEC2のコマンドをすっかり忘れていたため、コマンドの確認をしながらの作業でしたが、だいたい２時間程度の作業時間で完了しました。慣れれば１時間以内でもいけるかも。

そんなわけで、とりあえず一安心・・・かな？

LAN が Gigabit だからって、ファイルコピーが早いとは限らないのね

　最近、ひょんなきっかけで LAN 経由のデータ転送（ファイルのコピー）速度について調べてるんですが、「LAN が早けりゃコピーも早い」とはいかないんですね。とほほ。

なお、本エントリー内での単位の表記は B がバイト、b がビット、s が秒でお送りしております。

　例えば Ultra3 SCSI の RAID1 からの読み出しが 4.8MB/s だったり、SATA の RAID5 からの読み出しが 9.8MB/s だったり・・・。

　初めのうちは「何らかの原因で LAN が遅いのかも」と思ったんですが、書き込みだと 24MB/s （192Mb/s）くらい出てたりするから LAN の問題ではなさそうです。

　かと言って、単体の SCSI や SATA の HDD がそこまで遅いとも思えないし・・・。

そうなるとボトルネックは RAIDボード？

　確かめるにはパーツを１つずつ付けたり外したりしながら検証するしかないんですが、業務で使っている以上、ちょっと手が出せません（残念）。

　素人考えだと、RAID1 からの読み出しなら、１本なりの HDD からの読み出しと、速度的にはそんなに変わらないような気がするんですけどねぇ。あさはかでした。

　また、一般的には「 RAID5 は並列読み出しだから早い」と言われていますが、一概にそうとも言えないようです。もっとも、これが 100Mb/s の LAN だったら十分に高速と言えたんでしょうけど。

　やっぱり RAIDボードがどんな仕事（計算）をしてるのか、ちゃんと勉強した方が良いかなぁ。

　それ以外でも、先入観として「ネットワーク越しの作業はローカルより遅い」と思ってたんですが、相手が Gigabit Ethernet となると、いろいろ変わってくるようです。

　とりあえず今後の課題としては、ハード購入の際（特に NAS）には、HDD からネットワークへのデータの読み出し速度がどの程度出るのかを、確認しておいた方が良さそうです。

mbr を初期化し忘れてハマりました

　もともと Windows 2000 Server が入っていたサーバーのＯＳを、Red Hat Linux 7.3 に入れ換えて使ってたんですね。そのＯＳを Winsows 2000 Server に戻すことになりなったのが、そもそもの始まりでした。

　Windows のインストールはハード付属のインストールＣＤを使って行ってたんですが、インストール途中で再起動がかかると grub が起動してきて・・・あれれ？

そういえば mbr の初期化をしてませんでしたよ・・・orz

　とりあえずググッてみると、mbr の初期化には３通りの方法があるようで、１つめが

Windows 9x or Me の起動ディスクを使ってＰＣを起動し

fdisk /mbr

する方法。ただし、上記の起動ディスクには fdisk.exe は標準では入っていないので、何処からか用意する必要があります。ところが、該当サーバーの HDD は SCSI で RAID 構成なので、そもそもドライバが無くて使えません。

　２つめの方法は

Windows 2000 or XP のインストールディスク(CD or FD)で起動して、回復コンソールから

fixmbr

する方法であります。ところがこれって、HDD に Windows がインストールされていないとダメみたい。もっとも、やはりドライバが無いようで、

　
コンピュータにハードディスクドライブがインストールされていませんでした。
　

って言われてしまいます。で、最後の方法ってのが

Linux から

dd if=/dev/zero of=<デバイス名> bs=512 count=1
(デバイス名は必要に応じて /div/hda だったり /div/sda だったり・・・)

ってするんですが、もともと入ってた Linux は破壊済み・・・orz

　仕方なく KNOPPIX 5.1 でＣＤから起動しようとしましたが、どうも mbr に残っている grub に引っ掛かるようで、起動せず（オィ）。

　結局、CentOS 5.3 をインストールして、そこから dd コマンドで初期化しました。

　ちなみに何で Red Hat Linux 7.3 じゃなくて CentOS 5.3 かというと、単に Red Hat Linux のＣＤが手元になくて、CentOS のＣＤが手元にあったからで、特別な意味はございません。

MySQL への接続負荷をチューニングしよう

　普段からＷｅｂサービスのバックエンドには MySQL を使用しているんですが、実はパラメータをいじってのパフォーマンスチューニングってしたことがなかったんですよ。

　理由は

・	パフォーマンスチューニングはインデックスとＳＱＬの最適化で行うべきだと思っている。
・	MySQL は何もしなくても、それなりのパフォーマンスを発揮してくれるので、必要と感じなかった。

からなんですね。特に毎秒リクエストがあるようなＤＢ（Ｗｅｂサービス）でもないので、それで十分だと思ってたんですよ。

　でも、「コンマ何秒かでも早くしたい」って時がありますよね。そうなると気になるのがＣＧＩプログラムからＤＢへの接続の負荷（オーバーヘッド）です。「ＤＢＭＳを使う場合の最大の負荷は接続である」なんて話を読んだこともあるし。

　で、「接続の負荷を減らす」と言えばコネクションプーリングでしょう。なんせ、接続を維持したまま使い回すので、理論上接続時の負荷は無くなるはずです。

　でも、リクエスト毎にプロセスの起動・終了を繰り返すＣＧＩでは、ちょっとムリ。ＣＧＩとＤＢの間を仲介するサービス（デーモン）を置くしかないよなぁ。誰か書いてないかなぁ。と探してたんですね。

　ところが、MySQL の場合、パラメータの設定を変更することで、「接続に必要なオーバーヘッドをアプリケーション全体から見て無視できるくらいに小さくできる」って情報があるじゃないですか。

　と、いうわけで早速試してみました。作業は my.cnf の [mysqld] の部分に、max_connections と thread_cache の値を設定してやるだけです。

　ちなみにウチのサーバーの my.cnf には、max_connections の記述はなく、thread_cache には8が設定されていました（後で確認したんですが max_connections のデフォルト値は 100 のようです）。

　で、とりあえず my.cnf  の設定を以下のように追加・修正しました。

[mysqld]
max_connections=100
thread_cache=100

そして、おもむろに MySQL を再起動。結果は・・・心なしか早くなったような気がします（ちゃんとベンチマーク取れよ＞自分）。

参照リンク
　・[ThinkIT] 第3回：max_connectionsとthread_cacheのチューニングを行う (1/3)
　・コネクションプーリングの話 - naoyaのはてなダイアリー

冗長化の細かい話

　Seagate製のハードディスクがファームウェアの不具合によって、認識できなくなるかもしれないというニュースが流れてきました。

　事の詳細はエントリー最後のリンク先を参照していただくとして、この不具合を受けて、アメーバブログが不測の事態に備えてユーザーに、ブログにＵＰした画像を２日間はローカルに保存しておくように呼びかけているそうです。

画像保存サーバーのハードディスク不具合について｜スタッフブログ

　それで、思い出したんですけど、業務でデータを扱う際って ＲＡＩＤ でディスクを冗長化させたり、レプリケーションとかクラスタリングとかの技術を使ってサーバーを冗長化させたりするんですよね。

　この時、同一データを保存する事になるＨＤＤは、わざわざ別々のメーカーのモノを使うんだそうです。例えば、Seagate と 日立 と 富士通 のディスクで ＲＡＩＤ５ を組むわけです。

こうすることによって、故障のリスクを分散させるんですね。

　だって、全て同じメーカーの同じロットの製品で ＲＡＩＤ５ を組んでも、ほぼ均等に使用されている状態で同じ爆弾を抱えていた場合、一斉に故障するかも知れないわけですよ。それはちょっとマズイですよね。

　実はこの話、ＲＡＩＤ５ 構成のサーバーをバラした時に、ＨＤＤが全て違うメーカーの物だったんで、「もしかして残り物で組んだ？」と笑ってたら、先輩が教えてくれたんです。

　別にＨＤＤじゃなくても、あるメーカーがある時期に作った電源に不具合があって、一定期間使用したところで一斉に壊れたこともありましたし。

　ということは、レプリケーションとかクラスタリングを組む時には、ハードは別々のメーカーから調達しないと意味がないということか。

データを守るってのも、なかなか難しいものですね。

参照リンク
　・Seagate製ハードディスクのファームウェアに致命的な不具合、起動不能・アクセス不能になることが判明 - GIGAZINE
　・ハードディスクのシリアル番号確認・バッドセクタ修復・各種テストが可能なSeagate製公式フリーソフト「SeaTools for Windows」 - GIGAZINE
　・アメーバブログが画像保存サーバーに不具合のあるSeagate製HDDを使用、ユーザーに注意を呼びかけ - GIGAZINE

AmazonEC2 の OS をリブートしました

　ＡｍａｚｏｎＥＣ２に立てているサーバーが応答しなくなりました。HTTP はもちろん、ＳＳＨ も SFTP も応答しません。

　「AWS Service Health Dashboard」に障害情報が出てないかと思って確認したんですが、こちらは問題ないようです。

　て事はウチのインスタンスだけの問題か・・・。

　Firefox のアドオン「Elasticfox」で見る限りでは、インスタンスは生きているようです。

　まぁ、放っておいても状況が改善するわけではないので、思い切ってＯＳをリブートしてみました。操作は「Elasticfox」でインスタンスを選択してリブートボタンを押すだけ。驚くほど簡単です。

　ＯＳが起動してくると、無事に各サービスへ接続できるようになりました。やっぱりウチのインスタンス（と言うかＯＳ）がおかしくなってたのね。

　リブートの際、/mnt 以下の扱いがどうなるか心配だったんですが、問題なくデータを保持していました。インスタンスを落としたわけではないので大丈夫。という事のようです。

　で、肝心のＯＳがハングアップ（？）した理由についてですが・・・。これから調べます。