以下日程でBLOGサーバを停止するかもしれません。
7/4(土) 14:00以降
おそらく当日中には復旧すると思われますが、一先ずご連絡まで。
何やったのかは当BLOGの中でのべようかと。
技術的なネタをおもに書いていこうかなぁと考えております。
以下日程でBLOGサーバを停止するかもしれません。
7/4(土) 14:00以降
おそらく当日中には復旧すると思われますが、一先ずご連絡まで。
何やったのかは当BLOGの中でのべようかと。
引っ越しの時、こんなものが出てきました。
これ、画像にも書かれている通り2004年の外部向けサーバのバックアップテープです。
当時はFreeBSDで外部向けサーバを構築・運用してたわけですが、テープバックアップを勉強すべく、見よう見まねでdump/restoreコマンドを使ってバックアップ/リストアのテストをしてみた所、バックアップは出来たのだけどリストアが出来ないと言う不具合に見舞われ・・・・人柱として使ったのがなんと本番サーバだったと・・・・・Orz
原因は/etc/fstabの記述がまずく、ブートデバイスへのアクセスがうまくいかない事が原因だったわけですが、無知な当時はそんな事に気づくはずもなく・・・・復旧できずにテープはポイっとそこら辺に捨てたわけでございますのよ(うわーん)。。。その後、引っ越しのどさくさにまぎれてテープも行方不明になってたわけなんですが、この度何と、押し入れの隅から発見されましたと。
実はそれで全てのWebサーバデータが吹っ飛んだもんだから、やけくそになって数ヶ月後、BLOGに切り替えた・・・・というのが正直な所だったりします。実に2000年頃~2004年までのデータがこの中に詰まっており、これの損失はかなり痛かったです。で、忘れた頃にこんなものが出てきたと。当時はなんの知見もなくやっててハマったわけですが、今はLinuxのお仕事を通じて、dump/restoreコマンドに関しても完全に理解する事が出来てます。そんな訳で早速このデータのリストアに取り掛かりました。
まず、dump/restoreコマンドですが、LinuxとFreeBSDとではファイルシステムがext3(Linux)、UFS(FreeBSD)と異なることから、Linuxのdump/restoreコマンドは使用できないと判断。何となくufsdumpとかあれば行けそうな気もしますが・・・・FreeBSDのサーバをテンポラリに作る方向としました。
今頃物理サーバ単独でFreeBSDのサーバを構築するのも難しいことから、既存のVMware ESXiサーバであるこのサーバ
を使おうと言う事に。メモリの残量が少ないですが、まぁまぁ当時の外部サーバのメモリなんて128MBだったので。十分空きリソースもあります。
ただ、このケースだと増設カードが一切とりつけられないと言うわなが・・・・・・・・・Orzというわけで、ケースを買いに行く事にしました^^;せっかくの休みだ、秋葉原へレッツゴー。5980円のミニタワーケースを購入しました。
あと、リストアするにはテープドライブが必要と言う事で、実は引っ越し前にオークションで落札して入札しております、DAT72ドライブを設置しました。で、ミニタワーケースに乗せ換えたこのサーバに、AdaptecのSCSI-HBAを取り付けると。VHDCI⇔WIDE68pinのケーブルを接続して完成ー・・・・・・と。
これでVMwareを起動し、FreeBSDサーバを構成しますと。バージョンはメジャーだけでも合わせた方が良いかと言う事で、4.11-RELEASEをチョイス。ただ、あまりにも古すぎるバージョンであるため(多分、4年以上前のOSなので・・)、通常のFTPサイトではダウンロードできない事が発覚^^;以下のURLにアクセスする必要があるようです。
FreeBSD-4.11-RELEASEの場合
ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/4.11-RELEASE/
これは、kern.flpやmfsroot.flpをダウンロードするだけでなく、インストーラの中で指定するFTPサイト設定も、これを指定する必要があります。もう、2.x~5.xはftp.freebsd.orgにはおいてないようです^^;
さて、インストールはちょっと時間がかかったけど無事に完了。カーネルも何とか立ちあがってくれました。
さて、テープをテープドライブに挿入する。ACTランプが点滅し、停止した所で以下のコマンドをドキドキしながら入力。
kuki# mt -f /dev/sa0 status
Mode Density Blocksize bpi Compression
Current: 0×25:DDS-3 variable 97000 DCLZ
———available modes———
0: 0×25:DDS-3 variable 97000 DCLZ
1: 0×25:DDS-3 variable 97000 DCLZ
2: 0×25:DDS-3 variable 97000 DCLZ
3: 0×25:DDS-3 variable 97000 DCLZ
———————————
Current Driver State: at rest.
———————————
File Number: 0 Record Number: 0 Residual Count 0
kuki#
おおおおおおお!どうやら読めそう!
続いて以下のコマンドを入力する。
kuki# mt -f /dev/nsa0 fsf 3
kuki# mt -f /dev/nsa0 status
Mode Density Blocksize bpi Compression
Current: 0×25:DDS-3 variable 97000 DCLZ
———available modes———
0: 0×25:DDS-3 variable 97000 DCLZ
1: 0×25:DDS-3 variable 97000 DCLZ
2: 0×25:DDS-3 variable 97000 DCLZ
3: 0×25:DDS-3 variable 97000 DCLZ
———————————
Current Driver State: at rest.
———————————
File Number: 3 Record Number: 0 Residual Count 0
kuki#
で、以下コマンドを実行する。
kuki# mkdir /home/tmp
kuki# cd /home/tmp
kuki# restore -rf /dev/nsa0
プロンプトが返ってきたら処理は終了。ドキドキしながらlsコマンドを実行してみると・・・・・あった!4年分のデータが!
あとは、このデータのユーザと同一名のユーザを別途作成し、mvコマンドを使用して移動。FTPサイトを公開し、ファイルサーバ上のInternet Explorerを経由してダウンロードするだけ!
てな訳で、現在鋭意ダウンロード中の状態でございます。当時、大抵のパッケージをTARBALLでインストールしており、そのソースのファイル数が多くて結構時間かかってますが・・・そろそろ終わるだろうと。さて、復旧したデータからこんなデータを拾い出してみました。
うわーうわー、超懐かしいね。そして、当時のウェブサイトは結構真面目に作ってたんだなぁという事も理解しました。さらに言うと、自分のホームページ開設日が2000年2月26日であることも、この画面を見て思いだしました(大笑)。ちょっと、過去の遺産を整理してあれこれ画像を拾いたいと思います・・(他にも、当BLOGの前身の前身、ちょっとした語りとかも完全な形で残ってました。ちょっと読み返してみよう。未熟な小生を)
PLC環境を自宅においてみました。というのも、無線LANルーターの出力が弱いのか、趣味部屋に設置した状態だと電波が弱く、クライアントPCとの接続断が頻発していたため。
昔買った時、確かコンクリートも通過する強力な奴として売られてたような気もしますが、軽量鉄骨(旧家)なら通るが、鉄筋コンクリート(新居)じゃぁ駄目なのか?ってことで。PLCアダプターを購入したわけでございます。
今回使用するのはIODATAのPLC-ET/M2-Sというもので、Panasonicが準拠しているHD-PLC規格のPLCアダプターです。
親機・子機のセットになっておりまして。親機を趣味部屋、子機を居間に設置することにしました。取り付けは超簡単で、以下の通り結線するだけ。
どうやら、高速に通信できるようにするには、PLCアダプターが使用するコンセント上になるだけ通信機器が接続されていないようにしなければならないとの事。その為に本来はPLCアダプター以外の電子機器を接続するコンセントに、フィルターをかましておく必要があったりします。(逆にPLCアダプターにフィルター付けちゃうと、通信信号がブロックするのでNG)
しかしこのフィルター付きタップ、滅茶苦茶高い!ちょっと良いのを買おうとすると軽く10000円超えます(苦笑)小生が購入したのは3900円ぐらいの安い奴でしたが、これが限界。で、子機の設置についてはさすがにこんなタップいくつも買ってられないもんで、断念しました^^;
先の記事でも記載しましたが、速度は無線経由でおよそ10Mbps程度。まぁまぁ、無線の通信自体こんなものかな?と。まだ有線接続の速度は計測してませんが、その内確認してみようかなと思います。
結果は以下の通り。
【サーバ⇒インターネット】
下り受信速度: 56Mbps(56.2Mbps,7.03MByte/s)
上り送信速度: 41Mbps(41.6Mbps,5.2MByte/s)
【ノート⇒WLAN⇒インターネット】
下り受信速度: 13Mbps(13.1Mbps,1.63MByte/s)
上り送信速度: 5.1Mbps(5.17Mbps,640kByte/s)
Yahoo!BB ADSLの頃は、2Mbps/512Kbpsだったのだから、劇的なスピードアップだと思います。
ちなみに本日、PLC環境を入れましたよー。意外と簡単でびっくりしました。機会があれば説明記事でも書こうかと。
今回ファイルサーバのバックアップの手法として一般的に用いられるCopy On Write機能を使用したバックアップに関して簡単に述べてみる。
Copy On Writeと言うのは、所謂リポジトリ領域を物理的に確保しておき、まずはSnapshotコマンドを使用して当該ディレクトリの静止状態(写真をパシャッと撮った状態)を作成する。この静止状態との差異をリポジトリ領域に格納すると言う方式である。
この方式の利点としては、スナップショット用リポジトリ領域を少なく作成することが可能であると言う事。何もその領域の全てのファイルを余すことなく変更し尽くすなんてことが考えられないわけで、変更の少ないシステムにおいては特にこのリポジトリは使用量が少なくて済む。
代わりに、あくまで論理的なスナップショットを作成するにすぎないので、元ボリュームに何らかの障害が発生すると何もかもが全て吹っ飛んでしまうこと、バックアップしたデータは普通どおりAgentなどを使用してリストアするしか手がないことから、迅速かつサービス維持したバックアップは可能だが、リストアは通常のテープリストアとはあまり大差ないと言った所がデメリットかと。
こうした処理は大抵スクリプトを使用する。Windowsならバッチスクリプトが良く使用される。このスクリプトを使用して、ストレージに対して各種制御命令を発行し、
を行う事になる。あまり参考にはならないが、こんな風にバッチを書くんですよーと言う感じのものを記載しておく。元々はとあるストレージに対してこの機能を試すために家に帰ってのんびり作ったバッチスクリプトなのだけど、あれこれ見られたくない所はヴォカしております。
snapback.bat
@echo off
REM 環境変数の定義
set STORSVR=<STORSVR-IP ADDRESS>
set CLIENTSVR=<BKSVR NAME>
set STOR_USER=<ROOT>
set STOR_PASSWD=************
set DEV_ID=<SOURCE_DEVICE_ID>
set TVDEVID=
set TVNAME=TMP_VOL
set TMTIMESTP=
set VOLUME_NAME=\\?\Volume{97719672-5f9e-11de-9cf5-000c2970e09a}\ (Volume Device Path)
set DRIVELETTER=X
set CLICMD=”<Storage CLI COMMAND FULL PATH>”
set MOUNTCMD=”C:\WINDOWS\system32\mountvol”
set errorlevel=0:STEP1
REM ストレージサーバへのログイン
%CLICMD% <LOGINCOMMAND> -s %STORSVR% -u %STOR_USER% -p %STOR_PASSWD%
if %errorlevel%==0 goto STEP2:ERROR1
echo [ERROR]ストレージサーバへのログインに失敗しました。
exit /b 1:STEP2
REM スナップショットの作成
%CLICMD% <CREATE SNAP COMMAND> -s %STORSVR% -v %DEV_ID%
if %errorlevel%==0 goto STEP3:ERROR2
echo [ERROR]スナップショットの作成に失敗しました。
exit /b 2:STEP3
REM スナップショットのタイムスタンプ取得
%CLICMD% <SNAP STATUS COMMAND> -s %STORSVR% -v %DEV_ID% > TEMPSP.txt
for /F “tokens=1-2 delims= ” %%a in (TEMPSP.txt) do (
if not “%%a”==”Command:” set TIMESTP=%%a
)
echo [INFO]スナップショットの最新タイムスタンプは %TIMESTP% です。:STEP4
REM スナップショットの参照有効化
%CLICMD% <CREATE SNAP DEVICE COMMAND> -s %STORSVR% -v %DEV_ID% -t %TIMESTP% -n %SPDEVNAME%
if %errorlevel%==0 goto STEP5:ERROR4
echo [ERROR]スナップショットの参照化に失敗しました。
exit /b 4:STEP5
REM スナップショットデバイスIDの取得
%CLICMD% <DEVICE STATUS COMMAND> -s %STORSVR% -n %SPDEVNAME% > NAMEINFO.txt
for /F “tokens=1-2 delims=^=” %%a in (NAMEINFO.txt) do (
if “%%a”==”ID” set SPDEVID=%%b
)
echo [INFO]スナップショットのデバイスIDは %SPDEVID% です。:STEP6
REM 作成したスナップショットデバイスをアサインする
%CLICMD% <ASSIGN SNAP DEVICE COMMAND> -s %STORSVR% -v %SPDEVID% -c %CLIENTSVR% -a <READONLY>
if %errorlevel%==0 goto STEP7:ERROR6
echo [ERROR]スナップショットのアサイン処理に失敗しました。
exit /b 6:STEP7
REM バックアップサーバ側のデバイスリスキャン
%CLICMD% <RESCAN COMMAND> -s %STORSVR%
%CLICMD% <RESCAN COMMAND> -s %STORSVR%
%CLICMD% <RESCAN COMMAND> -s %STORSVR%
if %errorlevel%==0 goto STEP8:ERROR7
echo [ERROR]デバイスリスキャン処理に失敗しました。
exit /b 7:STEP8
%MOUNTCMD% %DRIVELETTER%: %VOLUME_NAME%
if %errorlevel%==0 goto STEP9:ERROR8
echo [ERROR]スナップショットのマウント処理に失敗しました。
exit /b 8:STEP9
%CLICMD% <LOGOUT COMMAND> -s %STORSVR%
if %errorlevel%==0 goto NORMALEND:ERROR9
echo [ERROR]ストレージサーバのログオフ処理に失敗しました。
exit /b 9:NORMALEND
echo [INFO]成功しました。
これらバッチが終了したら、バックアップ処理を開始し、(ここではXドライブに)マウントしたデバイスからデータをバックアップして行く。ただ、スナップショットはあくまで論理的なものであり、あまり永続的に保持することは推奨しない(少なくとも個人的には)。
何しろ、LinuxのLVMでスナップショットを1日ほど保持した所、1日経過するちょいと前ぐらいで突然スナップショットどころか元Volumeへのアクセスが出来なくなったりしたのだから。やっぱり、バックアップが終了した後は、ストレージの負担軽減も狙ってスナップショットは破棄した方がよさそうだ。
ただ、NASで有名なNetApp Filerの場合、長期的にスナップショットを確保することを想定してかなり効率的なスナップショット機能が備わっている。この場合は長期保管してもきっと問題ないんだろうと思う。
バックアップ後に実行するであろうSnapshot破棄バッチ(雰囲気だけ)を記載する。
流れとしてはバックアップ前実行スクリプトの逆であり、
となっている。
de_snapback.bat
@echo off
REM 環境変数の定義
set STORSVR=<STORSVR IPADDRESS>
set CLIENTSVR=<BKSVR NAME>
set STOR_USER=<ROOT>
set STOR_PASSWD=************
set DEV_ID=<SOURCE_DEV_ID>
set SPDEVID=
set SPNAME=TMP_VOL
set TIMESTP=
set VOLUME_NAME=\\?\Volume{97719672-5f9e-11de-9cf5-000c2970e09a}\ (Device Path)
set DRIVELETTER=X
set CLICMD=”"
set MOUNTCMD=”C:\WINDOWS\system32\mountvol”
set errorlevel=0:STEP1
REM ストレージサーバへのログイン
%CLICMD% <LOGIN COMMAND> -s %STORSVR% -u %STOR_USER% -p %STOR_PASSWD%
if %errorlevel%==0 goto STEP2:ERROR1
echo [ERROR]ストレージサーバへのログインに失敗しました。
exit /b 1:STEP2
REM アンマウント処理
%MOUNTCMD% %DRIVELETTER%: /D
if %errorlevel%==0 goto STEP3:ERROR2
echo [ERROR]スナップショットのアンマウント処理に失敗しました。
exit /b 2:STEP3
REM スナップショットデバイスIDの取得
%CLICMD% <SNAP DEVICE STATUS COMMAND> -s %STORSVR% -n %SPNAME% > NAMEINFO.txt
for /F “tokens=1-2 delims=^=” %%a in (NAMEINFO.txt) do (
if “%%a”==”ID” set SPDEVID=%%b
)
echo [INFO]スナップショットのデバイスIDは %SPDEVID% です。:STEP4
REM スナップショットデバイスのデタッチ
%CLICMD% <DETACH COMMAND> -s %STORSVR% -v %SPDEVID%
if %errorlevel%==0 goto STEP5:ERROR4
echo [ERROR]スナップショットのアンマウント処理に失敗しました。
exit /b 4:STEP5
REM スナップショットデバイスをアンアサインする
%CLICMD% <UNASSIGN COMMAND> -s %STORSVR% -v %SPDEVID% -c %CLIENTSVR%
if %errorlevel%==0 goto STEP6:ERROR5
echo [ERROR]スナップショットのアサイン解除処理に失敗しました。
exit /b 5:STEP6
REM スナップショットデバイスを削除する
%CLICMD% <DELETE SNAP DEVICE COMMAND> -s %STORSVR% -v %SPDEVID%
if %errorlevel%==0 goto STEP7:ERROR6
echo [ERROR]スナップショットのデバイス削除処理に失敗しました。
exit /b 6:STEP7
REM バックアップサーバ側のデバイスリスキャン
%CLICMD% <RESCAN COMMAND> -s %STORSVR%
%CLICMD% <RESCAN COMMAND> -s %STORSVR%
%CLICMD% <RESCAN COMMAND> -s %STORSVR%
if %errorlevel%==0 goto STEP8:ERROR7
echo [ERROR]デバイスリスキャン処理に失敗しました。
exit /b 7:STEP8
%CLICMD% <LOGOUT COMMAND> -s %STORSVR%
if %errorlevel%==0 goto NORMALEND:ERROR8
echo [ERROR]ストレージサーバのログオフ処理に失敗しました。
exit /b 8:NORMALEND
echo [INFO]成功しました。
スナップショットのバックアップは非常に便利なんだが、使い方を誤るとデータが根こそぎ失われる危険性もあるので、注意が必要である。もし、コストに余裕があり、よりミッションクリティカルな状況が発生した場合は、Mirror型バックアップを行うと良いだろうね。
おそらく当ウェブサイトは以下の予定で完全に停止します。
停止予定:6月25日(木)20:00以降
再開予定:6月29日(月)21:00以降
今回、回線をADSL12M(実質2Mbps)⇒フレッツ光100Mbps(実質50Mbps)への切り替えを行う事にしました。その為の停止となります。
予めご了承くださいますようどうぞよろしくお願いします。
何に悩んでいるかって、先日入手してXen Serverを導入したサーバのOSをあれこれ入れ替えてみたのだけど、何故か
なのだ。確かにWS2K8R2は動かないだろうなーと思ってた。なにしろBIOS上にVirtualization TechnologyのEnable/Disable設定が出来ないんだもん。連携出来ないんだろうなぁって誰もが思うよ。
が、何故かVMware ESXiとXen Serverが動いちゃったんだろうなーと。何ともそこだけが良く分からない^^;もしかしたらVMware ESXiとXen ServerってBIOSの設定とか対応状況とか関係なかったりするのかな・・・・・・・・?
だとするとxSeries 206mをWindows ServerからXen/VMwareに置き換えた方が実は良かったりするんかいな?と思ったり。引っ越したらちょっとばかし考えてみようか・・
先日構成したNFS領域とは別にMSFC上に領域を構成し、XenServerからマウントしてみました。
当初はBLOGサーバからマウントしていたNFS領域を使用しようとしたのですが、マウントした瞬間BLOGサーバからもXenServerからもアクセスできない状態になってしまい・・・・Orz恐らくこのBLOGも普通状態に陥ったかと思われ。申し訳ありません^^;
さて、無事XenServerから別領域をマウントさせた後、試しにWindows Server 2003 R2 x64 Enterpriseを入れて見てるのですが、どうもパフォーマンスが悪い。それが左のグラフの通りで。
L2スイッチに空きがないためにL3スイッチに直付けしており・・・・その為100Mbps接続ではありますが、それでもこんなに低いスループットなのかとちょっと驚愕している所です。そういえばNFS領域にrsyncしていた時も似たような現象が見受けられたような。高くても20Mbpsぐらいが関の山だったんですよねーと。ただ、共有ディスクのスループットは限界まで行っている・・・ということは、Windows側のオーバーヘッドが相当に高いんでしょうね・・・・
NFSのパフォーマンスチューニングとかあるのかなぁ?ちょっと調べてみようかと思います。
と言うわけで、最近導入したサーバにXenServerをインストールしました。
スペックはCore2Duo T7200/2GB RAM/320G SATA HDD x2/MSI 945GT SpeedSter でございます。ラックマウントサーバのケースに無理やり搭載している形となっているため、増設カードが一枚も付けられません^^;
とは言え、オンボードでひとしきりの機能が備わっているため、特に不満を持つこともなく淡々とインストールが進められ。ある意味、VMwareよりも敷居は低くて評価しやすいと言えるかもしれません。
インストール後のLook&FeelはVMware ESXiに似てるのかもしれませんね。
で、仮想管理サーバ上にXenCenter5.0をインストールしてみました。
正直、Core2Duo T7200のIntel VT機能をきちんとMSIのこの古いマザーボードが適用させてくれるのか不安な所がありましたが、Windowsが動くと言う事はきちんとIntel VTが動いているんでしょう。ある意味らっきー(笑)正直言って、完全仮想化モードでの動作は期待してなかったので^^;
後は冷却ファンをもう少し高回転のものをチョイスしなければ・・・・壊れてしまう^^;(静穏化のためにファンを変えた所、静かになったが壊れそうなぐらい熱くなってきた(苦笑))その内、ケースを買い替えようかなぁと考えております(笑)